Detecting Upgrade Spawns

Detecting Upgrade Spawns
0
#1

Right now the spawn event in the action frame for an upgrade uses the same unit type value as the original firewall unit.

Looking at the python starter algo, it creates and upgrades two filters on turn zero. That spawn event list looks like:

“spawn”: [[[27, 14], 2, “1”, 2], [[0, 14], 2, “2”, 2], [[19, 16], 2, “3”, 2], [[8, 16], 2, “4”, 2], [[14, 16], 2, “5”, 2], [[13, 16], 2, “6”, 2], [[19, 15], 0, “7”, 2], [[8, 15], 0, “8”, 2], [[19, 15], 0, “9”, 2], [[8, 15], 0, “10”, 2], [[26, 15], 5, “11”, 2], [[23, 18], 5, “12”, 2], [[10, 24], 5, “13”, 2], [[4, 18], 5, “14”, 2], [[16, 25], 5, “15”, 2]],

You see [[8, 15], 0, "8", 2] (for the filter) and [[8, 15], 0, "10", 2] (for the upgrade). Both have 0 (filter) for the unit type value.

This makes it much harder to detect upgrade spawn events!

Can spawn events start using the new unit type value of 7 for upgrades?

I realize there is a bit of a trade-off here as you would need extra information to determine what type of firewall was upgraded, but this would bring it inline with how removal spawn events work (they use unit type value of 6).

#2

I agree that parsing the replay has become a little more involved.I’d like to suggest an additional option for making it easier to read. How about treating the upgraded filter/encryptor/destructor as an entirely new unit type in the replay file (both for the spawn event as well as in the p1Units/p2Units)? This way you can easily detect upgrades as well as what type of unit has been upgraded. So 7 == upgraded filter, 8 == upgraded encryptor, 9 == upgraded destructor.

#3

@n-sanders
Interesting suggestion, thanks for the feedback! This seems small enough in scope that shouldn’t be a problem to implement. I think because of weird reasons there would probably be two spawn events, one that is the firewall type at that location, then another that’s the upgrade type like you suggested. Is that okay or would having two spawn events be bad? If its okay I’ll add it to my list. This week is pretty intense but next week should have time to implement it.

@max1e6
Thanks for the suggestion! That would be a lot more work to implement though would have to change a lot of stuff. But I will for sure keep it in my head if an opportunity comes to change a lot of stuff, and also when we are planning on implementing future stuff. I thought about doing it that way too when first implementing but the main issue was having to change so much stuff for it. Like after all events would have to use the extra types, 3 new command strings for players to send, being able to turn it on and off in the config without messing up something, a bunch of weirder things in the back of the code. But, definitely has its advantages too like more direct to parse, I’ll keep it in mind!

#4

Two spawn events when the upgraded unit is ALSO being spawned that same turn sounds perfect.

If an upgrade is being spawned for a unit that was previously on the game board, I’d assume you’ll only see one - the unit type 7 spawn.

Is that correct?

(again, I believe this is exactly how the removal spawn events are handled in each case)

#5

Can we just have new event type ?
"events":{..., "upgrade": [[[x,y], unit_type_id?, player_index],...]

#6

So I’m just going to make it so that:

if you have an old unit and upgrade -> spawn event where UnitType = 7(upgrade) occurs, with the position matching the old unit.

if you spawn a new firewall and upgrade it same turn -> 2 Spawn events, one for the firewall another for the upgrade.

The gid of the unit btw will change after upgrade.

@Demorf Adding events is a pain because the starterkits, frontend etc have to be edited to serialize them and use them properly. I think adding a spawn event that has the UnitType int be upgrade(7) and gid and position be the unit that was upgraded as above should be enough?