Adding arbitrary spawnargs at runtime--good idea?

[SteveL]

Hi guys. Is there any reason not to attach extra spawnargs to entities at runtime? At first glance it looks like a very useful technique, which avoids having loads of global variables and that could even make up for the lack of dynamically-sized containers in the scripting language, but there could be plenty of disadvantages I haven’t thought of.

 

I’ve found I can spawn a target_null or some other entity in my blueroom and then add any keys I want to it, and retrieve the values later. Easy to see how you could implement a variable-length array or dictionary object that way, and pass it between functions.

 

There’s probably no way to recover the memory used of course… but do you think anything else would go horribly wrong if I used that technique in a real map?

[Sotha]

No idea. But I can't see why you would attach stuff to an entity, rather than simply have a mapname.script and use global variables in there.

 

It is easier to troubleshoot if you have it all in a single script file.

 

Here is an example of a loot cache I made long time ago:

http://wiki.thedarkm...Loot#Loot_Cache

[SteveL]

Hi Sotha. Thanks for the link, nice idea

 

I would still be using a map script to do the above. The "data container" entity would be populated by the script. The advantage of using the technique I was asking about is that you don't need to know in advance how many global variables you need, and the final code will be shorter.

 

Made up example: say I wanted to keep track of which AIs had passed through a trigger so I could make them all drop down dead (or whatever) later. I don't know when writing the code how many will do it, so I don't know how many global variables would be needed. I might also want to store some extra info like when they did it or in what order. Rather than create a set of global variable flags for each and every AI in that part of the map, I could just have the trigger fire a script that stores some info in the trigger:

 

void main()
{
  mytrigger.setKey("ai_count", "0");
}
void mytrigger_activated(entity someAI)
{
  float num_ais = mytrigger.getFloatKey("ai_count");
  num_ais++;
  mytrigger.setKey("ai_count", num_ais);
  mytrigger.setKey("tracked_ai"+num_ais, someAI.getName());
}

 

Then later on, I can just cycle through all the tracked_ai1 ...2 ...3 keys and retrive the list of AIs that had passed through the trigger in order. And any other info about it that I want to store in there.

Edited November 28, 2013 by SteveL

[Obsttorte]

If you use a single entity for each container you should get the memory back by simple erasing the entity (void remove() or so). Adding spawnargs during runtime shouldn't cause any problems.

[demagogue]

To be honest I do this a lot. I didn't find it a big resource hog & it's a simple & intuitive way to do things. You can define the spawnargs either in a .def file or with a script (if conditional), and then over the course of the game scripts can get or modify them as needed.

 

Edit: You could even think of entities as a natural unit of a system. This is how our brand of Location_Settings started, using the existing LS entity as a hub to drop useful location-sensitive spawnargs into, and then have a script attached to that, so it became a more developed location system in itself. So now dropping the entity into your level is a way to boot up the system in the level; it's intuitive like that. That's one way I think about it anyway.

[SteveL]

Excellent. Thanks guys. And I look forward to learning how to use location settings