Guild of Writers

AFAIK You should *never* remove lines from an SDL file. It's bad practice in general. I don't know if it causes any problems, but I have noticed Cyan never seems to do it.

If you look at how SDL blobs are stored, you will find that they are *very* dependent on the *exact* structure of an SDL definition being consistent. This is why *any* changes to SDL should be done in a new descriptor (so the engine can extract the old data, reformat it, and then re-store it into the new blob format). Otherwise, existing SDL blobs can cause major problems if the format it expects to parse it with has changed...

I also already fought with the crazyness of SDL parsing and streaming (both the .sdl files and the blobs)
If I understood it correctly, UruDistro will always copy the latest STATEDESC block and then apply the modifications (if it does not do it, that definitely has to be implemented - I just assumed it as I expected Chacal to know that an existing STATEDESC block must never ever be modified). So removing a line, while uncommon, would work then. If you really decide that while the XML allows it, UruDistro will not do it, please make the script fail (instead of silently skipping) so that people notice it.

Thanks, you all are quite right.
Just to make it clear, to add or modify a SDL variable, the install script does the same operations that we do manually:
- find the last version of the statedesc (a block of text)
- copy it
- add or modify a variable (a line) in it
- increment its version number
- append it at the end of the file.

To reverse our change, I first thought I could simply remove this version we added. But it may cause problems with the engine, and it may make the sdl file incoherent if another change has been applied after ours. The proper way to reverse our change is thus to process this as a new change, adding a new version, with the old value of the variable.

The operations would look like this:

sdl delobj
(makes no sense at all so not implemented)

sdl addobj
install: add a new version of the last statedesc block, add or replace a line in it
( add an addobj to the uninstall xml with the old value)

uninstall: add a new version of the last statedesc block, add or replace a line in it with the old value

I think the simplest way of making sure only the proper operations authorized is to enforce them in two different DTDs, one for install and one for uninstall.
Basically, for installs a delobj is authorized only for prp objects, never for files, age, fni, sdl.
For uninstalls a delobj is authorized only for file, prp and age objects, never for fni or sdl.

I still vote for being able to use delobj on all objects. It needs to be implemented anyway for uninstalling, and the restrictions in my eyes somehow "break" the really nice design. There might be use cases for it in future, and if people want to mis-use it that would be quickly known anyway.

For uninstalls a delobj is authorized only for file, prp and age objects, never for fni or sdl.

That one I do not understand... how do you want to uninstall an addobj on an sdl or fni file? And why did you put fni on this list at all...?!?

It's all a question of finding the reverse of an operation. See previous post on this. The reverse of an addobj is not always a delobj, it depends of the type of game file.

For the <file> section, an addobj means adding a file, or replacing a file if it already exists (for example, replacing a prp with a new prp).
Uninstalling that means: if the file existed before, replace the one we put by the old one (that's an addobj). If not, just delete the one we put (that's a delobj).

For the <sdl> section, an addobj means modifying an sdl file (not adding an sdl file):
- find the last version of the statedesc (a block of text)
- copy it
- add or replace (if it existed before) a variable (a line) in it
- increment its version number
- append it at the end of the file.
Uninstalling that is not a delobj, since we never delete versions of statedescs in sdl files. We must add a new version but without the variable we added previously, or with the old value if it existed. So it is in fact an addobj with a different value.

For the <fni> section, an addobj means replacing an old value of a setting with a new value (I don't think we can add new settings, the plasma engine would not know what to do with it).
Uninstalling that means putting back the old value, so it is an addobj with a different value.

For the <age> section, an addobj means adding a new page (a line in the age file), or replacing one if it already exists (for example, if we just want to add a ",1" to force loading a page).
Uninstalling that means putting back the old value if it existed (an addobj with a different value), or deleting the line with our new page, which is a delobj.

So as you see, delobjs don't always make sense.

However, for fnis, it can be that the setting was not set in the fni file at all before we changed it, so addobj would add something, and the reverse would be a delobj. One could also adda comment which is removed later.

And for SDL files, I would actually make that differently: I would consider addobj and delobj to talk about the available variables. addobj would mean "copy the STATEDESC and add/replace the line", while delobj would mean "copy the STATEDESC and remove the line". That would IMHO make the most sense, as otherwise there would have to be an addobj which removes a var (the reverse of an addobj which adds a new var), which hardly makes any sense. The fact that under the hood, no matter what you do, the SDL file grows, should be encapsulated by the distribution system. The comment argument also applies here.

Yes, that makes sense.

I'm still wondering how to handle plSceneObject deletions in prps.
I am considering adding a new action "delobjall".
Action "delobj" would delete only the plSceneObject from the prp.
Action"delobjall" would do all this:

delete the visible object from plDrawableSpans
delete the plDrawableInterface object
delete the physical object (plGenericPhysical object)
delete the plSimulationInterface object
delete the plCoordinateInterface object
delete the plSceneObject object
remove the plSceneObject entry from the plSceneNode object

This makes sense, but figuring out the rollback for this is gonna be a bitch.