hyperion

So, the issues with replays was istream seekg being broken for text input with mingw (magically eating crlf as lf and so offsets are off), works when set to binary. @vladislavbelov @wraitii, The optimizer somehow breaks profiler2 in mingw, and I noticed profiler2 initialization is racy with native Linux build as well, couldn't figure out where it goes wrong so far (thou gcc bug less likely than 0ad bug). Replacing profiler2 with a stub and we have optimizations with mingw and no race with test in Linux; and basically the same execution speed in wine as a native build. @vladislavbelov, do you have a suggestion for a replacement of nvtt? Might look into it if there is a path forward. Otherwise I have to stick to releases and use the 0ad-data tarball.

git-format-patch / git-send-email and then use git-am Commit access isn't that important with git, Linus is the only committer for Linux Also easy to add back if desired. But better they push their changes to their own public repo and someone doing commits on a regular basis pulls from them (DVCS).

They also rebuild the engine for java script changes and stuff that isn't intended to be committed. A lot be cut if you wanted. Remaining known issues are optimizer breaking the build and texture conversion (nvtt), then polishing. For me it's a major reason not to contribute as it doesn't respect author and only knows committer. If you are lucky enough there is a patch by: in the message and if less there is a concern stating it (the latter I consider unacceptable). There is no need to move to github or even git to accept pull request, just devs willing to do review there and apply the patches. The only reason to migrate to github is lack of infra and infra personal.

It certainly isn't trivial. Whether to and where to split pyrogenesis and 0ad, strip build artifacts or tarballs from history, to exclude external libs etc are questions which need answers. Well, I'd start with the infra. Setup test.git.wfg.com. Add some test repos, setup hooks wanted, like maybe fast-forward only or run linter/CI for example, reports like mail and what not and try to break it. Play with gitweb, trac and if you want something github alike maybe gitlab and try to break it. Then document the setup you like best (and wait for it to get shot at from all sides ). In the meantime others can think about the actual conversion of the repo.

Only loading order matters. Mods are loaded from top to bottom in the enabled mod section.

Just recently looked at arcanist and thought it's trouble. Then came across https://gitlab.haskell.org/ghc/ghc/-/wikis/why-not-phabricator and have to say the section "one year of arc on #ghc" is a hilarious read. Not going to use it ever. I think facebook took over maintenance of phab, not sure what their plans are yet. Guess little short term implications for wfg but a possible switch would be a good opportunity to migrate to git as well.

Little had to be changed in cmake to get it working with mingw as well, have scenario and actor editor working now. Returning a fixed duration for replay length makes them work otherwise. So the only big issue now is not being able to generate mods, respectively being able to run in svn, which is blocked by nvtt not liking mingw at all.

But that probably also means older versions don't do fancy stuff which break user experience if the setting is not recognized. Are there any reported cases of green stripes bug for older versions?

See project_add_manifest() in premake5.lua. There are also plenty of pragma linker comments ignored by mingw and some specific function calls that could be replaced. Don't remember them offhand. They are sometimes even commented with do not really work. premake isn't that bad until your use-case outgrows it. Not really familiar with meson. Also me thinks the 0ad code is organized as-is mostly to fit premake, where it should be the other way around.

It seems all it takes is to play a different map than the one and only mainland with low size. Valid reason for blocking expansion is the distance between civ centers and possibly high cost. Also people do expand by means of planting structures at the border, some times house chains to cross half the map. Also some snowballing is needed or the game won't ever end. Me think snowballing isn't excessive in 0ad.

Thanks for the long answer. That has some issues with macOS and its sdk If you want to build on an old mac what is the issue with installing a more recent compiler? Just treat it like any other dep. I'd like to help with that. Seemed a bit annoying with premake The manifest is an xml file, guess there should be a fancy gui on windows to generate it. Then you simply include it in the rc file and the resource compiler will do the right thing. Is somewhat orthogonal to what you do with your patch. https://docs.microsoft.com/en-us/windows/win32/sbscs/application-manifests in the rc file add: IDR_RT_MANIFEST1 RT_MANIFEST "pyrogenesis.exe.manifest" done. The minimalist one I use for mingw to replicate what I call the linker hack: <?xml version="1.0" encoding="utf-8" standalone="yes"?> <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"> <dependency> <dependentAssembly> <assemblyIdentity type="Win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" processorArchitecture="*" publicKeyToken="6595b64144ccf1df" language="*" /> </dependentAssembly> </dependency> </assembly> But there is a lot that can be set like dpi awareness etc, then people don't have to set properties to work around green stripes I suspect A lot of maintainers are annoyed that. 10 years later still stuck with premake ...

Some time passed and I thought I post an update on the status, haven't given up just got sidetracked: Fixed the user.cfg issue mentioned earlier but found one with replays (can't rewind to start of line). Fixed spidermonkey for mingw64-runtime >= 9.0.0 Found out where the debug info got lost. Premake has a very hidden feature to add -s to the linker options unless you explicitly enable debugging within the premake script! Got fed up with premake enough to write a cmake script. Can even package mods . Probably only works for Linux right now. Most of wdbg restored. Missing stackwalker might not be easily fixable due to dwarf vs pdb? Anyway low priority. wseh might be doable as mingw 64 bit unlike 32 bit actually uses seh, have to investigate further. collada only used during caching/building mods (lack of nvtt prevented me from even trying) and so I only noticed during cmake porting that some more work might be needed than originally thought. To conclude, a 64 bit port seems quite doable, the issues I ran into are mostly due to using mingw instead of msvc. Next steps: use cmake with mingw try building atlas find out what's wrong with replays Current wishlist for A26: Drop nvtt for something else rather earlier than later, not gonna fix it, I have no clue what an appropriate replacement could be. Seems to be not that much work once you know the replacement and are somewhat familiar with texture conversion in 0ad. Only use <thread> instead of pthread and win threads. 80% of the work seems updating mongoose. use std:filesystem instead of custom implementation and sometimes boost. Use a proper pyrogenesis.exe.manifest instead of those code and linker tricks which seem to tell windows to run in win98 compat mode. Might fix some issues users see currently.

0.2s is indeed so little that you could say it's effectively the same thing. Still it's a penalty nonetheless, and if needed, could be adjusted.

No, batches take the same time to train but there is a pause of one turn before autotrain adds a new batch to the effective queue. If you manually add batches they go directly to the effective queue and so the 0.2s gap doesn't happen.

Nice, anyway, in maps there are often a clump of school of fish, how would that look?

20 years ago C++ was the only reasonable choice for the engine, I'd still pick it today. As for scripting for mods, lua might have been an option but I guess javascript was a decent choice as well, even more in hindsight. As for writing the whole game in python, besides not being as widespread or mature at that time, search for GIL. There is no "database", just the filesystem.

Another update: If I disable the optimizer in gcc the game actually runs, just played a game in wine. The only issue I noticed 0ad refuses to write a user.cfg. Also packaged tinygettext from upstream and using it as external dep. libsdl2 and rust got an update and no longer need any changes to be usable. So the current status is: Mostly runs with all optional stuff except for lobby disabled. Nothing from ./libraries, nor premake nor tinygettext from 0ad are used. Only spidermonkey and 0ad need patching. Fcollada needs a minor fix wrt pkg-config file. The rest is vanilla (Gentoo patches only if there are any). No wseh nor wdbg in 0ad, I'm gonna leave that out. Slowly getting there.

With 768 min height x1.4 fits into 1080, x2.8 fits into 2160. So those two are probably the most meaningful options. x1.5 may lead to broken UI with a FullHD display.

It's getting off topic. For a project like 0ad the only way I see it to be finished is when it is dead. So I hope it will never be finished but be maintained and worked on for years to come. LibreOffice or the Linux kernel aren't finished either but provide an api which they promise to not break if at all possible. If needed the API will be marked deprecated and use of will possibly spit out warnings for quite a while before being removed. There is no reason 0ad couldn't do the same if it wanted. But supporting >= without a stable api makes no sense what so ever. A modder should only ever use >= if he is exclusively using such an stable yet till now and for the foreseeable future inexistent api. PS: You could also have the mods installed into a versioned directory like replays, which could alleviate the issue of broken installs to some degree.

if a mod only uses what is marked as stable/public api then it should be guaranteed to work with future releases. As 0ad doesn't have an such an api for modders there is no point in supporting the >= specification in the first place (It's always a lie). You could just treat >= as = for backward compat and issue a warning for the mod developers that >= is gone. This would prevent lot of "can't start new release" issues at little to no cost.

Documented and stable.

It might make sense to not allow >= at all but a list of = only unless you start maintaining a proper api which I doubt will ever happen

Some small updates: I have a static pyrogenesis.exe. It runs till after reading configuration but then fails with a pagefault (outside legal mem range). Running gdb within wine seems tricky. By default the backtrace is only framepointers and if I try dwarf-2 symbols which is apparently supported winedbg crashes. So I put debugging it aside for now. I started cleaning up my patches, only over 60 left of more than 150. I also packaged premake-5.0.0_alpha16 and rdb's fcollada and use them as external tool respectively lib; they work both fine it seems Building nvtt on mingw-w64 is completely broken I found out.

Oh, thanks. At least it makes it valid json ...

"Buddhist Evangelism" isn't a { key : value } pair, so no braces around it, like for genericName.