Jump to content

Itms

0 A.D. Project Leader
  • Content Count

    2,259
  • Joined

  • Last visited

  • Days Won

    98

Posts posted by Itms

  1. Hi Teiresias, this is very interesting! Our use of C++ unit testing to run JS tests is really subpar. If we can use jasmine through spidermonkey it would allow us to have a better tool for testing JS code.

    Would it be possible for you to demonstrate how to run, for instance, simulation component tests (in binaries/data/mods/public/simulation/components/tests/), using jasmine? Those tests rely on "Engine" methods which are defined in the 0ad engine, so I'd like to see how that works out.

    Coverage information would be nice to have. I wouldn't say it is mandatory (we have engine coverage and we don't really look at it) but if we have it it's definitely a plus, and it would push us into analyzing coverage information more often.

    Thanks a lot for your proposal!

  2. @gameboy (y)

    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.

    • Thanks 1
  3. 5 hours ago, JasonFriday13 said:

    @Itms Just so you know, I've done work on cross platform support. So nsisbi is fully cross platform on linux (I use ubuntu), and bitness agnostic too so it doesn't matter if your OS is 32 bit or 64 bit. I know one of the other developers also packaged it for Homebrew on Mac too.

    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 (y)

     

    @gameboy 我的中文不太好:pardon:你是对的,我们必须使用英文。为了packaging 0ad,你必须使用Linux。如果你没有Linux,不可以 ! ! 如果你不是 Wildfire Games member,你不需要作packaging, 你不需要有Linux ! :)

    • Like 2
    • Thanks 1
  4. 14 minutes ago, nani said:

    I'm on board with disabling some "questionable helpers" for competitive rated games but I wont cripple the mod so we all have the same lower bottom minimum 0ad experience when these features could/should be in the game rather than as a mod. Just stating that these mods are trying to improve the playability not cheat.

    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).

    • Like 2
  5. 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.

    19 minutes ago, gameboy said:

    But the problem does exist, and you can test it.

    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.

    • Like 2
  6. On 9/4/2020 at 6:14 PM, Itms said:

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

    26 minutes ago, Itms said:

    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.

  7. 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?

  8. 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.

    • Like 2
  9. 23 hours ago, Nescio said:

    Part of the problem is that the “O11: Templates (Balancing)” group is automatically added to any patch that includes a file from the simulation/data/ or simulation/templates/. Ideally only those that are explicitly labelled [gameplay] would be. Just a few examples that don't affect gameplay balance at all but have the O11 group added nonetheless:

    There are dozens more.

    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.

  10. 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).

    30 minutes ago, badosu said:

    Interestingly I see this on the bottom of the page, but I didn't perform any action:

    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.

  11. (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.

    • Like 1
  12. 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.

    • Thanks 1
  13. 11 hours ago, Nescio said:

    What is the advantage of embedding? Why not simply use e.g. Firefox's?

    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.

    12 hours ago, Nescio said:

    Also, I noticed the libraries/source/spidermonkey/ folder in the svn development version is already 3.3 GB.

    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.

    12 hours ago, Nescio said:

    However, I read SM68 requires C++14 and SM78 uses C++17, so I guess that'll require a lot more work?

    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.

×
×
  • Create New...