s0600204

Whilst autotools may use CBUILD for the build system and CHOST for the system that the built application is to run on, premake5 uses os.host for the build system and os.target for the system the built application is to run on. Thus, I think you might want to go back to os.istarget("windows") in your patch, as the rest of the file expects arch to be that of the system the built application is to run on, and pulls in the correct architecture-specific headers accordingly. (Of course, I could be getting confused...) (That said, the architecture detection on Windows is broken anyway: our autobuilder is 64-bit but spits out a 32-bit executable... the only thing telling it what arch to build for is what you see in that file.)

@Stan` Ah, I'd forgotten about that. That does clarify things, thank you.

Heh, one thing at a time. (There's also mongoose, tinygettext, and several other things that can be found in source/third_party/) Very easy in the case of valgrind: D3646. Haven't looked into cxxtest at present. We already have our own fork of fcollada: https://code.wildfiregames.com/source/fcollada/, although it's not pulled in like other external dependencies (and in fact there are some differences between that and the code that is currently bundled within library/source/). (There's also #5907 to take into consideration.) Personally, I'd like to see FCollada replaced with something that's actually maintained (by another project I mean, not by us). (Ditto with nvtt.) But it's beyond my ken to suggest possible alternatives. And to refactor code to use said alternative. [...] because I patched in the value of CHOST I require to cross compile. I was a little confused as I haven't had to do that in my own exploratory work. Still not too sure what ${CHOST} is supposed to contain. Then again, I'm largely unfamiliar with autotools, so if it's something specific to that then that might be why.

I myself have been looking into creating a script akin to the current build-osx-libs.sh file, but for Windows; with the hope that it would lead to us debundling the Win32-specific binaries and headers. I'm curious to see where other people have got to in their own attempts. Anyone willing to share a link? The "CHOST hack"?

Moderation: Split the discussion of building a 64-bit pyrogenesis into its own thread, as it had deviated from the original purpose of this one.

Have you altered the Structure Tree within your mod at all? Perhaps increased the amount of "Trainer Units"? (Do you have a file called: gui/reference/structree/Sections/Trainer/TrainerSection.xml ?) If so, you will need to change style="StructNameSpecific" to style="StructNamePrimary". As to the other error, could you check that all templates listed in the StartingEntities section of your simulation/data/civs/{civ}.json files exist? (If they don't then you should also see errors when starting a "Random" (instead of Skirmish or Scenario) map with that civ in play.)

In all seriousness, was that a dig at Microsoft or at me? (History repeating in the sense of Microsoft bringing back Vista-like ideas; or history repeating in the sense of the next wave of comparisons of a new version of Windows to a former, widely disliked, version.)

Subtle. The change to the BSOD screen I'd prefer would be that it wouldn't auto-reboot after a few seconds. (I have a Windows 10 laptop issued to me for work. Sometimes - but not always - when I return to the office I find it powered off. Took me months to realise why - it BSODs, reboots, hits the bitlocker screen and - seeing as I'm not present to enter the code - powers down. I return later and have no idea why it's off.) (Also, when I am present, by the time I've grabbed the nearest device capable of reading a QR code and opened the relevant app... the darn laptop's rebooted, and taken the code with it!) From what I've seen, I'd say it looks more like Microsoft are trying to bring about the second coming of Windows Vista.

We could add a scrollbar... or we could remove the description/history from the Structure Tree - it doesn't really contribute anything (and it can still be read in the "Civilisation Overview" and "Match Setup" pages).

Indeed. I've been lurking in the chat room of the proposed fork: thus far they've chosen a name: "Phorge". Amongst the ongoing discussions, I think the one most relevant to us (in that it might affect our own decisions) is that they're considering dropping support for subversion (and mercurial) repositories. (Also, for those who don't like arcanist, there's been some discussion about replacing it with a new cli client (written in rust/go) and/or supporting "git push" directly.)

simulation/templates/template_unit_infantry.xml file has "structures/{civ}/elephant_stable" instead of "structures/{civ}/elephant_stables" in its build list. simulation/templates/units/ptol/camelry_scout.xml has an aura of "camel_stench" which should probably be "units/camel_stench".

As mentioned on #0ad-dev, Phacility (the organisation behind Phabricator) is winding down operations, and - as of June 1st - Phabricator is no longer being maintained. Announcement: https://admin.phacility.com/phame/post/view/11/phacility_is_winding_down_operations/ Upstream task: https://secure.phabricator.com/T13654 We're self-hosted, so the only impact on us is that existing bugs, security vulnerabilities, and so on may/will remain unpatched. (They claim to no be longer accepting bug reports, and have stated a plan to decommission "Discourse", the site they prefer people use to submit reports.) There does appear to be a group that are considering forking Phabricator and continue down their own path. Very little news (as of yet) about how the "big" users (e.g. Facebook, Wikimedia, Mozilla) will be handling this. IRC where people are discussing the fork: #phabricator on libera.chat Select excerpts from the above IRC: https://d.i10o.ca/tmp/phabricator-future/ Chat room for discussions: https://temp-community-phab.zulipchat.com Shared document where things for the fork are being documented: https://docs.google.com/document/d/1YxQ_JGdhWYPSdoaI_m1TLzwbGLZdtOD7ux2SVL263Ow

@GunChleoc, you appear to have an old version of enet installed in /usr/local/include/enet, which is being used instead of the Ubuntu-repository-provided version.

--> https://code.wildfiregames.com/D3219 Committed: r24387 (update of the premake5 files) r24388 (patching our build scripts on *nix systems)

It does, and it looks like it is. I've raised a concern on the commit I believe to be the cause: https://code.wildfiregames.com/rP24279

Correction: you can, but you need to move further than the building-preview indicates. @wraitii, it appears that building-previews are not respecting BuildRestriction's MinDistance, but transitioning from being red-hued to normal a little prematurely. (This also happens with towers.) After a little research: the value of it->second.size on CCmpRangeManager::1385 is 0 for building-previews. (Is it because it's a building-preview, or because its a local-entity?) Either way, the obstruction radius of the building being previewing isn't taken into consideration. Once a player tries to place a foundation, one final check - this time with the foundation, for which the value is > 0 - is made and suddenly the distance is too small...

Thank you for the report. A fix is being prepared... has been applied.

Ok people: cool it. I think we can all agree that the #BlackLivesMatter campaign is important, particularly after the events of the past couple of weeks. And yes, it is a pity that the actions of a select few spoil it for everyone. I think we can also all agree that all lives matter: regardless of race, creed, ethnicity, religion, disability, place in history, or any other factor. However, this message is getting lost as this thread continues. Whilst we welcome constructive and reasoned discussion, the three posts immediately before this one did not meet this criteria, hence why they have been hidden and the users concerned given warnings. Please note that continuing to insult each other and/or act contrary to this forum's community guidelines/code of conduct/rules - particularly over such a sensitive topic - might lead to temporary bans of those that cannot keep a civil tone.

Those three are used by the rmgen wall builder to, well, build walls. AFAIK, none of them are used by the in-game user wall-placer. indent: Specifies offset from the centre of the wall line. Allows wall elements to be placed in front of (e.g. palisade spikes), behind of (most buildings), or inline with (e.g. fortresses) the line of a wall. orientation: Each wall-piece has a side that faces "in" and a side that faces "out" (important for gates, and wall-towers that have doors on the rear). orientation tells the script what base rotation to apply to the model to make sure the wall piece "faces" in a way consistent to every other wall piece. bend: Some wall pieces "bend" - the direction to the "outside" of a wall changes along the length of the wall piece (e.g. palisade curve). bend allows definition of that. For now, not a lot is done with this - specifying "cornerIn" or "cornerOut" to the wall-builder when using the palisade wallset will get you the palisade curves instead of wall-towers (along with a 90-degree turn in the wall) - but I think the idea was that when the wall-builder builds a wall with corners in it, then if one of the "bending pieces" has a bend that matches the one needed, then the bending piece is placed (instead of a suitably rotated wall-tower). For pieces that bend, orientation is that the wall piece starts at, not as it is in the middle. orientation and bend are measured in radians multiples of Pi, in case it is unclear. The random map "Walls Demo" demonstrates use of the rmgen wall-builder. (I would say use it if you need to make sure that your new palisade variant can be read by rmgen scripts, and that it's placing things correctly... unfortunately, the script is a little naive with regards to names - your wallset is ignored as there's already another wallset with a name starting "wallset_palisade".)

Should be inside ~/Library/Application Support/0ad/.

As Stan' points out, the wonder population aura provides an absolute bonus (+10, increasing to +50 with the research of "Glorious Expansion"), not a proportional one. It it really added a +10% bonus, then one wonder would raise the population limit to 330 (or 370 after researching "Glorious Expansion"). Thus, it is proven empirically.

Bonuses are currently applied thusly: [base] * [proportional bonus] + [absolute bonus] Both +20% and +15% are proportional bonuses, so (at the point where a unit enters the overlap in the radius' of both auras, and assuming no other auras in effect) they are multiplied together to get a total +38% bonus, which is then cached. The caching allows the final calculation to be as above - which is relatively quick to calculate - rather than having to iterate through every aura active on the map, determine if they're in range, whether they should apply, etc... all several times a second. When a unit moves out of the radius of one of the auras, the cached proportional bonus is divided by the proportional bonus of the aura no longer in effect, and the result replaces the old cached value. Absolute bonuses work similarly, except they are added to (and subtracted from) one another, with the result cached: only recalculated when a unit passes in or out of another applicable aura. You might use an absolute bonus to add a given bonus regardless of the base stat (e.g. +5 resource carry capacity).

@abc1: If both auras affect whatever units you're controlling, then yes the effects will combine. @sphyrth: you're asking if 0AD is doing: [base attack] +20% +15% (equivalent to: [base attack] * 1.2 * 1.15) or [base attack] +(20 + 15)% (equivalent to: [base attack] * 1.35) I believe it's the former, which in this theoretical scenario where both auras are in effect, amounts to +38% to unit attack. @Feldfeld: Whether or not an Ally's aura affects you depends on how the aura in question has been defined. It is also possible for an Enemy's aura to affect you if defined to do so. As an example: the Ptolemaic hero Cleopatra has an aura that increases the heath of allied Heroes, and a second aura that lowers the health of enemy Heroes.

As requested, all posts off-topic (and those flaming and/or trolling) have been split elsewhere. Those with value in them may be restored in/as a different thread, later. However, to everyone who posted before the split, regardless of who they be: Be. Nice. It is acceptable to disagree with someone else. It is not acceptable to insult, to demean, or be overly aggressive in your posts. I hope that is clear to everyone. No exceptions. Oh, and please keep on-topic in future, thanks!

(Split posts out of original thread as it was off-topic there.)