leper

We should just make sure that the attachments work properly, I'll note this in the update topic.

Fixed in r16201.

From the topic that contains the application form:

Must be some ninjas on IRC.

Intel graphics? Enable GLSL.

The nick used by whoever posted that on the EB forums.

Nick doesn't ring a bell, quite impressive to speak on behalf of the team without being part of it.

Why should anything be considered a punishment? Those are the rules you have to follow if you want to use our lobby service (which nobody is forcing you to use). Ignore them and you aren't using the lobby service anymore. (Anything that isn't an outright ban is because whoever is moderating that incident is being nice.) Apart from that I find it interesting that some of the most vocal about this issue have never been seen on the lobby...

Implementing something to hellban users is work. Work that could be spent on things that benefit everyone, banning users isn't that hard. (As you can read in the lobby subject (text on the right) there is no n-th offense stuff anymore. If someone doesn't like how the lobby is run they are free to host their own, it's not like there is no readme detailing the setup.)

Having read some of their code some time ago I got the impression that the C++ code is written by Python devs. Which results in some strange C++ code. (Using "and", passing std::string instead of const std::string&, and some other things. From a quick check it looks like they got some more tests now which is an improvement) Maybe I'll open a pull request for some of those issues.

PeneThor unbanned.

There has been some influx of mostly young users recently...

That one was also taken care of (and some more).

Should be taken care of (server logs are nice).

Secret stuff. (Still needs some cleanup to remove some code duplication, but I'll commit that to my fork soon)

The sprintf_s could be fixed by including lib/secure_crt.h instead. g_XmppClient is defined and set to NULL if you build without the lobby (at least when using premake, so your build system is broken). You should use OS_ANDROID in cases where you have different ifdefs. The changes to lib/config2.h should go into some build script or project file. Unless you implement ENet 1.3's protocol with that library you will not be able to play multiplayer. Seems like a good start

The user-writeable mod folder is where mods should be installed (as that should be user-writeable on all systems). If someone wants to install a mod system-wide they can surely find the installation folder anyways. I knew I missed some documentation. Thanks for pointing that out. Nice work (haven't tested the mod yet, but looked at the code a bit)! Might it be easier to just create a simulation to query it? Or should we just expose the template loader to the GUI? It seems like quite some code is at least partially duplicated from functionality already implemented in the simulation. I might have to take a look at scrolling of gui objects now... (pesky contributors contributing ) Thanks for a nice testcase . Also using the nested repeats might help with making the GUI XML files a bit more readable.

Well that is not an apology for your behaviour that went against the ToS/ToU. I gave you a chance to be unbanned but it seems you don't want to be.

Use a script to fetch dependencies and build them, see http://trac.wildfiregames.com/browser/ps/trunk/libraries/osx or even better http://trac.wildfiregames.com/browser/ps/trunk/build/android. Breaking network compatibility and calling it a first class citizen is not the way it works. The real changes needed to make the Android port anything more than a proof-of-concept is someone working on a usable user interface. Supporting the editor on Android seems a bit strange for a platform where sharing the maps you created without any other tools will be a bit cumbersome. Nobody who wanted to rewrite Atlas (you're not the first) produced anything working, or pointed out a lot of things that were broken and not fixable without a complete rewrite (not that Atlas is without issues). If someone is actively going to work on something that big having an idea of what does not work now is a huge part of not introducing those bugs again, and that does not guarantee that no new bugs will be there. Patches that replace huge parts of the engine just for one platform and the sake of it and make that platform incompatible with the rest of the game are very likely not going to be accepted.

http://play0ad.com/category/game-manual/

The code supported multiple backgrounds for quite some time. It might need some slight adjustments, but it shouldn't be a lot of work. If LordGood could give us some layers to show that would help a lot.

That'd be a bit more involved. Mostly because we don't even support scroll bars for objects, but just for lists (and some similar elements). I'll see if I can take a closer look sometime.

r16034 adds support for nested repeat tags. See the repeat GUI object documentation on trac. EDIT: Also created #2952 to clean up the summary screen xml.

Looking at the code it should be easy to make the code match another letter. Currently it is hard-coded to use [n], but just specifying what to use in another xml attribute for the repeat tag doesn't sound hard to do.

So you wanted some of the perks of being a team member without any of the obligations? That's not how things work. Also the Wildfire Games Application Form states: Notice the contributions part you stopped doing at some point and never resumed? Your project didn't have much apart from a huge forum post that didn't convey what you wanted to do and huge forum posts about things that might or might not happen have a high tendency to be left unread (or skimmed over and deemed to long). Phrasing your initial post properly instead of demanding something might also have been a better way to help others understand what you wanted to say. Also being intent on forking without even seeking a discussion with the upstream isn't how you're going to get commit access either. No, the first two posts in this topic do not count as seeking discussion. "Whole-world" with only some outside of Europe and America and you posted this on a Tuesday morning (yes, not only you have other obligations apart from just reading this forum), so the chance of anyone having time to read the forum and reply to posts that require knowledge of some things is pretty small. Moderator rights is the wrong term. Priviledge is the word you are looking for (some might say obligation). We are trying to interact positively and closely with modders, but the fluctuations in the CoM and other related issues (read Romulus) might have made us a bit cautious with handing out such priviledges. Your reaction of leaving a short while after also makes that judgement quite right, doesn't it? Because emotions are so easily conveyed across a text-only medium where people have better things to do than wonder whether someone who dropped a few patches and disappeared feels about not getting a response within 10 minutes. You also didn't take care of your other patches, so just adding more to the pile does not really count as helping a lot. You could have forked the git clone and worked there so that others can see your work and we can see how some of the patches might be useful. But you didn't even do that, after neglecting all your patches on trac, and then you come demanding SVN commit access which is an earned priviledge that isn't handed out without any consideration whatsoever. And since then you also didn't even release your changes anywhere and you still wonder why nobody cares about a fork that doesn't give anything back.