Ykkrosh

It's broken due to #500 which will probably take some effort to fix

Yeah, it should be there in the Edit menu, though some actions (like changing map settings) are currently ignored by the undo system and can never be undone.

Yeah, the red is the regions of terrain decals that are outside the texture - the textures are set up with GL_CLAMP_TO_BORDER and the border colour should be the default (transparent), so it sounds like a probable driver bug since it's drawing some random colour instead.

If you're running the game like "pyrogenesis ...", then try "./pyrogenesis ..." instead. (The first version has to search through $PATH to find the executable, and the game doesn't bother searching $PATH when trying to find itself so it fails.) That API design is ancient and was never implemented - the only documentation that's not wrong is this but it doesn't say very much so it's probably not too useful. But the "events" array should contain events with the name "Attacked" whenever a unit is attacked, so it should be possible somehow to detect and respond to those events (maybe with some extra code in common-api/base.js).

Yeah, sorry about that I think undo/redo for map settings and player settings is important, because it's too easy to accidentally mess something up (e.g. delete your map description) and have no way to recover. Assuming we add that at some point (it shouldn't be too hard, I think, though it might need some tweaks to the command processor system), maybe a reset-to-global-defaults button would still be useful but I don't really know. (A reset button without an undo feature would be pretty dangerous, though )

I prefer to keep the C++ interfaces simple, since that makes them easier to understand and to maintain, and then put the logic in the scripts since they're more flexible. Whenever you do anything with entity positions you have to check for e.g. !IsInWorld() and then respond in some appropriate way, and it's usually easier for the script to decide how to react than the C++ (since only the script knows the context in which it's running - maybe it will ignore the target, or maybe it will have remembered the last known position, or something). So I'd prefer not to pass entity IDs into C++ unless it's either necessary or hugely more convenient. If it's a script that needs to know the distance, it's probably better to have the script do the computation (to keep the C++ interfaces simple; performance won't matter), and it should probably go in a new file in helpers/ since other code might want to use it (e.g. Attack.js already does some computing distances between units). Probably not with any accuracy at all. If you build in Debug mode then the F11 profiler should show script functions, but it disables the JIT so it's very unrepresentative. Alternatively you can do Engine.ProfileStart("some name") / Engine.ProfileStop() to explicitly add a region to the profiler tree (it'll be somewhere in the 'simulation update' branch, I think), though the profiler has some cost itself so it'll distort the results if you're timing very short intervals.

Hmm, I don't think that's true - some people run 32-bit userspace on 64-bit kernels. It seems the most reliable option is to actually run the compiler and see if sizeof(void*) is 4 or 8, since running the compiler is what matters in the end. Premake doesn't seem to make that particularly easy though, since it expects the compiler to be specified when running make rather than when running premake, and you have to implement the checks with low-level Lua. (CMake seems to handle it automatically with the CMAKE_SIZEOF_VOID_P variable which is nicer.)

If I remember correctly, the LOS/FOW computations are pretty cheap now. A much more expensive thing is checking whether any enemy units have come within vision range, which is heavily affected by the size of that range, but it should be possible to improve that significantly through engine optimisations since the code is currently a bit stupid. So I think any changes should be motivated just by gameplay and not by performance.

Hmm, that sounds like a bug. What OS / graphics card / drivers are you using?

True, I suppose I see it more as a reaction to the older editor designs than as an imitation of them, so a slightly different kind of influence . (Probably the most fundamental difference in the implementation is that the UI is outside the game engine and uses the standard Windows/etc controls, whereas Age games do the editor inside the engine, which leads to a very different code design. But most fundamental concepts are pretty similar - see the standard game view, paint on the terrain tiles and elevation with brushes, drop units onto the map, add triggers, etc. That seems a generally sane approach but probably not the only conceivable approach, and I suppose we could have ended up with something very different if we'd had different influences, where you e.g. build the map's terrain as an arbitrary mesh in 3ds Max and export it directly into the game, or build every map out of thousands of precomposed chunks of terrain+objects (like Dungeon Siege), or something.)

It sort of is, since about the only RTS editor I had much experience with before implementing Atlas was the SWGB editor (which is the same as AOK's), so I probably stole some inspiration from there . (But more came from the design mockups, and a bit from ScEd, and some just made up based on what seemed sensible/easy at the time.)

In theory, yes, though there will probably be minor bugs so it'll need some testing and fixing (as well as all the GUI work to let you save and select what files load, and the file formats etc, so it wouldn't be trivial to get it working).

It should be technically feasible to add something like that - the game engine is capable of loading mods that override the standard files, and we could (and have been vaguely planning to) make it so each map is a self-contained mod that contains whatever extra files you want. Currently the unit types are defined in XML files like this, but it should be feasible to add some UI for editing them (which we've also been vaguely planning to do) so you don't have to touch the XML directly. It'll need quite a lot of code so it probably won't be done particularly soon, but I'd certainly like to get those features implemented eventually

Hmm, is managing wildlife population levels a fun activity for players to engage in? I'd expect any equations would devolve into some trivial guidelines ("always hunt everything except for 5 deer then wait 30 minutes and repeat") that players would look up in a guide, and then the gameplay would consist of panning over the map and counting animals, which sounds pretty tedious to me and would distract the player from the main focus of the game (managing their economy and military). It could be a good component of an ecology simulation game, but we're making an RTS game, and I don't see how a mixture of the two could really work. (Incidentally I happened to see some documentary recently which rubbished the idea of modelling ecosystems as mathematically stable systems, since they're actually not stable at all - they're constantly changing, and after a sudden disruption they don't return to their original state. I think the programme may have made some potentially dubious claims, but it sounded convincing that stable systems were an inaccurate oversimplification of real life, so it probably wouldn't be "very lifelike" ) I will - the game already has to handle newly-created obstructions (e.g. buildings), and dynamic changes to forests (e.g. cutting down trees), so dynamically creating forests probably shouldn't introduce any problems that we don't already have to solve. I guess the trickiest parts of spawning new trees or animals is picking precisely where to put them, and not making it look stupid and confusing by having them suddenly pop into existence for no observable reason.

Hmm, sounds like it's probably a driver bug, so I don't think there's much we can do to debug or fix it . (You can make the game start in windowed mode by putting windowed=true in ~/.config/0ad/config/local.cfg as a workaround for switching-out-of-fullscreen problems.)

Should be fixed now (see #836 for a few more details).

Done - the 4-year experiment into UI scripting is now officially a total failure. The only intentionally removed functionality is the 'new map' dialog box - the implementation via RMS seemed to complexify the map settings data (I think it was some combination of player_defaults.json, settings from the last loaded map or RMS script, the current map settings UI, some values from the C++, and some values from the dialog), and it was inconsistent with the new map you get when first launching Atlas, so now it just does the same as first launch (i.e. load the "_default" map) which seems to make everything much simpler and more controllable. To replace the dialog's functionality, I added a "replace terrain" tool, which is like the normal "paint terrain" except it paints every tile that's using the same texture as the one you click on, so on a blank map you can easily replace the default grass with any new texture (plus you can use it non-blank maps if it happens to be useful). Also I added a "resize map" button, which is pretty limited and unreliable but works for blank maps. There's no way to change the default height trivially (though you can raise/lower then use "flatten" with a giant brush size) - it'd be good to add a feature that can raise or lower the entire map at once (and tell you whether it's clipping at either end). Otherwise I think it should be pretty much the same as before. Hopefully I didn't add too many more bugs - please complain if there are any (other than general ugliness).

Hmm, I don't think there should be any difficulties - the UI should already be independent of the simulation turn rate, and pausing is just like a really really slow simulation rate, so I think it should be possible (and a useful feature to add). I could be mistaken, though

I'm not sure they necessarily do - if the game picked a default sidedness depending on orientation (maybe the side nearest to the nearest civ center is considered the inside) when you place the first wall segment, maybe with some control to override it (press space to flip or something), then any future connected segments go the same way round, would that be sufficient?

The game ought to say "Audio has been disabled, due to problems with OpenAL on OS X." when you launch it, which partially explains it . (The relevant problem is #685 which needs to be investigated and fixed somehow.)

Maybe, but in some cases I imagine you might want to see exactly what a player could see - resource counts, fog-of-war, combat alerts, etc - to get a better insight into how the player made decisions, or something. A separate mode that shows you the whole map and all the unit details would be good too, though.

You explained it well - I was just repeating it and saying I agree it'd be good, in contrast to what "control all units" does . (I want to implement a replay system some time and I expect that'll have some way to watch the game from the perspectives of different players, so this would be a natural extension and could probably share the player-switching UI (except working in normal games, not just replays), so I won't try implementing anything right now but I'll keep it in mind.)

Yeah, "control all units" doesn't work well now - the gameplay code still thinks you're always player 1, and the option just changes the UI code to let you issue commands to other units, and the gameplay code doesn't yet verify that players are only commanding their own units, so it sort of lets you control them but not properly. If we switch everything (UI and gameplay state) to player 2 when you select one of its units, that'd probably work much better.

Do you mean it's a problem with each new alpha release, or with the frequently-updated 0ad.dev Ubuntu packages? Alpha releases will probably change files in every area so you'd have to download everything anyway. Maybe it could help with 0ad.dev, though I imagine it'd be hard to keep all the split packages in sync (without being able to bump all their versions to a consistent number, since that would force a re-download), and if you want to keep up with frequent changes then maybe using SVN is better public.zip shouldn't be a problem - the engine will load every .zip file it finds in that directory, so we could just split it up into multiple ones.

Given the suggestion in post #3, there's a new SVN tree for lossless files (currently the only ones are in music/), with a directory structure mirroring the main SVN one. I think the rough plan is that new audio files should be added there as well as manually putting .oggs in the main SVN, and that's about all for now, but it means in the future we can re-encode as necessary to improve quality/size.