Messages

Wait, you said you uploaded it on GitHub and I assume there was a link, but I don't see a link. Or were you planning on doing that later? (And hopefully it's got the original Burnt on their as the starting point so it's easy to quickly browse all the changes, yeah?)

Oh that's pretty cool... I will again admit I don't like the current new theme, though it was the best free one I could find that didn't need more than an hour or two of tweaking, and the idea is that although I'd love to have a really nice one like we did before the SMF/PHP update, I also didn't like the idea of putting time into something that would likely at some point be ruined yet again / require a ton of maintenance one day, so wanted to avoid custom solutions and prefer a drop in, which Burnt mostly serves as.

I could at least check it out and throw your mod up as an option on the forums. Will have to see when I've got time for that...

Ha that's not Beta 14, or even Beta at all, that's just SDIs doing normal SDI things

They were built this way from the beginning, it's known and not an issue. Ideally they could be rebuilt using Cogmind's newer systems that would allow finer control, but I decided to just leave them as is for now (there are some advantages...).

In this particular encounter the Derelict has just somehow taken possession of 0b10 bots. Derelicts don't really do that to other derelicts, or at least it's not a theme in Cogmind.

I like it! It's an interesting idea for theme, although one with little impact in the bigger picture since most of the time whatever they assimilate is quickly killed by whatever else they're fighting, combined with the fact that even if they survive, the are easily separated from other bots due to their speed (since they're not really meant to lead other types of bots, only follow bots or work with others of their type).

Such an action would also have to treat different assimilated bots differently (if the goal is to add some new flavor), since some types of things they assimilate would not realistically have a purpose to follow them, and should be doing other things.

Overall probably not worth the trouble compared to what is gained...

But instead, what do you think of making it such that manually swapping any weapon behaved like launcher swapping, without distinction of type? My thinking is that statistically, the main reason I manually use the / command to swap a weapon is when I want to use this single weapon (as a digging tool mostly) without activating the whole volley. Most other weapon equips I do are either auto replace from the ground or inventory or auto equip in the first empty slot (but I don't use the modal view, where I assume it's more widespread to equip missing weapons using the / command).
That's why I think it would be better if it behaved that way:
- Make launcher behavior the default for all weapons when manually swapping with /, keeping normal behavior otherwise
- Auto use the Cycle command when Reswap concerns a weapon pair (because we assume that a player Reswaps a weapon only to unequip a digging tool or lone-use equivalent and would have used Cycle to reactivate all weapons after that)

Wow that sounds super extreme xD

Like.... I'm using '/' all the time for swapping, and it's often not for just one weapon. Lots of people do in many situations, another common example being switching to different damage types for different encounters. Or sometimes of course just switching for other reasons, but it doesn't have to be just for a single lone use. Digging is an important exception, I'd agree, but it's kinda hard to generalize that, and cycling seems to handle this quite quickly. If you're not in combat as much you can even typically keep all your weapons cycled off, so that swapping for temporary use of a digging tool, for example, is that much simpler.

Overall I think there are definitely some possibilities for finer control that might better suit a given player or even specific build type, but they get complicated to add in and stuff like that is probably only likely if there is more interest. Would have to get others to back such a feature and hash out the details. Doesn't look likely in the near term.

Oh actually that's not the bug, the scoresheet/history is right, they're supposed to be Unaware, but because the Mutant was set to a Derelict type, the other bots in the encounter were also picked from Derelict types. They're supposed to be 0b10.

Not a bug because this is for an non-public incomplete prerelease version (and that feature has yet to be completed as well ). It seems in that case you are a patron and you can read more about this on Patreon, specifically the most recent X2 release post which also covers some of the remaining features before it goes public. As stated when X1 went out, there are still many things to do with regard to those changes, only the absolute minimum was implemented for experimental testing purposes!

(Note: For prerelease-specific discussion we use the patron channels on Discord, or you can also leave comments on Patreon itself.)

- Double tapping the swap key / to swap the last pair

Note this is already possible by using the Reswap command (Spacebar+r, or Shift-Alt-r).

Double tapping already has the purpose of closing the swap menu, and aside from Spacebar+r you can use the 'Y' option to reswap to a previous part, though yeah this latter one requires first selecting the source part. It is, however, more flexible overall.

Does seem like an interesting alternative idea though to make double '/' do the same thing as the existing Reswap. I would be kind of afraid of people accidentally swapping things if that is possible, though if it's only a manually enabled option that wouldn't be a problem...

What do you think about the current Reswap option?

- Option to always auto activate all inactive parts of same category when swapping (to a digging weapon for example)

This is probably too complicated? Or at least you'd have to be able to define more specifically what it is you want it to apply to. Like right now we already have this option with launchers, but that's a very specific applicable category, whereas "digging weapon" is very vague.

You probably already do this (?), but using the cycle command is really effective for this purpose, either by clicking on the button or using the ' key.

- Press swap button, then CTRL (or SHIFT) + choice to swap and disable all other parts of category, only keeping swapped one active

Again I think this is best approached using the CYCLE button or ' command. No need to really add yet more commands for this particular thing which can already be achieved in a similar amount of time.

Yeah this is normal behavior. Not all sensing is equally accurate, because not everything updates at the exact same rates, but certain actions can force updates at different times.

Yeah Beta 15 adds machine intel if you know the map, but not the other way around. The purpose for the new QoL feature is purely so that you have easier access to knowledge about known machines outside view, since markers are shown at the edge of the screen. There is no similar need to show machines (not to mention problems it causes)--simply turn on intel markers if you want to know their locations.

Three hours! That's how long it took to properly track and fix this considering how unusual the conditions ended up being xD

Good timing on this at least, since I normally don't use this particular hack so never really had a chance to encounter it, but saw it a lot during my stream and realized while fixing this that it was due to a new Beta 15 feature that automatically adds machine intel for those within terrain revealed through other means such as Layout(Zone), which is something I do a lot and that's why I was confused my intel kept turn off in my recent stream (this would've started happening to a lot more people if it went public with Beta 15 without the fix...)

Whelp spent almost two hours debugging this today and couldn't find the cause, but did learn a bit more about it for now.

It's definitely new in Beta 14, and related to the inventory changes where somehow it's possible for the inventory to not redraw correctly upon restart from game over. Unfortunately the actual crash itself (and therefore the trace data I have) doesn't occur until later when trying to use the inventory, rather than during it's initial partial failure to initialize/draw, so I'm not sure when that's occurring or why. I checked all the related code and didn't come up with anything, so it is probably something extremely convoluted and it'd be nice if we get some more reliable info on a cause. Guess this'll have to remain in there for now until then, but at least it's just a quick restart of the fresh run in that case...

I don't have many details on this, but there is apparently a very rare issue that can occur upon starting a new run immediately after a loss.

The inventory window does not appear correctly and attempting to interact with items will crash the game. anting reported it on Discord and shared an edited screenshot (attached) to give an idea--basically the inventory is missing its border (a clear indication of having not actually completed its initialization for some reason).

It would be some sort of timing or input-related issue, but no idea beyond that. There's no serious impact on play (other than initial confusion ), since it's right at the beginning of the run and restarting the game will of course return everything to normal, but it would be nice to know exactly how to cause it so it can be resolved. Save data/state would not be helpful here, it's just some specific input steps...

(Edit: I posted this before looking through my data as I try to clean up new issues in Beta 14, and it's looking likely this issue actually did start in Beta 14, and has hit a few other people who didn't report it but are uploading error data. It's likely related to modal inventory in combination with a particular input sequence I haven't been able to repeat yet. Investigating more...)

Ah great and thanks for getting back to update the report!

Ha, you're right I have been--don't normally use seeds myself, if I was doing more runs and not playing special modes lately I guess it would've become pretty obvious

Not a bug though, would consider it a feature request (moved to the appropriate board with a new title) since this mode is generally for more advanced players and the log is hidden by default to begin with. This was actually on my list to consider when the mode was created, but it's rather problematic to automatically review earlier messages, and goes beyond the intended feature set of the mode behavior so I didn't add it. (Would likely end up requiring a whole new type of log notice. It's on the future potential QoL list, which is still incredibly long...)

And technically it's not just this but other things that can appear in the log early on may have the same behavior. I might expand it with new functionality some day, but no plans for that right now. What might be more likely to spur me to action is if it ends up confusing people using old saves with new versions, but players who use this mode tend to not have such issues.)

That's okay, no save necessary since this is a special case and Freighters use custom AI that is allowed to change its destination under some conditions, and it is separate from the advance Swarmers which are just running on a more standard routine and have no direct connection to the convoy. Their standard consistent behavior only really applies to active Garrisons.

Depends on the part, but you can use 'v' to toggle weapon range view (which comes with other features, too, and is the same thing as clicking on the little 'v' button under the Volley window). And for ranged utilities you can usually toggle them off and on again to have an animation that shows their range (since toggling is a free action).

There are indeed at least a couple new ways it can accidentally get turned off, haven't gotten a full list of them yet but noticed it myself during play, will add this to the list to check!

No that's fine, just means it doesn't want to do anything after the other weapon, doesn't really matter what the other weapon is hitting (even though yeah in Cogmind you can't follow-up in such a case, but that's a mechanical thing not a lore thing!).

Ha that would definitely get one's attention xD

CS out here trying to foil your specialist plans

(Melee specialist is not too hard to get with speccing into melee right away in Materials with hammers and maces and going from there--quite powerful, even. Any specialist achievement is tough to get if you don't start with it immediately, unless you were pacifist much of the time before starting anyway...)

Ah quite right, there is an issue with the code after integrating the new sword with the disruption system, good report!

Log excerpt (for some reason the [tt] tag isn't working) :

Newer versions of SMF no longer support the [tt] tag (though reportedly original posts that still use it are okay). Would have to add a mod to manually to restore [tt] functionality. Apparently the developers say you should instead use "font=Courier New", which is... sort of a weird approach since not everyone necessarily has that font.

There is also "pre", which still works for most of the same situations while not quite being the same thing, though I used to use this a lot years ago.

You just can't inline it like you can with [tt].

It is indeed a special cannon-type attack, yes

Normally you wouldn't necessarily know this across an entire run of data, though yeah you could pick it out in specific types of runs if attentive...

Yeah this is known and just how it was built, since what it can show expanded significantly from when it was first created, but despite the increased variety in its content, it's not always checking every possible aspect in order to avoid excessive calculations which would only rarely catch an extra special case. Ideally it would be rebuilt from scratch, but I'm not planning to do that since it doesn't come into play often enough and putting the cursor on different objects is generally changing it all the time anyway (especially with mouse users, which are the majority of players).

I think you're the first person to notice and report it in years, but thanks we'll leave this record here for reference. Funny thing is most frequent players don't even use that window at all--I am one of the rare ones who likes it, though I haven't been in a situation where this particular content issue mattered in my runs before.

It's technically possible (as you can see ) under special circumstances, specifically when a non-combat ally knows about an enemy that it learned about from some other ally but you don't know about that particular enemy, and it's sending that info to other nearby allies. So it ends up being fairly rare.

It seems like kind of a strange behavior so it'd probably end up being removed if enough people do notice it and think it weird, but this has always been a thing and it's rarely pointed out (this is only like the second or third time in the past decade?).