bb_

I won't argue on what is the definition of "cheating", but I would like to leave a comment on the "real solution" proposed. Having a system with a single host computing everything and sending out the data would be a great simplification of the code and indeed solve some of the cheating issues. It definitely would make our work as programmers a lot easier (no more cross platform out of sync, no more deserialization bugs etc.). However, there is one particular good reason why we (and every similar game too) go through all the hassle of a lockstep networking model (i.e. simultaneous computation of the simState in all the clients): A single host computation system will not work practically. The problem lies into the fact that the bandwidth of an internet connection is limited. (An old article on the topic is here: https://www.gamedeveloper.com/programming/1500-archers-on-a-28-8-network-programming-in-age-of-empires-and-beyond) In a single host computation system, the host will have to send (a large portion of) the gamestate to every client multiple times per second. The data of the gamestate is required to show the player what (s)he is supposed to see (units in its vision). This needs to be updated with a good frequency so that the player can respond accordingly. Currently we have turns of 200ms, so that means a frequency of 5 per second (in the past in 0 A.D. we used turns of 500ms, which wasn't ideal, but sure one can tweak a bit here). A gamestate can have a size of several MB's. I just tested: a new game on the acropolis map is already 500kB, so having a big map with 8 players in late game will be like 5MB. This means we need to be sending 25MB to every client per second. With 8 players and some observers, this will easily be a few hundred MB per second. Even on 1Gbit/s fiber class connections you won't be able to do this (1Gbit/s usually gives just over 100 MB/s). This issue prevents any MP game from running stably, so it really is not a practical solution. Even if one would have sufficient bandwidth, there is also the issue of latency. A message send over the internet takes time to arrive at the other end. Currently one a player can give a command based directly on the current turn in the simstate. The command then has to travel to the host and then back to all clients for it to be executed. So basically one needs to send stuff twice over the internet. If one has a single host computation system, the player sending a command is actually already lagging behind (since the simstate has been send from the host to him). Then secondly, the player gives a command, which is send to the host, and lastly the host sends a new simstate to the client. So in total 3 times things have been send over the internet. Meaning that the latency of commands is increased by 50% (and probably more since the package sizes have increased too). Also a single host computation system is filling one hole with another: since the host will now have full control of the simstate, and no one is controlling it, (s)he can change it. So such a system makes it possible to cheat the simstate for the host. Creating an (imo) even bigger problem than the information leak problem in a lockstep networking model. Surely one can come up with "solutions" like dedicated (trusted) servers, but then one runs into the question: who will maintain and pay for those servers? In all it boils down to the quote, quoted above too: While technically it certainly is possible to design a system without information leaks, such a system is nonviable to produce a playable game.

Dear members of the treasury committee, Following FOSDEM 2025 in February, see the report:report2025.pdf, and with your approval, I would like to distribute the funds accordingly. From FOSDEM 2020 I still had E125.25 in my possession. At FOSDEM 2025, we raised E396.10 in the cash donation box meaning I have E521.35 to distribute. Seeing the expenses in the report, I propose to send E224.10 myself and E104.50 to @Itms. The remaining E192.75 should be send to SPI (or used for other means). Receipt of the costs can obviously be provided in PM. We are looking forward to reading your reply and we are happy to answer any additional question you might have. bb, on behalf of the attendees. report2025.pdf

Just a wild guess: delete your cache. Most likely ~/.cache/0ad

0 A.D. will be present at this years' FOSDEM event in Brussels, Belgium. We will have a stand run by team members. You can come by to say hi to the developers and maybe pick up some goodies. We are happy to meet community members at the stand! What is FOSDEM? FOSDEM is the "Free Open-Source Developers European Meeting" held every year in Brussels in the first weekend of February. It is a weekend long conference with stands, lightning talks and more than a thousand lectures. For more information about the event see https://fosdem.org/2025/. Where is FOSDEM? FOSDEM is held at the Solbosch Campus of the ULB university in Brussels, Belgium. See https://fosdem.org/2025/practical/transportation/ the address. When is FOSDEM? FOSDEM is held in the weekend of 1 and 2 February 2025. Where can we find 0 A.D. at FOSDEM? Our stand will be in the K-building at ground level throughout the weekend. Who will be present from 0 A.D.? Stan, Itms, Phosit, vladislav, plumo and bb will be there.

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.