zoot

Probably because "HTML support" is subject to interpretation Just having to render a few HTML help pages doesn't require the same amount of API power as a full-blown gaming UI.

http://librocket.com/wiki/license

From http://trac.wildfire...i/TextureFormat: I wonder if this is done for normal maps? If not, it would seem a factor in degrading normal map quality when zoomed out.

historic_bruno (or some other highly informed individual), do you have any comments on the above? Would it make sense to have an actor file with 'groups' looking something like this: <group behavior="UnitActivities.js"> <variant name="Idle"> <props> ... </props> </variant> <variant name="Melee"> <props> ... </props> </variant> <variant name="gather_tree"> <props> ... </props> </variant> <variant name="gather_grain"> <props> ... </props> </variant> <variant name="gather_fruit"> <props> ... </props> </variant> </group> Basically, the script 'UnitActivities.js' would define under which circumstances a new variant would be chosen from the group. The script would be able to hook into the message passing system, just like other simulation scripts, and subscribe to relevant messages like those broadcast when a unit begins gathering or building something. When it receives such a message, it can then pick the right variant from the group, and update the actor accordingly.

Sounds about right. I think all actors are entities, but not all entities are actors.

If it's not open source (GPL compatible) it's useless for us.

Does WebKit support WebGL?

http://trac.wildfire...com/wiki/Entity This? I have yet to completely figure out how 'entities' and 'actors' relate. However, I am currently pondering whether it would be feasible to link each variant in an actor to a script somehow and then that script would define the relevant 'behavior' for when the variant should be activated... so you would attach a 'behavior' to a variant, sort of how you attach a material to an actor.

Not yet. Myconid had done some nice groundwork on it, but I believe he postponed final implementation for the time being.

What is a template.variable? Are there any documentation on that somewhere?

Another disadvantage (apart from the possible memory bloat) is the loss of fine-grained control. Consider how many websites - even today - resort to Flash when they need to do anything even remotely advanced visually. I don't think we would want that clunkiness for every effect we want to add...

As far as I can tell, they are. For instance, the "gather_*" variant names are coded into UnitAI.js. Probably not much to do about it under the current engine architecture, though.

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

I believe the main difference is that the technique in the video simulates lightning comparable to raytracing. Without that, you won't get the distinctive prism-like optics that raindrops have, and so they will look more artificial or snow-like.

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

A few ideas for how our rain particles could be improved: (Note that YouTube has garbled the resolution, so the effect in the demos doesn't look anywhere near as good as it would in real-time.) IMO it's particularly interesting how the particles without proper environment lightning essentially looks like snow. Paper and hi-res video here.

Give it a shot: http://trac.wildfiregames.com/wiki/Mod_Layout#gui

Another benefit is that there are tons of UI artists working in HTML/CSS while essentially none are working in "Pyrogenesis XML".

Blame the filter bubble.

Two completely different licenses can be compatible (e.g. BSD code can be used in a GPL program), so it is a bit less straightforward than that.

Right. So to use that image, it would probably be necessary to contact that author and ask if he could kindly make it available under CC-BY-SA 3.0.

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.

We use CC-BY-SA 3.0. I am not sure whether it is compatible with CC-BY-SA 2.5. Worth investigating, since there's probably plenty of good content under the latter. This one seems to use CC-BY-SA 2.0. Same as the above - we need to find out whether it is compatible. This uses CC-BY-SA 3.0, so this should be fine as long as we attribute the author properly somewhere in the game. This may be necessary if the licenses are incompatible. For now, the best thing you can do is to 1) make sure you keep track of the source for all materials you use, 2) make sure you post that info somewhere 'safe' on this site, so it isn't lost if you retire from the project one day. In the end, the team needs to come up with a process and guidance on how to deal with this.

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

Did the console errors go away? I believe that is what myconid was referring to.