Grid Sage Forums
- April 26, 2024, 07:54:15 PM
- Welcome, Guest
|
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.
1
Bugs / Re: [Beta 13] Phase wall remains open and unpassable
« on: Today at 02:49:48 AM »
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).
2
Fixed Bugs & Non-Bugs / Re: [Beta 13] (spoiler) Misleading projectile arc prediction
« on: Today at 02:47:05 AM »
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.
3
Fixed Bugs & Non-Bugs / Re: [Beta 13] Explosion prediction can be misleading
« on: Today at 02:28:04 AM »
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 
)
)
4
Fixed Bugs & Non-Bugs / Re: [Beta 13] (spoiler) Misleading projectile arc prediction
« on: Today at 02:25:39 AM »
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.
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.
5
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...
6
Confirmed Bugs / Re: [Beta 13, non-modal UI] Unable to label Operator (and other robots) above part
« on: April 23, 2024, 07:04:08 PM »
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
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
7
Confirmed Bugs / Re: [Beta 13, non-modal UI] Unable to label Operator (and other robots) above part
« on: April 23, 2024, 06:52:08 PM »
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.
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.
8
Confirmed Bugs / Re: [Beta 13, non-modal UI] Unable to label Operator (and other robots) above part
« on: April 23, 2024, 05:23:48 PM »
Actually not yet since that's a lot more complicated, but I've known about that one since the first version of Cogmind
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...
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...
9
Confirmed Bugs / Re: [Beta 13, non-modal UI] Unable to label Operator (and other robots) above part
« on: April 23, 2024, 04:34:09 AM »
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
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
10
Ideas / Re: Showing the depth identified exits lead to
« on: April 23, 2024, 02:55:42 AM »
Multi-shot would help increase total damage output, for sure. It's more likely to spread, but if you can overcome that while at the same time having a large multislot weapon, it punches through anything, not to mention imagine creating such a thing that not even any damage resists can block 
Multislot constructs, and maximizing your total number of constructs for even more compounding bonuses, are where it's at. We've seen some insane construct builds before.
Multislot constructs, and maximizing your total number of constructs for even more compounding bonuses, are where it's at. We've seen some insane construct builds before.
11
Confirmed Bugs / Re: [B12] Branch exit might use stair tile instead of door tile
« on: April 19, 2024, 06:02:00 AM »
Ah cool, thanks for the saves, if repeatable that'd be neat to knock this off the list
Too bad the notification for this one came in rather late today, since I was just doing some debugging in the older version earlier and was all set up for that, but now I'm back on the next version again so I guess it'll have to wait until return to older things to check this out...
Too bad the notification for this one came in rather late today, since I was just doing some debugging in the older version earlier and was all set up for that, but now I'm back on the next version again so I guess it'll have to wait until return to older things to check this out...
12
Fixed Bugs & Non-Bugs / Re: [Beta 13] Ally-repaired broken propulsion auto-activates despite settings
« on: April 19, 2024, 05:58:04 AM »
Yeah the behavior is meant specifically for you attaching propulsion. I guess it could technically be extended to include other types of "new part being attached," but maybe better not to since there will be more exceptions added and exceptions are not great, then it'd end up being inconsistent every so often during expansion... Other cases are few and far in between, so you can do so manually if necessary.
13
Fixed Bugs & Non-Bugs / Re: [Beta 13] Allies ignore trap knowledge too often
« on: April 19, 2024, 05:55:48 AM »
They will avoid traps during general movement, but if there's other stuff going on, in particular confrontations with enemies, they're no longer going to care--combat takes priority. This is intentional behavior.
14
Fixed Bugs & Non-Bugs / Re: [Beta 13] Mouse auto-pathing goes around repaired/collapsed walls
« on: April 19, 2024, 05:53:41 AM »
Autopathing does avoid collapsed tiles by default as of Beta 13. To get through via mouse you need to move adjacent to them to show that's your intent.
15
Ideas / Re: Showing the depth identified exits lead to
« on: April 14, 2024, 12:30:40 AM »
Scrap Engine is actually one of the most powerful items in the game when used properly (people have put together flying builds with massive integrity and weapons that can one-shot any bot in the game--any bot)
(people have put together flying builds with massive integrity and weapons that can one-shot any bot in the game--any bot)
16
Fixed Bugs & Non-Bugs / Re: [Beta 13] Gun Armor deletes new Scrap Engine weapon
« on: April 13, 2024, 09:57:35 AM »
No you definitely still lose the slot, it just might happen to last a little longer, unstable technology and all... (the lore source will be more filled out in a later Beta, as to its true origins)
17
Fixed Bugs & Non-Bugs / Re: [Beta 13] Scrap Engine weapon doesn't have newly added critical effect
« on: April 13, 2024, 09:56:44 AM »
It was already done that way before, but changed during prerelease since it ended up making less sense the other way.
18
Fixed Bugs & Non-Bugs / Re: [Beta 13] Propulsion Burnouts scoresheet entry refers to parts lost that way
« on: April 13, 2024, 06:39:42 AM »
More specifically to the point, it would need a different name entirely because the actual "burnout" as recorded is the named event that is reflected in the message log when that occurs. Don't really want to introduce another term, though.
19
Fixed Bugs & Non-Bugs / Re: [Beta 13] Propulsion Burnouts scoresheet entry refers to parts lost that way
« on: April 13, 2024, 06:36:31 AM »
Yep, that is exactly what it records, the number of propulsion actually lost to it, not integrity damage. It could potentially be switched, since actual complete burnouts are quite rare, but it's not a bug and not yet on my list (we were actually having this discussion earlier this week).
20
Fixed Bugs & Non-Bugs / Re: [Beta 13] Scrap Engine weapon doesn't have newly added critical effect
« on: April 13, 2024, 06:33:38 AM »
Yeah that's a possibility, this is normal behavior. As you might be familiar "Burn" is a special critical that specifically requires Heat Transfer to operate, but your weapon currently has no base heat transfer capability at all, so the critical will not show since it doesn't currently apply. Technically it has that chance after the modification, but it won't show.
21
Ideas / Re: No ground-to-attached-to-inventory-to-ground auto-replacement option
« on: April 13, 2024, 12:29:56 AM »
Yes very specifically the Storage Unit swapping rules were actually changed for a short period during Beta 13 development to make sure that doesn't happen, but it actually lead to even more problems for players, so was switched back
Specifically with Storage Units you're going to have to be more specifically aware of which ones you want to keep, and do this manually rather than relying on the automated system if it won't suit your needs. But making a special exception for those does lead to even more issues for the majority of players in the majority of situations, as we discovered through actual experience with the alternatives earlier this year in testing.
There won't be warnings added for this particular feature, you'll have to swap manually if you don't want automated behavior, which has very few rules and is quite consistent for the very reason that it's easy to predict what will happen if you let the automated system do its thing.
(The system is getting expanded even further in Beta 14 to allow manual ground-attached swapping when the automated system will otherwise do nothing, but that's a different issue.)
Specifically with Storage Units you're going to have to be more specifically aware of which ones you want to keep, and do this manually rather than relying on the automated system if it won't suit your needs. But making a special exception for those does lead to even more issues for the majority of players in the majority of situations, as we discovered through actual experience with the alternatives earlier this year in testing.
There won't be warnings added for this particular feature, you'll have to swap manually if you don't want automated behavior, which has very few rules and is quite consistent for the very reason that it's easy to predict what will happen if you let the automated system do its thing.
(The system is getting expanded even further in Beta 14 to allow manual ground-attached swapping when the automated system will otherwise do nothing, but that's a different issue.)
22
Fixed Bugs & Non-Bugs / Re: [Beta 13] Gun Armor deletes new Scrap Engine weapon
« on: April 13, 2024, 12:24:02 AM »
Yeah that's not a bug, just the way things are. SE can create things in temp slots, but you're going to lose them all the same when the slot is gone, but as described on the part, sometimes a temp slot may require an extra bit of time before it really disappears because it's no longer supported. Best to just keep SE off if you're about to have an unstable situation, so that it doesn't produce anything under poor circumstances, or keep going and have it build something else after the fact... Temp slots are unstable by their nature.
23
Ideas / Re: Auto-overload propuslion when melee attacking with momentum
« on: April 10, 2024, 04:07:14 AM »
Interesting you mention saying you have no idea how you'd complete ++ without speedy prop, when the more common opinion among extended-area players right now is that fast prop is a harder way to achieve ++ compared to slow prop these days. (Of course not everyone agrees and some do it with fast prop just to prove the point, but the trend in opinions has been obvious.)
24
Ideas / Re: Showing the depth identified exits lead to
« on: April 10, 2024, 04:03:13 AM »
The lack of that information is indeed by design, and will not be added. You will have to gamble!
But, be aware that you're talking about new branch areas that haven't even been completed yet, so it's still early to be weighing what is and isn't worth it in the bigger picture. You'll be seeing more.
But, be aware that you're talking about new branch areas that haven't even been completed yet, so it's still early to be weighing what is and isn't worth it in the bigger picture. You'll be seeing more.
25
Ideas / Re: Auto-overload propuslion when melee attacking with momentum
« on: April 09, 2024, 03:06:27 AM »
Heh, not saying you're not a veteran, you clearly are, just wondering about all the others up there (almost everyone else in the top 50 hangs out on the Discord, so it's easy to ask if I do need the info... but anyway I'll come back to this when I get to it on my list)
(almost everyone else in the top 50 hangs out on the Discord, so it's easy to ask if I do need the info... but anyway I'll come back to this when I get to it on my list)