leper

Thanks for reporting this. #1930

Ah, I wonder how I missed that when committing the hero button... Fixed in r13401. Thanks for reporting.

Could you post the first errors from interestinglog? (See GameDataPaths for the location of the file)

Locked again, as this didn't go anywhere.

The host needs to forward UDP port 20595 in his router. (See the multiplayer setup page on our wiki) (In case that doesn't help you you should search for a guide on how to port forward with your router (model/brand))

The folder where the data is placed needs to be mods/public/. You can create the user mod folder and the game will read files from there (for the folder see above).

The archive reader only supports DEFLATE compression or no compression, so you would have to adjust your compression settings. But that isn't how the game is supposed to be modded, as we have support for user mods you could just create the file and folder structure in ~/Library/Application\ Support/0ad/mods/user and the game will load it and replace the file of the same name that is present in public.zip.

Thanks for reporting, this is fixed in r13383.

Wow! (Just some comments as to not distract from that beauty too much, but the background could use some more work (I know it is just temporary) as it looks a bit too modern. The player names for the diplomacy screen need a bit more vertical space.)

The issue quantumstate encountered isn't actually one (more like a feature) as the server prevents creating a lot of accounts from one IP in a short timespan. My issue is probably due to some packaging error of the gloox package I'm using (I currently switched to a build of the 1.0 SVN branch of gloox, but there is still problem and I need to find some time to investigate that further).

It is.

That would probably depend on me finishing my mod support work at some point in the (hopefully not too distant) future. Alpha 14 would be a possibility IMO. I still haven't managed to register an account, or log in with one quantumstate created. (Just getting "disconnected" messages (added some code to prelobby.js))

That would still count as a derivative work so either he'd have to release his code as GPL 2+ or he would be infringing copyright, as he clearly didn't clean-room reverse engineer the engine. But he would still have to distribute the source code and anyone could just release the same for free.

Possibly /usr/share/0ad/data/config/ or /usr/games/share/0ad/data/config/ (depends on the distribution, but the latter is common for Debian based distros). EDIT: There is an error with the -xres=123 switch (the site lists =xres=) EDIT2: Also the Linux config paths are XDG base dir conforming. About the other paths see the GameDataPaths wiki page.

You should take a look at gui/session/input.js around line 415 (determineAction()). The worldclick is handled in gui/session/session.xml which just calls handleMinimapEvents() in input.js (which is probably where you should start with this ticket).

Try starting the game with -autostart=MAPNAME -autostart-ai=PLAYERNUMBER:BOTNAME -autostart-ai=PLAYERNUMBER:BOTNAME. (replacing the stuff in all caps with the map and bot you want) Example: 0ad -autostart="Oasis 01" -autostart-ai=1:qbot -autostart-ai=2:qbot-wc For more options please read the readme.txt.

The minimap code is actually in source/gui/. The minimap component is only used by the former to know which entities to render. Going from the gui code via the simulation just to update the minimap seems strange and is probably bogus. Either go from the simulation to the minimap (analogous to the way the entities are handled) or from the simulation to the gui code (which you already do) and then from the gui code to the minimap. The first way would probably lead to some problems that would need to be worked around, and the second does seem to be the better design choice.

If you want to play Alpha 13 (multiplayer, as there are quite some new players showing up in #0ad) you could install it alongside, as SVN is already some changes ahead. (If you want to know if all those features listed in the announcement are in your SVN copy you just have to run svn up)

LOGWARNING() and LOGERROR() is what you are looking for. EDIT: debug_warn() prints to stdout (or stderr (I'm not entirely sure without checking)) and breaks into the debugger, so it should be used if the code that triggers it indicates an engine bug. While LOGERROR() should be used for cases where modders can trigger it (eg: Wrong data files).

You're right on that. I'm sure there would be some issues if we would go down that road, but we shouldn't do that as that doesn't seem to be the right way of handling this.

Small nitpick, but "The game" should be replaced by "The UI". (The ResourceGatherer component can handle multiple resources at once, but the UnitAI code related to gathering explicitly drops all other types when switching)

Use patch -p1 < file.diff (the -p1 strips the paths for the files to be patched until the first / (inclusive))

There have been some plans to have more than one main menu background. I recall some discussions about one for each civilization (but that was back when we still had 6 of them), but I don't think adding some variety would hurt.

Really great progress on the last few images! Keep those coming!

Should be fixed as of r13274.