leper

Because you haven't even bothered to look at the actual code at work here, so your "proposal" will fall apart when confronted with reality. The first hint would be that the lobby doesn't use HTTP, so using HTTPS would be more than cumbersome. Same for that secure downloads ticket where you have more text that confuses issues, doesn't clearly state the actual issue (or at least I stopped reading after seeing that wall of text), and ignores that the downloads are already mirrored somewhere. Also tickets are for somewhat workable issues, not long walls of text that call for discussion. I'd strongly suggest finding out what is actually used before all those proposals, as currently you are just making it harder for anyone actually wanting do work on any of those.

Except it requires updating the clients to only use that mechanism (you'd want to prevent clients from using the old one, right?), someone to actually do the work, quite some testing so it actually works properly. There is a difference between what is the required amount of work needed in theory, and what needs to be done in practice. You suddenly used the word "Web". If you start using words in a context where they just appear to indicate that you didn't think about the problem, then you'll have to deal with being called out on that. If the server is compromised an attacker doesn't even need to look at the passwords to impersonate anyone. And in this case they could just try a downgrade attack to get the actual password (we did disable the plain mechanism, but a few of the supported ones aren't that hard to break). We've known that for quite a while, the issue is that someone needs to do the work. threat model No, they are not secure. You just increase the amount of work an attacker needs to do to get possible candidates that match (and how many users do you know with very long passwords (phrases would be better, but I digress). That's not really long, then again you haven't defined your threat model at all, so if the attacker is someone with brains and a Pentium, then you might have a point. If we are talking about server farms or tons of graphics cards that's something completely different. Windowed mode without decorations, or run things in some other X server, or copy the password, then start the game, or get a better program to handle your passwords. Some things are more interesting than others to work on. And so far I've seen lots of talk and no single line of code. Welcome to the internet, I see you must be new here. Only if you try common passwords, at which point the issue is that you are using a common password. One could just try the list from that one Yahoo! leak and get quite far. Unless rate limiting kicks in. True one can just use something distributed to try those, but that wasn't listed in the attacker model. And there is no issue with that, as long as the places they reuse it for are things that for some reason require an account, so they just use hunter2, because if it gets leaked nobody will even care. Depends on whether they used the same password for something that doesn't need a lot of security as for something that most likely should. Why not? Because someone might get offended because they themselves are doing stupid things? How do they remember 500 accounts? But something that you could fix quite easily (probably a diff with about 5 lines (and most of that is adding a checkbox)). Could maybe be done without any interruption, but most likely couldn't. At least it didn't seem that way last time I checked (which allegedly has been quite some time). Well, I'm not responsible for the lobby in any way anymore, so meh. Also you should really define threat model, attacker model, and most of all help with fixing things instead of writing lots of prose. (Eg upgrading the lobby server to something that isn't mostly unsupported, enabling TLS for lobby communication, getting the actual game download links to use HTTPS, ...) It isn't. Not server admins?

Patches welcome. Yes. See the comment earlier about us needing to invalidate all accounts if we were to switch to another SASL mechanism, since at least last I checked there was no way to nicely upgrade that otherwise. By the standard definition of "Web" this isn't a "Web Application" :P Yes, this does suck a little, however so far nobody really cared about passwords for some random game, and we don't even send the actual password (true, one could build a table for that, but the same is true if one hashes on the server; so whatever you do you just make it harder for some attacker once they have already gotten too far). Secure against what? A server compromise? Well, no, but neither would it be if we did hash it there too. It just makes things a lot more work intensive. One could store the password in some password manager or keychain and just copy it into the game every time one logs in. That'd require not storing the password as an option though. So they should use file system encryption, or encrypted containers. And how many multi-user machines are likely to run games and include users that don't trust each other? I haven't heard of anyone deciding to run it atop of a rump kernel so far, but I don't consider that impossible. Without a desktop environment, I haven't run one of those for years. If someone uses the same password for their nukes (instead of the default 00000000) and some random game they deserve what they get. The user will get more stupid to work around your "fixed" technology, so you can either make things useless to people able to read the documentation, or you should stop rewarding people unwilling to read.

Not without changes to both the simulation (to enable it to set the light environment; currently it doesn't even know that there is one) and the renderer.

We are hashing the password on the local machine and only storing that. If you are worried about your password getting compromised you should be more interested in getting TLS enabled, which might need some work to get some Let's Encrypt cert handed to the lobby server, and then switching the authentication mechanism used to one that only stores the hash on the server (in our case the hash of the hash of whatever the user enters) (and yes, this would mean invalidating all accounts currently existing). Your attacker definition seems to include at least read access to your local file system, in which case you are more than screwed already. If you are considering backups, well encrypt those, same for your file system in case you are worried about that. The keyring "solution" has quite a few issues. What if a user changes their OS? What if they just change their desktop environment? What if they don't use one? And all of that doesn't really do anything but protect you against an attacker that allegedly already has quite some access, at which point they could just hook the game and get your password. If you really don't want that hash to be stored in the config file, write a patch that adds a checkbox to save the password only when it is checked. While you're at it you might also want to prevent copying the text that is in the password field. Also don't use the same password for some random game you found on the internet as you do for your banking or your nuclear power plant controls. And don't use quite a few other programs that save passwords, you might be surprised by quite a few (I'll just list Pidgin here, since that seems somewhat similar to the lobby).

I was unsure about this, but I checked the code, and both work.

FMOD might be gratis for "small" users, but still uses a proprietary license, which prevents us from using it.

Techs can replace actors, which would allow you to do that. Not very nice since you might have to nearly duplicate the actor (use those file includes where possible), but currently there is no other way.

Check out the Upgrade component. Since the entity schema documentation is currently waiting on someone to update it (yes, I'm totally not using this post to get work on that going again), you might want to read the top of simulation/components/Upgrade.js to know what you can use.

You don't have to build the exe yourself since we do have windows autobuilds in the repo, which means that you don't need VS. If you also provide the source code (required by the license). I guess looking into how we package the game itself would be a good idea, you might want to look into the files in source/tools/dist. A word of caution though as there is a higher likelihood for bugs (OOS especially, since the dev version is less tested in multiplayer) when using random snapshots. I mentioned using a VCS earlier, using branching would allow you to support the latest stable version and work on the next one without too much difficulty. In some cases you might run into issues when new code needs to be added to the engine (read c++ side), so you wouldn't be able to add those things until a new stable version is released. There have been a few discussions about separating engine releases from game releases, which would help with a frequent release schedule. However most simulation related changes don't require c++ changes, so just shipping newer JS components should help with frequent relases. So you'd just have more recent JS code in your mod, and wait with adding certain features that require c++ changes until a new release is out.

I guess you should really start using SVN, so you don't run into lots of issues when a new release shows up, but only have to fix a few things while the changes are still well understood and the people who changed things are around. Full error output would be nice, see GameDataPaths for where the logs are stored. Being able to look at what your mod looks like would also be nice. (Try using some version control system, and having that somewhat public would help with debugging things.) To disable your mod (assuming you don't just want to rename/move your main menu files), just delete the user.cfg file (see the wiki page linked above for where to find it).

However for reasons of sanity I guess you don't want "units/hylian/hylian_citizen" : "units/hylian/hylian_citizen", there, but rather something like "skirmish/units/default_citizen" : "units/hylian/hylian_citizen", where you'd need to create that skirmish/units/default_citizen template. Or keep the skirmish entities that currently exist and just replace them with what you want (might not work perfectly given what quantities you want though).

Yes, that's the section. No, count does not work there, same as your proposal. This is an object or well set, so multiple definitions of the same key ("skirmish/units/default_infantry_melee_b") are either invalid or at the very least pointless since just one of them applies (depending on the parser the first or the last one). If you want more units you will have to add other skirmish entities to the maps, and then just replace them with nothing for the civs that don't get extra units. Or we have to find a way to spawn units when a unit is spawned (I seem to recall someone running into issues with that and there is some ticket I wanted to look into related to that).

The starting entities are just used in random maps. Skirmish maps use preplaced skirmish entities that get replaced by civ specific units. The generic replacements (including {civ} handling which replaces that with the civ code) is done in the skirmish templates (simulation/templates/skirmish/), and different replacements are specified in the civ.json files under SkirmishReplacements. So I assume you might want to provide a different version of the skirmish templates (in case you want to be incompatible with the 0ad civs right now), or provide lots of replacements in the civ.json files. Assuming you don't want to follow the naming convention the game uses (which I guess is a sensible choice).

That's some gui coding that should be relatively easy to do. Currently it isn't supported, but that is because so far nobody wanted different resources there. It might also need a few checks in the engine related to tributing resources, and possibly looting things. @s0600204 might be interested in improving the resource modding support even more. But hacky solutions do have a tendency to break, I guess I don't need to tell you that. So striving for proper code does help with reducing the maintenance work going forward.

Needs a small amount of code. This is related to the other damage tickets (which by now provide a relatively nice basis for this) #1909 #1910 #1911 #1912, which are being worked on by a contributor, so having a user for a few of those things will help with getting this written. Ah, #2951 paying off. You just have to change what a corpse is. Corpses are "corpse|template" template names, which means the special corpse filter (the file named corpse.xml) in templates/special_filter defines what happens with the original template. So to make them selectable just add <Selectable merge=""/> to that template. For repairing/raising them from the dead you could take some inspiration from the foundation template and play with the initial health in addition to some health decay (negative regeneration or something). For eating this sounds like something that was done at some point in the past, however that code was more of a quick hack to get it working and might need some updates to actually work. Also it has the limitation of preventing those units from gathering at all, possibly more limitations it has been a while. Adding another bar is easy. Having some shield should also be somewhat easy if the health component does check if that is present and first does damage to the shield and only afterwards decreases health. For just firing multiple projectiles that is what buildings and ships do. But the code that does that is somewhat hacky. So currently doable by using workarounds. Projectile bouncing would need code. If showing up for specific civs means just them being able to gather it, then yes, just don't specify any other resources in those ResourceGatherer tags for that civ. If we care just about not taking damage this could be doable by modifying cmpDamageReceiver to just ignore a few attacks randomly. Or we modify it to also get some information about who is causing the damage, which would allow some more fine grained possibilities, then implement a custom cmpDamageReceiver (eg cmpDodgingArmour or something) and use that for those dodging units. With that slight modification to the DamageReceiver interface to pass the attacker information along another implementation can just do a few fancy things: attack back (though one would have to directly reduce the health, else two such units fighting with each other might cause strange issues), something vampire style, etc. With a little code, yes. I guess one could place actors there that have some decal based on territory. That seems like a somewhat strange approach, however currently there is no (or maybe no nice) way to set the terrain texture. There's cmpHealth's SpawnEntityOnDeath. That's just for a single unit though. In some way, but it would most likely run into lots of issues and be a bad experience. There is a Loot component that in conjunction with the Looter component does something when an entity is destroyed, though that isn't quite what you asked for. Delenda Est might have a hacky way to do something like that. A nice implementation might need some work. Could be done with a trigger and a range query. So not right now but the code for that (apart from figuring out how to nicely hook that to the rest) should be quite simple. One of the early patches that added healing worked like that. So it depends on what abilities you'd want, and if actually having buttons for those is the best way (which it might be if there are a few). if (cmpTerritoryManager.GetOwner(pos.x, pos.z) == cmpOwnership.GetOwner()) cmpPosition.JumpTo(pos.x, pos.z) Or something along those lines, and with proper checks for conditions that should be handled. There currently are no auras based on territory, if that gets added this should be quite easy, for now you might have to make do with range auras on territory roots. Should be a roughly 3 line diff, maybe slightly more to make that behaviour changeable based on templates.

Since I haven't seen any checks in that the input and output folders exist (and create them if they don't), I guess you should add those folders to the repository itself. Since git doesn't handle folders, but just files you'll have to do something like add an empty .gitignore file or similar to those folders and commit them.

Right, and I guess it would be best if TheUndyingNephalim also used SVN (at least it would help with future improvements), but for now I just mentioned it.

In that case I guess the instructions should just enable the mod in the mod manager (in-game, under Tools & Options) and save that, then start atlas. A22 isn't released yet, but there are currently RC (release candidate) builds available. (http://releases.wildfiregames.com/rc/)

You could do that in-game by providing unlocking technologies that unlock one hero (and prevent the other technologies from being researched). (At least that was the way our generic civs (hellenes, celts) handled the choice quite some time ago.) One could possibly use a Trigger script and message box to make that decision if that is what you prefer. Probably not, but "religion based mechanics" is quite vague. One could add some way to get some "religion" resource (similar to AoM) and then use that for those mechanics, but some details on what those mechanics might be would help with answering this. This is possible without touching the engine in theory (and it would be a good test for the engine!) but it will come with a performance cost for the pathfinder. Shouldn't that depend on whether the other classes (ships, big siege engines, etc) are still needed? Not really but modding that is possible. Just write a new component for this logic and add it to your building template. You will need to mod the ProductionQueue component to make it interact with your custom component. Depending on how exactly you want that to work that is already possible. At least WC3-style camps that can be "acquired" using capturing are already doable (and IIRC are present in Delenda Est). So if the requirement for buying them or making it depend on diplomacy isn't that strict there is no new code needed. Probably not a fully featured turn-based over-world campaign. We don't have definitive plans in this area but the "strategic map" we could have for campaigns would be largely less important than in Total War:Rome II for instance (I never played Medieval 2, sorry) There are a few possibilities here. A WH4k DoW-style (or maybe CnC style) territory like map (without any real interaction apart from attack this thing now) should be doable with the very wip campaign infrastructure patch. Though I guess that falls short of a TW (basing this on Rome TW) quite a bit. One could emulate something like this (the AI would need quite some work though) by using triggers to block commands of other players for a "campaign turn" and add some way to end a turn. Actually starting matches might take some more work, I guess one could at least reuse parts of the campaign infrastructure if one decides to limit the available maps. You might need a different green grass ground texture so things blend in nicer, apart from that it does look great!

Depends on what kind of xml file you want to know about. (Some reading about how xml works (tags need to be closed) might be helpful, in case you haven't figured that out already.) For actors you might want to read the Actors wiki page, which (judging from the edit history) should be up to date. For other files look at the file format wiki pages, and the other pages for artists and modders listed on the wiki. In case something isn't clear and you figured out how to improve it, do so (it is a wiki). Otherwise please do ask questions, it is quite hard to improve documentation if it isn't used or people don't point out issues.

They can, you are just unable to use the system to run them at the same time.

See GameDataPaths for where to find the logs with the full error messages, which does include the first error (which in some cases is the reason for the others). Still not sure if you fixed all errors, since that last post of yours does not tell.

I didn't quote the manual that tells you what you'd have to do to run a task in the background without a reason. I also didn't tell you how I got to that information so you ignore it. I'll also not help avoid reading the documentation even if you PM me (also stop doing that to everyone instead of actually trying to read answers). And no, I don't have access to the lobby server anymore, and the script is unlikely to help you since that is a bog-standard init script that also doesn't hold your hand in any way. TL;DR: Read the earlier reply, then read the manual, then read your system documentation.

Same for the related files.