historic_bruno

Those would be profiling hooks, basically timers that give some idea of the performance in that part of the code. You can access profiling info with F11 or save it with Shift-F11 I believe. I'm pretty sure the AI isn't allowed to directly access simulation components, which is why those aren't defined. Also the API which the AIs have access to is not nearly complete. If you look at simulation\components\AIProxy.js, there is an OnAttacked event that doesn't appear to be used by the AIs (it may not do anything in fact, but could be a starting point). Also AIProxy.prototype.GetFullRepresentation is worth investigating. Anything you figure out here should either go in the AI proxy or base-AI module so all AIs can use it, and it will be no doubt very appreciated. Edit: I see how those events work. Look at simulation\components\Attack.js in the CauseDamage method. It sends out an MT_Attacked message, which might well trigger the above OnAttacked event in the relevant AI.

Oh, every time it finds another civil centre in the XML, it replaces the last "target entity", which might have been a civil centre or some other unit.

Should it always pick the lowest entity ID? That's easy to add.

My guess is we'll use whatever works best and is easiest to maintain in the long run. I haven't seen a firm decision yet, so I would second k776's advice to discuss this with Philip (Ykkrosh). You would have some useful input into how well Premake4 works, what it can and can't do.

Good to hear it. The changes mentioned so far are in r9617 (will need a build to see them).

Constructive criticism is what 0AD needs at this stage, it's not taken personally I've added some controls for per-player starting camera position. It currently handles position but not rotation (see #1 and #55). The exact starting camera behavior would be as follows: 1. If a scenario's data specifies "StartingCamera" position, that will be the player's starting view (note: this might be in SoD or FoW), 2. Else if the player has a civil centre, the starting camera is focused on that, 3. Else if the player has an entity, the starting camera is focused on the first one, 4. Else the global camera is used (the last view seen in Atlas).

I was thinking of that too, but it will require changes to game setup because currently player assignment is the same control as AI choice. Not sure how difficult it would be to change that. Scenarios should have the option to "lock" the player slot, as you said either for no AI at all or for a custom AI that suits the scenario. I guess it's no big deal until we want a scenario like that.

Ah, I found the problem, thanks I'm adding an AI option to the player settings, which isn't yet shown 100% correctly in game setup, but it lets you play cooperative with an AI (both you and the AI can control your units). There's a few ways to do this but I think the first is simplest: as opposed to

Here's a feature that I think will be appreciated, a filter on the entity list:

I totally agree about the toolbar, the way it is now is a bit kludgy. I think it's designed so that each button is a tool specific to a panel (terrain / object / etc), so it's not straightforward to add e.g. undo/redo or save/load buttons. Maybe it should be changed to a standard toolbar. I also think the simulation buttons should be moved there, with nice shiny icons The ideal toolbar would be like in other apps where you can break it into pieces and drag them around for a custom layout. OK, does population bonus get added to the population limit or does it have some other purpose? True, but I don't see any way to change the spinner interval :/ I guess we could use a custom control (as a work around you can hold the arrows down and they will gradually increase the interval). Hmm, I can't reproduce that. Either something is different with the autobuild or I'm using the wrong steps. File > New, and then try changing number of players? I don't think that's expected behavior, because the UI look and feel is more old-fashioned windows, where hovering doesn't change focus (you can move your mouse anywhere on the screen basically and it lets you continue typing where you were). I tend to instinctively move the mouse cursor away before typing (so it doesn't obstruct the controls). Having to click once in the game area to get focus doesn't seem like a big deal to me. I guess it also depends how sensitive and quick your mouse is.

If you do, could you also commit the player icon? Assuming it's compatible with the game's licensing.

I guess we need some way to notify the UI when map settings are undone/redone? Well me or Philip, unless someone else wants to tackle it

I'm considering moving the "number of players" control from map to player panel, at least duplicating it, but the code becomes simpler if it's on the same panel. Would a reset button be useful: so you could reset the player data to defaults? Or maybe integrating with Atlas' undo/redo functionality would be better, if possible?

Yeah, it's a known problem caused by a bad compromise between two alternatives: fixed zoom distance from the terrain and constraints on max/min height of the camera.

OK, since Atlas is now written purely in C++, I had to scrap my previous JS attempt at the player editor. But I took the opportunity to rework the layout a bit and here's what I've come up with: Instead of a typical tabbed notebook control I'm using a "ChoiceBook" which means there is a choice box/dropdown that lets you choose which player to edit. I don't particularly like the player icon, it's an old one from the SVN, I like the one in Mythos' mockup a lot better.

It's not really an error, just looks like some debugging output that didn't get cleaned up :/

Hi, for water you need to lower the terrain (all the water has a fixed height).

Well you and I discussed this already, of course. Scripting makes much more sense in the game than it does in the scenario editor. The ability to instantly prototype is nice but not used often. Any really useful changes to Atlas require knowledge of C++ anyway. So in my opinion it's not worth having to maintain wxJS and be tied to an old version of wxWidgets, just to support functionality that isn't used.

Great story! I can see that book on my shelf from here and really enjoyed it (although maybe not as much as the Heimskringla). My nickname's story is a bit more boring I think. Bruno is a name meaning "brown" which I chose randomly back in high school while studying French (we had to pick European sounding nicknames, and Bruno is at least visually similar to my real name: Ben). The "historic" part comes from when I played Age of Empires online through the MSN Gaming Zone (back in 1999 or 2000, I believe). Some here may remember that when signing up you needed a unique username but it would suggest alternatives if your desired name was taken. So I tried Bruno (which was taken) and was recommended "historic_bruno" and I've used that as my nickname ever since

It was a long-standing bug in team initialization (possibly going back to A3?), which should be fixed in r9399.

This should be fixed in r9392.

Try this.playerData.popLimit.

Seems to work, but I get a few warnings: WARNING: JavaScript warning: simulation/ai/jubot/military.js line 180 anonymous function does not always return a value WARNING: JavaScript warning: simulation/ai/jubot/military.js line 205 anonymous function does not always return a value WARNING: JavaScript warning: simulation/ai/jubot/military.js line 229 anonymous function does not always return a value WARNING: JavaScript warning: simulation/ai/jubot/military.js line 253 anonymous function does not always return a value

The game always pauses if it doesn't have focus, even if something like task manager is on top, I think this is expected behavior. I'm not sure why it would minimize though.

In fact, looking at Median Oasis it is very similar to the Neareastern Badlands random map. They both have a central oasis, only Median Oasis seems to have more rolling hills than steep cliffs. Adding it as a random map shouldn't be too difficult Oh, I didn't know this. So in that case a map like AoK's black forest will not be possible, since trees alone wouldn't form an obstacle to most units. One thing that could be added, if you think of a real-world dense forest, it's not practical for large armies to just march through, you have to go fairly slow and not in a straight line. So the pathfinder should force units to scatter out of a formation if they enter a forest and also there should be a time penalty, so it may be faster to go around a forest than through it.