hyperion

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.

In reality it's hard to spot fish. So job well done. Maybe a hotkey to select all gaia in a selection rectangle, like observers can is all that's needed. Wouldn't be limited to fish either. There are other things hard to spot which is a given if it has to be realistic and look beautiful. Anyway, any of the make ugly but functional visual changes for competitive play belong into mods.

Goldfish, they are colourful, so you easily see them.

Arguably yes, but it shouldn't crash with the integrated gpu either.

There is but that's a poor man choice. Premake will reject --cc=icc (cc option used to set toolset analog to os option ), so will default to probably gcc. if cc == nil then filter { "toolset:clang" } cc = "clang" filter { "toolset:gcc" } cc = "gcc" filter { "option:icc" } cc = "icc" filter {} end So the above only works because we put icc last. Often that doesn't work, if we could use toolset:icc the premake5.lua could be written a lot cleaner.

Agreed, just that premake terminology is rather awful. I pass in --os=windows --cc=mingw (for better or worse), so os.istarget("windows") and os.ishost("linux") become true. Then there is the premake command system { id } which I believe sets --os=id and results in os.istarget(id) to become true. Hard to not be confused at this point. Anyway I can't take the current os.istarget("windows") path here for cross-compilation. I could rename CHOST to target_triple thou that wont change the logic.

And because we define it ourself I thought it's to test whether we use a doggy compiler or such

So it's to guard against someone redefining MAP_FAILED to nullptr?

Just because there is a coment doesn't mean the code does what is intended or meaningful. Isn't one of the points of intptr_t that the round-trip is guaranteed? So why check?

Was wondering why my wdbg_stub didn't get picked up, turns out due to a bug I introduced into premake5.lua the windows-only cpp files got omitted during compilation So, some time later that stuff is fixed and builds as well. Came across a curious thing static_assert((void*)intptr_t(-1)) in wmman, gcc barfs on the reinterpret_cast here, but even if not I don't see the purpose of this assert. May someone enlighten me? So, more serious business, I started to look into how to properly implement the changes into premake5.lua. Some googling makes me feel I'm among the first to ever cross-compile with premake. Many issues to address. premake-core has no icc support (--cc=icc is invalid) (optional, highly desirable) premake-core does not respect RC respectively RESCOMP (required, some symlink with PATH hacking might work) So how to handle this? Patching the copy in tree seems beyond ugly. windres doesn't support -isystem, only -I for includes So no sysincludedirs permitted. Don't use them? Build rc as a standalone static project? Does VS have something like whole-archive? Simply drop the error_dialog? Below a patch to set cc and arch usable for cross-compilation, anyone sees a setup this might break? premake-cc-and-arch.patch

Yes, I know I'm not yet done

wdbg is problematic too, sal.h /* FIXME: __in macro conflicts with argument names in libstdc++. For this reason, * we disable it for C++. This should be fixed in libstdc++ so we can uncomment * it in fixed version here. */ #if !defined(__cplusplus) || !defined(__GNUC__) #define __in #define __out #endif so I threw it away The ancient mongoose copy also needed a minor fixup, now the project compiled, with all extras still missing. Linking is the next step, but I guess lot of changes to premake files are needed. Not yet figured out how to go about it.

CBUILD, CHOST, CTARGET correspond to the configure args --build --host --target which you might be more familiar with. So I cross compile from linux to windows with CBUILD=x86_64-pc-linux-gnu and CHOST=x86_64-w64-mingw32, and I use x86_64-w64-mingw32-g++, x86_64-w64-mingw32-ar etc as well as x86_64-w64-mingw32-pkg-config. Not really familiar with premake, so whether to respect CHOST, use PKG_CONFIG=, or a switch like --with-pkg-config= or all of them I'm not sure which is most inline with how premake does things. Pulled, thanks.

As @Stan` quoted. I called it hack here because I patched in the value of CHOST I require to cross compile. No problem reading lua but doing things properly would take time looking up stuff and I'm fast approaching the original estimate of a couple hours, so I settled for the cheap solution for now to be revisited later I love hearing debundling. I'd even throw out the stuff in libraries/source/, cxxtest and valgrind should be easy, fcollada and nvtt are dead upstream so forking and putting up as fcolladaAD and nvttAD and treating them as external libs should be fine.

Not in general, but as a project should stick to one way and the nominal lead immediately pinged you ... Btw. wseh is also broken (32bit only) and in wgl.h ... ... doesn't have enough exclamation marks. You only know after experiencing it.

Simplification of history is often used in politics, as such I have some aversion to such practice. Not putting you into that same boat, just saying. The current situation is so far off that it's sort of fine. I mean citizen has another meaning in modern society so we can easily hide behind that meaning. There are actually places where historic accuracy is unproblematic, such as models and names, which are handled rather well in 0ad. But there are parts lacking which I think are more appropriate than trying to project some historic concepts into gameplay. For instance civ info having a few sentences at most an neither structures or units having any background texts. Campaigns, once we see more of them are another place where history can play a major role.

So you prefer <cstdint> and not importing those types into global namespace? (well the implementation might still do it) As for avoiding the question, I guess you are qualified to dictate the answer It's indeed the source for this issue and also the cause for breaking the off_t family. The whole header might profit from spring cleaning. C++11 mandates C99 after all. Is that 32bit runtime and on windows? Thanks, fully support the effort, pulled it, still need the CHOST hack thou.

It indeed isn't meant in a negative way. Can be called lore if that sounds better. It also means to create a mod is fairely easy technically, mostly just effort. Still there are quite a few question that come to mind which need be answered first: applicability across civs whether it doesn't distort truth as much or even more than citizen soldier (over simplification might be worse than omission) whether additional constraints on unit design have negative effects on "balancing" whether the possible added (even if only perceived) complexity is an issue (mostly for new players) or offsets the gain due to lore. I can't help much answering those questions, besides Rome I have only shallow knowledge of that time. As for the non history aspects I somewhat sceptical that you can break even, thou that's just a hunch based on personal priorities.

So basically it's just decoration and not a game mechanic. So the only benefit is potentially better immersion. Do all current and possible future civs fit that scheme?