sanderd17

I wanted to test this mod, but every time I download it, I get a size mismatch (only downloads 3MB, 12MB, 37MB, ... never the full 43MB). Does anyone have the same problems? LordGood, could you maybe upload your file somewhere else? Dropbox, github, ...?

We need mods too. Thanks to the recent mods, we saw flaws in the modding design of 0 A.D. I've done quite some commits splitting up huge files, and adding other ways to mod content (with less chance on conflicts). Without mods, it would be hard to notice our flaws.

Right, that repairing problem is actually quite simple. For building structures, we have a buildtime stat. If a single unit builds the structure, that's the time it will take. But for repairing, we don't have such a stat yet, so units just repair stuff at 1 hp/s. Which is, for structures and ships, not viable. Introducing a stat for it doesn't cost that much work, balancing it will be harder though.

I believe the UnitAI los code only checks new units to see if there are hostile units visible. Less data to be send by messages also means less data transformation though, as you need to clone it for every message you send, you don't know what the message receivers will do with it. I believe it's executed once per turn (200 or 500 ms). So it should be rather fast. Not sure what you mean by our grid. We have a terrain grid, but that's only for rendering and the long range pathfinder. Entity positions are stored as fixed-point numbers, and are precise up to a few micro-meters iirc. The range manager uses those positions directly. The range manager can split by owner (so scripts can give a list of players if they only want enemies, allies, ...). And by implemented component: all units have the IID_UnitAI interface, resources have IID_ResourceHolder, anything possibly hostile has IID_Attack, ... Which mostly filters out the not-wanted entities at the gate (apart for the los query, as that's used for multiple purposes, s.a. finding enemies, finding new resources, finding a dropsite, ...)

Yes, but due to the small range, only to two (maximum 4) males.

Iirc, it's something like +10%, so certainly not huge, but a nice bonus. And the radius is rather small. They have to be quite close for it to work. But since units often shuttle to the same dropsite, if they work on the same mine, they're most of the time close enough.

Note that -jx means there will be x number of threads. So it works on all processors, but if your number of threads is a lot bigger than the number of processors, it will just make your system very unresponsive. I have 4 cores, and either build with -j3, if I know it will take long, and want to do other stuff. Or -j8 if I'm planning to watch it until it's done. And for the script, I don't know why so many people are writing build scripts for 0 A.D. Once you have the right dependencies, building it is just one to four commands. And with auto-complete just a few tabs away.

We have missile accuracy with pseudo randomness and a distance precision term. As for the cost per missile, not good as long they're very trigger happy.

Not sure what you mean. The first phase of the game is focused on building up a village with natural resources. Which is strange when you start in an urban environment. No resources, everything prebuild, ...

No ETA yet, it's not the easiest thing (collision detection, being able to control the density in some way, ...). But you can copy-paste forests from other maps now

Units are already enlarged (compare them to the size of a ship, or a house). They're actually 4m tall. I believe making them any taller would break realism.

Btw, we got copy-paste in SVN

And hold the ALT key to select actors (move or delete them).

Fixed in svn

This is the way to mod something, copy a file to your mod, and modify it. It's also why we're working on splitting those big files, and loading stuff by directory instead of by complete path.

Do we have so many duplicates in the unit strings? Something isn't right there. We shouldn't have duplication thanks to inheritance (except in some cases, where we'd need multiple inheritance). The splitup seems good for me. Could you also add the AuraName and AuraDescription tags to the templates extraction? (I didn't add those as I knew you were working on it).

The hotkeys are loaded into session.xml, so it's normal that file fails. And you need to give the path relative to your mod main directory for the script, so probably "gui/session/hotkeys/activepause.js" or something. Also, I don't think script tags are valid inside object tags. The scripts are defined directly inside session.xml, which loads all "gui/session/*.js" files, so just placing your file there should be enough. EDIT: I thought you switched to SVN, though I shouldn't have suspected that given you still use the 0ad shell script.

Thanks for reporting, it's fixed in SVN now: http://trac.wildfiregames.com/changeset/15391/ps/trunk/binaries/data/mods/public/simulation/components/Cost.js

Your mod certainly doesn't get loaded, as your XML file is wrong. An XML file may only have one root node (in the case of included XML files, a root node with the name "object". If you want your script to be ran, place it in the session/ directory, and it will be loaded automatically. Anyway, my suspicion is that your "0ad" commands points to a shell script which doesn't pass on the arguments to pyrogenesis. Can you find out what "0ad" is on your system? "which 0ad" should tell you the complete path, after which you can open it. If you're not sure about the script, try with pyrogenesis directly.

Mods have to be in ~/.local/share/0ad/mods/ I think, but if you use SVN, you can also place them directly in binaries/data/mods/ under the directory you checked out. Keeps your work and the work you use for reference closer. There's no "on" and "off" for buttons. If you want to switch between two states, you need to keep a (possibly global) variable somewhere with the current state. You shouldn't have to create that directory. As I said, it's a new change, so you can only use it if you use the latest SVN checkout. If you're using the A16 release (which looks like it given the path), you'll have to edit the massively big gui/session/session.xml file. But that will cause conflicts with our future versions of the session.xml which are hard to maintain since the file is so big. That's the reason I split off certain parts of that file (s.a. the hotkeys). But it's only available in the development version now.

Thanks, good luck with spring too

The issue isn't with that patch, it's with the the changes to Spatial that got in 9 months ago. Of which parts are reverted, but not everything. And there's still no decision on whether we want to continue with the current version (and fix the issues with it), or rather rewrite it. in any case, I thank you for this patch, as it's a nice solution for the duplication problems.

Of course you can use animations to switch props, it's the primary purpose of props. Not a different prop at the begin than at the end, but different animations have different props. S.a. you can see in the carrying-meat, carrying-grain, carrying-food, ... animations. The garrison flag is also an animation (which causes some problems in moving things, as the walking animation is a different animation).

The current decision is to not pay per task, to not give us the administrative overhead when reviewing patches. Reviewing takes a great deal of our time. Anyway, about this patch, I've been pointed out that there's an other patch in trac too about removing that costly sort (and a more complete rewrite): http://trac.wildfiregames.com/ticket/2430 We'll at least have to compare the two, as #2430 also fixes the issue with the limited number of entities in a query (see http://trac.wildfiregames.com/ticket/2573).

It pulls in Component.h -> CmpPtr.h -> Entity.h. So it should know entity_id_t. But anyway, doesn't matter a lot. As you say, that entire file should be using the same types, so the entire file should be cleaned.