vValue and DCT

[Luke-Jr]

vValue is currently working well, but it is limited by a lack of ability to interact with many aspects of the game, and its usage is restricted to maps (at best). Dynamic Config Tree is the next step toward making vValue fully usable. DCT is a revamping of our config system. At the most basic level, it is a set of configuration settings stored as vValues. These configuration settings can be accessed via multiple entry points from a tree of objects and attributes. For example:

Code: Select all

Game
-Match
--Round
---Grid
----Cycles[1..n] (cycle object)
-----Player (player object)
------Name
------URI
------etc
-----Colours
-----Position (coordinate object)
------x
------y
-----etc
MyPlayer (player object)
-Cycle (cycle object)

None of these attributes are fixed even at compile-time: servers may add new settings at will, and expect clients to keep track of them.
vValues can reference arbitrary attributes in the tree using either relative or absolute paths. Thus, a server could invent a new attribute and reference it from cycles or other game elements.

This allows for much better server-side control while keeping clients able to perform predictions and the like. It will be possible to use vValue+DCT alone to do some very basic scripting, given some skill (I think it would be similar to the prolog language, but this is hearsay). At the same time, real scripting can be done server-side and use vValue+DCT to communicate enough physics and rule changes to clients for predictions without the client needing scripting capabilities itself.

[Z-Man]

Hmm, currently, with the progress with Io I'm making, I'm rather thinking that secure scripting will be possible and that any form of limited scripting would be a waste of time. Of course, that may change anytime I run into the template/macro wall.

[Luke-Jr]

Hmm, currently, with the progress with Io I'm making, I'm rather thinking that secure scripting will be possible and that any form of limited scripting would be a waste of time. Of course, that may change anytime I run into the template/macro wall.

Scripting is still scripting and has overhead as such. vValue isn't meant for scripting, that's why it's "limited".

[Z-Man]

For the purpose you gave, speed isn't really that critical. Extrapolation is not done a tousand times per frame. Also, the main problems we see so far aren't the continuous extrapolation problems (like zones not moving on straight lines, but on bent lines, or cycles accelerating in other ways than the client thinks) but the discreet ones: zones being the "ball" and getting kicked around, and cycles supposedly being invulnerable, thus passing through every wall, but the client failing to know that. Only a real scripting language with conditionals would be able to solve those.

But: There is another place where a speed optimized, limited expression evaluator has its place: The renderer. We could use it to animate textures, to dynamically calculate texture coordinates or even transform vertices. Provided we don't want to go the hardware shader route, where we get similar functionality for no CPU time at all.

[Luke-Jr]

Rendering doesn't need to know the position of cycles and walls? Or the colour of cycles? That stuff would be specified by vValues in the DCT...

[Luke-Jr]

Oh, and an important part about DCT I forgot to mention: resources should be directly loadable into the tree. This means any aspect of the config can be saved to a XML resource. It also means we can allow saving/restoring Arma games easily.

[Lucifer]

Can we clear up a little misunderstanding bout vValue? It's not supposed to be a scripting engine, it's just supposed to provide some expressions for use in a few places. I think luke only suggested it could be expanded into a full-blown scripting engine for fun, but it looks like that's the part that's been focused on instead of what he's actually working on it for.

Last I heard, the purpose of vValue was to let you do things like:

<zone optionsyadayada>
<point x="x(t)" y="y(t)">
</zone>

Where x(t) and y(t) would be replaced with expressions that would be evaluted at each timestep to place the zone and would provide some movement to the zone. There are quite a few places we've figured out that would benefit from having a value specified as an expression rather than a constant. There's been some disagreement on whether or not restricting these expressions to functions would be useful, but there is very little disagreement on whether or not having expressions themselves would be useful.

This would be independent of scripting, which would allow a server and client to have this feature whether or not scripting was compiled in. I've suggested that we use our scripting engine (whatever it winds up being) to evaluate these expressions when scripting is built in, but that received a mixed reaction. One problem is that the scripting engine would probably allow extended use of the expressions themselves, which would make them incompatible with our own vValue implementation. Otherwise, the vValues themselves aren't intended to interact directly with scripting. By directly, I mean there's no syntactical or interpreter context that includes the actual text of the vValue, but obviously the scripting engine will have support for vValue itself and an interface to use vValues.

The work was started back when there was no sign of scripting appearing anytime soon in the game. I'm starting to consider whether or not it's useful in that form since it looks like we'll have actual scripting in the next release, but as always luke can spend his time doing whatever we want, and I think our own vValue implementation will be useful, even if its usefulness is somewhat limited in the presense of a real scripting environment.

[Luke-Jr]

Can we clear up a little misunderstanding bout vValue? It's not supposed to be a scripting engine, it's just supposed to provide some expressions for use in a few places. I think luke only suggested it could be expanded into a full-blown scripting engine for fun, but it looks like that's the part that's been focused on instead of what he's actually working on it for.

Correct, vValue's purpose is not scripting, but I've only said that in the last 2 of my posts here...

Last I heard, the purpose of vValue was to let you do things like:

<zone optionsyadayada>
<point x="x(t)" y="y(t)">
</zone>

Where x(t) and y(t) would be replaced with expressions that would be evaluted at each timestep to place the zone and would provide some movement to the zone.

Correct, though we might at some points want to optimize it to not evaluate every timestep (only reevaluate when the result would change)

Otherwise, the vValues themselves aren't intended to interact directly with scripting. By directly, I mean there's no syntactical or interpreter context that includes the actual text of the vValue, but obviously the scripting engine will have support for vValue itself and an interface to use vValues.

Not sure what you mean by this, but the only interaction scripting would have would be to get the actual current value of a setting, or to set the setting to a new expression (either as a parsed string or by creating objects).

The work was started back when there was no sign of scripting appearing anytime soon in the game. I'm starting to consider whether or not it's useful in that form since it looks like we'll have actual scripting in the next release, but as always luke can spend his time doing whatever we want, and I think our own vValue implementation will be useful, even if its usefulness is somewhat limited in the presense of a real scripting environment.

1) You don't seem to want automatic script downloads; thus, clients still need this to not be left in the dark as to certain server-side features.
2) This allows arbitrary settings to be defined by any part of the game, including resources. For example, a cockpit can define its own configuration settings.
3) We can move all game logic, rules, prediction, etc into DCT as settings. Things like cycle acceleration and speed become arbitrarily defined settings that have no inherent use by the C++ code. They are instead referenced by a vValue used to determine a cycle's position.

[Z-Man]

Crap. That bloody login prompt destroyed my post. And the censoring system is destroying my cursing. I'll try to restore:

I don't doubt vValues usefulness, it's rather close to what I thought tFunction would become. However, it should know it's place. I think it should be used as a replacement for full blown script where the script can't be used* or can be used, but with a too big performance penalty (in core rendering routines, ignoring Luke's trolling attempt since in the end, ALL data ends up in the renderer). I'd optimize vValue for that purpose. I'd probably restrict it to floats, that gives it extra speed. Let the configuration tree handle the variety, make it store floats, ints, bools, strings and vValues.
Or, alternatively, I'd develop a good scripting language from it. Which is NIH syndrome.

About the DCT: that sounds like script to me, too In the scripting languages I know, objects are essentially maps from symbols to other objects (a tree), and some objects are values (the tree nodes). So again, it may just be that the script will give us a DCT implementation essentially for free. Even with prototypes: you could say "create some new game settings here, for use only for this one cycle there. Change only the speed, this should be the snail cycle.". And cross-references.

Persistence, BTW, is nontrivial even with the best tools. That is because of the various relationships objects can have to each other. Especially, they don't form a tree. And they form relationships with objects that are not persisted. You have to make sure that "Player 1" from the savegame is the same "Player 1" that was already created by the menu system.

* because, say, the expression needs to be downloaded to the client and we can't allow it for our script choice, or because scripting is optional and we want that flexibility anyway. Neither of which is set in stone. Ruby and Io seem to support safe downloads, and Io and Lua would be small enough to be distributed with the game and thus be mandatory.

[Lucifer]

Well, if Io and Lua are that small, we should seriously consider just using the scripting engine for this, to be honest. I'm thinking about 2 things here. First, vValue and tFunction and all that stuff were dreamed up before scripting was started, and under the belief that we could get some third-party code to do it (and we failed, somehow, still haven't figured out how, but that's a different argument). Second, under the assumption that scripting support would be optional because the scripting we've talked about was always using something big and bulky.

The first isn't true anymore, there will be at least ruby in 0.3.0. The second is still conditionally true, but I've been paying attention to the Io thread somewhat.

So, like I say, if Luke wants to still do it, that's his prerogative, so long as he doesn't mind terribly if we later discover it's not useful in light of where scripting went. If I were he, I'd wait and see how the Io thread works out.

[meriton]

Out of curiosity: What do we want to accomplish by scripting support? (I see plenty of threads about the details, but what is the big picture?)

[wrtlprnft]

Well, some things I'd like to see possible:

• Native map rotating without everytime.cfg or piping into arma.
• Implement game modes like styball, ctf, htf, CvS as scripts and don't bloat the game with them. All you need for that is a reasonable interface for zZone/gZone
• Stat scripts
• A script for tournaments and the like that keeps scores and so on

All ideally suited for scripting IMHO.

[Luke-Jr]

About the DCT: that sounds like script to me, too In the scripting languages I know, objects are essentially maps from symbols to other objects (a tree), and some objects are values (the tree nodes).

More or less, the tree structure is similar to our C++ layout, and could easily be useful as our API for scripting as well. But objects-and-properties alone don't make a scripting language.

So again, it may just be that the script will give us a DCT implementation essentially for free.

Or vice-versa.

Persistence, BTW, is nontrivial even with the best tools. That is because of the various relationships objects can have to each other. Especially, they don't form a tree. And they form relationships with objects that are not persisted. You have to make sure that "Player 1" from the savegame is the same "Player 1" that was already created by the menu system.

That's why we're identifying users by their URI.

Well, if Io and Lua are that small, we should seriously consider just using the scripting engine for this, to be honest.

Why force people to learn a scripting language when they can just set a few config options? Also, some settings are related to rendering, and thus need to be at least decently fast.

I'm thinking about 2 things here. First, vValue and tFunction and all that stuff were dreamed up before scripting was started, and under the belief that we could get some third-party code to do it (and we failed, somehow, still haven't figured out how, but that's a different argument).

Third-party code was never in vValue plans...

Second, under the assumption that scripting support would be optional because the scripting we've talked about was always using something big and bulky.

Scripting support should still be optional, and vValue/DCT allows us to move even our existing prediction code out of the client without losing the benefits.

The first isn't true anymore, there will be at least ruby in 0.3.0.

The first is true, it is still a requirement and must be true before a stable release.

So, like I say, if Luke wants to still do it, that's his prerogative, so long as he doesn't mind terribly if we later discover it's not useful in light of where scripting went. If I were he, I'd wait and see how the Io thread works out.

Does Io provide efficient caching of expressions?

As far as scripting uses, in DCT.txt, I've noted plans to move certain currently built-in capabilties into the scripting realm.

[meriton]

Well, some things I'd like to see possible:

• Native map rotating without everytime.cfg or piping into arma.
• Implement game modes like styball, ctf, htf, CvS as scripts and don't bloat the game with them. All you need for that is a reasonable interface for zZone/gZone
• Stat scripts
• A script for tournaments and the like that keeps scores and so on

All ideally suited for scripting IMHO.

That means scripts are part of the arena, and are thus replicated to the clients, which then execute them as part of their arena simulation?

[dlh]

Does vValue actually work now? Can it parse expressions and return the result? Right now we need an expression parser, so we can do what Lucifer has cited:

Code: Select all

<Zone …>
    <Point x="x(t)" y="y(t)" />
</Zone>

However I'm slightly confused. What would be the parameters passed in to the function? The current time? I just wrote a “expression” parser, in about 210 LOC. It is stack-based, which looks like this if you've never heard of it (2 2 *, or more succinctly 2 dup *). If you're in #armagetron there is a #rpn chat command, which does the same thing.