leper

Same for simulation/data/cheats, simulation/ai, simulation/templates/{campaigns,formation,other,rubble,skirmish,special,special_units} and a lot of files in simulation/templates/ that just provide a base for generic stuff and not anything balancing related (mostly). There are also lots of files that aren't changed from svn but copied over for no reason. Copying/changing them when needed would make that more maintainable. I'd advise you to take care audio/music/ and some of the icon files which are clearly infringing copyright.

binaries/data/mods/public/gui/{pregame/mainmenu.xml,gamesetup/*,savedgames/} for the GUI part. Reusing most of gamesetup should help with not having to duplicate a lot, but just having a dummy screen and filling that in later might also work just fine. source/{gui/scripting/ScriptFunctions.cpp,ps/Game.{cpp,h},ps/SavedGame.{cpp,h}} for the actual loading and starting (though that will need a different way for multiplayer saved games). source/network/Net{Server,Client}.{cpp,h} for the rejoining logic. Not complete by any means, but it should give you an idea where to start.

#1088 No. Yes, see the ticket. But there is nobody working on this currently.

You likely installed the 0ad package from the games repository for Tumbleweed (rolling release). You should use the 13.1 repository.

Looks similar to #2627.

Ignoring most of your post, but I have to answer to this part: Commits including code you contributed (full listing): r15150, r15677, r15699, r15868. There are some patches on trac that were applied (and are in the above listing), or they did get a review and weren't improved and thus aren't going anywhere, or the ticket was just invalid. Yes, commits can be reverted, but patches can be improved before they are committed and as can be seen you didn't do that. Code contributions (patches) say more than long forum posts and judging from yours your demand for source access, the demand for getting an answer in less than 8 hours, and the above rant some 3 months later is presumptuous at best.

Delete this file and try again.

You are sharing your SVN folder between different operating systems, run update-workspaces.bat when you switch them.

Mail sent.

Ah, I just misunderstood you. Yes, the unit must have gained the XP before being converted (else it would have been promoted). The GUI problem is only the visible manifestation of a simulation issue which shouldn't happen in that way (but does because we mix two different ways to handle technolgies on ownership changes).

I'm still able to reproduce the bug with the steps you listed above, did you change anything else? You could just use cmpPromotion.GetRequiredXp() || 1but that is a workaround for a bug, nothing else. The issue is that the requiredXp apply the tech change, while nothing calls IncreaseXp(). See the patch above, and the other possibility listed in that post.

So how does selling stuff released under Attribution-NonCommercial-ShareAlike work exactly? Any specific reasons why we should? This would also require us to ask contributors if they would agree to relicense their works (else we'd relicense stuff just for the sake of it while any adaptions can use a later version of the license ( 4.b )) EDIT: I removed your duplicated post.

The attached patch only promotes units that are newly created or already owned by the player when the technology is researched. I'm not really sure what way we should prefer for the game (though I agree that promoting units upon conversion is strange) (the other possible change is just adding a message handler for ownership changes and calling IncreaseXp(0)). The attached patch might also lead to strange behaviour if there are multiple promotion techs that build upon each other and only include the (n-1)th rank. That way you could research the first promotion tech, then convert an entity and after that research the second promotion tech and the entity would remain at rank one. Up until it gets a normal promotion where it will go straight to rank 3. Some discussion about how we want to handle techs in the context of conversions would be nice as currently we seem to have some mixed behaviour (with some components applying changes on-the-fly) and others caching them and only changing values if they get a ValueModification message. Is the third issue easily reproducible? Can you please create a ticket with instructions on how to reproduce that? The last issue reminds me of a bug we had with some interpolation optimization code some time ago, but those changes were reverted. Is this easily reproducible? Again a ticket would be nice. promote_later.diff

Did you by any chance copy a whole config file instead of creating a new one at some previous point? If yes, delete that one.

Seems like you're the first one testing this to this extent. Looks like the actual actor isn't copied over for Fogging (there is no way to do this currently, but it should be trivial to add), while the techs are not applied in the preview and corpse cases because we do not send messages for local entities to scripts that globally subscribed to that message (to prevent them from picking up non-network-synchronized data). I'll open a ticket. EDIT: #2907

Because the support for that version ended on May 9 2013.

As can be seen on the Linux Mint website Linux Mint 16 is obsolete since July 2014. We do not provide packages for unsupported distro versions in our PPA. You should upgrade your OS (maybe to an LTS release).

Place them Place them in the user mod in the user mod folder. You will have to specify -mod=user for the svn version only (as the last mod). Or specify -noUserMod for the release version and specify the same mod (which should be in the user mod folder) for both.

#2489 is another issue, that is a bug with sending the already translated size string in the game report stanzas. I'll commit a fix soonish that changes the code to send the size of the map (in tiles) and translates it on the receiving end. EDIT: Fixed in r15895.

http://play0ad.com/download/linux/#a0A.D.providedpackages

Yes, the current system is far from perfect, but it is still working for most languages and there are quite some other issues that have higher priority. Something that could be done would be to stop including all glyphs (see my comment on #2843). Thank you! I'll take this into account when I have to build that mod for the next release. Attached.Created using ./pyrogenesis -mod=mod -archivebuild-compress -archivebuild=/path/to/0ad/binaries/data/mods/jplocale -archivebuild-output=/path/to/0ad/binaries/data/mods/jplocale/jplocale.zipYou might want to update the information at the link in the mod.json (still points to A16, the fundraiser, and doesn't include any information about the lobby (at least none that I can find)).

Checking the lobby might be a good idea too.

Care to elaborate? That's one of the reasons why there are two mods now (and because some of the fonts used might provide glyphs for more than one language and collisions between those could look ugly). Those fonts are in a mod as others do not need those glyphs and the current way we handle fonts needs those huge files. (See also #2843) Finding nice looking and compatible (license) fonts isn't really easy though, so if someone knows of a better looking font (or more complete one) just tell us. It's a mod for a reason, and if you (the Japanese community, same for Chinese and other font/language families) can do a better job at providing a mod (which I assume is a lot easier as there is a lot more documentation about such fonts in those languages) please do so. If we have a font that has the needed glyphs we can display it. Scripts needing allographs will not work, that would need a new font renderer using Pango and HarfBuzz.

See http://play0ad.com/about/official-logos/.

I noticed that the po file for the mod selector was missing. Also added a mod for zh_TW, and renamed the mod containing ja. Using MicroHei for Chinese glyphs. EDIT: http://sourceforge.net/projects/zero-ad/files/releases/locales/