zoot

He's not using Windows.

Note that "normal" shadows are disabled on that pic, so that particular room should look darker on a proper PC.

Someone will get around to it when there is a need for it. The release is only weeks away anyway.

This is from the map Sicilia: After the boar died, the tower kept on firing at it.

By the way, HTML will also make it much easier to do things like help pages and tech trees in-game.

Can you post images/video?

Sweet! From their FAQ: Do you happen to know anything about its memory footprint?

How about this: I define a new component interface for "variant events". Any component (e.g. UnitAI) may implement this interface. It has only one simple method that allows other components to subscribe to "variant events" emitted by it. Components that wish to subscribe to such events must in turn implement a counterpart callback interface that I will also define. The <group> element in actor XML will take a 'controller' attribute. The value of the controller attribute must be a valid name of a component on the entity which the actor is associated with (e.g. "UnitAI"). When the actor is loaded/created/instantiated, it will invoke, on the component named in the 'controller' attribute, the method to subscribe to variant events emitted by the component. Variant events are simple string messages like "GatherFruit". When the actor receives an emitted variant event, it searches child <variant> elements of the <group> element for ones that have the variant event message in their 'name' attribute. If a match is found, that variant will be chosen for the actor and its rendering updated accordingly. Would that make sense? The main improvement over the old approach is that it is cleaner - the 'name' attribute of variants become unambiguous. That will allow me to implement new "variant events" for civilization phases and destruction levels in good conscience Edit: Instead of defining a new interface, I could also use the message passing system.

I guess XUL isn't quite HTML/CSS (not that HTML/CSS has to be an ultimate requirement), but it does seem like an improvement over hacking together our own format. I wonder if it can play nice with SDL, though.

Did a before-and-after GIF with Shield Bearer's maps just for fun: (Sorry for any epileptic seizures this may have caused.)

historic_bruno has committed a new build to SVN. If you can try it, let us know if it works.

Further down, they state: So, unlike in the case of the GPL, the original portion of a CC-BY-SA 3.0 work adapted from a CC-BY-SA 2.0 work would remain incompatible with e.g. the DFSG. I.e. we still need to avoid CC-BY-SA 2.0 content and content derived from it.

I agree, that would make some sense (though I think we'd need a lawyer to formulate it). The clause is inherent to the GPL, though (as you note), so it is an issue specific to CC-BY-SA content.

Woo, alpha 11 release party! No?

Probably the specularity shader could be hacked to see a light source at the camera. That should make the specular highlight always show. Then, if need be, you could add a sinus function or some such to make it show up only periodically.

I don't actually see any explicit mention of the mapping between XML elements and component names that quantumstate described, though I suppose someone smart enough might infer the relation from the way the name 'Example' is carried through the document.

I'm sure Romans wore all sorts of colors - Tyrian purple was just one particularly coveted one. I like the idea too because it is both original (not the boring RTS-standard secondary colors) and clever (historically based).

When in a game session, click MENU in the upper right corner, then "Settings". You should get a dialog like this: A territory border toggle has not been implemented yet, I believe.

Yup! And I would add: - Someone needs to update the copyright blurb in art/LICENSE.txt as suggested here. - Someone needs to ascertain that we are allowed to redistribute CGTextures under CC-BY-SA 3.0 (and not some other version) and update art/LICENSE.txt accordingly. - There seems to be a huge backlog of textures whose provenance is unknown and therefore may be illegal to redistribute; someone needs to determine how this should be dealt with.

We have permission to relicense those, though, right? (Though the blurb doesn't state the version number of the CC-BY-SA we are allowed to use - that ought to be cleared up too.)

Very good point. I hope we can avoid non-CC-BY-SA 3.0 textures, then.

Excellent, that was the main piece of the puzzle I seemed to be missing. Thanks.

As far as attribution goes, I believe it is generally sufficient just to state "I used this dude's texture" somewhere reasonably prominent, without necessarily linking it to the exact texture in question. For keeping track of the sources of textures internally, perhaps just a 'file' on this forum would work - unless one wants to include it in the release for the sake of tidyness/completeness.

Credit could be given in a separate file as suggested here, but I don't really dispute everyone will be happy in the end

I hope it's cool I post this here, since it is mostly relevant to developers: As a random exercise in familiarizing myself with the codebase, I'll be writing a wikibook about the Pyrogenesis engine here. Hopefully, it will grow into a useful reference for new and prospective contributors in particular. If you have any comments, you are welcome to leave one on the talk pages or of course edit the book yourself. (In case anyone is wondering, I chose the Wikibooks site over the Trac wiki mainly for the stability of their infrastructure - it'll be easy enough to copy content over if need be.) It'll be a "when feel like it" kind of thing, though, so don't expect any super-fast pace, as far as I am concerned