Messages

Perhaps if you do another Polybot-like project it would be a good time to experiment, but it seems wise to keep the system as is in Cogmind at this point. Maybe a 7DRL prototype would show that a more granular system is a better system, but until then it sounds like it would just add loads of dev and testing time to fix several minor issues with the risk of creating several more issues in the process.

That kinetic knockback looks so cool. Now I have more reason to use cannons (when I get back to playing, heh), and that seems like a really great way to bring in more environment interaction, which is a neat element of Cogmind I've felt doesn't come up much in practice.

It's extra motivation to go into the Garrisons, which are kinda like Hell's Arena in DoomRL. An early optional high-risk/high-reward area to test and take advantage of one's skill.

AFAICT adding new commands wouldn't break anything, and neither should removing commands not related to movement or basic interactions, given that the commands.cfg file I include with the WASDRL release only contains the keys it replaces and no more.

I noticed that the commands.cfg commands are all synced up again. Does that mean that, barring commands being removed, the commands.cfg will just work for future versions without rebuilding?

Swap mode with low-contrast filter reminds me a lot of Hyper Light Drifter.

Pay to win.  Paypal over a mere $1.00 and instantly reset core to 100.

The best thing about this one is that 100 core is a pittance, unless you mean 100%.

Pretty much. DoomRL will automatically stop the player when getting to a doorway or staircase, and IIRC when spotting an enemy, but otherwise you just keep going.

Granted, when playing KB+M with my setup I tend to just tap the keys repeatedly to move quickly, but then again DoomRL is far more combat focused than Cogmind, so I'm usually going tap, tap, RMB (to shoot), tap, tap, tap, RMB,... the whole time, with the run command mostly for quickly getting to a staircase after clearing the level.

In Cogmind I almost always move a few spaces, look around, move a few more, look around, carefully consider what to go to, frantically run across a hall into another room, wait a bit, and so forth. If I have a Sensor Array I'm also often waiting for a bit between every few moves if I see something suspicious outside, so I'm not sure how much I'd even use a run command.

I mean, it doesn't have an effect if it is set to show status, it's more that because shift+w/a/s/d produces the information for the item at slot w/a/s/d I can't use that for running, so having a key that works with wasd for running would be nice.

On the other hand, it would be easier to have something like DoomRL where hitting a key (spacebar in DoomRL by default) makes the next movement action a run.

Wait, 'r' is a hardcoded function? I've been using it for player status in my 8-way WASD keybind and hadn't noticed any issues. I suppose I should consider moving self-status to another key to allow running.

I'd defer to whatever Kyzrati or zxc say, but in my experience, you can get to the Factory and do decently well without storages, if you go for a less aggressive build. It's tricky, but my current run is nearly past Factory (-5 and well set up), and I haven't had storage since IIRC -9.

The key thing is to avoid all combat. Get flight or hover as quickly as possible, and try to find sensor arrays or visual processing units. If you get in a fight, you might be able to find replacement parts from salvage, but that's unreliable (the above build has gotten lucky several times now in that regard), so try not to get in a fight.

The only thing I could think of that would reduce attrition enough to make a storage-less combat build viable would be armor and shielding. I see where you are going with targeting, but that would require that you both get the first shot off, and have it be fatal, and that you are rarely if ever ambushed by more than one enemy at a time.

Technically there are already some other variables that might cause a desire to manually assign weapon order (hence the option in the config file to block weapon autosorting), though they're somewhat less important. Adding more variables to that equation would make manual weapon sorting almost required for even just semi-optimal play.

Are those variables just "I think my EM weapon will kill this Grunt, I should make it go first so that my Kinetic will then have free reign on the enemies behind them", or "I should cannon first to break this wall before firing anything else", or "This grenade should clear most things, leaving the assault rifles to deal with stragglers" (kindof, though granted auto-re-targeting is melee only AFAIK), or are there other things to be concerned about?

I could see the point of a utility that focuses it, though apart from "focus on core" I don't see myself using it. As for actual systems built around it, I could see that becoming a "grab left upper leg with right third finger" problem in a hurry.

Technically the DRM-free download is even more compact, at 25 MB, but Steam bloats it a bit.

I kinda noticed that earlier, since I like to play on the train on my laptop, so I tend to download it via my cell phone tether, and it's no problem. Thanks, Kyzrati.

Rebuilding from a fresh Beta 3 commands.cfg works (not sure if perfectly, it only modifies movement, pickup, info, and ally order keys), and I've updated the WASD github release with beta 3 compatible keybinds.

There seems to be a bug with transferring a complete commands.cfg from b2.1 to b3. It seems almost centered on a weird name sync bug when generating a new commands.cfg file in b3, starting at line 174:

Code Select Expand


171  CMD_BS_DEFAULT_WAIT                     "Stair/Trap Interaction (2)"    -       -       -       GREATER
172  CMD_BS_DEFAULT_WAIT_M                   "Wait (1)"                      -       -       -       KP5
173  CMD_BS_DEFAULT_WAIT_M                   "Wait (2)"                      -       -       -       PERIOD
174  CMD_BS_DEFAULT_GET_ATTACH               "Get Item"                      -       -       -       g
175  CMD_BS_DEFAULT_DETACH_ALL               "Get Item and Attach"           -       -       -       a
176  CMD_BS_DEFAULT_LOOK                     "Go Naked"                      -       Shift   Alt     p

The thing is that it still works as the descriptions would suggest, rather than the CMD_* string. I'm not even sure how the commands.cfg works anymore.

Awesome! This is like... the first report of rebind use in the wild (aside from players I know are using the automatic keyboard layout rebinding, which is a somewhat different thing).

I suppose I should have posted my WASD stuff in this thread rather than its own, but meh.

I know this is kinda the opposite, but maybe putting in a section about "when you've died and don't know it yet" so that new players know to just restart from a losing position, rather than spending 500-1000 turns desperately looking for some pile of parts to save them, and then dying even more frustrated because they didn't get lucky (I've gotten lucky this way once out of at least 6 or 7 runs where I lost everything around -7 or -6 Lower Caves, and I was in the Lower Caves because I'm still not sure where Factory->Factory exits tend to be).

How do partial traces affect squad dispatches? I almost never let the trace complete, but I often let detection happen and then bail mid-trace. Is that still hazardous to my health?

I posted this on Reddit, but I figure I'd post here as well to get more feedback and testing.

I've been experimenting with AutoHotKey to use WASD (with chorded diagonals, so W+A moves northwest, S+D moves southeast, etc.) in several Roguelikes, including Cogmind. The code and compiled AHK script with example keybinds is on Github. Just put the commands.cfg in the appropriate folder with custom keybinds set up, run the AHK script, and it should work.

The only caveats are:

• I think there is a minor issue where a key gets locked as "down". I can't find a way to reproduce it, it's only happened a couple of times within about 10 hours of testing, it only happened recently (after at least 50 hours of testing), and quite a few lines of code are dedicated to pre-empting that issue in the first place, but if it happens hitting the offending direction again will clear it up. Thankfully the natural instinct is to move in the opposite direction, which will keep the character in place while the player hits the correct key.
• Running (Shift+WASD) and Mapshifting (Alt+WASD) only work diagonally, since Shift/Alt+Any Letter does their inventory function (ex. Shift+a will pop up the info window for the part labeled a, but Shift+a+s will move 10 spaces southwest). This is because there is no way to adjust how Cogmind handles inventory keyboard keys, and if a player wanted to find info for part 'd' they shouldn't be expected to use a mouse or else simultaneously move 10 spaces. I don't know if there is a solution to this besides a mode that forces inventory management to only use the mouse. Ctrl+Shift+WASD (force melee) works in all directions.
• While the script handles pressing and releasing a wasd key quickly (within a frame or two), there is a bug where the modifier keys used are forgotten. My AHK knowledge isn't quite good enough to figure out why. For now, Modifier+wasd needs to be held down until the expected action occurs.
• Currently the only way to configure the input keys and compatible games is by recompiling, though the relevant parameters to change are at the very top. If there's demand I'll set up an ini file for this, but for now the ini file only controls buffer timings.
• Not so much a script caveat as a speed issue, but AFAIK Cogmind has no "shoot here immediately" mouse command (unlike DoomRL and ToME, which do this on right-click). This means it's often easier to use 'f' to fire even with the mouse always in one hand, especially since left-click will only target if an enemy is hovered over, otherwise it will make you move.

As for the rebinds, short version (anything not listed is unchanged):

    wasd - Movement/menu manipulation. Basically replaces numpad keys
    x - wait
    q - pick up item
    e - pick up and attach item
    c - look mode
    f - fire
    r - status
    z - item info (item under cursor (look mode)/player (otherwise))
    v - order ally
    Shift+Alt+1-4 - Coverage/Energy/Integrity/Matter modes
    Shift+Alt+g - Go naked
    Shift+Alt+f - Show volley range
    Shift+Alt+z - Intel toggle mode
    Shift+Alt+v - check ally orders
    Ctrl+PageUp/PageDown/End - Log manipulation (PageUp/PageDown/Home/End are used internally for diagonals)

Also, in case anyone is worried about accidental movement (it does use chorded diagonals, so s+d is southeast, for example. Meaning s -> s+d would be south -> southeast if not handled properly), there's a 67ms buffer where the script checks for a second key, so even sloppily going from one key to two keys will get the intended diagonal, though pianoing from one key to the next (i.e. releasing in between) will perform two cardinal movements. Going from chord to single key does seem to quickly shift from diagonal to cardinal, and I'm going to be testing that further to see if I can make sure release buffering works like press buffering can shift quickly from diagonal to cardinal, but it follows the same buffering rules as sloppily pressing two keys, so the issues should be rare. If issues come up, increase the amount of buffer frames in the ini file.

I'd say DF Adventure mode counts, especially in the more recent versions, it's just far on the Band-like side of the table.

Don't be afraid to go for early storage units. Even if you are planning to do a flying build, or similarly light build, getting a storage on -10 and dropping it on -9 or -8 after you get enough slots for that lighter build (or keeping it for a heavier one) will let you be more flexible when starting out, and if you are going for a light build, it generally requires 4+ flight units or 3+ hover units to pull off anyway. At that point, the choices are:

• Dedicate the initial storage space to flight/hover units, gambling on not losing too many weapons or power sources on -10
• Gamble on finding enough flight/hover units and other useful parts on -8 or higher. Not a bad idea, but not fully reliable
• Temporarily use storage units to hold onto flight/hover units and other useful bits found in -10 and maybe -9. More reliable than gambling later, and safer in case of mines than either other option, and allows for holding backup weapons and legs/treads if that is more immediately necessary

You mean like this?

 

I did, and it's sort of workable for the most part, but it felt like an afterthought. The way that various windows pop up and close, and just general feel of menu navigation gave me the impression that the game is clearly intended to be played with a mouse. I know this is a minor detail to most users, and ToME is generally well regarded, but my OCD/ADHD tendencies often inflate small nitpicks into bigger distractions and frustrations over time.

Oh...yeah...the mouse is pretty much the go-to inventory navigation device. I'd have to check to make sure you can even reference items directly by letter, rather than using cursor keys and enter. Granted, I use WASD & mouse (I know, such a casual. Diagonals are handled by AutoHotkey) for ToME, so I hadn't really thought of it much. I mean, I went through all the work of setting that up in DoomRL and ported it over to ToME because both games are much faster to control with one hand on the mouse, and both of their default keybind setups either require using mouse LMB move/auto-explore or having 3 arms in order to play as rapidly and smoothly as possible.

I love Vim, so I reeeeally prefer HJKL to arrows/numpad. So much so that it pretty much kept me from enjoying ToME.

Why didn't you just adjust the keys? It's not that tricky to set up custom keys in ToME (at least in ToME 4). If there's any conflicts, then I guess just change the conflicting keys to DCSS equivalents. (Note, I don't know what conflicts there would be off hand for HJKL, my setup for ToME and DoomRL is based on WASD and some AutoHotKey trickery).