Author Topic: User specifiable fields for BLS fields  (Read 582 times)

I want the ability to add fields of bricks to be saved when bricks are saved.

For example, when a brick is saved, a +-Owner fiels is saved, I would like to be able to force save files to include my own fields. I wrote an event that allows any brick to be turned into a water brick with a given current. When I save and load these bricks, I need to know which bricks were water bricks (my script dynamically creates physicalZones, and does not create new datablocks, so uiNames are out of the question). Currently I am doing this by checking if the brick had fxWater as its shapeFX, however there is no way to know what the current of the water was. I would like to be able to tell saves to be saved with a +-Current field that, when loaded would set brick.current (or whatever) to be the value it had when it was saved.

Can you put all of that into laymen's terms? I can't quite understand what you want. You want an add-on that saves brick zone variables?

I also want this.
Can you put all of that into laymen's terms? I can't quite understand what you want. You want an add-on that saves brick zone variables?
Allows you to add specific variables that are set on the brick to save. For example, if you did %brick.lastPlayerToTouch = "Destiny" you could call some sort of function like registerBLSField("lastPlayerToTouch"); and then that variable (%brick.lastPlayerToTouch) would be saved into the BLS file, then anyone that used that BLS file could load it up and %brick.lastPlayerToTouch would be set to "Destiny". It'd be a very useful tool.

Any sort of system like this would be jumped on by modders and we'd end up with a situation where your average save file size is x2/x3 the original size. People are not able to differentiate between things that need saving and things that don't, so they'll take the shortcut every time and register 20+ save types. Not to mention there would then be collision issues where two add-ons try to use the same ones.