Reliably setting feature and unit IDs on creation

Reliably setting feature and unit IDs on creation

gajop's in-engine scenario and map editor

Moderators: Moderators, Content Developer

gajop
Moderator
Posts: 2972
Joined: 05 Aug 2009, 20:42

Reliably setting feature and unit IDs on creation

Post by gajop » 21 Aug 2017, 08:33

For some reason Spring prevents us from specifying unit and feature ID on creation.
This most often happens if an object already had that ID, was recently destroyed, but the ID slot wasn't freed (yet).
I assume this was done to ensure users aren't sending commands for wrong units (due to latency).

This essentially makes setting IDs on object creation very unreliable, as there is no way for content devs to know *when* those IDs are freed.
The solution is usually to use a different ID system and map that to Spring IDs. This is ugly and introduced additional code bloat, but is what SpringBoard does now.

I would like a better engine solution to this. Any suggestions?
0 x

User avatar
FLOZi
MC: Legacy & Spring 1944 Developer
Posts: 6059
Joined: 29 Apr 2005, 01:14

Re: Reliably setting feature and unit IDs on creation

Post by FLOZi » 21 Aug 2017, 12:20

In testing I found 3 frames were the required waiting period between death and the ID being freed, https://github.com/SpringMCLegacy/Sprin ... ld.lua#L78

You can check if the ID is valid by polling...?
0 x

hokomoko
Spring Developer
Posts: 530
Joined: 02 Jun 2014, 00:46

Re: Reliably setting feature and unit IDs on creation

Post by hokomoko » 21 Aug 2017, 12:40

I don't think engine IDs are good for tracking a specific unit, that's not their purpose.
It shouldn't be too difficult to make a special unitrulesparam to keep track of units.
0 x

sprunk
Posts: 79
Joined: 29 Jun 2015, 07:36

Re: Reliably setting feature and unit IDs on creation

Post by sprunk » 21 Aug 2017, 17:19

What *is* their purpose, then? What's the point of allowing to give a specific ID to `CreateUnit` if it won't even work in the most obvious use case?
1 x

gajop
Moderator
Posts: 2972
Joined: 05 Aug 2009, 20:42

Re: Reliably setting feature and unit IDs on creation

Post by gajop » 21 Aug 2017, 17:20

Thanks FLOZi, I think I might play with that as my workaround.

@hokomoko: What's the point of allowing content devs to set the object ID if those cannot be set reliably?

EDIT: sprunk beat me to it.
0 x

User avatar
smoth
Posts: 22295
Joined: 13 Jan 2005, 00:46

Re: Reliably setting feature and unit IDs on creation

Post by smoth » 21 Aug 2017, 17:29

why not merely grab the id and store it in a lookup table on creation?
0 x

sprunk
Posts: 79
Joined: 29 Jun 2015, 07:36

Re: Reliably setting feature and unit IDs on creation

Post by sprunk » 21 Aug 2017, 17:34

Because you can't modify a unit ID after it has been created so everything that uses these IDs would have to do the extra step of translating the ID.
0 x

gajop
Moderator
Posts: 2972
Joined: 05 Aug 2009, 20:42

Re: Reliably setting feature and unit IDs on creation

Post by gajop » 21 Aug 2017, 17:37

I have been doing that for years smoth, but it complicates the rest of the code.
Everything needs to use the custom ID but still translate to spring ID when using Spring functions.
0 x

User avatar
smoth
Posts: 22295
Joined: 13 Jan 2005, 00:46

Re: Reliably setting feature and unit IDs on creation

Post by smoth » 21 Aug 2017, 17:46

just might be a necessary hurdle. Seems like the standard way of handling things even in dbs where you have unique ids. Id is never based on assigment as inevitably you will have an id conflict(at least that is what I was taught)
0 x

hokomoko
Spring Developer
Posts: 530
Joined: 02 Jun 2014, 00:46

Re: Reliably setting feature and unit IDs on creation

Post by hokomoko » 21 Aug 2017, 18:15

gajop wrote:@hokomoko: What's the point of allowing content devs to set the object ID if those cannot be set reliably?
A short possible history lesson:
  1. CreateUnit was implemented in lua
  2. Some game dev asked the engine devs if they could set the unit ID of the unit being created.
  3. Engine dev replied: "No, it may still be in use and it's not reliable at all"
  4. The game dev said: "Well, so only do it if it's possible"
  5. Engine dev, demoralised and depressed said: "I have no idea how this helps you but I will code it in because my soul is empty"
  6. A few uneventful years pass
  7. gajop asks how to reliably set feature and unit IDs.
This may or may not reflect actual events, but it's a good story which matters more.
2 x

sprunk
Posts: 79
Joined: 29 Jun 2015, 07:36

Re: Reliably setting feature and unit IDs on creation

Post by sprunk » 21 Aug 2017, 18:19

sad
0 x

User avatar
FLOZi
MC: Legacy & Spring 1944 Developer
Posts: 6059
Joined: 29 Apr 2005, 01:14

Re: Reliably setting feature and unit IDs on creation

Post by FLOZi » 21 Aug 2017, 18:40

My view is that they can be set reliably so long as you don't try and destroy and create in the same frame (for obvious enough reasons).

I may be (one of) the game devs in #2 & #4, fwiw.
0 x

sprunk
Posts: 79
Joined: 29 Jun 2015, 07:36

Re: Reliably setting feature and unit IDs on creation

Post by sprunk » 21 Aug 2017, 18:59

The delay makes any solution very inelegant though. Blinking out of existence (even for 3 frames) can have minor gameplay consequences but, more importantly, is just very unpolished visually and looks like a bug.

What if Spring.DestroyUnit had an extra boolean parameter that just hard-removed the unit and performed the extra cleanup that recycles the ID on the spot?
0 x

hokomoko
Spring Developer
Posts: 530
Joined: 02 Jun 2014, 00:46

Re: Reliably setting feature and unit IDs on creation

Post by hokomoko » 21 Aug 2017, 19:20

What if you don't use engine ID for things that it isn't meant to do?
0 x

Google_Frog
Moderator
Posts: 2404
Joined: 12 Oct 2007, 09:24

Re: Reliably setting feature and unit IDs on creation

Post by Google_Frog » 22 Aug 2017, 03:50

hokomoko wrote:
gajop wrote:@hokomoko: What's the point of allowing content devs to set the object ID if those cannot be set reliably?
A short possible history lesson:
  1. CreateUnit was implemented in lua
  2. Some game dev asked the engine devs if they could set the unit ID of the unit being created.
  3. Engine dev replied: "No, it may still be in use and it's not reliable at all"
  4. The game dev said: "Well, so only do it if it's possible"
  5. Engine dev, demoralised and depressed said: "I have no idea how this helps you but I will code it in because my soul is empty"
  6. A few uneventful years pass
  7. gajop asks how to reliably set feature and unit IDs.
This may or may not reflect actual events, but it's a good story which matters more.
For some more detail, I found that the save/load gadget in ZK used the unitID and featureID parameter. When I took over polishing the gadget I discovered that these parameters are unreliable so removed them in favor of a mapping table.
0 x

User avatar
Silentwings
Moderator
Posts: 3433
Joined: 25 Oct 2008, 00:23

Re: Reliably setting feature and unit IDs on creation

Post by Silentwings » 22 Aug 2017, 10:34

Iirc hokomokos history lesson is basically what happened.

I can't see any solution to this except lua keeping a 'mapping table' for when it demands both unique and choose-able IDs. Asking that IDs are both choose-able and permanent with 100% reliability is not compatible with asking that they are also unique; the engine has to have the option to say "sorry, the ID you want is already in use". I guess that having a mapping table inside the engine (which is the logically elegant solution) is not possible because of cache misses.

Maybe from a practical point of view it would help to have e.g. Spring.IsUnitIDFree(unitID), to check if a unitID is currently free for use with Spring.CreateUnit(...), but this would add more empty souls into the history lesson.
0 x

gajop
Moderator
Posts: 2972
Joined: 05 Aug 2009, 20:42

Re: Reliably setting feature and unit IDs on creation

Post by gajop » 22 Aug 2017, 10:47

I think if there is not going to be callout which can be invoked beforehand, that would force-clear the IDs, it should simple be impossible to specify object IDs on creation, as it's not reliable or useful in any real way.

We're better off just making our own mapping tables.
0 x

sprunk
Posts: 79
Joined: 29 Jun 2015, 07:36

Re: Reliably setting feature and unit IDs on creation

Post by sprunk » 22 Aug 2017, 13:07

Asking that IDs are both choose-able and permanent with 100% reliability is not compatible with asking that they are also unique; the engine has to have the option to say "sorry, the ID you want is already in use"
This wouldn't be a problem if you could recycle the ID immediately, without having to wait X=3 frames (destroying the previous unit in the process, but usually that's desired anyway).

However since hoko says this isn't meant to be, I agree with gajop that under the current state of things this is a trap that is probably better off removed.
0 x

Kloot
Spring Developer
Posts: 1842
Joined: 08 Oct 2006, 16:58

Re: Reliably setting feature and unit IDs on creation

Post by Kloot » 22 Aug 2017, 13:23

Anyone who suggests a callout to force-recycle ID's does not sufficiently understand engine internals. /thread

The ability to assign ID's via Spring.Create{Unit,Feature} primarily exists to aid save/load gadgetry. It wasn't intended to be any more "reliable" than that (despite what some people might have started to believe) and also isn't going anywhere.

For the case of a newly upgraded unit evicting an old (which then gets destroyed) allowing in-situ creation is a far better idea, but empty souls etc.
0 x

gajop
Moderator
Posts: 2972
Joined: 05 Aug 2009, 20:42

Re: Reliably setting feature and unit IDs on creation

Post by gajop » 22 Aug 2017, 13:53

The ability to assign ID's via Spring.Create{Unit,Feature} primarily exists to aid save/load gadgetry.
Then it fails (is not reliable) at its primary purpose because that doesn't work when you first need to remove the existing units.
0 x

Post Reply

Return to “SpringBoard”

cron