sanderd17

The female unit is already civ specific, so you just have to add this code to the Viking female.

Check if it's better when you change the settings: http://trac.wildfiregames.com/wiki/Manual_Settings Though it's true we have problems with bigger screen layouts in general, but until someone willing to work on it has such a screen, it won't get solved.

If you can do something like that, go ahead You can join #0ad-dev on quakenet if you want info on something, or to discuss stuff.

Yes, construction time is a lot longer, which means you need more units on building rather than on gathering resources. Ptolemaics are even quite bad at the start, even with their free houses.

Well, objects in JS are like maps, but they get handled pretty differently in the background. When you create an object, behind the door, there is made a class for it. So when you change the properties of an object, the class gets invalid, and the object gets transformed to a lot slower "dictionary mode" (accessing a value is some 40% slower after a single delete). While Maps will be native objects where deleting and adding keys is a lot more optimized.

Do you have the error? Without actual message, we're just shooting in the dark. Yes, the AI doesn't support saved games yet (neither does the multiplayer, so saved games isn't of much use now ). For the AI, it's just like a new game starts. So it will try all stuff like it does for new games before starting to attack. Some things aren't possible anymore (like researching techs), so there's a chance it just stops advancing there. IIRC, the "use actual depth" is disabled by default. It should be disabled by default, as it's not only causing problems on OSX, it also eats CPU cycles like sweet cakes on integrated Intel graphical cards.

They mostly build their fountains on an existing water well. So there was some streaming water coming out of it, but not in crazy amounts (more like just streaming of the edges). Edit: http://en.wikipedia.org/wiki/Fountain#Ancient_Roman_fountains

It has to be a separate actor (just one or more planes with water), because it needs a special texture. You can search for "water" in the actor section of Atlas, and you'll find some of the actors related to water.

Your models look good, but I wonder if you can add water, like in the Persian wonder, the hanging gardens (you do need glsl enable to see it). It would make a fountain a lot more interesting I guess.

Can you try to open the dae file with a text editor, and change the units to meters (= 1 meter)? It should make importing better I guess. It's one of the first lines of the dae.

Yes, right. If you read the description, you'll see he talks about kill/death ratio.

It's somewhere on the forums here. Bajter worked on it, and made the forum posts and stuff.

It's planned, only the lobby needs fixing to support the new stats.

In case the trying fails, or gives strange results, you can read this: http://www.wildfiregames.com/forum/index.php?showtopic=18035&p=282135

That's a design choice, it's forbidden to repair on purpose: http://trac.wildfiregames.com/browser/ps/trunk/binaries/data/mods/public/simulation/templates/structures/rome_army_camp.xml#L52

Except that we will have to rewrite every line of JS ever written, it's very close to JS syntax.

Using something that compiles to JS is completely backwards imo. You'll have to rewrite all code, and still have problems with the JS engine (s.a an ever changing API, jit bailouts, ...).

Gameboy, do you have the commands.txt for that game? It's most likely something I have done (working with formations). EDIT: nevermind, it shouldn't happen anymore. I removed that state

Example of such a competition (it was pretty hard to find something decent, most of the images and videos are purely amateur work):

Did you click "register"? If it's your first time in the lobby, you need to click on register.

We still have plow competitions here, where you have to plow your rows as straight as possible with a horse and a single plow. It ends up pretty straight. Though for sure, not everyone plowed like that, and you still have the fertilizer influence. And about that per biome field, I said it would be difficult, not a huge pain in the but. But you probably won't find someone to work on it very soon.

Normally the release should be faster, because it's all packaged in one file, and everything is cached.

Faster in what way? Faster to load, higher FPS, something else? The autobuild is made every time some source file changes that requires it. Every programmer on the team can trigger the autobuild.

Currently, the viking boat is indeed the size of a quinquireme. While Wikipedia suggests that a quinquireme would have been around 45m long, and a viking longship only around 20m long.

The game has a tick every turn, currently, that's every 200ms (though it may become shorter in the future), when there's lag, the turns become longer. Every simulation change can only happen on a turn (some components listen to a turn tick, execute some action, and notify other components if necessary). Between the turns, there's also graphical interpolation, to make the image smoother. Everything that happens between turns isn't synced in any way between different players. F.e. player commands in a network game need to wait until the next turn to be executed. The UnitMotion and Pathfinder only really care about simulation. Every turn, the UnitMotion component brings the Position a bit closer to the next waypoint given by the Pathfinder. That's what happens in the move command. The dt argument is the length of the turn, so the UnitMotion component can know how far it can move. The Position component does care about graphics, so with a MoveTo command, only the next position is set, and every frame is interpolated towards that new position. The move command are actually given by the scripted UnitAI. That's quite a big piece of game logic that decides stuff like detecting enemies to approach and fight, finding a new tree when the previous is cut down, walking in formation... The move command are given directly to UnitMotion. About the components, you are about right. Every entity is defined by an xml template, that denotes the entity has an instance of certain components, with certain settings (like the move speed in UnitMotion). There are a few special entities (like the SYSTEM_ENTITY and player entities), but most components are used on regular entities. The components are referred to with an ID on the scripted side (like IID_UnitMotion). It's also possible to have separate implementations for the same interface, and refer to them with the same I'd. Like the scripted component UnitMotionFlying is accessible under the IID_UnitMotion, so UnitAI sees no difference, and you can command planes like any other unit.