Ykkrosh

Updated the build instructions page to include them.

I can't reproduce that problem (on OS X 10.5) - the cursor seems fine whenever I move it around and click stuff. Has anyone else seen a similar problem?

I think using custom features of file formats is generally bad (like using custom file formats), since it makes editing unintuitive and often requires special tools - better to keep things simple so you can use any old Ogg Vorbis exporter and a text editor. I don't particularly like the current sound-group XML system, though - the XML files are verbose and unintuitive and contain lots of redundant data. Maybe it could be more like the texture XML format where you can specify the defaults for a whole directory then override them for groups of files, or something. I don't have any detailed ideas but it seems like an area where an improved technical design (and implementation) would be pretty useful to make it easier to maintain sounds.

Hmm, it sounds like more people disagree than agree with this. The colours look sufficiently distinct from our terrain textures (which are not highly saturated) to me, and the shading on the bars makes them stand out a bit more, and the bars aren't so important they should dominate the display, so I'm tending to think the current approach is okay. Would other people prefer outlines? (If so, maybe produce a screenshot mockup to show what they'd look like?) Changed it back.

It's meant to be alarming . The usual cause of immediate desyncs is when the players have slightly different versions of data files - we probably ought to check for that specific problem at the start of the game and report it so it's easier to see when that's the problem. Other causes of desyncs are serious bugs and need to be fixed, but I think they're quite rare. Slow framerate, or smooth framerates but jerkily-moving units? The first problem needs general engine optimisation (there are certain cases where e.g. pathfinding becomes very slow); the second problem needs better latency-adapation in the networking code (currently it'll be jerky if any players have >200msec RTT) and reduced non-network latency (move the network message processing into threads so it's not delayed by rendering). Good point - filed as #591. #572.

Added resource supply bars. Made building bars bigger (you can edit the sizes in template_structure.xml etc). Changed it so nothing happens when hovering on a unit (but I'm not sure I like the lack of visual feedback).

(Eventually these settings should be exposed by the map editor so you don't have to edit the XML. But they're not yet.)

In the "conquest" mode (the default), a player loses when they have no entities in the "ConquestCritical" class - currently template_unit.xml and template_structure.xml add that class to all units and all structures, but I guess we'll want to change it to ignore certain units. Currently the only alternative mode is "endless", where you can't win or lose - custom scenarios might want to use something like that and write their own triggers to control victory (at least once we've implemented custom scenarios and triggers).

I added some. They look like this. They're displayed in the same cases as the selection circles: either when a unit is selected, or when the mouse is hovering over it, or when it's inside a bandbox that you're dragging. The bars always render as green-on-red (regardless of player). Entity templates can use <StatusBars><HeightOffset>5.0</HeightOffset></StatusBars> to control the position of the health bars, above the ground the unit's walking on. The code determining the sizes and textures etc is in mods/public/simulation/components/StatusBars.js. Are there changes that should be made here?

The latest release of Boost works too - any version should be fine. If you're on Windows then you don't need to download any libraries, so are you on Linux? and if so then what distro?

In actual gameplay you can never look above the horizon, so you'll never directly see the sky. You can only see the bottom of the skybox by looking outside the edge of the map, and it's most sensible to draw black there. (You can see the sky indirectly in water reflections, so we still draw it in that case.) Lighting shouldn't have changed at all.

I think the danger with adding child objects is that the GUI engine might have pointers to the objects (when tracking focus, or when in the middle of an event handler on that object, or via a script value corresponding to the object, etc) and then delete the objects (e.g. when replacing the parent text box's content) and then try to use the pointers. That would be the same problem whether the objects were created dynamically by scripts or dynamically by special icon-handling code. I'm not really sure what's a good solution, though. I'd guess maybe keep a single GUI object and have some extra code in GUITooltip to make it trigger tooltips based on some function of the mouse position determined by the GUI object, so the text box can trigger it when the mouse is over an area it knows is an icon (and then it can update the tooltip text too), or something like that, but I don't know the details.

Dynamic creation/deletion of controls would be hard, since the whole GUI engine was designed with the assumption that it would be static, so I expect many things would potentially break (mostly by crashing with invalid pointers) and I'd prefer to avoid that if possible. For the special case of tooltipped icons in text, it might be easiest to add special support for that into the GUI engine - it already supports "[icon=foo]" to insert symbols (defined in common/setup.xml), so I guess we could add tooltips to those icons somehow. Probably depends largely on how powerful/generic we want this to be.

I thought the secret was already unlocked by the guy who proved they must have been built with extraterrestrial assistance, most likely from Sirius.

Our approach until now has been to use XML for everything, but we haven't needed to pass data directly to scripts until now. (Most XML files are only processed by the engine, and entity template XML files are heavily modified by the engine before the simulation scripts get to look at them). It feels kind of weird and inconsistent to start using JSON, but I can't think of any serious technical disadvantages - it's easy to read and write in JS, it's easy to process in external tools written in Perl/Python/etc, it's easy for humans to read and edit (as long as they don't want to add comments). Only problems I can think of are that it's harder/slower to parse in C++, but if it's necessary we could add an API to make it easier (though it'd probably still be slower), and that it's harder to do automatic validation of the file format, but we don't really do that for XML files anyway and it hasn't been a big deal.So I think using JSON is probably good now. Yeah, there's no diplomacy stuff in the rewritten simulation code. I've tried to make sure some components (RangeManager (used for finding enemy units) etc) support players in alliances (e.g. their API takes a list of players to consider, not just a single player), so hopefully it won't need any fundamental changes anywhere, it just needs all the little details to be added in. Sounds great

No it won't - it'll give a "permission denied" error

It should be safe to just ignore the warning - we're changing the game so the next release won't need libtxc_dxtn at all (but it may still need you to run "driconf" and enable the S3TC option).

Yeah, there's some of that throughout the engine . Good to clean it up when possible. The mapping from JSON to an in-memory JS value is trivial; the mapping from XML is more complex and the result is often worse (since e.g. there's no single obvious way to represent arrays in XML) and we'd probably have to write the code ourselves to do it. So it's just easier and more natural to use JSON, when the data's only going to be used by scripts.

I think it's best for this to go in gameplay scripts instead of in CMapReader, so that the engine doesn't depend on any details of player data (it just cares about player IDs and otherwise is flexible). (simulation/helpers/Setup.js can set up the player entities based on the map data, probably.) (My current theory is that code only ought to go into the engine when it'd be either impossible or slow or otherwise painful as scripts.) I think this doesn't need to be in the engine, it can just be in scripts. Probably we need to add a way for GUI and simulation scripts to load arbitrary XML (or JSON?) files but then the scripts can do their things without needing more C++. Yeah, breaking things is fine as long as we update all the maps in SVN, there's no guarantee of stability yet. Hmm, I'm not quite sure how that's meant to work in terms of the game design - are these separate civs that players can choose from, or are they just historical notes on the unit types that are provided? (Is some designery person reading this?) I'd expect most of the details for technologies and behaviours etc to be specified in independent files, and just referenced by name from the civ data, so they can be easily shared by multiple civs and independently edited by mods. Some of it (e.g. lists of structures) maybe doesn't need to be explicitly specified at all, it's just an implicit consequence of the building/training/etc lists specified in that civ's entity templates. Why? (Setting them individually doesn't sound like it'd be a huge pain, but maybe I'm missing the problem.) Looks good to me

2. Yes. 1. Yeah, I think Brian already mentioned that - it's caused by the fog-of-war changes (the fogged/non-fogged colour overrides the obstructed colour). There's a related question of what should actually happen when building buildings - perhaps the best option now is to only allow building in visible (non-FoW non-SoD) areas where you can see anything that's in the way, and later to change it so you can attempt to start building in FoW but the builder might give up when he gets closer (e.g. if an enemy building was placed in the way), or something like that.

I've been using it the same way as you (SoD = black unexplored regions, FoW = grey previously-explored regions where you have only partial knowledge), and it looks like that's the way most people on the web use it, and we can define things to mean whatever we want within our own game, so I'll say you're right

Could you post a screenshot of what you mean?

Use the movement tool, select a unit, then right-click in the direction you want it to face. There's not (yet) any rotation around other axes. Press 'g' to disable the in-game GUI.

Hmm, that's weird but good . I guess their software is buggy somehow, but I don't know exactly how and I don't know what we're doing to trigger it and I don't know why you'd only get the problem after updating graphics drivers . Would be nice to understand it, but that's probably hard and not worthwhile if it's working okay.

That XML format could probably be simplified a bit: remove "NumPlayers" (it can be derived from the list of players), remove "ID" (it can come from the index in the Players array), remove Colour.a (it always has to be 1), remove Gaia (it always has to be player 0 so making it explicit in the XML is unnecessary and adds potential for errors). Otherwise it looks good to me. I don't believe so - there were just the design ideas linked from there, and not much more that I can remember. I reimplemented the game setup screen about 4 months ago (since the old one was overly complex and didn't work with changes to the networking system) but I just tried to do a simple barely-sufficient design, rather than basing it on the more complex concepts that have been suggested. It hasn't been changed much since then and nobody else is currently working on it, but it could do with some improvements Also there's multiplayer host vs multiplayer client, which might (or might not) make a similarly-significant difference. (Clients should be able to select their own civ, and we probably want to let them select teams/alliances too, but most other settings can only be edited by the host.) Splitting .js files is easy (just reference them all from the .xml), and modularity is good. Probably the XML layouts are harder - you can't mix-and-match different XML fragments (at least without adding that feature to the GUI engine), so sharing code isn't possible, and duplicating code is bad, but mixing all the different modes into one file is also bad. I'm not really sure what's the least bad approach Currently, nowhere. Would be a good thing to add - I don't know exactly what data we need, but it probably includes some for the game-setup GUI (name, history, logo, etc), some for session GUI (name, etc), some for random map scripts (listing which entities to place at the start of the game, etc), and some for simulation (toggling civ-specific behaviours, etc). Hopefully there's not too much in total - creating an XML file per civ sounds sensible, and all the different bits of code can read what they need. Probably should go in mods/public/simulation/data/civs/or similar (since it affects the simulation code, not just the GUI).(One thing we want to do well is supporting mods, and if creating a new civ is as simple as copying-and-pasting an XML file and then editing some of the names, that'd be great ) Hmm, yeah, the hotloading thing isn't entirely robust with invalid input. It seems hard to fix since there's lots of different error conditions all over the place . If one is encountered frequently then I think it's worth trying to handle it more gracefully.