Grid Sage Forums
- April 24, 2024, 07:08:09 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
Ideas / Re: Showing the depth identified exits lead to
« on: Today at 07:04:42 PM »
Indeed it seems like quite a comprehensive guide...
2
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
3
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.
4
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...
5
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
6
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.
7
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...
8
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.
9
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.
10
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.
11
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)
12
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)
13
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.
14
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.
15
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).
16
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.
17
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.)
18
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.
19
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.)
20
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.
21
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)
22
Ideas / Re: Auto-overload propuslion when melee attacking with momentum
« on: April 09, 2024, 02:09:30 AM »May i suggest changing it in a different, less annoying-to-use way?Yeah I hadn't really given it much thought yet, was just the first approach off the top of my head, but overall the general intent is usually to avoid adding complexity to the rules, however that can be achieved while maintaining the desirable balance and removal of any tedium. I've actually never heard or seen anyone doing this overloading thing, not even all the veteran players who top the leaderboards and like to minmax, though I do wonder if anyone else actually does it.
For instance, requiring the player to have moved with x speed as their last action for that speed to apply with momentum to non-ramming attacks? That would remove the benefit from constantly switching propulsion from overloading to not overloading, at least when attacking a single enemy, because even if they move away, you'd want to keep propulsion overloaded when following to get the maximum bonus from momentum.
I know there's probably quite a few issues with that alternative, but it's just an example.
But anyway, yeah I do think the idea of requiring movement on the previous turn to get the speed bonus makes sense. I mean to be honest originally at the beginning of this thread that's how I assumed it works
23
Ideas / Re: Scroll through items in the Search Screen?
« on: April 07, 2024, 09:02:55 PM »
Not scrolling through like that, no, but you can use keyboard or mouse to select an item and the map centers on it, then also repeat that command again for the same item to have you path straight to it.
You can scroll the list itself when it's too long (which is what scroll normally accomplishes there), but I'm assuming you mean to simply scroll through the entire list as it shows you each item's location one by one. Overall not as helpful, but note that they're also listed in terms of distance from your current position.
The manual covers more advanced features like this. Once you're familiar with basic functionality of the interface, you might want to check out the section on Advanced UI, and also the advanced config options--lots more you can do which may not be obvious at first.
You can scroll the list itself when it's too long (which is what scroll normally accomplishes there), but I'm assuming you mean to simply scroll through the entire list as it shows you each item's location one by one. Overall not as helpful, but note that they're also listed in terms of distance from your current position.
The manual covers more advanced features like this. Once you're familiar with basic functionality of the interface, you might want to check out the section on Advanced UI, and also the advanced config options--lots more you can do which may not be obvious at first.
24
Ideas / Re: Auto-overload propuslion when melee attacking with momentum
« on: April 07, 2024, 05:20:33 PM »
Okay, now I see what you mean. It would've been really helpful if you mentioned the Reaction Control System in your original post, since that changes everything and I wasn't thinking about that at all, was just looking at overloaded propulsion in isolation. (You mentioned momentum, but I considered that as a part of movement, but here we're talking specifically about in combination with another utility.)
). In the case of overloadable prop it instead cycles past that state automatically, probably a decision made because you're more likely to want to siege anything you can when you can, the entire reason to be toggling treads at all, whereas there are multiple different scenarios in which you want to toggle propulsion, and it's not always to overload.
So back to the original point... considering this discovery, attacking while overloaded should also burn out your propulsion (perhaps even at a higher chance?), and under such circumstances, having a permanent option to enable that would not be desirable, since then it could damage your prop due to attacks, and you may not always want that in every encounter.
Clicking the CYCLE button doesn't overload propulsion, only swaps it between active/inactive.Oh right, I'd forgotten that it doesn't behave like siege mode with treads, which does get cycled to (non-flight player here
At least i don't think so? I'm certain i tried several times in my last run to toggle overloading like this, and it didn't do anything?
The reason i checked was because i thought it did overload, so either i missed it during that run, or it was accidentally removed.
Edit: I double-checked a recording, and clicking CYCLE turned my flight units from all active to all inactive. They briefly go yellow, but that's it.
). In the case of overloadable prop it instead cycles past that state automatically, probably a decision made because you're more likely to want to siege anything you can when you can, the entire reason to be toggling treads at all, whereas there are multiple different scenarios in which you want to toggle propulsion, and it's not always to overload.Correct me if i'm wrong, but doesn't the auto-threads feature already detect attack intent?Right, but I was making that statement under the working assumption that you get no benefit from toggling while adjacent to an enemy to make an immediate melee attack with suddenly overloaded prop, in which case there would be no way to know your intent is to an attack simply be moving into a cell with no enemy.
So back to the original point... considering this discovery, attacking while overloaded should also burn out your propulsion (perhaps even at a higher chance?), and under such circumstances, having a permanent option to enable that would not be desirable, since then it could damage your prop due to attacks, and you may not always want that in every encounter.
25
Ideas / Re: Auto-overload propuslion when melee attacking with momentum
« on: April 07, 2024, 07:55:39 AM »
This doesn't actually help you, because overloading propulsion only increases your speed while moving not attacking, in other words, during the run through cells towards an enemy, for example, not while you're already adjacent to the enemy you want to attack. When you attack you just make an attack with whatever speed and momentum you already have at that point. An automatic toggle isn't really feasible, since it's not known when your intent is to attack. Also remember to use the CYCLE button (or hotkey) to quickly overload all your propulsion at once if and when you are going to approach a target. But don't expect that staying in an "overloaded" state means anything after you've already engaged and aren't actually moving anymore (this is also why your momentum drops as soon as you do anything over than move).