zoot

Not sure. but I would expect in CCmpVisualActor.cpp or something linked to that.

Ilves, could you zip up your actor and models and post it here (unless it is "top secret", of course ). Then people can try and tinker with the code and see if the turret can be made to work.

I'm still convinced turrets can be implemented relatively easily. We just need to find the best way to do it.

I see. But in that case why would one want the turret to be an entity? Props already have an established way to specify how they should be positioned relative to the main actor.

Indeed, twist.

Steam Greenlight apparently does: http://www.wildfiregames.com/forum/index.php?showtopic=16476entry249547

Drew Bliss of Valve Software giving his talk at UDS: He has just announced that everyone here are in the beta

I think the only criteria is that you can make something that works. You can submit any patches you've made on Trac. Most gameplay programming is done in JavaScript, by the way.

Doing it per-map (duplicating for each and every map where this is wanted) sounds messy. As far as graphics is concerned, surely the relevant files can just be reduced in quality without breaking multiplayer. Texture quality can be reduced with a setting at load time (scale it down e.g. 2x). Water effects can already be turned off from the options menu / default.cfg. Non-graphical things like formations and stances are another matter because it impacts gameplay determinism.

800x600 is very low res by todays standards, but even if we did want to support it, it should be a setting, not a separate version of the game.

How does other games have any bearing on how 0 A.D. works? When things can be adjusted via settings, I don't see why anyone would want a "light version".

Sure, but why create a "light version of game"? Why not just adjust the settings?

Why not just turn off the effects you don't need?

That is essentially how the change gudo is proposing would work. Props are entities, IIRC. The "Partian shot" case seems a bit more tricky, in that you will want the actual mesh/skin to "twitch" rather than just rotate the whole thing.

Head over here if you're interested: http://www.valvesoftware.com/linuxsurvey.php I will be attending the Ubuntu Developer Summit in Copenhagen in a few days and hope there will be some kind of beta announcement there as well. There will also be a number of game development related sessions that I will try to attend and report back on if I pick up anything of relevance to 0 A.D.

It will require a minor (in my unprofessional estimation) bit of coding in any case, but I believe having it as a prop is the way to go.

"Commands"? Aren't they objects which can receive method calls like everything else?

Isn't that essentially what props are? Entities which parent another entity?

The effect of the tech could be made dependent on the wonder surviving.

I don't think the recommended limit is a hard limit of any kind. 0 A.D. has always aimed to support quite low-end stuff. If you are willing to drop support for the lowest-end machines, you can probably use 1000-2000 polys just fine. Or you can get someone to optimize the engine for your requirements - it is open source, after all. Nice modelling, by the way.

I don't see anyone disagreeing that it should be possible to turn it off. I don't see anyone disagreeing about the default social network either, as long as 1) it is possible to turn it off completely and 2) its possible to switch to any other social network.

Or "vegetation" But indeed, nice work.

I agree! plumo's reports are great publicity, but they would be even better if they are kept in a non-technical language that everyone can understand.

If no one thinks there should be a fixed set of social networks, what is the disagreement about? I suggested a way to allow the user to have a say in which social networks to support - by doing it over an intermediary server. I'm interested to see if there are any better suggestions.

Well, sure, but no one suggested that we shouldn't work on the game because it might benefit hardware manufacturers and all that ... stuff I did, though, suggest a line of reasoning which would imply that I am also opposed to only supporting Dell computers, for instance. I hope you will agree that would be a bad idea. In other words: It's not "it might benefit someone" that is the issue. It's creating a lock-in to one vendor (or a fixed set of vendors) who then benefits exclusively from it that is the issue.