Leaderboard

I have not been this impressed with a game (that is free to boot) in a very long time. Never so much as to actually join a forum for it in probably over 10 years. Well done. I plan on supporting this game and mentioning it to all of my friends for years to come. Its nice to meet you all.

Between Spidermonkey 1.8.5 and 38 there have been many profound API changes and it took us countless hours to adapt the code to these changes. The GUI was especially difficult because it used a wider range of different API functions for the object oriented aspects. During the upgrade we have reduced the complexity of this interaction, which helped streamline the upgrade process in the future. You have valid points for the object oriented approach and I'm not against it, in principle. I just advise to keep the upgrades in mind an avoid adding too much complexity and diversity to the C++ <-> JS interaction. I don't know how much the Spidermonkey API keeps changing nowadays, but given how much Javascript is still changing, I suspect that's still an issue.

Coming soon to Terra Magna.

If you provide some more information on what the channel is about it's probably more likely for people to actually check it out

Network latency should not be an issue, the turn lengths are 500ms in multiplayer and you can test by simulating lag that if the meanRTT <= turnLength, there is no network lag perceivable. On "Simulation interpolation lag": However there is a different aspect that can make the simulation consume 550-600ms, even when there is no performance bottleneck: it's the approximation / interpolation of the turn events to the intended turn length. The computation may be done in 50ms, but the events should unfold in 500ms on screen. I think the approximation depends on the performance of the recent frames, is inaccurate and can thus overshoot often. At least that's the only theory that I can come up with that explains when one measures and displays the time between the "TurnStart" and "TurnEnd" network packets (#5323). If I recall correctly, even on a new_rms_test map with about 20 entities on the entire map and only the localclient, < 10ms ping and no units moving there are often 550ms between the two packets. Other things to thread: There are some edge cases that need async calls or threading: The NetClient threading doesn't really remove performance bottlenecks, but it is absolutely necessary to split it so as not to get disconnected when some C++ or JS code blocks the main thread for some seconds, like we saw in every single a23 4v4 if one didn't simulate lag to increase the timeout tolerance artifically. (ticket and patch somewhere) Map generation is threaded already (one couldn't see the loading screen progress). But not all parts of the loading screen are threaded. Running the renderer and simulation in different threads might or might not have potential (for both loading screen and ingame). Rejoining clients that finished the loading screen simulate the missed turns - that can freeze the application for many seconds. This is the most important issue to be fixed. It would be probably better if the rejoining client simulates 3 turns, the other players one turn, rather than the others simulating 0 turns while the rejoining client simulates all missing turns. XMPP connection startup freezes the GUI until the server responds or timeout (ticket somewhere) STUN connection buildup freezes the GUI for some hardcoded seconds replay menu loading thousands of new replays will freeze for that period userreporter libCURL interaction was threaded, but if the server times out, then the main thread exists while the userreporter thread still waits (ticket somewhere)

Interesting, thanks for sharing. In other words: elexis: 37.9% fatherbushido + leper + mimo: 26.6% everyone else: 20.3% autobuild: 15.2% A project that depends mostly on one person is actually quite vulnerable.

@Servo I could distribute a modified version of the game with that patch applied but you'd have to install it manually. would that be okay ? (Could make a new bundle but it takes around 6h so meh)

There is some cool mech concept art in OpenGameArt.com which could be used for the design of such an easter egg unit for 0 AD, e.g.: https://opengameart.org/content/sci-fi-vehicles-collection

Since our announcement was shared in a few places among them the Wildfire Games Forums a few questions were asked. It is time to answer some of them. Project name No, the final project name will be Fork AD 9001. Project goals We still adhere to the old ideals of doing things properly. That means we first have to fix some code rot so there is a nice foundation to build on. Do note that this does not mean that there are no improvements upon already sound bases. While we intend to improve all aspects of the game, our current focus is on mod support and single player improvements. Different culture How we differ is in that we actually discuss things when discussion is needed, and ask for each others feedback. As opposed to a culture that makes one think of the quote "What we've got here is failure to communicate". Though we apparently caused quite a surge in WFG team communications with our announcement, you're welcome. Private source Yes, the repo is currently not public. Select individuals might be given access if it seems worth it however. Contributing to 0 A.D. We think some people might want to read the initial announcement again if it wasn't clear enough. Everyone is free to do with our released code what the license allows them to do. But that is where us contributing to 0 A.D. ends. Last we checked trying to interact with them did not lead to any useful result, and talking to walls is not the best use of our time. We do wish them luck with getting Alpha 23 released in a state that is worth calling a release. Something else that might be worth reading are the words of the most active contributor that is left "Secondly the capable motivated and available developers went down"source. And since we want to let people make up their own mind we do include some statistics, that might be skewed by a few factors. Among them are people committing patches by others, people doing reviews of others' code instead of committing things, and more. And not even all of us kept contributing through that full date range, but without further ado: git shortlog -sn --since='2017-01-01' --until='2017-12-31' 618 elexis 248 autobuild 228 mimo 147 fatherbushido 80 Imarok 59 leper 49 bb 48 Stan 46 Itms 30 wraitii 14 LordGood 14 Pureon 14 s0600204 13 enrique 9 vladislavbelov 6 FeXoR 3 gallaecio 3 scythetwirler 2 omri Despite our reservations against what is left of the team, we do appreciate them allowing part of this discussion to happen on their forums. As always we are open to questions and if you want to have your questions answered immediately, then you know where to find us. Kind regards, fatherbushido, leper and mimo.

Looks gorgeous, m8

Yeah it's the lighting

Hopefully by Christmas.

@AlexandermbEnts?