think I'll make a quick note about this somewhere - while dmls can do a lot of things in a very convenient way, there are limitations one should be vary of;

- anything that requires mission reprocess will not work (like modifying light properties).
- there are limits on what you can do with an object that has physics, you will not be able to move an object which has physics, and you won't be able to modify any physics related properties (like radius) by regular means.

- you can work around this partially by removing the PhysType from the object, moving it to the desired location, and then assigning a PhysType to it again. do note that when you do this, the PhysType you assign in the end always needs to be OBB (submodels 6), if you try anything else, the object will end up with no physics (no explanation, it just works that way).

- while you won't be able to change any physics related settings, you can reset them by reloading the PhysType on the object (remove it, and readd it, and again, the only one you can readd is OBB with submodels 6), and all the physics properties will be re-inherited from the archetype. you can set the desired properties on the archetype via gamesys.dml (do note that this will affect things globally, so make sure you won't do something that will break things).

-when adding scripts, always add a null script if you are adding less then four;
+ObjProp xxx "Scripts"
{
"Script 0" NVRelayTrap
"Script 1" ""
"Script 2" ""
"Script 3" ""
"Don't Inherit" false
}
if you don't fill in the "" value, any script that is on the respective position on the archetype will get re-inherited, causing all sorts of evil stuff to happen (more instances of the same script is a bad thing).


when making dmls, it's always prudent to check whether they actually work - either add dbmod_log 10 to your cam_ext.cfg and examine dbmod.log after you run the game and load the level with its dml, or open the level in editor and load the dml into it via the dbmod_load command. if you've screwed something up, the log (or the console) will spew out errors.

however, to check whether they really, positively get applied, you will need to run the game, make a save, start up the editor, type set game_mode_backup 0 into the command windows (and press enter), then go to the game mode, load that save, go back to the editor mode, and check the object in question manually (for example, when trying to modify climbable sides of a ladder, all logs looked fine, but when trying things ingame, it looked liked the dml was not getting applied, and doing the extra check has confirmed that it was not, as it's a physics property).


will add more stuff if I find something interesting.

you can create new objects via dmls (setting up an existing junk object as non-rendered physicsless tweq trap and triggering it in some smart way), but I don't think you will be able to link the spawned object to anything, as you have no way of knowing the spawned object's id.

but yeah, the OneRifledSlug would be an impossibility. //edit ND 2.48 - this no longer is the case, dml archetypes can be created now.

nope, act/react cannot be dml modified as far as I know - just as you said, no mention of this in the proplist.

//the latest NewDark supports this.

I tried that at first, but I was doing it wrong. The lowly pistol setup gave me the right answer: setup the "Setting" number as -1 instead of either 0 or 1.

Any ideas on how to get the little picture and text in the ammo display right? An unmodded emp rifle shows a little lightning bolt in the ammo display plus the text "EMP". Once modded, the display has no picture or text. For now, I would like to keep the lightning bolt, but have the text say "ELEC".

Ok if I'm reading this right, the dml system can change in game variables or scripting?

I'm sorry if i'm anoying as hell.

I really need to make a sort of headtracking work for my project.
Just learning ss2 modding while I am at it.

But yeah opened some .dml's and saw what u mean "in game object config files"

- there are limits on what you can do with an object that has physics, you will not be able to move an object which has physics, and you won't be able to modify any physics related properties (like radius) by regular means.

I just found the hard way that this isn't exactly true...

You can move objects that have physics - they just won't stay moved. One minute they are where you put them and the next they are back where they came from. Was just going to ask for a clue when the answer was here all along.

I wanted to do it, therefore it was absolutely necessary.

I wanted to see what happens when you mix ammonia and bleach.  Therefore...

it's still not working, but in this case, the limitation will not cause any serious problems. basically, the SFG will just end up with no physics (even though you assigned sphere), meaning it won't be affected by physical force (explosions and similar). you will still be able to pick it up, and once you do that, all potential problems will be gone, as once you drop it, the physprops will get reinherited from the archetype.

try moving a turret if you want to break things.

they do, but not very much, afaik. that's why I'm saying, not having physics on a weapon in the world is ok for all practical purposes - you have to be really, really observant to notice the difference.

so if you want to dml move a weapon, feel free to - should carry very little risk, if any.

\" is probably what is causing the problems. I think you will have to avoid those.