leper

As always posting full error messages (starting from and including the first one) does help.

If you only execute those commands in the same shell and run them in the foreground, then obviously you are only able to run a single command at the same time. But since I'm assuming that you aren't running something like DOS you should be able to make use of multi-tasking and run one of them in the background. It might be advisible to script the startup, possibly even hooking it to system startup (at least that's what I did on the lobby server). Judging from your PS1 you are probably running bash, in which case read the below taken directly from `man bash`

Why should we? If we did you'd have to find something new to complain about, some of us might take over the world or worse, someone else might pick up where we left (in which case you'd have to voice your complaint again), etc. But most of all because we are doing this because we want to. (Locked, since people already started feeding the troll.)

Maybe we can now actually serve a valid cert for releases.wildfiregames, which someone might have complained about a few months ago...

What the editor supports is just sensible choices, if you really want to go somewhere were you might run into limitations (be that performance, memory, or just the code not designed to handle more than a certain size (though I would consider crashes that don't tell you that you are doing something unsupported bugs)) you can. Open the editor, save the blank map, delete the .pmp file, open the .xml file in an editor, add something like <Terrain patches="25" texture="blue" priority="0" height="16384"/> under the Scenario tag, save. Load it again. You might want to play with the patches parameter, but at least using 50 works (in the sense of you possibly eventually seeing a result, though editing terrain is very slow, and that map is huge enough that at the zoom level where you can see the whole map you'll likely not see much of any unit). (Might also be that we should only do certain recalculations in atlas after some modification finished instead of all the time.) Also since it seems relevant you might want to take a look at some of the old campaign demo scenario maps, though those are just mockups.

(First let me curse about the forum software that managed to have an "autosave" feature that doesn't work, thus I'm writing this again... Now in a proper editor because @#&#036;% WYSIWYG doesn't help with splitting quotes.) As the schema should say that is just an example. More specifically an example of what is currently used in the public mod (though it might not be accurate and complete). Yes, just add them to the respective token list under the Identity tag. For the purpose of the game: None. Most of the games code doesn't even know that there are two different lists, that is an internal detail of the Identity component. The only difference is that VisibleClasses might end up being shown to the user in e.g. GUI tooltips (requirements tooltips, unit training tooltips) and are translated (if the mod has a translation). Yes, just add them to the respective list. Done. They aren't the same. They could as well be named A and B, apart from the detail that CivilCentre is displayed in the GUI. There is no meaning in a class which is just a bunch of characters, the only meaning comes from specifying the same string in a few places (e.g. technology requirements). If you mean entity templates that are used to reduce duplication when specifying those look for files named template_unit_support.xml. If you mean for classes (be that in Classes or VisibleClasses) then no, since those are just a bunch of characters without any intrinsic meaning. (Slighly modified, blame me being lazy after fighting with the forum.) This is related to how we handle template inheritance which is explained in some detail in the CParamNode documentation. I'll give a short overview of how token lists are handled (which is what both Classes and VisibleClasses are; notice the datatype="tokens" attribute). The token list elements of the parent (after the parent was already handled fully, taking care of inheritance) is enlarged by adding all tokens in the template. Except for those starting with a -, these remove the token from the list. Note that trying to remove tokens that are not present in the parent will result in a warning. So for your example we get template_unit: Classes: {Unit ConquestCritical} ; VisibleClasses: {} template_unit_support: Classes: {Unit ConquestCritical Human Organic} ; VisibleClasses: {Support} template_unit_support_female_citizen: Classes: {Unit ConquestCritical Human Organic FemaleCitizen} ; VisibleClasses: {Support Citizen Worker} Yes, that's all there is to it. For a specific unit open the developer overlay (Alt+D) and toggle "Display selection state", you will see the Classes and VisibleClasses for that unit. If you mean all, then no. Some grepping of the templates should give you an idea, but since there is nothing to "load" it doesn't seem very interesting. You could however write a little code and use the Units Demo map that places all entities and get a full list if that is really what you want.

For patching public.zip one could extract that, patch it, then compress it. (There are also binary diffing/patching tools, and our zip files are not compressed, so that shouldn't be too hard to do.) Also you might want to check the documentation for your patch(1), especially the -E (or --remove-empty-files) option.

Nice work! Care to publish the additional tooling somewhere? Also I do hope you are interested in working on some of those improvements. About games being stuck, it might be interesting to save the game at that point so they can be inspected manually (as the AIs might be in some state where neither can win, but none is defeated). Proper (as in fully deterministic) AI serialization would help with figuring out some of the internal details at that point, maybe we'll get there someday. For the summary that looks quite a lot like what we do for replays already (and part of it would be the first line in commands.txt files). About the extra parameter I'd both appreciate having that per player and then kept in cmpStatisticsTracker and updates to that being done via simulation commands. As for running multiple games in parallel I'd do that via some sort of launcher, so we don't have to worry about possible non-threadsafe code in tons of places. So the only issue we'd be left with would be file system access (and that should be read-only for the most part, except writing the statistics (and that should just use pid+timestamp), but that should be done to one file per game, so there is no huge issue there). Running a few games consecutively could however be done by the game relatively easily.

Fix your editor (take a look at the diff if you want to know why); handle interpolation (mostly just needed for the current (or first) line, unless some waypoint is actually another unit that is moving); figure out in what ways the code for UnitAI is broken now (there are some 5 years of changes to account for), figure out in what ways it was broken back then (though just figuring out in what ways it is broken now should suffice); remove that ugly duplication with the RallyPointRenderer; reconsider using std::list there (as in not using it); think about formations again (just because they are somewhat broken doesn't mean we should break them even more); possibly some more, also read the ticket that might have some insight.

Female citizens are able to build military buildings, they just can't place the foundations for them. If you want that you can just remove the entries from the Builder list by adding -template in the token list.

You can, however that just restricts being able to place the foundation, not the actual construction of it (see the Mauryan Worker Elephant for an example of that).

Adding only ResourceGatherer but not Builder will do that. Since you inherit from some unit template you will most likely need to disable them by using <builder disable=""></builder> . As for restricting what buildings a unit can build, no there is no way to do that currently. If you really need that you should open a ticket on trac. (I suspect the actually needed changes to restrict building to only those present in the Builder list shouldn't be very complicated.)

Just looked at the code, the Actor Editor indeed hard-codes the public mod, though you might be able to manually open a file from another mod. They should show up (if the mod config is saved (enable the mod, press the save button in the mod selection screen) in Atlas though. (Also the Actor Editor is broken on *nix #1553, so removing that hard-coding (and making it use the vfs like mentioned in a commit from 2008 (r6395) would be nice if someone is inclined to work on that.) As for the icon issue (and I guess a few other questions) having your mod in a public repository or something can be quite helpful (as debugging remote and blind is quite hard most of the time). (Also keep asking questions, this helps a lot with figuring out where documentation could be improved (also feel free to do that if you find something lacking) and it tends to expose bugs or limiations.)

Was the mod enabled and did you save that config? (If not there might be either a bug or a limitation in atlas)

Just to rule out the obvious, but did you restart atlas after adding that unit (hotloading could be broken in atlas (on some platforms))? Are you doing your work in a mod? If yes, is that mod enabled? You could try adding your custom template to the public mod to rule out any mod related issues, if none of the above worked.

Hacky solution, yes one could merge most of these things, also just doing this in awk might be nicer. The final sed is because some commands (training siege) seem to list the entities this applies to last instead of first (which doesn't matter, but makes this a bit longer than it should be. I'm not sure why you have numbers, then xN in that list, nor do I really care, but yes one can figure that out from a commands.txt file. For a proper solution one would also need to handle cancellations, and possibly parse the json for each command to make sure the order doesn't matter. grep "cmd 1" commands.txt | grep "train" | sed 's/^.*units\///' | sed 's/","count":/ /' | sed 's/}$//' | sed 's/,"entities.*$//'

Mostly just some amount of work that might not be that fun, or at least needs someone somewhat interested in drawing lines (mostly the interpolation part, and cleaning up the whole duplication with rally point lines). At least the part about just adding flags (or something else which could be used as an indicator) as implemented in the last patch there should be working and (at least given what I recall about that patch) should be relatively easy to factor out if someone wanted to do the work.

Changing templates and loading save games might work, but I would recommend against doing that for proper testing. Same as hotloading is fine for figuring out if something fixes a bug, but could break unrelated things in various ways. Stats for entities present in a saved game state should still be the same after loading, so newly trained units will have the new values while everything the existed before that point will still have the old values. Same as for hotloading (exept that there you might run into some things being cached and not being invalidated when hotloading).

Look for interestinglog.html and mainlog.html (where might have been mentioned already ;-) ).

(Sure someone could download the map, try it and whatnot, but that requires doing more than just looking at the logs.)

To select actors (which are just graphics, no impact on gameplay) press Alt. (This and a few other things that might be useful are mentioned in the Atlas Manual.) For logs (and also where to place maps when installing them (assuming that they aren't in a mod, and even if they were the information would be there)) see the game data paths wiki page.

No, check the structure tree if you want to know. You can disable the aura range visualization if you don't like it, also there is a hotkey to toggle it.

Sounds somewhat related to #4480. At least in the sense that there appears to be some invalid entry there. Might be interesting if a visual replay with that player follow option is able to trigger this again.

Because that citizen soldier doesn't have an aura.

You'd be surprised if you knew more