The UruDistro.xml file

Announcements and discussion regarding Chacal's UruDistro

Moderator: Chacal

Re: The UruDistro.xml file

Postby Tsar Hoikas » Thu Jul 09, 2009 10:22 am

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.
Image
User avatar
Tsar Hoikas
Councilor of Technical Direction
 
Posts: 1919
Joined: Fri Nov 16, 2007 9:45 pm
Location: South Georgia

Re: The UruDistro.xml file

Postby Zrax » Thu Jul 09, 2009 11:36 am

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...
User avatar
Zrax
 
Posts: 204
Joined: Fri Sep 28, 2007 5:19 pm
Location: Waist-deep in a conecano

Re: The UruDistro.xml file

Postby diafero » Thu Jul 09, 2009 12:13 pm

I also already fought with the crazyness of SDL parsing and streaming (both the .sdl files and the blobs) :lol:
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.
I prefer e-mails to "diafero arcor de" (after adding the at and the dot) over PMs.

"Many people's horizon is a circle with a radius of zero. They call it their point of view."

Deep Island Shard | Offline KI
diafero
Deep Island Admin
 
Posts: 2824
Joined: Mon May 05, 2008 5:50 am
Location: Germany

Re: The UruDistro.xml file

Postby Chacal » Thu Jul 09, 2009 12:35 pm

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.
Chacal


"The weak can never forgive. Forgiveness is an attribute of the strong."
-- Mahatma Gandhi
User avatar
Chacal
 
Posts: 2442
Joined: Tue Nov 06, 2007 2:45 pm
Location: Quebec, Canada

Re: The UruDistro.xml file

Postby diafero » Fri Jul 10, 2009 8:34 am

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...?!?
I prefer e-mails to "diafero arcor de" (after adding the at and the dot) over PMs.

"Many people's horizon is a circle with a radius of zero. They call it their point of view."

Deep Island Shard | Offline KI
diafero
Deep Island Admin
 
Posts: 2824
Joined: Mon May 05, 2008 5:50 am
Location: Germany

Re: The UruDistro.xml file

Postby Chacal » Fri Jul 10, 2009 9:43 am

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.
Chacal


"The weak can never forgive. Forgiveness is an attribute of the strong."
-- Mahatma Gandhi
User avatar
Chacal
 
Posts: 2442
Joined: Tue Nov 06, 2007 2:45 pm
Location: Quebec, Canada

Re: The UruDistro.xml file

Postby diafero » Fri Jul 10, 2009 1:08 pm

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.
I prefer e-mails to "diafero arcor de" (after adding the at and the dot) over PMs.

"Many people's horizon is a circle with a radius of zero. They call it their point of view."

Deep Island Shard | Offline KI
diafero
Deep Island Admin
 
Posts: 2824
Joined: Mon May 05, 2008 5:50 am
Location: Germany

Re: The UruDistro.xml file

Postby Chacal » Fri Jul 10, 2009 1:50 pm

Yes, that makes sense.
Chacal


"The weak can never forgive. Forgiveness is an attribute of the strong."
-- Mahatma Gandhi
User avatar
Chacal
 
Posts: 2442
Joined: Tue Nov 06, 2007 2:45 pm
Location: Quebec, Canada

Re: The UruDistro.xml file

Postby Chacal » Tue Dec 07, 2010 4:28 pm

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.
Chacal


"The weak can never forgive. Forgiveness is an attribute of the strong."
-- Mahatma Gandhi
User avatar
Chacal
 
Posts: 2442
Joined: Tue Nov 06, 2007 2:45 pm
Location: Quebec, Canada

Previous

Return to UruDistro

Who is online

Users browsing this forum: No registered users and 1 guest

cron