Event-driven variants

[zoot]

This is an idea I've been toying with and might implement if it doesn't break anything:

It should be possible to define a prop as only being shown if a certain condition is met.

This would be useful for a number of things:

- Showing different/more props for different phases.

- Showing different/more scaffolding objects as the construction of a building progresses.

- Showing different/ruined props on damaged buildings.

- etc.

Any comments on how/if this should be done? Specifically, what should the conditional test against? A JavaScript expression? Something else?

(While looking into this I came across a link to this sikrit topic that might be informative. Perhaps someone could file a FOIA request for me? )

Edited August 16, 2012 by zoot

[MishFTW]

That would be cool. Perhaps some parameters affected by map biome?

[Wijitmaker]

This should be possible right now by the config in the actor. For example, right now when a citizen soldier goes to a tree to chop wood, they drop the sword and shield and switch to an axe. What you are wanting to do should be pretty easy - just would need a hook to utilize the variant name.

See here: http://trac.wildfiregames.com/browser/ps/trunk/binaries/data/mods/public/art/actors/units/celts/infantry_javelinist_a.xml

I'm not sure if this would help, but you could bring in different props in an "animation" with the events of an actor - this is used on archers and javelists. See here: http://trac.wildfiregames.com/browser/ps/trunk/binaries/data/mods/public/art/actors/units/celts/infantry_javelinist_b.xml

If you would like to do something like visible city phases - I would think that you could do it similar to units and how they upgrade through experience - basic, advanced, elite.

It would require 3 separate actors though.

[historic_bruno]

You might also look into actor variables, which are currently used only for construction dust particles via the "numbuilders" variable, but maybe could be extended to control other things.

[zoot]

If you would like to do something like visible city phases - I would think that you could do it similar to units and how they upgrade through experience - basic, advanced, elite.

It would require 3 separate actors though.

Hmm. The problem is that if you also wanted 3 levels of destruction, that would be 3*3=9 actors, and you would need to name each of them in some hacky way (like "town_destroyed3") and then try and put the right name together at runtime. Also, a structure like the Celtic house already has 3 variants, so that's effectively 9*3=27 variants, and you would need some way to couple the randomly selected variant to the matching upgraded/destroyed actors.

In the end, I think it would be tidier to branch inside the actor files somehow.

Edited August 9, 2012 by zoot

[Enrique]

Hmm. The problem is that if you also wanted 3 levels of destruction, that would be 3*3=9 actors, and you would need to name each of them in some hacky way (like "town_destroyed3") and then try and put the right name together at runtime. Also, a structure like the Celtic house already has 3 variants, so that's effectively 9*3=27 variants, and you would need some way to couple the randomly selected variant to the matching upgraded/destroyed actors.

In the end, I think it would be tidier to branch inside the actor files somehow.

Hmm... thinking about it, instead of making 3 custom destruction props for each building, I wonder how may look the following: making just 3 generic destruction .daes. This would be destruction props animated from the center to the outside in a "exploding manner" showing them based on the building health. Like "fake" physics.

[zoot]

Hmm... thinking about it, instead of making 3 custom destruction props for each building, I wonder how may look the following: making just 3 generic destruction .daes. This would be destruction props animated from the center to the outside in a "exploding manner" showing them based on the building health. Like "fake" physics.

You mean like shrapnel? That would be a transient effect/animation? It might look okay, but IMO you would still want a custom damaged model/actor/something for the sake of relaying building health info to the user for structures that were damaged off-camera.

[Enrique]

You mean like shrapnel? That would be a transient effect/animation? It might look okay, but IMO you would still want a custom damaged model/actor/something for the sake of relaying building health info to the user for structures that were damaged off-camera.

Not sure what do you refer with shrapnel...

I think building destruction should be more discussed (or I missed important threads about it). I tested some days ago playing with destruction decals on the buildings, but due to the "sharing" nature of our textures and tiling, the tests looked weird/unconvincing. However, with the addition of a new UV coordinates that Myconid introduced there may be a better way for decals.

My idea is to have 2 levels of destruction (aside of the good health building look)

-First destruction level adds destruction decals, and adds the destruction props with animation.

-Second destruction level adds another destruction prop, and fire. (same decals)

[zoot]

-First destruction level adds destruction decals, and adds the destruction props with animation.

What would the animation do?

[Enrique]

What would the animation do?

Fake physics of debree, kind of "exploding" from the building center, falling to the ground and finishing the animation being static, not too far away from the foundation limits.

Since making models for every building in each destruction estate is too much work, this destruction damage idea came to my mind.

[feneur]

(While looking into this I came across a link to this sikrit topic that might be informative. Perhaps someone could file a FOIA request for me? )

That's just http://trac.wildfiregames.com/wiki/XML.Actor but in forum form instead. Note that it's outdated, so http://svn.wildfiregames.com/entity-docs/ and in your case probably more specifically http://svn.wildfiregames.com/entity-docs/#component.VisualActor should be more relevant It might be a bit outdated as well, but if so it's more of "missing information" kind, the page you linked to might actually contain inaccurate information.

[zoot]

Thanks.

[zoot]

I think the best solution will be to do something like "sub-variants", i.e. once the engine has picked one variant, there can be more levels of variants under that variant that will be activated on the basis of some kind of conditional.

[zoot]

That's just http://trac.wildfiregames.com/wiki/XML.Actor but in forum form instead. Note that it's outdated, so http://svn.wildfiregames.com/entity-docs/ and in your case probably more specifically http://svn.wildfiregames.com/entity-docs/#component.VisualActor should be more relevant It might be a bit outdated as well, but if so it's more of "missing information" kind, the page you linked to might actually contain inaccurate information.

The link says:

Conditional variant groups aren't yet implemented at time of writing, but Philip has a plan for linking the variant strings to global and entity events, detailed here: http://www.wildfiregames.com/forum/index.php?showtopic=1799#

I can't see any description of such a plan in the pages you linked to. Is there something else in the topic, perhaps further down in the comments?

[historic_bruno]

The link says:

I can't see any description of such a plan in the pages you linked to. Is there something else in the topic, perhaps further down in the comments?

Philip's mysteriously referenced plan describes the actor system exactly as it is now The discussion in the staff forum is from 2004-5 and actually predates the terribly outdated info on Trac. By "conditional variants" I assume the author was referring to selecting a variant in response to game conditions, like chopping a tree, wielding a sword, etc., which is of course possible. The only thing proposed that isn't possible yet is "global variants" which would affect all actors in the game, there's a TODO about that in CUnit, but since seasons are the only given example and we don't want seasons, it's super low priority.

Don't trust anything you read on Trac pages beginning with XML.* as they are hopelessly outdated and need replacing It's only a question of finding someone with time, energy, and knowledge to do so

[zoot]

I think the best solution will be to do something like "sub-variants", i.e. once the engine has picked one variant, there can be more levels of variants under that variant that will be activated on the basis of some kind of conditional.

This is what I would like to do (as a refinement of the above): The <group> element should take an 'control' attribute, which in turn would take some kind of expression to be evaluated. The <variant> element should take a 'case' attribute, which would take a literal value. When the evaluated value of the expression in the 'control' attribute changes, it will be matched against the 'case' attributes of the <variant> child elements of the <group> element. When a match is found, that variant will be the one used by the engine.

An alternative, probably more efficient approach, would be to let the 'control' attribute specify a class of events (e.g. "civilization phases") and let the 'case' attribute specify a particular event in that class (e.g. "town phase" or "city phase").

Any suggestions for what stuff in the engine that could be drawn upon to do any of the above? I thought about using the 'actor variables' that historic_bruno pointed to, but these seem local to the individual actor - i.e. if the civilization phase changes, you would need to update a variable on all actors, which seems inefficient. Is there a global variable or event scope that would make sense to use? (Sorry if such a thing is already documented somewhere, I weren't able to track it down on the wiki.)

[zoot]

The engine has a message passing system described here that I could probably hook into. (Only, I'm not sure what would be the best way to do that in data-driven way, since the message passing system probably works on pointers while the actor XML works with strings...)

[zoot]

Can someone please tell me what scripts do to subscribe to messages?

[historic_bruno]

Can someone please tell me what scripts do to subscribe to messages?

Assuming you mean simulation component scripts, they should implement a message handling method like "OnMessageType" and are automatically subscribed to messages for that entity. There is also "OnGlobalMessageType" which subscribes globally (messages for any entity). This is a relevant document if you haven't seen it yet: http://svn.wildfiregames.com/docs/writing-components.html

[zoot]

Assuming you mean simulation component scripts, they should implement a message handling method like "OnMessageType" and are automatically subscribed to messages for that entity. There is also "OnGlobalMessageType" which subscribes globally (messages for any entity). This is a relevant document if you haven't seen it yet: http://svn.wildfireg...components.html

Thanks, but where are the proper names for those methods defined?

For example, the technology manager seems to broadcast a "MT_TechnologyModification" message when a techology is researched (and civilization phases are apparently just techs). How would a script sign up to receive this message? Should it implement a message handling method named "OnTechnologyModification"? (If so, why - where is that name defined?)

[zoot]

Apparently, the message type "TechnologyModification" is defined in TypeList.h. Now to find out how that becomes "OnTechnologyModification"...

Edited August 13, 2012 by zoot

[zoot]

In the end, I will probably need to try something like what Wijitmaker suggested:

This should be possible right now by the config in the actor. For example, right now when a citizen soldier goes to a tree to chop wood, they drop the sword and shield and switch to an axe. What you are wanting to do should be pretty easy - just would need a hook to utilize the variant name.

My only gripe is that hardcoding variant names like that doesn't seem like a good practice. For one thing, it's nearly impossible to tell what names are in use, and what their semantics are, when they are littered across the codebase.

Edited August 13, 2012 by zoot

[zoot]

Does anyone know why this limitation has been introduced:

// Just allow one selection at a time
m_EntitySelections.clear();
m_EntitySelections.insert(selection_lc);

I thought it would be fairly clever to allow multiple selections at a time, so you could have one selection based on phase, one based on building health, one based on weather, etc.?

Edited August 13, 2012 by zoot

[zoot]

sunds good to figure that in the follow cases :republican legionaries armor to imperial armor.(Lorica segmentata)

or...

Bronze Helmet to Iron. change texture if you reach a technology.

in Age of Mythology you can seach technology and that affects props, same thing in Starcraft 2.

same with villager tech and tools. villager with rustic tools and your search can be provided him new tools, with new stats.

I agree, that would be fairly cool. And not too hard once we get down to it.

[Gen.Kenobi]

In the end, I will probably need to try something like what Wijitmaker suggested:

My only gripe is that hardcoding variant names like that doesn't seem like a good practice. For one thing, it's nearly impossible to tell what names are in use, and what their semantics are, when they are littered across the codebase.

They shouldn't be hardcoded at all. (This page is very very confusing - Assuming that this is the way to create new variants )