hyperion

Using entityid as order is just one possibility, straight forward and easy to understand. Nothing inherent. Basically you have two types of events, those that have or might have side effects and those who don't (at least wrt simulation). The removal of a corpse for instance is a case of the latter. For events with side effects you must guarantee the same order of execution every single time, however you do it.

It was removed. The main reason might have been it being deemed sexist.

Cloned, loaded and crashed Tried with A25, see below for the errors: ERROR: JavaScript error: globalscripts/Templates.js line 21 simulation/data/civs/east.json doesn't contain Name loadCivFiles@globalscripts/Templates.js:21:11 loadCivData@gui/common/functions_utility.js:37:28 @gui/gamesetup/gamesetup.js:13:30 onPress@gui/pregame/MainMenuItems.js:90:13 performButtonAction@gui/pregame/MainMenuItemHandler.js:77:9 pressButton@gui/pregame/MainMenuItemHandler.js:63:10 ERROR: JavaScript error: gui/gamesetup/Pages/GameSetupPage/GameSettings/Single/Sliders/RelicCount.js line 51 can't access lexical declaration 'g_CivData' before initialization @gui/gamesetup/Pages/GameSetupPage/GameSettings/Single/Sliders/RelicCount.js:51:1 onPress@gui/pregame/MainMenuItems.js:90:13 performButtonAction@gui/pregame/MainMenuItemHandler.js:77:9 pressButton@gui/pregame/MainMenuItemHandler.js:63:10 TIMER| gamesetup/gamesetup.xml: 61.2914 ms TIMER| common/global.xml: 271.786 us ERROR: JavaScript error: globalscripts/Templates.js line 21 simulation/data/civs/east.json doesn't contain Name loadCivFiles@globalscripts/Templates.js:21:11 loadCivData@gui/common/functions_utility.js:37:28 init@gui/gamesettings/GameSettings.js:24:13 SetupWindow@gui/gamesetup/SetupWindow.js:29:39 init@gui/gamesetup/gamesetup.js:47:18 onPress@gui/pregame/MainMenuItems.js:90:13 performButtonAction@gui/pregame/MainMenuItemHandler.js:77:9 pressButton@gui/pregame/MainMenuItemHandler.js:63:10 ERROR: GUI page 'page_gamesetup.xml': Failed to call init() function

Quick notes only header sorting: changing sort order might cause changes. IIRC curl on at least on windows isn't safe and we can't assume the code base to be free of "order hacks" loops: std::ranges::iota is c++23

Human reaction time is around 200ms, some gamer are even faster. 50ms with 150ms net delay sound like a very nice target indeed.

Just because teams aren't locked doesn't mean there can't be defaults. Looks like a bug.

c-style ps_stringutils_stringFromDouble as for str, I don't like this as a namespace name, I'd prefer a proper name. If it's to long in certain TU due to heavy use just use using or alias.

When logging in there there should be a checkbox for staying logged in, otherwise after a certain timeout you will be automatically log out.

Changing CC always has it's price and shouldn't be done lightly. The c++ core guidelines linked by @vladislavbelov earlier would otherwise be an ideal basis to start with as a parent for CC. auto: I like where the CC speaks of using auto in moderation. old style for loops: well, one could theoretically argue anyone with any coding experience in any language knows how they work at a glance which might be of minor help in maintenance but personally I don't mind. misc: moving lib/* to ps/* is fine with me, this is a historic curiosity that could stay but if someone wants to do all the cleanup, review, testing and committing - sure. The alternative is to split lib/* into an own repo and depend on it, so as to align with the original intent but I see this as the lesser approach here. I also have a preference for free functions over the CStr approach.

Just use the -writableRoot option

Parsing xml isn't very fast, also you have a whole inheritance chain of xml files for a template. Once you have done all work you have an in memory representation which you could just dump bit by bit to disk and read back which is much faster. Well, it's not exactly as easy but explains the basic idea quite well. The code is open, for the gory details I suggest you start digging into it.

This was changed at some point so you can't hide 200 units in a fort.

I think there is bug where if water height is much different to terrain height the view rect in the minimap gets rendered out of proportion.

Agreed, just changing the default isn't the best way. Some UI changes to properly promote forwarding without confusing users certainly would be better. Rewarding hosts with a "first class host badge" is probably already a good incentive. But we shouldn't assume people to be stupid and properly tell them the drawbacks of each method. There simply doesn't exist a just works solution without wfg hosting the games or proxying all traffic. So implicitly pretending otherwise wont help casting a good light on 0ad. I faintly recall @Langbart having written a guide somewhere ... Forwarding requires you to have sufficient rights to configure your router. Stun is a technique which allows you in some cases to bypass this limitation. So quick'n dirty solution only in the sense that it's easily abused as a one trick pony. The biggest problem is only some people will be able to connect to you while others can't depending on their ISP, this giving the illusion of all is well when it's not.

Just delete the metadata.json, it's not needed at all. Don't even try manually fixing it.

Teaching people on how to setup forwarding is not the goal but to let them know they are using a problematic setup. If stun is the only thing they get working, so be it. The main problem I see is they don't even know that there is an issue, which is always the biggest hurdle to address.

Not sure what you are up to, before even creating a game one could pop up a message "Warning: stun enabled, random success, please consider forwarding, read more ...". Connection testing can also be done by the lobby, upon creation of a game or otherwise, which I consider a low traffic solution. The important bit is to educate game hosts that stun is a poor solution in general, the indicator is mostly for people to learn if they aren't able to connect to stun hosts so as to get rid of the impression that it's 0ad fault.

One could indicate whether it's a properly reachable host (forwarding) or randomly reachable host (stun), if people believe stun is a full solution they won't care about a better setup. Also ip6 support could help. Sure there are other reason than stun, but I guess it's the reason in a vast majority of cases.

Please reread his post. The following simply wouldn't make any sense then "Making a general reduction of the range of vision, the player will have to scan the map for new resources, mainly hunting in the first few minutes, watchtower becomes much more important, new CC builds are encouraged, technologies and vision auras like "sibylline books" would again have a good importance, etc.." Well, it's perfectly natural and realistic for those ranges to be different. As we don't build a simulator and as long as there is a very good reason why for gameplay purpose it must be the same unification is a possibility. The one given here is ridiculous. The one given by @Nescio in D3487 is at least reasonable but was shot down all the same. We had such a release and it's plain awful if your units change behavior based on phase. This experiment was reverted right away.

Edited 19 minutes ago by real_tabasco_sauce Well, you liked the statement of @borg- where he suggest 40 instead of your 80. So what I see is salami slice tactics, better to nip this trend in the bud. As for nature, I prefer chess over dice, prefer civilization over ego shooter, I prefer 0ad to be a strategy game over a high apm game.

Ha, it ends with ad hominem ... Well, if I make a patch to increase the vision range of all units to 120m will you support it full heartedly or are you just opposed to changing the game? Ha, it ends with ad hominem ... Well, if I make a patch to increase the vision range of all units to 120m will you support it full heartedly or are you just opposed to changing the game?

Right, ridiculous to be able to see moon and stars. A simple Pythagoras can show you the difference isn't enough to "make sense" For me this a matter about the nature of the game, and I object to any reduction of vision range as this is a bottom less pit. If the precedent already only needs such a meek reason when will this stop?

There is a counter proposal for the stated purpose in the OP which is still not sufficient but clearly more useful towards that goal by @LetswaveaBook in this thread. I don't want longer vision range, because I'm aware why some people push for low vision (has utterly nothing to do with the stated purpose), but I really dislike any further reduction.

Feel free to increase the vision of all units to match catas Yes, they are to fast, faster than inf is fine but not by this much. In A23 they were also much weaker in P1, defense structure were worth more and even anti deathball tactics still existed (splash) making it less obvious. Well, you only hear and see what you want, not much point arguing further. You prefer dice while I prefer chess.

Spaces are forbidden