zoot

In a general sense I agree, offending people shouldn't be a goal in itself In this case, though, it's at odds with historical accuracy, which is really one of main 'selling' points of the game. (Also, I respect that 'electric shock' a lot Germans feel towards this - and I don't think most of them are as unreasonable about it as this particular poster were, either.)

Please see the report here: http://trac.wildfiregames.com/ticket/1791 How do y'all think this should be handled? I think the units should either begin executing the task when their own queue is complete, or wait for everyone in the formation to complete their queues and then begin all at the same time.

As far as I know, Atlas does not rely on scripting at all - it's written in C++. As for simulation, AI and RMS, those need to be separate - if I download an RMS someone made, I don't want to have to worry that it might be hacking the simulation to give my opponent an unfair advantage, for instance.

As far as I am concerned, triggers is something stored in a map. Having the map editor stored in a map would be horribly weird

Not really. We're not representative of most users anyway. The decision making process here is something like if 1) someone implements it and 2) someone commits it and 3) no one removes it again, then it's a go!

Gold is a metal.

I don't know yet - something similar to what historic_bruno suggested. Maybe I will have to make a new 'scripting host' or maybe I can find a way to use one of the existing ones. The slightly tricky thing is that we want triggers to be able to respond to both simulation and UI events, though they are run in different contexts.

0 A.D. shouldn't concern itself with perceptions at all. If some people want to be offended, that is their problem, not ours. If a few minor changes can make the game accessible to more people, though, that would be worth considering, IMO.

The Bundesprüfstelle doesn't seem to agree: Unless better advice comes up, this is probably the most reliable to go by.

trigger is supposed to be an object of the CTrigger class, initialized with eventName as an argument into its constructor. See this example: Date cToday(9, 5, 2007); // cToday is initialized to Sept 5th, 2007 Edit: MapReader.cpp looks a bit off though, made a fixup: https://github.com/z...20b2c...b5245af The segfault on TriggerManager.cpp:25 persists, however. Edit2: Fixed this, it was just some dumb variable initialization issue.

I've been trying to make the reader add triggers to an internal list as they are loaded: https://github.com/zootzoot/0ad/compare/a620b2c...b5245af Unfortunately, the above segfaults at TriggerManager.cpp:25. Can anyone tell me why? I'm not that familiar with C++ and its lists.

Here is a outline of how a trigger reader could work: https://github.com/zootzoot/0ad/commit/a620b2cee3de6563763c8ca7a117879701525d07 If anyone wants to help out, fork dat repo and get on with it.

Please do

Name an action 0 A.D. would be able to take as root that it can not as non-root - other than bad things like getting hacked?

It happened once on that map, I cannot reproduce it.

Anyone else getting this: http://imgur.com/a/SCDKN (Look on the ground on the right side of the images.) As I move a building preview into the horizon, the preview projects a huge, overproportioned shadow on the ground. The map is Acropolis 7.

http://play0ad.com/packing-siege-work-in-progress/

Does that make it easier to understand?

- Siege packing - Diplomacy - Rubble - Mauryans - Other stuff

Do the triggers need to be "compartmentalized" or "sandboxed" somehow, the same way GUI and simulation are compartmentalized from each other (where you can't immediately call simulation stuff from the GUI and vice versa). If they don't need to be compartmentalized - i.e. if we can run them in the simulation as is - I guess they could use the standard API for interacting with entities and components? Or perhaps your point is that the standard API may not currently offer all the state the triggers might need?

Yeah, that would be what the "Script" button is for. I would prioritize the simple, GUI-defined triggers, though, since the most people will benefit from those. Yes, something along those lines.

I see no flaw in that. The simulation is supposed to take place inside the map, so it is only natural that the map would have to exist before the simulation begins. If doing something like Kimball and historic_bruno describes, there might be a "AddNewUnitType" effect which you could run in response to some event (e.g. "MapLoaded"). Here is a mockup I dug up on the forum which illustrates it quite well:

Why not do this with normal simulation scripting? Adding a dependency on yet another scripting library when we already have SpiderMonkey == madness and/or SPARTA!

As leper implies, I was altering the prototype of an existing function. I couldn't have used "playsound == true" because existing code might be calling the function with no playsound argument, while still expecting the sound to be played. historic_bruno's ultimate formulation is less confusing, though.