Messages

A slightly related problem is being able to identify prototypes based off leaked information while inspecting them. I can tell what a thing is gonna be before I scan or equip most of the time by just examining it and looking at the mass.l

I see that as you knowing the variety of parts well and having a mostly full gallery, not a problem.

Alrighty, looked into this today while working a new feature as part of a request, and made a new discovery. It's not really a bug, just an inconsistency, because you can already control this behavior via the options menu! It's under the Default Image section, where you can select "Background." As per the context help there, it applies to new images (including resizing) as well as post-cut areas.

Aha!  Thanks for the patch.

:OOOOOOOOOOO

*Big Thumbs Up*

Seconded!

Thanks for the quick feature add

Another thought: I wasn't Alt-Tabbing at all in the lead-up to this bug, but I was dodging and avoiding enemies quite a lot, along with toggling parts accordingly.  Perhaps the types of input sequences that trigger this bug are more common in stealth gameplay?

Hurray, I can use an official non-patch release again!  (Also new features! )

Ooof, timing would throw a wrench into things.  I can't easily reproduce that, especially now that I know where I'm going!  And even trying to get the exact same sequence despite robot movement variation would result in being shot to pieces...

It may well have to do with mouse input; I do use the keyboard for some commands, but I use the mouse extensively both for common commands and for triggering labels on things I want to screenshot (like the entrance to 7 ).  Mouse input is also harder to reproduce precisely from memory, which doesn't help matters.

Anything you could do to repeat this would be great! It shouldn't really have much of anything to do with game logic, so what save you use may not even matter, but certainly keeping as many variables the same as possible makes it more likely to reproduce the same situation, just in case.

Hmmm, turns out that the post-bug save won't reproduce it (possibly some elements of the DC data load showing intel labels even if the player doesn't have the secondary log in intel mode, some state carried between maps, or heavy dependence on mouse positioning during my initial broad Shift+mouse look around to see roughly where I was on the map).  And the pre-bug save has too much random variation of robot behavior in between the saved point and the bug occurring to get the exact same command sequence to even be accepted and result in the same UI state - different wander paths of neutrals result in hopping at different points, and so forth.  Plus in between that saved point and the bug occurring I earned the achievement one would expect to immediately precede a first visit to 7, and that impacts UI state too...  Other than that the pre-bug save is exactly what I loaded up when starting that session (I fished it out of the daily backups), but that seems to be enough to prevent reproduction.

Oh, and I forgot to address this:

Of note in the run.log is this line:

W=0316075 |   BS::placeMachine() | Terminal at (22,72) has more targets than CMachine can display at once: 26

What a juicy terminal for a flight hacker!

Nothing special there, that's actually not too uncommon. SL3 terminals may sometimes fill up all their slots, and maybe even have too many to show because there are so many possible hacks now and they can only do up to 26 (a~z), in which case they simply can't make all their direct hacks available

Haha, I don't dive into the run.log file very much.   Good to know that that's not the cause.

Ah, I see.

Ideally this would happen to me sometime, so that I can just attach the debugger and closely examine the state, but so far I've never seen it xD (having the game produce enough of the right diagnostic data to reliably debug it remotely would be tough). As for others who encounter it, they'd have to remember their exact sequence of key presses before it happened, and be able to repeat it, before I could possibly do so here.

Would a sequence of keypresses from entering the map suffice?  It was so close to the start of the map (I literally made one move to get my sensors to activate and DC to load up, then looked around) that I remember what I did from that point pretty well.  I could try to reproduce it from the pre-lock save (which has the problem that there's an enemy in between who may or may not hit, possibly changing the build), or from the post-lock save, or just say what I did.

Thanks for reminding me of that thread!  That would indeed be workable but annoying (against the principle that players should not be driven to external tools for optimal play), and AAs are in fact the only place where the problem presents itself (prototypes all either falling under the normal risk-reward system of formal identification or being guaranteed good and thus safe to put on).

Player-assigned tags would definitely be nicer, though may or may not be much harder to implement.  I think it's a new text field attached to each one (directly or indirectly) either way, and the question is the difficulty of letting the player specify its contents, though I'm not sure if that's the case in the underlying architecture.

Update: the "friendly" End Task (the one that gives the process an opportunity to clean up) through my computer's Task Manager sufficed to shut down the game, with the "hibernating" sound played.  No crash log was generated.  Attached are the following:

• the automated backup save from before this game session, which hopefully allows reproduction just by heading over to 7;
• the final save produced when quitting by force;
• the run.log for that session.

Of note in the run.log is this line:

W=0316075 |   BS::placeMachine() | Terminal at (22,72) has more targets than CMachine can display at once: 26

What a juicy terminal for a flight hacker!

Are there any more diagnostics I should try or files I should include before starting the game back up?

I've just entered 7 for the first time and I wanted to start by looking around the map (since I have DC).  To get consistency in my map movements, I used the Alt + arrow key system to move, and I took screenshots every so often for later reference.  This worked at first, and then suddenly stopped working.

I have tried:

• pressing relevant keys (Shift, Enter, Alt, arrow keys) to ensure they are not stuck;
• ensuring that the issue is not with my keyboard or mouse by using them in other applications;
• escaping to the menu (doesn't work).

I am hesitant to try restarting in case diagnostic data (possibly beyond run.log) would be overwritten by doing so.

The game does not:

• respond to movement commands, whether by mouse or keyboard;
• respond to map movement via Alt+arrows or Enter (Shift+mouse still works, oddly enough);
• allow parts to be activated / deactivated / cycled as a slot type or reassigned using the mouse (no drag-and-drop animation shows up);
• allow parts to be equipped (ditto);
• allow for the primary log to be expanded, the secondary log to have its mode changed changed, the inventory to be sorted in any way, or the part status display to change modes (though for all of these the "you've moused over something" animation and SFX still plays, as with the previous two);
• respond to right-click examine or "s" status;
• open the world map, whether by mouse or keyboard.

The game does still:

• autosave;
• play corruption glitches;
• animate off-map intel labels (such as machine locations);
• open the Scan and Evasion windows on mouseover (though labels do not display whether from the Scan window or by their keys);
• display pathfinding to the cursor as the mouse moves.

I'm really not sure what's up here, and since the game isn't crashing to desktop I may not have a crash log.  I think I do have to shut it down by force now, but if you have any diagnostic requests let me know!

Some roguelikes with more complex identification minigames have both formal identification systems (where the game explicitly tells the player the name of the item after some work) and informal identification systems (where the game does not explicitly tell the player the item name for their work, but the player knows the name or at least under what circumstances to use the item).  These games can allow players to "tag" informally identified items with the player's suspected item name, or other very short notes such as "throw at enemy".  (Without telling them if they're wrong, of course!)

Cogmind by and large works very well with only formal identification, in that the identification tradeoffs are interesting and well-balanced.  (Do you want to risk that prototype being faulty?  Do you want to spend time and matter putting on that unknown item to restore your memory of what it is?  Do you want to spend time and inventory space taking either to a Scanalyzer?)  However, there are a few cases in which sufficiently experienced players will both already know what an item is without formally identifying it and run the risk of confusing it with another item unless they spend resources on a formal identification.

Some examples, which spoil late-game rare items

Prototypes where only one item exists with the properties shown before identification do not count; players who have seen them before and have a good idea of the items in the game will be able to re-identify the item as needed by those properties.  The primary place this comes up is in consumable Alien Artifacts, many of which have the exact same such properties and are instead informally identified by the context in which they are acquired (accompanying machines and/or terminal logs).  Since several of these have good reasons not to use them immediately, this is an annoyance.

For example, a player might find a Dimensional Node Initializer in the caves (and recognize it by the accompanying log and the hideaway layout), get the Transdimensional Reconstructor from Zhirov (ditto), and then want to use the Transdimensional Reconstructor to escape a bad situation before they have had an opportunity to reach a Scanalyzer.  Now they are stuck guessing which is which if their inventory has been rearranged at all in the interim, and since they're probably being shot at they run a real risk of winding up at the center of a node explosion!

Another case is when a player finds a Core Reset Matrix in Quarantine and does not want to use it.  They know for a fact what it is by the very distinctive machine layout, but in order to recognize a future one in the same run they must lug it to a Scanalyzer only to drop it (and are likely leaving something else behind to make room).

[close]

I understand why art isn't shown for unidentified items, and the costs of identifying do make sense in most cases, but in these instances it makes more sense to me that the Cogmind would be able to tag an item appearance with a short name and recognize that same appearance later, even though that appearance is not itself shown to the player.

I also understand if this would be difficult or impossible to implement, but I thought I'd bring it up.

Another creation, this one animated!  Cogmind players may have a good idea what's going on here...



I've also started my own (spoilery!) thread for the prequel project, including a post in which I discuss some of the animation choices I made in this piece.

Yes, there's a reason I preemptively stuck my tongue out over it! XD

Trying my hand at animation, here with scouts reporting back that they found Zhirov and Zhirov is not very happy about it:



This came out of testing a "zone of control" mockup and noticing from previews that the idea was complex enough to require multiple mockups to properly introduce.  So I wanted to first depict a situation where robot transmissions were important and very visible (to show why zone of control matters), and discovering Zhirov is a great event for that.

There are a lot of attention-getting HUD animations because I wanted this type of event to get noticed even if the player is looking at a different area of the map, or doesn't have the map visible at all (because they have one or more menus fully covering it).  Zhirov's visit to edit MAIN.C's memory also makes a good way to introduce players to the possibility of invasion alerts, because Zhirov isn't quite as hostile as the later invaders, but the strategic choices the event offers the player are large enough to warrant the alert.  (Later invasions will generally come after the player knows about the invading faction, so their hostility should be clear.)

In making this, I also noticed that the prequel is more reliant on its logs than Cogmind, and so the log text animation must be faster.  Indeed, it's not even necessarily meant to be perceived as an animation in gameplay, as long as it does its job of getting players to read the logs; several of the UI animations shown here follow the same principle of being informative and fast over being flashy.

Regeneration / Integrity Siphon
Equipped parts slowly regenerate (faster with higher alert) (this would give negative score bonus) (mutually exclusive with all other challenges)

If they siphon from your core, that could actually be quite dangerous in Materials... but yeah, if you manage to set up a good flight stealth build despite that you're basically set to win.

Another idea:

challengeLoudAndClear: The Cogmind constantly emits IFF bursts, alerting nearby bots to your position.

Maximum BOOM: Win in April Fools' Day mode.

( )

Since we're on the subject of terminology for the coverage / exposure mechanics, some remarks from my experience:

• When I first read the manual (shortly after hitting Factory for the first time), the distinction between part coverage and core exposure did serve to emphasize that parts cover and protect cores, which suits the tactical lesson that should be imparted to new players about keeping slots full.
• However, having "core exposure" potentially refer to both the static value inherent to the robot core and the calculated chance of that core being hit when the whole robot is hit is confusing; I myself didn't know exactly how the buff to core hit chance for piercing damage worked until I read this thread.
• In my prequel mockup series, where these values are not static because the player can design parts and cores alike (though tiny cores are expensive), I did change this to suit the game: coverage is always the value set by the part / core design, while exposure is always the calculated chance to be hit when the robot is hit, and is not defined without a specified robot.  (And yes, I did calculate the static value for Engineers from their exposure % and part coverage. )

Your call on what terminology is best for Cogmind.

Okay, okay, it was system corruption instead of a logging failure. XD

Haha, I went to make the change just now only to find that I had already gone through with plans to do this just before the Beta 1 release, so for the past year we've actually had a dedicated RNG specifically for hacking. And it's a high-quality RNG, too, so really this is pure variance... Nothing the can be done about it beyond this aside from actually fiddling with the results to make it not fail (or succeed!!!) so much in a row, but that's not really a great road to go down.

Haha, good job, past Kyzrati version.  (Except for logging that this was already done.)  XD

Yeah, fiddling with the results would be the opposite of helpful here.  Might be my knowledge of probability speaking, but I like knowing that the probabilities are always as stated and I can calculate streak chances on my own using that.

This would be fun to have!  Since Cogmind has very distinct regions, we might also want the graphs to indicate progress through the game world; perhaps changing line color as the world map does?

Are you intentionally wanting to retain a true (255,0,255) base layer for some reason?

Yes, for the reason that sometimes I start drawing on the base layer and then realize I want to put something underneath it, which is far more convenient on transparency than true black.

I've marked this as "minor" because for now I'm working around it by doing my resizing before any drawing and then generating a new layer to replace the original base layer.  Mostly I wanted to let you (and anyone else who might want to ensure a transparent base layer) know about the behavior. 

This is something I noticed while using the new color channel application options on one of my mockups; I can create a new image for the transparent base layer background, but when I resize it to the usual mockup map size (necessary because the map is only 50 cells high) the base layer background turns black again.

Bugs with random components are generally a nasty sort. XD

Heh, coming up with taglines before the name?

Well, the taglines are sticking before the name!    And in this case, "bring your world to life" fits quite neatly into my trailer plan.

Yeah allowing players to summon them as the only way they arrive offers a nice choice, but really any game can become so much more, or something very different to different players, once you add 100% optional content like that, and the amount one can add is almost limitless given unlimited time and resources, or a game that is purely a thought experiment anyway

Sufficiently open and sandboxy games are like that as a genre, and in this case I'm fine with it because player-designed robots are going to make the game very different to different players anyway, even among players who do intend to fight the Sigix.

(Lore-wise, technically the Sigix could arrive anyway, looking for their lost ship that never reported back )

Yes, once you signal Earth to provoke the sending of that ship you would logically be on something of a clock, so you want to make sure you come out of taking down that ship with enough research and manufacturing power to quickly exploit Sigix technology - as with the rapid expansion of Complex 0b10 - but what about players who just never signal Earth?