Itms

@gameboy You must first discover how to build the game on Linux. You must use the Terminal (see https://ubuntu.com/tutorials/command-line-for-beginners) When you understand how the Terminal works, you can follow the instructions on Trac to build the game a first time: https://trac.wildfiregames.com/wiki/BuildInstructions#Linux If and only if everything works, you can run the packaging script in the terminal: cd source/tools/dist/ ./build.sh The last step should fail because nsisbi is needed instead of makensis. You should then copy the export-win32 folder to Windows and then use nsisbi. If you figure out how to use nsisbi on Linux, you can send a patch; else we'll patch the script for the next release, but probably not before.

Ah that is good, we will definitely use nsisbi from Linux if it works, instead of switching to Windows for the last step of packaging @gameboy 我的中文不太好你是对的，我们必须使用英文。为了packaging 0ad，你必须使用Linux。如果你没有Linux，不可以 ! ! 如果你不是 Wildfire Games member，你不需要作packaging, 你不需要有Linux !

I never knew what was your mother tongue, gameboy. If you can share it, we can try to resort to this whenever we have a serious misunderstanding, like here.

Completely agree. The only questionable thing we find in a few mods is the code that removes the mod itself from the list of enabled mods. Players should be aware that their opponent is using autociv or any other mod (in theory: as I said, they can't know if their opponent changed the code locally).

In this situation, it's you who doesn't understand me: for the last time You need to use Linux to run the packaging script BEFORE using nsisbi on Windows. I believe there is no problem in the code, it's just that you don't use or don't have the correct tools. I could test but I'm working on SpiderMonkey at the moment, and however much time I loose repeating things to you it's still quicker than packaging the game, which takes a couple hours. If you make the effort of understanding what's blocking you, then I can answer your questions if they are clear. No problem with that.

No, it doesn't need any update!

You need to run source/tools/dist/build.sh on Linux, then you can use nsisbi on Windows (instead of makensis on Linux) to create a Windows installer. What do you not understand? Can you stop pinging people all the time? Can you formulate questions instead of harassing us?

Maybe but why do you say that? The big difference is in the unlogged code. at first sight it could be anything, no?

I agree it's going out of topic. In the staff forums we have been saying that I will stop signing mods that change the mod detection code. For instance autociv "hides itself" from the list of enabled mods, specifically in multiplayer. I can't "unsign" it, but all mods will need a new signature for A24, at which point autociv and others will have to remove this hiding feature in order to appear on mod.io. As odalman mentions, this is not going to fix the underlying problem. Players can install non-signed mods manually, they can even modify the engine code if they have the skills. Out of sync errors will prevent players from directly modifying the simulation to their advantage, but they can always tweak the UI, implement auto-train and other things... The change to signing is mainly made in order to be fair and more open to players using mod.io who might be unaware of autociv's (and others) internals. I'm not sure we can do more without resorting to complex measures like using servers.

gameboy did you run the packaging script on Linux first as needed? NSIS is only the last step of packaging.

I think mistakes or inconsistencies can be easily fixed by just adding Balancing as reviewers manually.

Sounds good. I suggest not touching the O11 code ownership. Code owners are sufficiently complicated as they are. I think we should keep restricting code owners to team members @Stan` I will create instead a Balancing user group with the Herald rule Nescio proposes

In this case the best thing to do would be to create a Herald rule which is triggered when a diff title contains [gameplay]. Anyone can create such a rule, to be notified whenever they want The so-called "Code owners" (O11 and the like) are only determined by paths of modified files. I think it's still interesting to have that.

Ah! When seeing your last message I thought you had discovered a bug. But I just discovered that Stan has added you to the list of owners of the Balancing changes. You are basically an automatic reviewer for all those changes. @Stan` you probably shouldn't do that before explaining to people that it will flood their notifications/inbox

You're not subscribed to this diff, you shouldn't receive any notification about it. Are you talking about the public Activity stream? You cannot possibly catch up with everything. You should rather manually subscribe to what you are interested in, and monitor your emails or notifications depending on your preferences (by notifications I mean the small bell icon on the top left). This is a bit confusing indeed. It is a summary of the pending actions you would perform if you clicked "Submit". By default it would subscribe you. If you write inline comments, or choose actions in the Add Action.. menu, they will be added to the summary, waiting for you to press Submit.

I don't understand. When you click on the link above, you get to this page, right? As written there, your notifications should already be limited to what you are subscribed to. Do you have an example of a change that you would not have wanted to receive a notification for?

Here is the page for your account For others, click on your avatar on the top-right of the page, then Settings, then Email Preferences (which also handles notification preferences).

(I deleted the duplicate topic) The build restrictions are handled in binaries/data/mods/public/simulation/components/BuildRestrictions.js. It is there that you can find the logic behind where buildings can be placed. You would need to add some information to the templates of the buildings (in binaries/data/mods/public/simulation/templates) In the BuildRestrictions component, you will need to query the engine's TerritoryManager. Maybe you'll need to tweak it as well. It is implemented in source/simulation2/components/CCmpTerritoryManager.cpp.

Ah, I see it as well. Which one should I rather sign? Signing both sounds like a big overlap.

@Stan` @andy5995 I think I managed to "undelete" Hyrule Conquest and Vision Sharing. However I cannot see the Korean pack anywhere.

Hi andy, sorry I hadn't seen this topic, so I didn't know I had to review the mod. It's better to send me a PM (even though I can be long to answer, at least I know I have a mod to sign). I haven't deleted/rejected any mod, so I don't know what happened with yours. EDIT: I think one of the mod.io developers cleaned up all pending/incomplete mods from the whole platform.

There is a confusion here: we do use the same engine as Firefox. However, we need to build the game with it, so we need the development files of SpiderMonkey. When one installs Firefox, they only download the compiled Firefox which includes (or comes alongside) the compiled SpiderMonkey. Similarly, when we release 0 A.D., we distribute the compiled SpiderMonkey which is quite small. 0 A.D. end-users can download the compiled SpiderMonkey to run 0 A.D.; on the other hand, they cannot build 0 A.D. For that, one needs the development files which are heavy. If you want to take a look, in some package managers, the former is called mozjs52, the latter is called libmozjs52-dev. That is because you built SpiderMonkey. If you checkout a fresh SVN copy, that folder is 98 MB (which is already heavy: it's the development files). It is worth mentioning that SpiderMonkey devs improved the size of the source SM tarball so in SM52 that folder is now only 35 MB. When you build a big project such as SpiderMonkey, the compiler outputs a huge lot of intermediate build binary files that take up a lot of space. If you want to reclaim that space after building, you can delete the folder libraries/source/spidermonkey/mozjs-45.0.2/. The built files, needed by 0 A.D., are copied elsewhere at the end of a build. Not really. It is SpiderMonkey that constrains which C++ version we support. Right now, it's a lot of work to migrate to C++14/17: that work is upgrading SM Once SM is upgraded, supporting new versions consists of a three-line change in premake and possibly some small adjustments. Upgrading SM also means dropping some old compilers, which is work, but it's communication work with package managers rather that programming work.

Sorry I'm only looking at this now, but you haven't installed any mods by any chance? If not, can you delete all the folders that are in "Documents/My Games/0ad/mods/"?

Not necessarily. I am going to try to update SpiderMonkey as far as possible in A24. I don't want to unnecessarily delay the release of A24, but the less obsolete SM is, the fewer problems we will have.