Grid Sage Forums

Grid Sage Forums

  • June 24, 2024, 08:57:00 PM
  • Welcome, Guest
Please login or register.

Login with username, password and session length
Advanced search  


LINKS: Website | Steam | Wiki

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Kyzrati

Pages: [1] 2 3 ... 174
Yeah I already fixed it some weeks ago for Beta 14. This was reported and discussed with newer players on Discord earlier.

Edit: I didn't add it to this list yet because I haven't yet transferred over my own changelogs for the past 6 weeks or so, was actually going to do that today or tomorrow but I'm in the middle of debugging some other newer Beta 13 issues right now :)

Fixed Bugs & Non-Bugs / Re: [Beta 13] Thief drones not moving
« on: June 01, 2024, 07:16:46 PM »
These aren't bugs, they are standard pathing behavior for adjacent robots during combat, which will wait if they're blocked by an adjacent bot that is currently occupying their most advantageous direct path.

You can see the same behavior around doorways or obstacles when fighting enemies at close range, which is why that works as a tactic to begin with.

There will be some occasional alternative behavior coming in Beta 14, but this is all normal.

Fixed Bugs & Non-Bugs / Re: [Beta 13] Zh not tracking
« on: June 01, 2024, 07:11:55 PM »
This isn't a bug, they don't actually get free tracking info when they're attacked, and have to look around. They may or may not find you in time :)

Fixed Bugs & Non-Bugs / Re: [Beta 13] Sv doesn't flee (spoilers)
« on: June 01, 2024, 07:01:22 PM »
Yeah his guards will not always leave with him, it can happen under some conditions and is fine. Always been that way.

Yep this isn't a bug, it's just their behavior, they need to be properly cleared by a Tunneler for the Complex to consider it an official part of their structure. (Note how Engineers actually special log text for doing that.) It's always been like that for the past 10 years, though wasn't nearly as often noticed before so maybe I'll make an exception now that Subcaves are a thing.

Yeah I recall that one, and have noticed it a few other times as well, chalking it up to spotting an exit that was previously known before using the chutes, which is what I thought must be causing the bug, and where all my testing efforts were focused, but I have seen absolutely no evidence of it in the code, regardless of whether it happens in releases xD

Yep, my first inclination purely from the logic has been Linux-only, but that wouldn't make much sense given its nature. Of course if any other Linux players are happy to try it out from here and confirm that'd be fine, too :)

There is no "grab the stairs sprite from outside the game." This would be some other sort of game-specific memory state issue.

Testing in an actual release build would be the next step to confirm, but that takes even longer and there's also nothing unique about release builds in this regard so is assumed unlikely to turn up anything. To that point, unfortunately by now I've already put waaaaaaaaay too many hours into this for what is a very unimportant issue, so I've decided it will live on forever! Pretty rare that that happens, but it's both rare and inconsequential so that's okay. I'm pretty curious about this one, to be sure, but not curious enough to continue derailing development for it :P

Yeah it's not a bug, just a built-in limitation of the faction system. You can actually create similar situations with Golems elsewhere, not just there. They don't have their own faction and when spawned hostile will actually share a certain faction that might be used for non-0b10 unaffiliated hostiles in other cases. This is just how it's built and is not currently planned to be expanded since the assembled don't have or generally need their own faction. Golems hostile to you will technically be friendly with some other interesting parties in the caves!

Ah, on closer examination, this wasn't the old issue which was fixed, it's just a case of circumstances causing the phasewall to get tuck in the open position (it's darker but you can see the different color of the tile there--that's the appearance of an "open" phasewall). In their open position you can fire through them, but they still won't let you move through that space unless you have Structural Interface. If another enemy passed through it would be detected again and close, but they don't otherwise close on their own if they managed to miss the closing trigger due to special circumstances. (This can happen with regular doors as well, but the more unique properties of phasewalls might make this stand out more, also being as rare as it is.)

Found the exits you were referring to, but... weirdly it still doesn't happen for me. Did a bunch of tests using these files as a starting point, and follow the same steps, but it's all still working normally. Pretty inexplicable.

Fortunately it's minor, but I'd certainly like to know why. Doesn't seem like this is likely to be resolved, hm :/

Added for Beta 14:
* NEW: Melee attacks made with any momentum benefiting from speed bonus while using overloaded propulsion can cause burnout as moving normally

I mean, everything in the game happens because that's how it was coded, including bugs.
I know, I'm saying it's done that way intentionally.

This isn't a bug, it's just how that particular event is coded. Disable at your own risk!

You'll find a number of other events and situations that use a similar approach for various reasons.

Yes this is not referring to a specific part, and is not a bug xD

It's just referring to Makeshift parts in general, and in their opinion, as stated.

Understandable, although as a part of the line-of-fire visualization rather than extra AOE visualization, it will remain for now.

This is allowed. The precise edges of your range are a bit fungible, especially in cases like that because the object on the other side is a prop that occupies its entire cell position and is pushed right up against the edge of whatever's next to it, so if you penetrate you do still hit the side of it (now if it was something smaller that probably wouldn't occur, but there was no distance to travel following the penetration).

Hm, I think this happened once before ages ago and that was fixed, looked like there might be some other source for it. I'll have to add this to the list to check later once I get back to look at Beta 13 stuff (can't load the save right now, working on Beta 14).

I mean... explosion predictions are pretty obvious because they have a half-square outline delineating the maximum in each axis direction, which is the more fundamental part of that display--it uses lines in addition to the interior highlight area and not just relying on color like the rest of the targeting interface.

Yep, it's intended and the way this will continue to work. As stated it's going to predict from wherever you're aiming, since that's the consistent behavior (you could very well be firing a volley including a cannon that you expect to destroy the initial target first, who knows :P)

Yeah I'm aware of this behavior, that's how it was built to show you the arc no matter what, since it's helpful to know even if it won't fire, which you'll generally know due to the other differences (in particular the lack of an explosion prediction showing AOE). I decided from the beginning to leave it this way since it can fall on the edge of helpful.

Arc is actually part of the line-of-fire visual (unrelated to AOE), which has always shown even when your target is out of range. In that sense it is consistent.

Ideas / Re: Showing the depth identified exits lead to
« on: April 24, 2024, 07:04:42 PM »
Indeed it seems like quite a comprehensive guide...

Okay yep I actually did find a way to force it to avoid other labels in this particular scenario using the existing system:

Above is the same scenario in your screenshot, just more obvious--without adjusting the relative label overlap cost for this case both labels would've been immediately right-oriented, but here they split due to a change in priority. I'll look at more widely implementing this change for the next release (it can actually affect some other types of objects as well), but hopefully there are no negative side effects. The thing is, something like this changing can cause negative/undesirable impacts on other scenarios, and you don't always know until you know :P

Okay yeah I've definitely confirmed that the system is capable of handling that situation properly, when a robot in view is standing on an item and you manually call up labels on that position. It always works properly in all the tests I've set up now, so I'd need a specific case where it doesn't work. I know I've encountered this myself in the past, but it seems to be rare, and actually may simply be behaving according to the rules, for example the labels end up overlapping and preferring the same direction due to what would otherwise be overlapping other parts.

Hm, actually... on looking at your image I can see that's exactly what's happening here! All orientations happen to have about the same "coverage cost," as in what objects will be covered if the desired labels are in a different direction, and covering objects themselves has a higher cost than covering labels (usually anyway, since they're based on actual length of the label that will be covered), so in the interest of keeping objects visible these labels in that scenario end up overlapping one another, but they do both still exist. Now ideally in this case since you're creating the labels manually for a specific location it would prioritize labeling instead of avoiding objects, but it uses the same system for both processes (since they're rather complex overall), meaning it is going to follow the same avoidance rules.

Maybe this specific scenario could be addressed by having a dynamic cost for label covering, and adjusting that when doing manual labeling... overall this is quite a lot of work for something that doesn't come into play very often :/ (you can right-click on your ally if you really really need their info, or use the pure/mass robot labeling option)

(Note this is overall different from the original non-FOV version addressed earlier in this thread, as those labels are created more directly, rather than using a generic system, so can more easily have special handling applied.)

Edit: Yep, based on that screenshot I created a specific testing scenario to confirm that's what's happening. You can see all the blocking items in your screenshot there--I can force the labels to overlap in that scenario.

Actually not yet since that's a lot more complicated, but I've known about that one since the first version of Cogmind :P

Will look into it again but no guarantees. Maybe there's an easier way to solve it that won't involve too much spaghetti. (Inter-type label avoidance is not something the systems were really designed for, since normally you're not simultaneously labeling multiple different types of objects at once, just different instances of the same type.)

Edit: Actually though, now I recall this being inconsistent for some reason--it usually works even when manually labeling, but not always, would have to explore why that is...

Ah, it appears that specifically for manually labeled locations out of view, a robot and item occupying the same location will have overlapping labels, unlike when in view where these two labels will each be presented in a different direction so as to not overlap. So the label exists there, it's just under the other one.

This is because labeling items outside view requires basing it on old map knowledge, which is handled by different code unaware of any other label conditions, and that label must happen second. Will have to see about somehow letting it have necessary state info.


There we go :)

Pages: [1] 2 3 ... 174