bb_

Neither you can do it all by editing the xml file you already found. I guess: search your favorite tooltip in game and look how it is done there (hint: the mod up and mod down buttons on the right hand side of the modselection panel seem like a good candidate)

That file is used in the replaymenu in the public mod. It is loaded via Engine.GetReplayMetadata called from replay_menu.js

That's js. Not entirely accurate: you can pick up the code flow in buildRestriction.js (CheckPlacement), but the actual checks you are in the Obstruction cpp component (which is called from buildRestrictions, see the CheckFoundations calls). What would you need the "getGuild" function for? You can query the guild component just like any other component: Engine.QueryInterface(entityID, IID), where the IID is the IID of the component so for the guild you will probably use IID_Guild, you define this by ending your new component with Engine.RegisterComponentType(IID_Guild, "Guild", Guild); Assuming you name the component Guild and use "Guild" for the templates.

In the vanilla game, the ownership is handled by the ownership component, which assigns it to a player. Changing this to other entities requires cpp changes (as ownership is a cpp component (*cmpOwnership.*)). Not entirely sure what you want to do though. Any entity can call any entities components already. So if you e.g. wish to let one building issue a research in another building, you can simply do so by directly adding it in the queue: Query the ProductionQueue and call the "add to queue" function (don't know its name by heard, but should be easily found in ProductionQueue.js). If you want such a "Guild" building: make a Guild component which you add to the relevant building and let that handle whatever you want to let it do. (As advice make it a JS component, that makes querying other components much simpler) You can use the RangeManager for querying all units of a player. From javaScript code this can be done by Engine.QueryInterface(SYSTEM_ENTITY, IID_RangeManager).GetEntitiesByPlayer(playerID) From cpp code it works the same: query the component and call `GetEntitiesByPlayer` with the relevant playerID. From the return data (its an array) you then can check whatever condition on the entity. Query the GarrissonHolder and call `GetEntities`. It will return you all units inside.

Phab and arc(anist) are probably the most useful. Using git is not required at all when using svn.

There is https://cryptpad.fr too.

0 chance on that, since one needs to modify cpp code. Someone could bundle it

How about code which is already there: https://code.wildfiregames.com/D3200? Should be reasonably similar to what you describe here.

Global function? You mean any call that starts with "Engine". Those are the cpp interface function, defined in the various interface files. The cpp files are in the source directory of the game (at least if you have downloaded the source, I hope you would work on top of the svn/dev version, see https://trac.wildfiregames.com/wiki/BuildInstructions). Any other global function could be in the globalscripts (grepping is usually a good idea).

Following the thread below, @wraitii and myself have tried out several ideas to limit the possibility of dancing. In fact 8 different patches have been worked out by the two of us. A thankyou goes to @ValihrAnt and @Feldfeld for some preliminary testing. Links to all the patches are available in the relevant ticket https://trac.wildfiregames.com/ticket/5106. TL;DR. As it stands now two patches have been committed. Firstly https://code.wildfiregames.com/D2913 by wraitii to stop the case of patrol dancing (arguably the easiest way of dancing). This will make units patrolling wait a few seconds on each waypoint. So at the waypoints the unit is immobile and thus will be hit by arrows. Patrolling units will keep responding to nearby attackers, even if they are standing still at the waypoint. Secondly https://code.wildfiregames.com/D2837 by myself, to limit the dancing possibilities for all moves. This patch lets unit take time to rotate while moving. Hence the unit will be shortly immobile each time it turns. Again arrows will hit the target much easier each time the unit rotates, and thus dancing should be limited. Notice the rotation time takes effect on ALL moves and ALL rotations during the move. So big masses of units will slightly clutter en move slower (one can use formations, which have a much better performance compared to A23b, to counter this). Albeit we hope dancing is fixed now, there is no way for us to be sure. The best way to get more certainty is for you, the experienced dancer, to try out the svn version and dance away. Bring your best dance moves to the contest and please upload any replays showing your dancing skills in svn. In case dancing is still intrusive in gameplay, some additional fixes are in stand-by.

Hmmm, I see the updates on some other days too indeed. Maybe. Could also have been manual updates/script reloads etc. It HAS been updated ON TRANSIFEX. If someone (which could be you) translates it there, the translation will automaticly be ingame soon.

Sure the translation hasn't been updated in game. But it should be available to translate at https://www.transifex.com/wildfire-games/0ad/dashboard/. The translation will then appear ingame at the next update. The update script runs every week (friday morning), and in some cases (in particular near releases) we run it manually. It is done at the same time afaik. The translation update also updates the .pot files. Those are the source files of the translation i.e, they contain the english strings which need to be translated. The .pot files are also in svn (as you can see in the commit), and I think they are created and uploaded to transifex from the same script. We also pull the translations from transifex (i.e., get the .po files containing the actual translations) at the same time.

The translation update ran this morning, so the strings "should" be on transifex

This is probably due to the fact that this string hasn't been translated in chinese on transifex. Feel free to add the translation there.

> Is there a way to make some functionality to deregister from lobby after game starts? That could help. This is possible, in fact it is even possible to hack some naive way into the A23 lobby. Note to someone coding it: make sure dropped players can return. Late observers maybe less important. @badosuto do this one needs to adapt the lobby bots: only send the games which satisfy certain conditions to the clients. To actually implement it in the lobby, we should update the lobby bots we run. I am not able to do this but I guess user1 can (and otherwise I can ping other ppl). I think the easiest way to propose the change is making a phab revision with the changes (a mod won't work for this issue, since we need to change the serverside). Also a proactive ddos'er can still store the ip's of games being hosted and kill them when they disappear (obviously it will make it harder for the ddos'er).

Even though we would like to do something, we really cannot do much. Since your IP in the lobby is made public, everyone can figure that out. Yes it has been made harder to figure it out in svn, but in theory one always can figure it out. When someone is DDOS'ing your network. That is 100% out of our control. I only can give some advice: - Try setting another port when hosting your game (a stupid DDOS dude would only try the default, so might help a bit) - Use direct hosting/joining (you will need to share your IP via some other platform) - Contact your ISP, maybe they can blacklist some IP's

https://code.wildfiregames.com/D2759 Should indeed fix this. Thx for linking @Nescio

The development version (A24) can be downloaded following the steps at https://trac.wildfiregames.com/wiki/BuildInstructionsGettingTheCode. In case you need to build https://trac.wildfiregames.com/wiki/BuildInstructions might be of use too. For the dev versions of mods: I expect them to be in some github repo, most likely linked in the mods' thread.

ships have a rather large ungarrison range, this is done to make ungarrisoning the units work smoothly. https://trac.wildfiregames.com/ticket/2692

Nice work!! If you are interested, we could make this part of the vanilla game. Feel free to submit a patch at code.wildfiregames.com. Some comments on your code: you seem to duplicate some lists, it would be nice to reduce that duplication (also it would be nice to unduplicate some of the chat handling of the vanilla). Maybe one can use (exerts from) https://github.com/hpcodecraft/ASCIImoji somehow? Especially the dictionary in https://github.com/hpcodecraft/ASCIImoji/blob/master/src/asciimoji.js seems useful.

@GrapjasYou can even do that yourself: add `view.zoom.max = 10000` in your local.cfg. (All possible such options are in the default.cfg, you can change any value by adding a new value to the local.cfg)

Make a forum thread in the art subforum about the animal and dump the model in an attachment. Probably ping Stan and/or some other artist (alexandermb, wackyserious)

Thanks for reporting the issue. We already have a ticket on the related topic: https://trac.wildfiregames.com/ticket/3307 and as you can see there, there are some non-trivialities to consider when translating. Also note that since the names are displayed in the gamesetup, the translations are not lost, just not used correctly. It really is a coding problem.

In addendum of the previous post: The lag will increase for everyone. Currently there is only command lag (commands are executed only 2 turns after they have been issued). But now you will also see the simstate a turn (or two maybe, need to think about that harder) behind, hence your commands are based on info of turn n-1 (or n-2), while the are processed at n+2. So There will be an additional turn (or two) for every command, causing more lag for everyone.

Also here are some problems. Currently we only send commands and chat over the internet, so internet consumption of the game is extremely low (Probably few MB over the course of the game). With such a server system, the host needs much more bandwidth, which probably isn't available to everyone. Note that now the host will have to share the simState (say 1 MB) with every client, every turn (0.5s). Hence for a 4v4, we already need a 14MB/s connection. I am sure a fibre glass connection could handle that easily, but many many others certainly can't (including me). Having a server provided by WFG, would become very expensive, rather quickly, considering many games are played simultaneously (and the server needs to compute the simstate for all those games and handle the data distribution). Maybe one could have such a server for a few (1v1) games only. https://trac.wildfiregames.com/ticket/3556 is a related ticket.