sanderd17

Nope, just a small template like this: http://trac.wildfiregames.com/browser/ps/trunk/binaries/data/mods/public/simulation/templates/units/athen_support_female_citizen_house.xml The old common-api and common-api-v2 are completely removed from the codebase, and common-api-v3 is renamed to common-api. Btw, where can I find your sources to investigate that formation issue?

The mill has been renamed to "storehouse". Maybe that's your problem. And the icons take the same path as the template (I've thought about putting an "icon" key in the formations template. I'll take a look to see why it is messed up.

FeXoR, if it can help you a bit, the Engine is made to allow a water height map (or at least different water heights). The method to query the water height does it on a certain point on the map. I think, the main reason that different water heights aren't implemented yet, is because it's hard to design an Atlas GUI to allow different water levels in different places. But for random maps, this should be a problem.

I think it's easier to mod the ai code, so the ai can't research the tech. We want to differentiate ai and regular player as less as possible.

http://trac.wildfiregames.com/browser/ps/trunk/binaries/data/mods/public/simulation/data/pathfinder.xml Note that there is a hard limit on the number of classes (8 iirc, because it's implemented as separate bits in an u8 map). Units use default, buildings use building-land etc. The actual floating can be taken from the ships examples.

If the engine restricts something, it's for performance (the resolution is hard-coded, else the compiler can't optimalize the code good enough), but you aren't even restricted to our pathfinder. The pathfinder is just a component, like there are so many in JS or C++. F.e. the plane uses its own, scripted unitMotion component, with a small build in pathfinder. It doesn't take any form of obstruction into account (so the pathfinder is just drawing straight lines), that's why it's possible to script it. When we say "it's impossible", we mostly mean it on an economic base (too much work, will be too slow, ...). The pathfinder restricts the units for sure (else there's no point in pathfinding, if units can just walk through everything), but you don't have to use the pathfinder coded in the Engine.

Try running in windowed mode (ALT+ENTER to switch, or change the setting in the config).

Are you sure it plays without the changes? Or did you just not change anything visual? Unless you altered the GUI pages, you won't see any difference. Also, can you show us your paths? Where is pyrogenesis installed, where is the public folder, where is your mod, what's the exact command ...

What restrictions are you talking about? The Engine doesn't restrict a lot, it doesn't restrict that a unit is on the ground, or that a unit is even on a valid coordinate.

Can you zip your mod and upload it here? Also "doesn't work" is quite vague. Is pyrogenesis crashing, or do you just fail to see your changes? I have no idea what "properties" you're talking about.

No, those should be in different directories. Does this help: http://trac.wildfiregames.com/wiki/Modding_Guide Or this: http://trac.wildfiregames.com/wiki/GameDataPaths

You just took the example section of the XML. The actual schema is a few lines up or down. The schema defines that the attack has to be a decimal number f.e. When your mod is in a directory "MyMod", then you can execute it like "./pyrogenesis -mod=MyMod" (edit the pyrogenesis shortcut).

Just do a search for one of the damage names in your project (f.e. search on "Hack"), and you'll get a good list of files. In short, the types are defined in Attack.js, Damage.js (in public/simulation/components/) and there will also be some gui parts (most likely the selection files in public/gui/session/) and the connection between the simulation and the gui: GuiInterface.js. The AI would also need to be modified I guess. You should be able to do all that without recompiling though.

Note that "W3 schools" has no relation with the official W3C (unlike its name suggests). Sometimes there are flaws in their specifications. It's good for an introduction tutorial, but nothing more. For reference material, I advise https://developer.mozilla.org/en-US/docs/Web/JavaScript (obviously good for SpiderMonkey we use, but it also documents all other major browsers). Also see http://www.w3fools.com/

http://trac.wildfiregames.com/wiki/Manual_Settings

SpiderMonkey has been around for almost 20 years. So I doubt it will be a trap. Next to that, it's open. So the worst thing that can happen is that it doesn't get updated anymore (but currently, it seems to be updated a bit too fast for our needs). Also, translating the JS code to C(++) (if that even works) would most likely not give any performance advantage, as the code has to be interpreted very freely anyway. On top of that, the generated code file would be mostly unreadable. Also note that JS debugging is no problem. In contrary, since scripts don't have to be compiled, and are hotloaded, it's easier to debug than the C++ code, as you can just start and stop logging anything you want while the game is running.

You need power-of-two sizes in game, but AFAIK, it doesn't need to be square. F.e. a 16x128 texture should also be possible. Of course, you can use a square texture, and share it with different weapons (fit some types of sword on the same texture).

Pink is just the color the engine gives to objects without texture (so the texture isn't forgotten). The bow needs to be a prop anyway, so it can use an existing texture from a different file.

It would be better if you can download a working mod first. Lion, do you know a good mod to download?

If I'm interpreting that screenshot correctly, the file "testmod" is only a link (perhaps to a directory), but no a directory on itself. The "testmod" directory should be a directory with all added and changed files compared to the public mod.

I don't think that's a good idea. Why Spanish and not German, French, Dutch, Portuguese, Italian ... We also have a sizeable community in a lot of those languages. Adding all different languages would lead to a forum that can't be moderated, as it's hard to recognise spam in a language you don't understand. We also can't answer questions in a language we don't understand. AFAIK, we even have no programmers on the team that speak Spanish. I prefer the way it's working now. With the official forums in English (if everyone tries, I'm happy), and non-official communication can happen in all languages, but not on the forums.

We try to put all performance sensitive code in C++, which is still faster than asm.js. Certainly if you also know that the conversion of variables from regular js to asm.js costs some conversion time, just as with the conversion to C++ datatypes. Also, asm.js is meant as a compilation target, not as a language to write. Which would mean we can just as easily rewrite the performance sensitive algorithms directly in C++ rather than in some other language that has to be compiled separately to js.

That's in the civ.json file that you need to add "formations/" in front of the available formations for that civ.

I don't think using transifex for that is good. We might need to switch to a different translation service in the future (maybe something we host ourself). Also, many comments and error reports are in a language not all team members can read. Sometimes error reports are also specific to a translation, and not about the original English text. I do agree that it would be good to use the transifex comments to help with compiling such a list, but it isn't the best system to gather information.

Lets first see how it turns out without obligation