zoot

I decided to pursue a JSON-based solution anyway: https://github.com/z...ompare/triggers When I insert an element like this in a map's script settings, a trigger is created which shows a message if one of player 1's units is attacked. So this would just need a few more conditions and effects and it would basically work. Of course, none of it is supported in Atlas, but it would still be good enough for making, say, a tutorial, by hand.

Any particular reason you don't go open source like 0 A.D. has? Surely, you would be able to get many programmers if you did...

That is what the snippet quantumstate posted in #50 does. Battle detection isn't useful for attack notification because it doesn't keep track of the location of the attack.

I believe they already do, the problem is that the units sometimes block each other so they can't get out. It needs to be decided whether we want to make a hack to let units pass through each other in that case.

It's just for toggling battle music.

Yes, victory and defeat is implemented, but the bots have a tendency to hide female citizens in weird places (like along the map edge) till the very last.

I think all games have it, I have seen it discussed a lot in relation to games on Valve's Steam: https://wiki.ubuntu.com/Bumblebee It's not my impression that the game itself can do anything to pick the right card, but I don't have in-depth knowledge about it.

There is a ticket for it: http://trac.wildfiregames.com/ticket/9

The actual layout of the UI is defined in XML: https://github.com/0ad/0ad/blob/master/binaries/data/mods/public/gui/session/session.xml The behavior of the buttons below the unit portrait is defined in input.js: https://github.com/0ad/0ad/blob/master/binaries/data/mods/public/gui/session/input.js

See this: http://www.wildfiregames.com/forum/index.php?showtopic=14326

I agree. Not everyone who does a clean installation will be first-time players either. Maybe they just got a new computer or cleaned up their harddrive.

Is 'wildness' a measure of how hard the entity is to capture from Gaia? If so, I don't see why it should grow for abandoned (out of territory) buildings? Seems to me it should be constant, an intrinsic property.

There's this: http://www.wildfiregames.com/forum/index.php?showtopic=16262

The image on en.wikipedia is missing source info: http://commons.wikimedia.org/w/index.php?title=File%3A0adcarthaginians.jpg&diff=85564704&oldid=84012894

This happens when you have units inside the building foundation.

After having looked at it, I am not sure how to do it entirely or almost entirely in JS. If it was done in JS, where would it run? If it runs in the simulation, how would it know of UI events? If it runs in the GUI, how would it know about simulation events - to my knowledge the GUI does not receive messages sent out by simulation components? So unless there is some other way, I am leaning towards having a 'trigger manager' in C++ which both the UI and the simulation invokes to pass events and the like.

We don't need to rewrite any functions, we just create a thin wrapper in each context, which then calls the original function. That sounds like an RMS feature request, more than a trigger feature request. And what if someone else picked the same namespace? Also, namespacing does not prevent the type of error modes that may arise when two different scripts unknowingly manipulates the same globals: http://en.wikipedia....mputer_science) It's not about trust, it's just bad design. Honestly, it's a bit like wanting to run everything as root just for the sense of power it grants

But do you agree that the units should complete their own task before rushing off to do the queued task? They don't currently.

It's not just about security, it's about integrity. What if two different scripts both define an object named 'MyObject' in the same scripting environment? You get some kind of collision, and one of the scripts break. These issues can be avoided by running separate things in separate environments.

I see. But none of that really implies throwing all scripts into a big hodgepodge like suggested above. We can make one trigger API into the UI and another one into the simulation, without compromising their separation on non-trigger maps.

What was the difference between them? (I've never used either.)

Not all maps need powerful triggers. It should still be possible to choose to play on a plain map without all sorts of stuff going on behind the scenes.

Indeed.

Hi. You need to set preferglsl=true as well. I believe there was a description in the alpha 11 release announcement. Here: http://trac.wildfiregames.com/wiki/Manual_Settings

That's a poor argument. That's like saying: since there will always be some people breaking the law, we should not do anything to prevent it. It's not a tenable position. Simple: don't allow actions/effects like that unless every player agree to it. If you just throw all sorts of scripts into one scripting environment, you don't have that kind of fine-grained access control. They can even be overwriting each other's functions unintentionally - it would be a mess.