View Issue Details
| ID | Project | Category | Date Submitted | Last Update | |
|---|---|---|---|---|---|
| 0021695 | AI War 2 | Bug - Gameplay | Sep 28, 2019 10:53 am | Oct 2, 2019 5:44 pm | |
| Reporter | NRSirLimbo | Assigned To | BadgerBadger | ||
| Severity | major | ||||
| Status | resolved | Resolution | fixed | ||
| Product Version | 0.892 All Ship and Structure Visuals Done! | ||||
| Fixed in Version | 0.895 Major Progress On Tutorials Framework | ||||
| Summary | 0021695: Shots fired at Stacks miss if the stack separates | ||||
| Description | It seems to me as if a shot fired at a stack doesn't actually hit the stack if said stack separates (usually due to a ship being destroyed). This makes stacks MUCH more tanky than they should be. | ||||
| Tags | No tags attached. | ||||
|
|
Hmm. I'm pretty sure this is a reasonable critique of the current state of affairs, but I don't have stats or a recent look at the code to confirm. We could try explicitly re-routing shots in-flight I suppose. I'm not sure how much of a performance hit that would be. Chris? Thoughts? |
|
|
It's 100% definitely a thing that happens. I thought about it maybe a month ago and then forgot about it. It's tricky, because there's potentially a delay between units dying and the new unit being created; if there's not now, there will be once multiplayer arrives. Units being stacked are another similar case, although a less common one. I can't think of a simple and elegant solution for this one EXCEPT potentially this: 1. If a shot is heading to a location, and its target disappears, then keep have it head there even if the target dies. 2. In general have shots remember the type of ship they were heading for, and the faction of the ship they were heading for. 3. Also remember if a shot was heading toward a ship under a forcefield. If so, then act against the forcefield unless it died. Otherwise part 4 will cause shots to pierce through forcefields visually (but not functionally). 4. When a shot reaches its destination without a target, then it does a quick search for ships of the matching faction and type that are within a certain distance of itself. Maybe even something like 400px? If it finds something, it hits it. If it doesn't find something, it waits for 100ms and tries again (but stays invisible during this time). It can wait up to 4 times (so 400ms) doing this before the shot is completely disposed-of. There are some other ways I can think of to solve this, but the time-delay of units being created in the future is something that is the most problematic. --- Another way to solve this would be to NOT actually destroy units that are a stack dying. This might be the simplest. Instead to just have them throw off the explosion graphics as a separate thing, and reset their health and whatnot to full and decrement the stack count by one. This would probably keep combat the most fluid in general, and have the least amount of crazy code. |
|
|
I think the latter approach is probably the best. I think we could hit 1.0 without fixing this and it would be okay, so not a super high priority. Edit: If someone has a good save game where this is happening, I am curious to see how much of a problem this really is |
|
|
Agreed, simply resetting health would probably serve best. Also, would it be a possibility to change stacks into what I'd probably call "ship groups"? As in every ship group being an amount of ships with the same type, Mk level and buffs/debuffs traveling as one entity but having sort of a "multishot-multiplier" when they fire and in return being able to target every other "ship group" with as many shots as it has ships? |
|
|
well, stacks have a multishot-multiplier already; a stack of sufficient size gets bonus shots and does bonus damage with those shots anyway. What advantage would this ship-group notion have over the current implementation? |
|
|
Basically, what I'd have in mind is something like a staged-formation system. Where, every time ships of the same line and Mk level overlap in their collision radii they "merge" as is currently done with stacks. Only instead of stacks they take a "formation". So imagine you have a V-formation (let's say 5 ships like this): X X X X X So up to 5 ships this formation will be used. If it goes above it could change to something like this: X X X X X X X X X X X X X X X X X X X For up to 11 ships, and so on in potentially bigger and bigger formations with a bigger and bigger collision radius. This primarily helps out with collision since most ships will always be in a group, reducing the overall number of decollisions done. Doing it like this would also allow for ships to merge better while still appearing as a bigger fighting force on the map, instead of stacked icons "100+" which may even get covered up by other ship's icons there would be much less icons overall. This helps to represent the fighting force on the map instead of your ships getting destroyed by a stack of 400 ships which looks like a single icon and no big deal until you see how many it actually is. The second thing would be to realistically simulate these "ship groups" and do something like "1 group of 50 V-Wings shoots, there are 2 groups of 5 each Fusion Bombers near. To finish off the first group only 10 shots are needed -> send 10 shots to the first group and send 40 to the other group" which would tie into the issue we have. It'd reduce the amount of overall shots (since they get combined and the sources/recipients are less entities overall). So every time ships get destroyed from as "ship group" its sprite is deleted from the formation, until it drops to or below the size of the next smaller formation, at which point it'll get smaller again. Biggest problem I've found so far would be how to handle debuffs, because at that point I'd expect "ship groups" to split into a group which doesn't have a debuff and a group which does until it runs out, which is when they can combine again. |
|
|
-_- it removed additional spaces... |
|
|
Just imagine a block formation instead. X X X X X X X X X as a block formation for up to 9 ships, X X X X X X X X X X X X X X X X for up to 16 ships, and so on. |
|
|
I don't think we're going to implement something like these ShipGroups. The current mechanism is adequate and we're desperately short on time to get this out the door anyway. |
|
|
Yeah, that's the main problem. It'd probably require a lot of re-writing the basic entities of ships, setting up formations, etc. For now, simply having stacks not die and respawn with -1 ship but instead reducing the ship count by 1 and resetting HP/shield to max is the easy and best way out currently. |
|
|
Still looking for a good save game for this scenario |
|
|
arnaud_defrance is noting how this is making really giant stacks take forever, too: https://steamcommunity.com/app/573410/discussions/0/1628539187760327150/ |
|
|
I've spent some time looking at this and think i can probably get this sometime in the next week or so. I still need a good save game to test with though. That said, Chris, if you want to take it as a break between tuttorial/sidebar work you're welcome to. I'm still in the studying code and toughly sketching things in my head phase |
|
|
I've produced a save of lots of stacks fighting, but it's not these multi-thousand-ships-of-stacks that I've seen sometimes. Not sure how to produce them. I'll search among the saves I have from older games when I get back from work. |
|
|
Oh awesome, that would definitely be a nice thing not to have to worry about, thanks Badger. I think if I take a break from tutorials I'll be going into the UI and achievements, so this is all yours unless you say otherwise. |
|
|
Another save is attached, from arnaud_defrance. He writes: "Here is the save. Multiple waves have 1k+ small ships stacks that take a long time on planets. Otherwise just hack the spire archive. Note that the current version also has the ARS reference issue, where it fails to find the reference in the intel tab. This also impacted ship swapping once, with the screenshot in the bug report section. The stack issue feels the most annoying of the two though." https://steamcommunity.com/app/573410/discussions/0/1628539187760327150/?tscn=1569999144 |
|
|
I tried out this save game. The complaint calls out "Note that the current version also has the ARS reference issue". Well, the previous version had an ARS bug, which I fixed. When I load this save game the ARS hovertext in the Intel panel works fine. The complaint also says "My second problem is the spire archive. How can I succesfully hack it? The enemy spawn on top of it, they survive long enough despite me trying to get forcefield frigates in (that keep moving uselessly around and out of radius), my forcefield is upgraded but isn't enough, and due to stack issue my units don't kill the vanguard spam fast enough, despite having multiple canon turrets and 600 hundred strength of units from my fleets, turrets and parasited units." I did the hack at 8x speed w/o any micro (I literally didn't issue any commands once the hack started, just watched), and with only the ships on the planet from the beginning and it was an easy win for me. No giant stacks were generated, the ships on the planet just steadily mowed down the incoming AI forces from the hack. I didn't see anything that would make a player believe stacking was a problem. Incidentally, you'll find this hack even easier if you build a military command station instead of a logistical command station (since military buffs your ships and has guns, and lets you build extra turrets), and if you d on't put your factories and command station right next to the Spire Archive you are hacking, where the AI will be able to kill them. |
|
|
That said, this does look like a good test save for making the discussed changes to how a stacked unit dies |
|
|
I've done a first pass at the code change to make stacks die "off the top" and keep the same GameEntity as the "bottom" (visible) member of the stack to prevent shots from getting lost. It's an immense balance change. Previously during this hack the AI forces would get up to about 100-150 strength before being whittled down. It was a battle, if a one-sided battle. Now the AI ships evaporate when spawning. It's a slaughter, not a battle. I'm actually nervous about making this change given the balance implications. I have some more unit testing to do (pun intended) before I check things in, just in case I've made a mistake someplace. |
|
|
I think that this is definitely a needed change, despite the balance implications. We'll have some buffing needed for the AI, I'm sure, but I'm not keen to have the AI be doing well just because shots are missing all over the place, heh. Do you have the ships visually exploding when they die like this, still? This was the big thing that I was concerned about being a problematic thing from a code standpoint. Battles could look very static without those explosions. I'm actually really looking forward to us being able to redadjust the AI if we need to based on this, just because fighting against superior forces and winning is pretty cool. Versus recently it was seeming like it was inexplicable why I couldn't hurt stacks more than I was, which just didn't feel right. Since the performance impact of just giving the AI maybe 1.5x the ships they had before (in stacks) is negligible, but the overall flow will feel better, I'm pretty pleased at the prospect. Even if it will throw balance off for a little while. :/ |
|
|
I've pushed what I have to give you a sense of what's going on; it's not generating explosions whenever a unit in a stack dies (though in larger fights I think the increased rate of ships dying will make it less noticeable. For smaller battles I agree, some bonus explosions would be welcome. Is there an easy way to generate a "ship looking like its dying" sort of explosion effect? Right now I think we generate that effect by switching the Squad to a "burning and dying" visualization effect. I could say "Whenever you kill a stacked squad, create a new GameEntity_Squad next to it that's already dying"? |
|
|
I think I'll need to hook up a new system for handling that for the squads without it being a whole new GameEntity_Squad. We can just stay in the visuals area. If there's a singular place in the code (vis side is ideal, but whatever works, really) where I could have a CHRIS_TODO to spawn things from there, I could probably put that together. Note that won't have the icon burning and dying, but that's probably ideal anyway for when it's not killing the whole stack. The stack itself dying will still do the icon, but part of a stack dying wouldn't have that effect getting in the way. |
|
|
There's a single place in the GameEntity_Squad::TakeDamage() function that's where we figure this out. I'll give you a TODO. Agreed that no need to show the icon dying. |
|
|
Okay, I added in the burning and dying stuff and explosion sounds for when ships hit off a stack like that. All seems to be working well! |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| Sep 28, 2019 10:53 am | NRSirLimbo | New Issue | |
| Sep 30, 2019 1:37 am | BadgerBadger | Note Added: 0053317 | |
| Sep 30, 2019 10:47 am | Chris_McElligottPark | Note Added: 0053319 | |
| Sep 30, 2019 10:47 am | Chris_McElligottPark | Assigned To | => Chris_McElligottPark |
| Sep 30, 2019 10:47 am | Chris_McElligottPark | Status | new => assigned |
| Sep 30, 2019 11:24 am | BadgerBadger | Note Added: 0053322 | |
| Sep 30, 2019 11:25 am | BadgerBadger | Note Edited: 0053322 | |
| Sep 30, 2019 5:04 pm | NRSirLimbo | Note Added: 0053336 | |
| Sep 30, 2019 5:22 pm | BadgerBadger | Note Added: 0053337 | |
| Sep 30, 2019 6:08 pm | NRSirLimbo | Note Added: 0053341 | |
| Sep 30, 2019 6:09 pm | NRSirLimbo | Note Added: 0053342 | |
| Sep 30, 2019 6:09 pm | NRSirLimbo | Note Added: 0053343 | |
| Sep 30, 2019 7:41 pm | BadgerBadger | Note Added: 0053346 | |
| Sep 30, 2019 7:46 pm | NRSirLimbo | Note Added: 0053347 | |
| Oct 1, 2019 4:26 pm | BadgerBadger | Note Added: 0053372 | |
| Oct 1, 2019 8:30 pm | Chris_McElligottPark | Note Added: 0053376 | |
| Oct 1, 2019 11:38 pm | BadgerBadger | Note Added: 0053381 | |
| Oct 1, 2019 11:40 pm | BadgerBadger | Note Edited: 0053381 | |
| Oct 2, 2019 6:34 am | NRSirLimbo | File Added: s4 stacks.save | |
| Oct 2, 2019 6:34 am | NRSirLimbo | File Added: s4 stacks.savemet | |
| Oct 2, 2019 6:34 am | NRSirLimbo | Note Added: 0053382 | |
| Oct 2, 2019 11:07 am | Chris_McElligottPark | Note Added: 0053384 | |
| Oct 2, 2019 11:07 am | BadgerBadger | Assigned To | Chris_McElligottPark => BadgerBadger |
| Oct 2, 2019 11:27 am | Chris_McElligottPark | File Added: ArnB_SlowStacksKilling.save | |
| Oct 2, 2019 11:27 am | Chris_McElligottPark | Note Added: 0053386 | |
| Oct 2, 2019 12:39 pm | BadgerBadger | Note Added: 0053389 | |
| Oct 2, 2019 12:40 pm | BadgerBadger | Note Edited: 0053389 | |
| Oct 2, 2019 12:41 pm | BadgerBadger | Note Edited: 0053389 | |
| Oct 2, 2019 12:44 pm | BadgerBadger | Note Added: 0053390 | |
| Oct 2, 2019 12:44 pm | BadgerBadger | Note Edited: 0053390 | |
| Oct 2, 2019 12:56 pm | BadgerBadger | Note Edited: 0053389 | |
| Oct 2, 2019 1:11 pm | BadgerBadger | Note Added: 0053391 | |
| Oct 2, 2019 1:23 pm | Chris_McElligottPark | Note Added: 0053393 | |
| Oct 2, 2019 1:48 pm | BadgerBadger | Note Added: 0053395 | |
| Oct 2, 2019 1:58 pm | Chris_McElligottPark | Note Added: 0053396 | |
| Oct 2, 2019 2:03 pm | BadgerBadger | Note Added: 0053397 | |
| Oct 2, 2019 5:44 pm | Chris_McElligottPark | Status | assigned => resolved |
| Oct 2, 2019 5:44 pm | Chris_McElligottPark | Resolution | open => fixed |
| Oct 2, 2019 5:44 pm | Chris_McElligottPark | Fixed in Version | => 0.895 Major Progress On Tutorials Framework |
| Oct 2, 2019 5:44 pm | Chris_McElligottPark | Note Added: 0053410 |
