zoot

Not sure what 'position' would mean for the sound system in that case.

Because that would defy the point of an attack notification. You want to hear it regardless of where the camera is pointed, not only when you are already looking straight at the battle.

I like the current system It's straightforward, and doesn't lead to counter-intuitive cases like a wooden shield absorbing 50% of the blast from a nuclear bomb. (Speaking as a player, though, not as someone having done any gameplay programming.) I actually don't see how this relates to whether the armor value is a percentage or not. Even if the value is a percentage, it is still the same percentage being subtracted, regardless of "where" the attack hit.

Just to be clear, what we'll need for attack notification is the ability to play a sound without a position. That is, in the same way as music, but obviously separately from it (playing an attack notification sound should not interrupt the music etc.)

My comment was in response to the suggestion of having an in-game option that would allow the user to make e.g. red show up as e.g. blue.

This was on the Atlas Mountains random map, tiny, 1 Aegis Bot opponent, standard settings.

I just tried it. It worked well for some time, but then it began printing an error endlessly. Should that be reported somewhere?

Seems that the only thing that really needs to be C++ is the interface to the HDD. All the actual AI logic could still be JS. If you chose to do it this way, I believe we would be more likely to be able to use your results too, since we need to keep as much code in JS as possible, for moddability etc.

Actually, that should be relatively easy, since shield and weapon are just props (separate meshes) that can be turned on and off at will.

That's a pretty interesting idea, though nixing death sounds completely may be a bit drastic in my view. Perhaps they could be more subtle, blending into the other sounds you suggest, though.

Mods, in the usual sense, are JS only. But AIs are not necessarily part of a mod. But you are right that it doesn't really fit the pattern of striving to keep mod-specific stuff out of the engine. agapsguy doesn't necessarily intend to follow that pattern either, though.

Simulation components can be done in C++ (the AI manager is itself an example of this), so it shouldn't be completely impossible to extend it to support C++ AIs.

Others are much more informed on this than me, but have you inspected the AI manager? https://github.com/0ad/0ad/blob/master/source/simulation2/components/CCmpAIManager.cpp

stwf, on an unrelated note, is there a way to play UI sounds for e.g. attack notification? There is a simulation function called PlaySound(), but that is always tied to an in-world entity.

This seems like a good, practical rule of thumb. Obviously we can't make every shade in every texture perceivable in grayscale, but it ought to be possible for the most critical UI elements like the minimap, health bars etc.

simulation/components/Attack.js:435 var cmpPosition = Engine.QueryInterface(this.entity, IID_Position); Yep, that did the trick.

Did some testing: I'm not sure how the 'this' object is supposed to work? I can't find 'this.entity' anywhere, for instance, even while in break on lines referring to it. Also, apparently if I select a different stack frame, I have to 'step' before the 'Values' list is updated? Is it not possible to interrogate the various stack frames asynchrously, while the game remains in break? I'm not having much luck with this. I always end up in a non-existent file called "(eval)", resulting in this error in-game: ERROR: CVFSFile: file (eval) couldn't be opened (vfs_load: -110101) Other than that, it looks good!

Well, I was responding to Zaggy1024's suggestion. In theory, it certainly would. What I'm saying is that I probably wouldn't want to worry about it in the midst of battle. I'd prefer if it - like so many other aspects of the game - just worked.

If the colorblind guy says: "attack blue", how do I know whether he is referring to my blue or his blue? IMO it's not realistic to expect random noobs to agree on such things beforehand, and it creates a poorer experience for both parties that one can never be completely sure what is meant. "Tough luck", you might say, but then why change it all? If we don't intend to really solve the problem we might as well leave it as it is.

It's irrelevant what color he sees. The point is whether he understands the words the same way as other players.

Do you have any sources for this? All sources I've seen says they did not get them until the Imperial era.

Doesn't look particularly uglier than e.g. the AoE3 player colors to me:

The game is set in the 500 BC to 1 BC timeframe.

Alternatively, we could limit the selectable colors to these: (Source: http://jfly.iam.u-tokyo.ac.jp/color/#pallet)