bb_

It won't cause an OOS. Random numbers are all over the simulation and they do no harm in OOS'es. This due to the simple fact that it are all pseudo-random numbers. Basically, there is a set list of numbers, which is randomly created at the start of the match and agreed by all clients, used for all the random numbers generated in game.(The first call of a random function will give the first entry on the list and so on) So all clients will have the same random number at each instant a random number is asked for. Also see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Math/random You can check your commands.txt which has the random seed in the header. That is how replays keep in sync too.

I think the most important things are the required features listed in the first post. I do would like to add two: - Be loggable on a wilfy server (the actual chat being hosted elsewhere). Like we have with irclogs. (Probably this is possible with most solutions anyways) - Joinable with a little threshold as possible (no account, web based etc.) IRC is fine with me. I have use zulip too for some uni stuff. Works rather well!! Especially like the way how one can use TeX code there. Don't know about the logability and the need for accounts (but one can figure out). A Matrix with some IRC bridge or the like could be an option too. Have no experience with XMPP apart from the MP lobby.

Probably see my inline comment: https://code.wildfiregames.com/D5227#inline-101992

Hi and welcome Baelish !! You are already in the right place to share your map. Just attach it to your post here on the forums. The map (I presume it is a scenario/skirmish type map) consists of two files. one .xml and on .pmp. Maybe https://trac.wildfiregames.com/wiki/GameDataPaths will help you locate the two files. Just zip them and attach them. In order to use them in MP all players should download the map and place it in their local maps directory. The map should then show up in the gamesetup and you can use it. Out of interest: how did you create the contours of the map? Did you use a hightmap of some kind? In that case, what is the source of your hightmap?

There seems to be a bunch of errors before this one. These are about missing templates. Probably not too relevant, but doesn't harm fixing. I suspect you did add the `simulation/data/civs/Adrestia.json` file? What is the value of `Code` you put in? What is the value of `g_Players[g_ViewedPlayer].civ`? You can get that by adding a `warn(uneval(g_Players[g_ViewedPlayer].civ))' just prior to the codeline the error comes from. Also there might be more errors too (which don't seem to fit in the screen). No worries: you can find all errors in the logs (see https://trac.wildfiregames.com/wiki/GameDataPaths where to find them).

It has been so good having you around @Stan. Feeling bad now I wasn't there much for the last 2 years almost. Meeting at FOSDEM and staying at your place on @Imarok and my crazy cycling trip has been a pleasure especially. Going to miss you certainly, but all the best. And be sure to be welcome around any time.

2) https://code.wildfiregames.com/rP26438

As @Freagarachsaid committing the art makes arcanists' live easier (and as a consequence mine too). The art was made by Lion Kanzen (see the ticket).

Wait for the autobuild tomorrow morning, or revert to rP26521.

Don't particularly like the new default cursor. The old one could have been a weapon-head too, but one could sell it as a pointer too, making it a very universally used icon. The new one is a weapon however you look at it. I don't want a weapon on my screen when selecting a tree!! Besides that: the new cursor is way oversized. Making it feel very clunky too work with. The same comment applies to the new attack cursor (the image is fine there, just make it smaller). I would propose to restore the old default cursor and use the new default for attack-walk instead (that red line is not making things prettier).

For the record, this happens since https://code.wildfiregames.com/rP26393.

Delete your savegames, they have an outdated entry.

https://code.wildfiregames.com/D4437

I does, since the females are all trying to reach the same point in the field and only moving around eachother, to find a free spot, onces they bump into eachother. Then obviously they need to turn and reaccelerate.

The better values are having some realistic turnrates, instead of the almost insta turns that happen in current svn. What is seen as "clunky" movement, is not caused by turnrates or accelerations at all, they merely highlight the actual issue. Which is "units bumping into eachother all the time".

That the whole point of "Distributed Denial Of Service". It is many many IP's trying to connect to your server. All requests are blocked (since nothing is listening), but the shear blocking is sucking the bandwidth. Probably the initiator is not even part of the ddos. AFAIK, that is already the case. Do notice that someone who wants to join *needs* the IP, since it cannot join otherwise (if you want to send a postcard to someone, you will need the address...).

This is very much expected. In multiplayer the game needs to be synchronized over the internet. In order to do this, any command you send needs to be shared with all clients before processing it. More precisely, a client need to send the command to the host, then the host shares it with all clients. Hence when you give a command it is only executed a little while later. IIRC this "delay" is hardcoded to be .6s (or .4s?, whatever). In future we might implement having this time "dynamic" i.e. it would be as low as possible depending on the used network connections (this also related to the idea of "variable turnlengths"). This would make the game more responsive in some situations, in particular two computers on the same network. However do notice that there will always be some delay. In particular, if you are playing with someone on the other side of the globe, you will have at least .133s delay (we need to travel from the client to the host and back, so basically travel a full circumference of the earth). Simply by the laws of special relativity (nothing can move faster than the light). Likely this will be even higher, since your signal probably will travel slower and with some detour.

IIRC relics are spawned near gaia entities on the map. I read from your post, there are no gaia ents. So then the relic code will error saying it can't find a spawnpoint. Maybe a solution would be to add some triggerpoints on the map (these are invisible for the player). Would need to test if that really works.

For the second link, I suppose you refer to: It seems that epriestly (the old maintainer of phab) is just posting some suggestions on what one could do. It doesn't seem to contain any evidence that svn is/will actually be dropped. Not sure what the official line is (I heard some conflicting info from @Freagarach on irc). Would be good to figure out. This is an unfair comparison. A git repo contains far less than a phabricator instance: think of all discussions, attachments of whatever kind, non-committed patches etc. The fair comparison would be to compare the size of vcs's (git, svn etc.) with size of development tools like phabricator. If anyone has some data on either of these, please add them to the thread. Not the only person asking: https://secure.phabricator.com/D8775?id=20822. Also may I add https://www.tuleap.org/integration/tuleap-gitlab-integration-why-and-how-to-use-it and https://docs.gitlab.com/ee/integration/github.html. Feel free to list similar pages for other solutions.

Thanks for everyone posting their input. I have updated the posts at the top of this thread. Also I made a short list of the limitations in our current setup. Feel free to yell if I miss points. Between the listed points I feel there is some overlap. To start with the top point (not that there is any particular order, feel free to comment on the other points too) "Phabricator not being maintained anymore". If we want to migrate, we can migrate anywhere. @dave_k already posted some ideas on possible systems before: Obviously there is also the Phabricator fork, Phorge. And surely there are more. What are everyone's thoughts on these? Are there migrate scripts available for any of these? Do we loose any data currently in phabricator? What features do we loose? What do we gain? Can the trac or forum data be somehow incorporated. How does it work with external linking to the current phabricator pages. How does any choice relate to the feature list at the top of this thread?

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?