func_forcefield + water + movable object = WTF?!

[grayman]

I've adjusted the force on objects with less mass than the player, so they no longer go flying off. I've gone back through existing missions to make sure they're not broken by this.

 

@LS: If you're on Windows, I can provide you a modified gamex86.dll that you can test with until 1.08 is released. This dll should NOT be released with your mission.

 

Could you use that?

[LordSavage]

I run Linux on all my machines (except for iPad).

 

Edit: Well, I have a Windows partition for some Windows only software on my notebook but there is no Doom 3, TDM or DarkRadiant installed.

[grayman]

Okay, then the fix will be available in 1.08.

[grayman]

I committed a fix for TDM 1.08 that adds a 'version' spawnarg to func_forcefield.

 

version 0 (default) is the current behavior used in all FMs to date.

 

version 1 scales the impulse for objects with a mass less than the player's, to give a more realistic result when the same forcefield is used for a variety of objects.

 

Objects with masses > player's mass (70) will behave the same in both versions.

[Tels]

I don't really like the direction this "versioning" is going. Hopefully we won't have to add more and more of this stuff.

[grayman]

I don't really like the direction this "versioning" is going. Hopefully we won't have to add more and more of this stuff.

 

The 'version' spawnarg is no different than any other behavior-modifying spawnarg. And the entities are chock full of them.

 

But pls feel free to propose, discuss, and implement a different solution.

[grayman]

For those who find the term 'version' unpalatable, would you be more comfortable with 'scale_impulse' or 'scale_uniform'?

[i30817]

I don't like forward compatibility, but backwards could be done by changing the setting of the default according to the version of the mod the map was originally compiled with?

 

Ie: as long as the map was not recompiled with a new version it would use the old settings, new maps get the "saner" behaviour by default?

 

Of course, if the map IS recompiled, there are bugs lurking, so maybe a warning would be in order?

Edited February 7, 2012 by i30817

[grayman]

I don't like forward compatibility, but backwards could be done by changing the setting of the default according to the version of the mod the map was originally compiled with?

 

Ie: as long as the map was not recompiled with a new version it would use the old settings, new maps get the "saner" behaviour by default?

 

Of course, if the map IS recompiled, there are bugs lurking, so maybe a warning would be in order?

 

Not sure what you're getting at, but recompiling a map doesn't tie it to a particular version of TDM. If the map uses a feature that first appears in rev N, it won't work with revs earlier than N, but it should continue to work in revs N, N+1, N+2, ...

 

And a default setting stays a default setting ad nauseum. Default just means the mapper didn't specify a particular setting, so the default setting is used. We don't reset defaults from rev to rev, because that could break older maps, which isn't allowed.

[Tels]

The 'version' spawnarg is no different than any other behavior-modifying spawnarg. And the entities are chock full of them.

 

But pls feel free to propose, discuss, and implement a different solution.

 

No I was not good at explaning it. Don't have a solution or want one for this case, but just in general I hope that we don't have to ad such version-specific overrides in many more places. (It would be more clean to fix the mission instead.) But it is understandable that this ins't an easy solution.

 

As for renaming of the spawnarg, yes that sounds a little bit more clear.

 

@grayman and the last post: Maps can advertise which version of TDM they require at minimum. So maybe the TDM code can (not nec. for this feature, but perhaps in other cases), use this to determine which behaviour to use? But still, this is tricky. Imagine a FM with TDM version 1.0 doing something, then the author upgrades it and raises the minimum version to v1.08 without changing the FM - it would break then.

[grayman]

I hope that we don't have to ad such version-specific overrides in many more places. (It would be more clean to fix the mission instead.) But it is understandable that this ins't an easy solution.

 

But it isn't an override. It's new behavior that's available in addition to the original behavior. Existing maps continue to work as intended, and new maps can use whichever behavior best fits their need. I honestly don't understand why this is seen as a problem.

 

As for renaming of the spawnarg, yes that sounds a little bit more clear.

 

Ok.

 

@grayman and the last post: Maps can advertise which version of TDM they require at minimum. So maybe the TDM code can (not nec. for this feature, but perhaps in other cases), use this to determine which behaviour to use? But still, this is tricky. Imagine a FM with TDM version 1.0 doing something, then the author upgrades it and raises the minimum version to v1.08 without changing the FM - it would break then.

 

TDM provides a set of features that expands with each rev. The only reason we'd want TDM to inspect a FM to find the minimum feature set is if there are features in earlier revs that have undergone improvements and we'd like to automatically upgrade to those improvements so that this FM can take advantage of them.

 

The simpler view is to support every feature in every set and provide feature improvements that don't break FMs that use earlier versions of that feature. This lets a FM live as is forever, unless it wants to use a new spawnarg that wasn't around back then, or it wants to include vine arrows, or a SEED entity, or it wants multiple ways of starting a map, or to use a new voice set, etc. And some feature improvements it gets for free, with no extra work on the mapper's part, like AI that no longer treadmill forever into a wall, improved ambient lighting, nice zippy arrow flight sounds, etc.

 

So TDM is already responding properly w/o having to worry about the initial rev the FM came out on. That info is for players, so they know not to try to f.i. run a map designed for 1.08+ with something pre-1.08.

[Tels]

But it isn't an override. It's new behavior that's available in addition to the original behavior. Existing maps continue to work as intended, and new maps can use whichever behavior best fits their need. I honestly don't understand why this is seen as a problem.

 

I see it as a problem because there should be one *right* (physically ccurate) behaviour and the mapper should not have to select at all. But it is certainly not a big problem, unless we add more of this stuff in the future. If there are too many choices, not only will mappers make the wrong choices, but also they have more work to do.

 

It is the same with the "lighting falloff" choice in the ambient light location system - nobody at all sets the value, because nobody understands it or does even know it exists. And the default value is wrong (inaccurate for big rooms with distant lights). So you end up with all maps using the wrong values.

 

If I had a chance to redo that, I would have added just the right value, left the options out and forced that on mappers. That way players would get the right behaviour without the mapper doing anything.

 

This is purely a "design problem".

 

TDM provides a set of features that expands with each rev. The only reason we'd want TDM to inspect a FM to find the minimum feature set is if there are features in earlier revs that have undergone improvements and we'd like to automatically upgrade to those improvements so that this FM can take advantage of them.

 

The simpler view is to support every feature in every set and provide feature improvements that don't break FMs that use earlier versions of that feature. This lets a FM live as is forever, unless it wants to use a new spawnarg that wasn't around back then, or it wants to include vine arrows, or a SEED entity, or it wants multiple ways of starting a map, or to use a new voice set, etc. And some feature improvements it gets for free, with no extra work on the mapper's part, like AI that no longer treadmill forever into a wall, improved ambient lighting, nice zippy arrow flight sounds, etc.

 

So TDM is already responding properly w/o having to worry about the initial rev the FM came out on. That info is for players, so they know not to try to f.i. run a map designed for 1.08+ with something pre-1.08.

 

After reading this before my morning caffee, I thin this is exactly what I was writing?

 

(Minor point: the minimum version requirement is hard enforced - or at least it should be. If the author says "you need version x to run this mission", then TDM < x should not load this mission at all - this will only lead to problems. But I think greebo already added that to the code.)

[OrbWeaver]

I see it as a problem because there should be one *right* (physically ccurate) behaviour and the mapper should not have to select at all. But it is certainly not a big problem, unless we add more of this stuff in the future. If there are too many choices, not only will mappers make the wrong choices, but also they have more work to do.

 

Yeah, the conflict here is between changing default behaviours (with no spawnargs set) that would break existing maps, and requiring mappers to always set a spawnarg on new entities in order to get the "correct" rather than the "deprecated" default behaviour. I see this as a usability problem that could be addressed in the editor: perhaps the .def files could specify default spawnargs and their values which should be explicitly set on newly-created future entities, which mappers would have to specifically remove if they wanted the old behaviour.

[grayman]

Btw, I changed 'version' to 'scale_impulse' and updated the forcefield wiki.

[grayman]

I see this as a usability problem that could be addressed in the editor: perhaps the .def files could specify default spawnargs and their values which should be explicitly set on newly-created future entities, which mappers would have to specifically remove if they wanted the old behaviour.

 

How would this work? If mappers have to specifically remove a setting they get when they drop an entity into a map, to get back to the old behavior, that says the *.def file is set up to deliver the new behavior by default. But if that's the case, old FMs that rely on the old behavior will be given the new behavior and then they'll break.

[OrbWeaver]

How would this work? If mappers have to specifically remove a setting they get when they drop an entity into a map, to get back to the old behavior, that says the *.def file is set up to deliver the new behavior by default. But if that's the case, old FMs that rely on the old behavior will be given the new behavior and then they'll break.

 

Right, I'm talking about another layer of "default" which is interpreted only by the editor, not the game. For example, for this example you could use something like

 

entityDef blah {
   "scale_impulse" "0" // default if no spawnarg set, for old maps
   "editor_addProperty" "scale_impulse:1" // DarkRadiant will add key by default, overriding the "base" default
}

 

This would result in the improved behaviour being set for new entities created in the editor, but old maps with entities that had no such spawnarg would maintain the previous behaviour.

[grayman]

Ah, I see.

 

But wouldn't it cause some confusion?

 

The wiki says "this is the default behavior", and the mapper drops the entity into his map and does nothing to it. He expects the default behavior described by the wiki but gets a different default behavior. It seems the wiki would need to change what it says about the default behavior.

 

Also, what about this:

 

1 - I'm basing a new map on features found in SVN, getting it ready for the next TDM release. I do regular daily SVN udpates.

2 - My map has a few of these entities set up the way I want them, with the (old) default behavior.

3 - The *.def file gets changed as you suggested and my daily SVN update pulls it in.

4 - I drop a new entity into my map, and unbeknownst to me, DR gives it the (new) default behavior.

 

My expectation is that my entities will all behave the same, but I've got an odd man out in there.

 

It seems that default behavior is default behavior is default behavior. The only way you switch to new default behavior is to declare that certain maps that relied on the old default behavior are now broken and need to be rebuilt and moved forward.

[Tels]

There is already a way to make this work, AND make it obvious to the mapper.

 

This:

 

"editor_setKeyValue scale_impulse"	  "1"

 

This cause any entity it is on when it is created to aquire the spawnarg "scale_impulse" with a value of 1. So the default is 0, but any entity created in the editor carries the value 1 - and since it is in the list of spawnargs, the mapper can see what the current value is. And if he doesn't like it, delete the spawnarg.

 

Problem solved already

[OrbWeaver]

There is already a way to make this work, AND make it obvious to the mapper.

"editor_setKeyValue scale_impulse"	  "1"

 

Indeed, so there is. I didn't realise this exact functionality was already implemented.

 

Grayman's concerns about changes after an update are valid, but I think this is really unavoidable — whenever you update from SVN there is the potential that some behaviour is going to change in a way that is inconvenient for the map you are working on.

[Tels]

Indeed, so there is. I didn't realise this exact functionality was already implemented.

 

Yeah, greebo is fast - he must have a time machine

 

Grayman's concerns about changes after an update are valid, but I think this is really unavoidable — whenever you update from SVN there is the potential that some behaviour is going to change in a way that is inconvenient for the map you are working on.

 

Yeah, I think this is unavoidable - and it occurs seldom enough, too.

[LordSavage]

There is already a way to make this work, AND make it obvious to the mapper.

 

This:

 

"editor_setKeyValue scale_impulse"	  "1"

 

This cause any entity it is on when it is created to aquire the spawnarg "scale_impulse" with a value of 1. So the default is 0, but any entity created in the editor carries the value 1 - and since it is in the list of spawnargs, the mapper can see what the current value is. And if he doesn't like it, delete the spawnarg.

 

Problem solved already

 

Sounds like a good solution!

[i30817]

It is a good solution : i'd only caution for warning when Darkradiant opens old maps whose default spawnarg changed; maybe log those warning to a file too.

 

A sort of "hey hey, you better look at this", until it is recompiled from a "old default version" to a "new default version". If the setting is not default, BUT the different versions didn't have a default change, then no new warning (but keep the persistent file).

Edited February 13, 2012 by i30817