hyperion

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?

The size is guaranteed, it's not guaranteed to exist thou. If the target doesn't have 8bit bytes, yes. The only examples I'm aware of is hardware in the 70' which for example had 36 bit words, so you end up with either 9,12,18,36 bit bytes. Conversely if you have a C99 compliant compiler without uint8_t you won't have a type that you can use for u8 either, so you are screwed anyway if you want to port it to such a target unless you make sure the code never makes use of the feature that u8 is actually 8 bit in which case u8 is a bad name anyway. Not for windows. There it redirects to wposix which apparently broke mingw for some odd reason . Indeed there are other ways to go about it. But this doesn't change the fact we include dozens of headers where one would suffice just to to create a new header that is potentially only ever useful for compilers supporting c++17 (required by 0ad) but for some obscure reason not C99 (not an explicit requirement for whatever reason). Right, just that I'm faced with to many errors to care for now. Porting might become a major project by itself .

Long ago VS didn't support C99 I think Both are set to private? Sure, just as the only consumer (0ad) doesn't care either way I didn't bother thinking what could be an appropriate choice.

So sm and fcollada compiled. Sm was a bit of a pain and is probably usable. For fcollada the attached patch was already sufficient. Building 0ad seems to be a major headache thou. Premake pkgconfig module should check for ${CHOST}-pkg-config first and only fall back to pkg-config if not found like autotools does. After a little hack for pkg-config I got tons of issues with undefined stuff. Probably caused by legacy hack after legacy hack. So a first simple suggestion attached as well. Best to get rid of the whole header thou and use the standard instead of custom types throughout the codebase. fcollada-no-msc.patch pyrogenesis-types-include-stdint.patch

Then I didn't and won't read it. For me open source is open discussion. And what wasn't discussed in the open I treat as was never discussed. Sorry.

I will admit that a mere name change is probably a hassle, but I doubt that it would cause mass outrage. Given that maybe an overhaul would be better. I'm not talking about some people complaining on the forums. That hyrule still is on a23 should ring an alarm bell. One of the major reasons I never considered modding is the attitude towards such changes. There is even a recent thread to rename gaia. After a well grounded answer as to why gaia is actually a good choice there comes a storm of alternative suggestions. As for Citizen, I admit is wasn't a perfect choice, just a reasonably good one. So once you have a complete concept about how to integrate social classes into gameplay witch is in line with the theme of the game (primary warfare with a bit of eco) and it conflicts with that term, then the fallout becomes worth it.

Can we? And for what definition of better? Can you quantify OP civs? How many rating points can you compensate with the strongest vs the weakest civ currently? 10 50 500? Where does it start to be a problem? Can we realistically have different civs and different units if we want it to be within ±1 rating points? How about maps which favour some civs or strategies, or aren't perfectly symmetrical? Should they be banned? Last but not least, why can't people who are bothered by the slightest imbalance play mirror matchups? As for OP pikes, well, I still slightly prefer spears as they are more versatile.

Does this approach have the same shortcomings as using homebrew for mac? If so I don't think it's a great solution but nonetheless a clear improvement over the status quo. Well, as said before, I only have most of the deps so far. As for rust, took me a bit of digging to patch it so it would build (bootstrap depends on sanity checks for dist target which I don't care about in the first place). As for the quirks so far, gcc 11 is to new for the mingw runtime so I had to use gcc 10 configured to use pthreads so I get <mutex> <thread> etc. Then I configured all deps with --enable-static (as intended) and --disable-shared to reduce issues (don't remember which package didn't want to build a shared lib of the top of my head) and --disable-log for boost. In case of miniupnpc I had to use Makefile.mingw and use the static lib as target. The rest can be called ebuild bugs like excess deps or defines which are Linux specific. I don't mind sharing the exact setup once I have it working but it's Gentoo specific, so except for a proof of concept might not have much value for you. Anyway, if you use mingw on windows I think you won't run into much issues up to where I am either. PS: had a quick first look at SM and Gentoo has a patch for fortify source, remembered you showing me the flags used by the the ubuntu maintainer which apparently caused issues.

BSOD is always a system issue, so OS/drivers/hardware.

The Mauryans acclaimed as über OP don't sport pikes. Isn't it great other civs have something in their favour? --- For gameplay purpose we want a tank with little damage and high defence (aka. OP unit of the week). Once we settle what stats that tank should have it's time to find a representation which is historically and realistically at least somewhat plausible. If everyone thinks a pikeman is a misfit for this role, propose another skin. Not the other way around.

Na, what I don't like is storing binary artefacts in a repo and only providing the last step in a proper manner, instead how it's done for mac is how I see it should be for Windows too. Building from ground up in Windows strikes me as more difficult than cross-compiling for me. Some tricks were required but It was rather straight forward until I ran into rust. Never expected that bootstrapping a rust cross-compiler targeting Windows would be such a headache. I only expected 0ad itself to need quite some work to allow for cross-compilation which would be worthwhile irrespective of a potential win64 build.

As I don't like this approach I created a cross root to build a static 64-bit pyrogenesis.exe. Well, I got all dependencies cross-compiled with only sm and fcollada missing. Got stuck at building a rust cross std lib, guess will take a while until I have time and energy to get back to it.

Most slaves were the children of slaves and not some criminals. Thou sending criminals into mines sounds plausible.

Visible and invisible classes are the same internally. So nothing would "break". Why make it visible? So you can refer to it in descriptions. E.g this building can be garrisoned by Citizen. So it is visible because it is in use in UI texts and needs to remain visible. Sure it can be renamed but must be a name that isn't used already. As such Worker is not an option. Let's say you find an appropriate name for this class. Dependent text and code must be fixed (bearable). This still leaves the use of the term citizen-soldier in code and templates (variable/function/file names). If you even fix the latter even more dependent stuff needs fixing, possibly breaking quite some mods out there. Even if you fix any references in the source tree, the term will remain in the heads of people after being used for decades. There are also all sort references to the term all over the place (wiki, forum, youtube, twitter ....) where most can't be changed any longer. So I get your point and a better name might have been chosen once upon the time but I doubt you will find a dev willing to do all that work now and take the blame for the fallout.

Classes are meant to allow certain technologies, effects, aurae, selection to be performed on a group of entities. 0ad "Classes" and historical social classes have nothing in common at all. So slaves as a unit type could and probably should also get the Class Citizen. While the Class name Citizen isn't perfect it's not half as distorting history as depicting slaves as miners. The CEO of a global consortium like Nestle might have been a slave in Rome while the beggar living under the bridge would have been a freeman. Anyway changing the Class name Citizen wouldn't improve historical accuracy as it has technically nothing to do with history in the first place. On the other hand it causes major issues. The suggestion to only rename it on the surface increase complexity for maintainers and new contributors alike and should be considered code rot. The opinion that it's easy and doesn't come at a major cost and just has to be done right won't ever be uttered by a seasoned developer either.

So in your opinion dropping 32-bit build before 2023 is undesirable (sounds reasonable) which makes a straight replacement impossible for now. So how should a 64-bit build be handled?

I don't remember having seen the term in-game, correct me if I'm wrong. Citizen as class is also used for woman. As such the purpose of this change is to rename assets and create more mayhem than a24 did?