sanderd17

Ah, yeah, that needs a valid player. You've seen how an entity gets created. First, you have the Engine.CreateEntity. This calls the init functions of all components in that entity template. After that, the position is set to something valid, the player is set to something valid etc. So when executing the init function, you have no access to the player yet. But, when the player is set, the method ...OnOwnershipChanged(msg) is called on every component (see the BuildingAI for an example). The first time this happens, msg.from == -1 (-1 is the invalid player Id). When it's destroyed, msg.to == -1. So you could do the following instead: ProductionQueue.prototype.OnOwnershipChanged = function(msg) { if (msg.from != -1) return; // code to deploy units here } // Disclaimer: this code has been typed without testing, so it could contain typos or other bugs The name sounds good

There is an automated build ... in SVN: http://trac.wildfire...binaries/system But the executables aren't enough. To have the newest version of the game, you also need the data, which is only in SVN (it's the biggest part of the repo anyway), and the game won't run without it. Philip is moving the repo to git, and that change would go together with having a better autobuild tool, probably jenkins. But as it's a bit of a boring task for a programmer, it takes a while

It was discussed (and will be in A14) that farm fields should be infinite (the working on farm fields represents seeding, maintaining and harvesting). So different field types make not a lot of sense (it would clutter the GUI too IMO). You can already choose between different food resources (fruit, hunting, farming, fishing) and you can work with technologies to make one food resource faster or slower than the other. It's also discussed (and partially implemented, but not enough to get in A14) that other food resources (like berries, fruit, fish, and maybe even animals) should reproduce. So they become a valid extra resource source.

this.DeplayUnit won't exist. To access the definitions in the template, you need this.template.DeployUnit. The same for deploycount, although it's best to convert it it a number first. You do that by adding a '+' sign. So +this.template.DeployCount. Btw, AutoDeployUnit, or AutoSpawn would probably be a better name for it. And you also need to replace the {civ} string with the right name (see a bit further in the productionqueue). UI is a mess, sorry for that. Take a look to the gui/session directory. In session.xml, the panels are defined. If you search for "Gate", you should see how the panel to convert a piece of wall to a gate is defined. The panels themselves are filled in unit_commands.js. But you'll probably run into the same problems as mentioned in http://trac.wildfire...com/ticket/2084 (we should really look into getting that part of the UI fixed). To learn more about scripting, take a look at https://developer.mozilla.org. The tutorial maybe isn't the best, but it's a great reference work. And very accurate as we work with spidermonkey. Adding the interfaces makes your component callable by other parts. So components can interact with each other. But this is something specific to thist way of coding, so isn't documented outside 0AD. To call functions of a different component, you should use the interface name. var cmp = Engine.QueryInterface(entityID, IID_InterfaceName) gives you access to the component of a specific entity, so you can use all functions and attributes defined in the component for that entity. For changing the SOD and FOW, you should look to the rangeManager (in source/simulation2). I don't know what the method is, but there should be something to 'visit' a certain tile. If you have more questions, please visit #0ad-dev on Quakenet to get better explanation.

I remember seeing it somewhere, But I can't find where it's documented which civs get a bonus and which get less population. I think it should be made clear somewhere what the actual population cap will be for that civ in that game. Yes, but those also add the correct number to the population count, and it doesn't have anything to do with the maximum population.

1. Only the speed dependent things are coded in c++ for now (pathfinding, rendering, rangemanager ...), the biggest part of the logic is coded in JS (as that language is easier to write). But when you want to access JS logic in c++, you can always make a c++ interface class to the JS defined functions. Just look at the TechnologyManager, which only has an interface (ICcmpTechnologyManager), but no implementation. You can do the same with all JS components. 2. The XML files only contain the rather static things (initial health, armour and attack values ...) not the highly dynamical things (current position, current health, current action the unit is performing). So for that, we also have no XML schema. 3. There should be, but I don't know where. In any case, you can abuse RangeManager, and have an infinite range Also take a look at logs. Currently, every command a player gives is logged in commands.txt in the log directories (http://trac.wildfiregames.com/wiki/GameDataPaths). So you can use this for testing. You can also start 0AD from such a commands file, and replay the game to test if nothing changed.

supporting a gamepad you can connect to your computer won't be that hard. It's just remapping some buttons. It could already be possible by just changing config files. But supporting a different platform is a lot more difficult. Also because some of those platforms require you to buy development keys before you can develop for it. Of course, this is difficult to do when the game is free.

the code is almost finished, but as it won't be in A14, I postponed development a bit. there is still alot of work to be done for imagining new auras, and balancing them .

For both things, take a look at the Promotion component. That replaces a unit with an upgraded unit, and copies many things (like ownership, position, current and planned tasks ...) to the new one. For buildings, you could use the same I think (copying the production queue etc). And you can use some of that code to let it spawn arbitrary units. In the Garrison component, you can also see how to easy pick a good spawn position. And I believe the Init function is only called when the building is complete. Like the BuildingAI starts firing at enemies directly after the Init function. while in game it only happens when the building is complete. If you ever need to do something on the foundation, you should make that part of the template copyable to the foundation, but I'll have to research on how to do this myself. But if you're going to implement this all, I'd prefer if you split it in single functionality patches. Some of those patches could make it directly to the main game (if the code quality is good enough). But one big blob of code, with a zillion functionalities added will be too hard to review and never make it to the main game. If you keep all those patches in separate component files, I think this won't be too hard to split up.

The general plan needs to be saved (as it's following a schema: enlarging economy, building defense and then attack - or something similar). If it forgets where it was in the schema, and it starts all over. But anyway, wraitii, it should go through those first phases quite fast right. So maybe it's good to let the AI start over as it were a new game, for the time being.

Currently, the limits weren't changable, which was what you wanted. As we discussed somewhere on the forums that it would be nice to limit the population of celtic war dogs by the number of kennels instead of the general population cap (this post reminded me of that). I implemented a quick patch that would allow you to do what you want: http://trac.wildfiregames.com/ticket/2076 The patch has all code to work with kennels and war dog as you'd like with normal people.

I don't understand why you can't help implement it for 0AD. There is currently now way we "hope to implement it", just because nobody started working on it. A loyalty variable that is visible in the GUI, a bit like health is indeed something that has been discussed. Next to that, we want certain classes being able to capture certain other classes (like all soldiers can capture females, but only priests can capture soldiers). There was also a proposed difference between capturing and converting. Converting should happen automatically when the ranges and the times are right. Capturing should only happen when a command is given by the capturer.

on the Trac ticket about converrsion and capturing, I also included a patch for timer based conversion. But it's no good yet. Btw, you really want to work with Trac, as forum posts get lost in the stream. And Trac is clever enough to show all changes on top of the current code, so we see immediately what you do.

Looks like a nice addition to me. Did you test if it works? As we go in feature freeze in 5 hours, it's probably not for immediately. But it's an ideal change to read the wiki section on submitting patches, and submit this one for A15. http://trac.wildfiregames.com/wiki/SubmittingPatches

upgrading a building isn't possible currently, but we should implement that eventually anyway.

lsdh, as there doesn't seem a lot of people with a non-qwerty keyboard, could you make a documentation page on the wiki on how to change the shortkeys, what the configuration for belgian azerty on linux is etc... ? I just don't want to forget all that.

This would require some major changes for CCmpUnitMotion, or even a new CCmpUnitMotion component. It requires f.e. accelleration and turn circle. VDrift has a nice repository of cars: http://sourceforge.net/p/vdrift/code/1253/tree/vdrift-art/trunk/models/cars/ but I don't know under which license they fall. The main page says it's GPL, but that's probably the engine only.

IMO, it's basically apopulation limit, which is what houses are meant for. Which makes me think, it's too easy to teach maximum population after town phase, maybe houses should be more expensive after the town phase upgrade to slow down the boom.

starting regenerationonly after a period after the last worker left enforces micro on linear regeneration as you want to deplete asource as fast as you can, and when you let unit ai do, it doesn't work, so i strongly oppose the idea. For the different algorithms , I think real life should be followed, so sigmoid on the fish and linear on the fruit. I'd like to test it this way and see how it affects the game.

Wraitii, our main AI developer for the moment, is working on that. So it's currently not possible, but it should be possible in the near future. And even if he wouldn't be working on it, this isn't a task for someone not acquainted with the source code. So not for a newbie. I suggest you start by playing the game, so you get to know how everything works, and then you can look on trac to see what's still missing, or do your own proposals about what you want to implement. http://trac.wildfire...ayFeatureStatus http://trac.wildfiregames.com/report/1

Well, we need some better brushes too. I've made a brush that can create peaks instead of just round bumps, but it still needs testing and an icon (I can't make icons). If you're using the svn version, you can find the patch here: http://trac.wildfiregames.com/ticket/2059 but you need to compile it again.

I'm afraid it would require a re-design of about everything. Most basic components really expect that there's a square grid they can work with. So I guess nobody will bother with changing it. The 'cubes' way of working also has a disadvantage, you need far more cubes to have the same smoothness of terrain, so maps would cost more memory, the height of a piece of ground would be harder to calculate and so on. Also, currently, maps don't save height information of an object in the world. They just expect it to be "on the ground". When you have two pieces of ground above each other, that won't work. Instead of cubes, it would even be better to work with completely free meshes, and I think it would cost even less work than your cubes, while being less CPU intensive.

Yeah, I read the logs. I also said it's a lot of work, so it might have been really difficult. But it looks like you've got by with my first suggestion (working on the lobby), although I didn't know what the lobby needed in terms of features.

well, you should remove everything from /usr/share/0ad/mods/public/ except the public.zip file. Or, if that file doesn't exist, remove everything and re-install the 0ad-data package.

Can you see where it is installed? The ubuntu package has these files: http://packages.ubuntu.com/precise/all/0ad-data/filelist but I don't know where I can find it for Fedora without downloading. Maybe it's the same path. Now the /usr/share/games/0ad/mods/ directory (if the paths are the same as in Ubuntu) should ONLY contain a public directory, and that directory should ONLY contain the single file public.zip. If you see any other files or directories in there, delete them.