zoot

It ought to be simple to make the particles go upwards, though. Someone probably knows which file to tweak.

For this, I believe you need to hack the UnitMotionFlying component: https://github.com/0ad/0ad/blob/master/binaries/data/mods/public/simulation/components/UnitMotionFlying.js

You've fixed most of it, but shield props are still missing:

Actually, I think the reason these issues hasn't been addressed is that they depend on the pathfinder and that is currently being reworked.

Animators are sorely needed, I believe, so that would be a great place to get started. There is some info on how it works here: http://trac.wildfiregames.com/wiki/BasicAnimationImplementation In any case, welcome.

Has anyone else noticed that the Mauryan tower looks ugly when its collapsing:

Sorry, but this is absolutely not true. Lots of progress has been made on the AI, but it is still well below the skill level of an average gamer. I know this because even I can beat it

Lol. You may want to consider using more descriptive variable names than 'Lalala' too

High poly models would obviously be fine for a cinematic - and we can just run the simulation at a very slow rate, then speed it up in post-processing to get picture-perfect frame rates

I believe the only color space that works for everyone is grayscale, and that is probably going too far. But when we use reds and greens (the two most commonly affected colors), we should take care to use, say, a dark red vs. a bright green so brightness acts as an additional cue.

I wonder how they got such a badass voice-over

Yeah, I would just skip it if any key is pressed, effectively leaving it up to the user how much they want to preload. Also, there should be at most 1 such cinematic. I hate games that have like 10 different cinematics after each other and you have to tap, tap, tap to get through to the menu.

Would be a good opportunity to preload some data, so as to reduce delays while navigating the menus.

Right. Maybe it would be better to make a dedicated script that launches pyrogenesis and monitors whether it hits a breakpoint via the standard HTTP API, in which case it can launch the UI.

It most likely won't, since the whole minimap 'ping' thing still needs to be done. (And yeah, the bark is just a placeholder.)

As of this commit, it now plays a dog bark when any infantry units come under attack Any help with the minimap implementation would still be appreciated.

Perhaps I'm misunderstanding, but using FeXoR's suggested formula: damagereduction(armor) = round(100 * (1 - pow(0.9, armor))) If we translate to JS and plug in the numbers: damagereduction(50) = Math.round(100 * (1 - Math.pow(0.9, 50))) = 99 (link) damagereduction(9000) = Math.round(100 * (1 - Math.pow(0.9, 9000))) = 100 (link) Or if we use armor level 51: damagereduction(51) = Math.round(100 * (1 - Math.pow(0.9, 51))) = 100 (link) 100% damage reduction for armor level 51 versus 100% damage reduction for armor level 9000 is what I mean by "essentially the same". Of course one can always discuss whether more than 50 levels are needed, but it's a valid point that there is a limit.

That seems unlikely. What you are buying is access to a service, not the software itself.

As I understand it there would be diminishing returns, but armor level 50 would be essentially the same as armor level 9000.

A rainbow of colors vs. its simulated appearance for a person with protanopia (an uncommon, particularly severe form of color blindness): "Attack yellow!"

Would it be too much of a hack to have the debugging server launch a browser window with the UI when it encounters a "thrown" breakpoint in the code? Perhaps as an toggleable option? It would fit quite a lot better into my usual debugging workflow, than having to manually Alt-Tab out, browse through the file system, and finding the right file to open.

Sweet. Pyrogenesis is becoming an industry quality engine

Actually no, I shall associate it with the attacked unit, that should work fine. Then we can potentially have special attack notifications for heroes and the like. (So, stwf, ignore my previous request - the current function should do fine after all.)

Seems like substituting one simulation for another - the current armor value is also just a "simulated average".

Seems there is in fact something called 'distanceless' sounds, which is what is used for selection sounds. Should I use that? I guess I could associate it with the attacking unit, though it would carry no real significance.