bb_

https://dzone.com/articles/git-lfs-why-and-how-to-use Basically it would solve the size issue on the server Don't think you answered my question. How does git-lfs work with the versioning history of binaries? And does a clone automatically inherit the linkage? It is NOT. I tried to make in the first post clear what this thread is about, namely gathering ideas, wishes etc. regarding VCS.

I distilled a feature list from the posts above and will continue doing so. Please yell if I wrongdo anything here. Some questions from my side: How does that work with versioning of the binaries? And with clones? Can someone elaborate on these? what these are? why we would care? etc I am not sure if I understand the exact feature one is after here. "Being able to say 'this patch is ready to be merged'"? Lastly my own requested features: First and foremost, I find that all code, art and anything else must be in one and the same repo. Obviously there must be a clear directory structure. But for some patches (the secondary attack patch #252, is just one example) it is required to change both code and art at the same time. Having to propose different patches for different repo's, will make life a lot harder. We have been around a long time, the world around us will change and we don't know what will happen. Therefore I will strongly plea for keeping sovereignty. Make sure everything is available in a self-hosted variant. Using third-party services is perfectly fine with me, however we should depend minimally on them. Whether it is to avoid a total collapse of the service, changes in the service itself, or changes in the terms, it shouldn't matter us. We should be able to continue, and at any point be able to decide to stop using any service. To make things secure and reliable, I would recommend to have a third party back up which is usable as is, preferably using a different vcs. This will make sure that if our one server or vcs collapses, we can continue, using the other at will. A VCS should work, for everyone from anywhere. There should be a minimum of potential restrictions on joining deving. This means that the vcs should work on many platforms, be free of (third party) account registrations, have a simple workflow with straightforward commands (also understandable for ppl who never used a vcs before). Dev version testers should be made easy to test: we need them and they might not be as experienced as devs when it comes to handling code bases. Therefore precompiled binaries (autobuilds) should be directly available in the repo. This might also help devs on some platforms.

Some current limitation: Phabricator not being maintained anymore To much sysadmin time Many different systems used No full GUI workflow Highish threshold for new contributers Post reserved to gather pro's and cons of different solutions.

I try to keep track here of all feature requests. Please yell if I wrongdo anything. List of feauture request fro VCS Low sysadmin efforts (at most as high as phabricator currently) (Stan, wraitii) Security (dave_k) Proper binary handling (Freagarach, dave_k) All code art etc. in one place (bb, dave_k, Freagarach) Longevity (dave_k) Used in mods and other FLOSS projects (Stan, Locyneah, samulis) Companies involved are FLOSS minded (dave_k) Partial checkouts (Freagarach) Possibility to self-host (locyneah, bb) Reliable (dave_k) No branching (Freagarach) Branching (locyneah, maroder) Possible to work completely remotely (locyneah) Back up on devs machines (Freagarach) Public in production third party back up using different vcs (bb) Possibility for bots (elexis) Easy export of data (dave_k) Autobuild in repo (maroder, bb) Easy rebasing (maroder) Incorporate gitlab PR, github PR and phab Diffs in one system (wraitii) Usable by everyone from anywhere (bb) Simple straightforward workflow (bb) Low threshold for new contributers (Stan, bb, dave_k) Supported in maintaned platforms (Stan) 2FA (dave_k) Including (parts of) other (third party) repo's in ours (submodules) (Stan) Easily properly credit authors of patches, even if they don't have direct commit access (Stan) GPG signing of patches, tags and pull requests (dave_k) Support for GUI based workflow (samulis) Features not directly related to VCS Low number of different systems used (maroder)

This thread is meant to gather and streamline the discussion regarding our choice of version control system. Discussion appeared to be in several places. I did my best to gather all relevant material, but feel free to add any missing information. We currently use svn, this has been working ever since 2004. Some earlier discussion about the lobby bots: Below an excerpt from an e-mail Stan has send round a while ago to all staff members: A relevant related topic is On November 24 2021, a discussion on IRC: What I did like to hear from everyone (staff, contributors, svn testers etc.): What is required from the version control system and CI? Which features are required? And what is only nice to have? Please list your wishes in this topic, preferably ordered in priority. What are the current limitations and what are possible solutions for that? What are the pro's and cons for them?

I guess I found the culprit: the cost/Resources/wood entry must be a nonnegative integer, following the cost schema. Since you multiply with 1.2, this will be interpreted as a decimal (even though 1.2*30=36). So I suppose you can fix it by explicitly setting the value in the children instead of using the operator (maybe using the add operator still works). Another option is to try to fix the operators in this case.

Yeah, that is arcanist being a @#$%. Please download the icon manually and put it in the correct place. Sadly can't do much about it. (When committed this issue is gone)

Given the lobby changes to hide your IP from the lobby, we might be able to trisect which lobby user is malicious (and then act upon that). For the host who experiences a DDOS, please attach your mainlog.html to this thread (see https://trac.wildfiregames.com/wiki/GameDataPaths for where to find it). Make sure you to save the mainlog before you start 0ad again, since it will be overwritten. In that file all connection attempts are present, see the lines of the form XmppClient: Recieved request for connection data from {username} If one can change their IP address before the game, we have even more information (since the malicious user might store the IP to use later).

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'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.