leper

File loading order is alphabetical, a mod can just add a few files to actually extend the AI. As you have to add some code to make the AI do what you want, you can just add that to the AI. I suspect patches to make some parts easier to configure for mods are very likely to be accepted.

No. You just have to pass that setting like all other gameAttributes. Nomad for most maps is probably going to happen for RMS, for Skirmish maps that is already unlikely, and Scenario maps are either nomad or aren't. Why do mods need a specific init? So far everything has worked without one and there hasn't been any good reason to add something that isn't needed.

Might be caused by how the AI currently handles template loading. In A22 it loads all of them at the start, so that does slow things down. It still does that in SVN, but some work to enable us to move away from that behaviour has been done. However it seems the contributor working on that has been busy. As I haven't looked at any of those mods in any detail take this with a grain of salt. As long as the New Horse mod does not change any templates (because only the actor files change), and your mod does not change any of the horse actors, and both of the mods have dependencies specified correctly such that they depend on 0ad, then there shouldn't be any need for manually ordering them in any specific way. Just because something works a certain way right now does not mean it cannot be a bug. Same as eg the AI not serializing/deserializing properly is considered a bug.

They are in different JS contexts and cannot communicate directly. And the game is runnable without any gui. What the above code does will also break in multiplayer if cheats are not enabled since it relies on sending messages for other players. As for why there is a method to set starting technologies, well to set starting technologies. Pass what you want when you decide to start a game, or include that in the map JS data. What you seem to be missing is an idea of how all of that interacts, which is at least partially documented on the wiki.

Nope, that's a bug. I expect this to be fixed a the same time as handling mods in the lobby.

Yes, but after migrating the repo to the "new" server we only serve it over https, so you'll have to fix that in your local copy (some clients ask you as there is a redirect).

Doesn't looked fixed, unless the legs are meant to move forwards then backwards while the horse body stays in the same place. The others look nice.

Could you fix the camera that way it is probably easier to judge as it will be similar to how it will look in-game.

Why do the legs move, but the body stays in the same position for Attack, or is this some issue with what the camera is focussed on?

Given that we consider population as a resource in some parts, I'd also split that. The function already handles just the top panel, or am I missing something? As for loading js files, look for the corresponding xml files that include things. There is also some diff to load most things instead of specific ones.

Moving the part that does the layout of the resource objects into a function and calling that from the function where you replaced horizontallySpaceObjects with verticallySpaceObjects. Possibly placing that in some other file if you want to. Mostly so in your mod (or someone else in a mod) can just replace that new function without having to ship a modified copy of session.js. You added full copies of session.js and functions_utility.js to your mod, with small modifications. This is going to be hard to maintain. If the only thing you actually ship in your mod are two script files, one with the verticallySpaceObjects function, and one with the modified placement/layout function (which needs that part to be split from the function it is currently in), then the amount of work you will have to do when you upgrade to the next release will be reduced by a lot.

In case it wasn't clear, you could most likely also add the verticallySpaceObjects function to another js file that is loaded (read a new one), and I'm quite sure if you'd factor out the piece of code that's aligning the resources into some function and place that in a new file, then the latter is quite likely to be accepted if submitted as a patch. Will also help with future updates where you don't have to figure out what you changed in some files. And if that isn't possible at least add the unmodified file in a commit, then have another commit with the changes only.

You will have to create a verticallySpaceObjects functions that is quite similar to the currently existing horizontallySpaceObjects (gui/common/functions_utility.js), then change the call to that in gui/common/sessions.js to place the resource objects. I think the former or something quite similar to it might be in one of s0600204's patches or branches. The latter will be hard to maintain, so it would be best if you first moved that part into another file that just does that. And after you have done that you will notice that the population icon and counter will not be aligned properly. Mostly because that is handled slightly differently from the other "real" resources, so it might make sense to change that so that that specific hard-coding isn't needed anymore.

Assuming there'd be multiple threads for rating updates, then the GIL itself might cause game updates to take ages, which is an issue since it impacts the main functionality. Not having different functionality in the same bot reduces the chance that a failure in one of those features takes down the lobby.

One of the reasons was that ratings had some issue and that being in the single bot made the lobby unusable. Another of the possibilities that allowed was to limit the resources the rating bot could use, not that that was ever done. Merging them is a bad idea, the bots do different things and should not be one bot. Else modifying something about ratings requires taking down the main lobby functionality (match making). Using threads also will not solve anything since the bots are still in python and the GIL is still existent. What would most likely make more sense is to stop forwarding rating messages and instead send them directly to the corresponding bot. Also being able to run a lobby without ratings is something that should be supported (mostly because that requires fewer dependencies and setup that might not be wanted).

No, the AI was designed to be threaded, however apart from the infrastructure for that being there nothing was done (somewhat to make debugging easier, somewhat because nobody got to that).

Most likely the same issue as with the public repo once we switched to reqiring HTTPS there. Since the forum search seems uncooperative currently you'll have to figure out how to fix that url yourself.

Thanks, I can work with that. Can someone from the art team (or regular contributors) comment on the animation itself? Having the source files would also be nice (if someone mentioned in the previous sentence interprets this as a hint that could also apply to other things they'd be correct).

No.

Looks good, also you are missing a T in the title.

The only thing in the wall code (which isn't in the file linked above, but in Commands.js) is the ability to specify the obstruction group to be the same for all those entities. But that only needs a single obstruction group in this case as opposed to 2 as wall turrets need. As for how to implement I'd look at fcxSanya's post. One would have to specify a bunch of slots that either place entities that can upgrade (which would mean that no workers are needed), or foundations (in which case the linking component would need to take care of entities changing, but that is also needed for other things)). And some logic to destroy the linked (slot) entities if the main one is destroyed. Not exactly hard to do. I guess that ignores a few corner cases like displaying the slots for previews (which I guess could be worked around by having decals there, which could cause issues if a certain slot is obstructed (which needs to be handled in the placing of entities above)), and allows the individual entities to be attacked which might or might not be wanted. Then again some of us are still waiting for some assistance with other requests (eg https://wildfiregames.com/forum/index.php?/topic/22900-amphibious-animal-swimming-animation-request/).

#643.

8. Probably some combination of specifying the number of slots a unit takes (maybe a new component, maybe in Identity), using that when garrisoning and fixing all the small issues that will most likely pop up (at least I expect a few when combined with upgrades/promotions/). Alternatively you could switch back to the old code, but that will most likely cause more issues. Another thing to consider would be having different slots for different classes, but that might not be what you want. 45. Check the wiki for how to add new resources. All the other things will require some code (some of them having tickets, some not). 46. Most likely something to do with Health, and/or the resource| filter template. 47. Use svn, or edit some placeableFilter file in simulation/data.

Well someone might have also suggested having more than one person with access to some infrastructure. And last I checked I don't have any such access, and I might have better things to do than wait what seems like years for things to get anywhere than random ideas. Also libc++/clang even on some other *nix would help with not breaking that OSX/macOS/whatever support that always comes back to bite when a release is planned, but it does seem like just dropping that platform would be easier.

Testing should happen on as many platforms as possible. At least some libc++/clang and some MSVC++ tests would be needed. Guess what has been argued for since ages, also guess what happened so far.