sanderd17

Well, it still looks viable to me. You can start with small tasks to get to know the engine. Like changing the way resource gathering works. This would teach you some things about how writing simulation components works, and how to get that info into the GUI. And later on, continue working on the resources to f.e. store resources per depot. Other things are of course difficult. We also want big maps (in some cases), but there's a reason we don't have them.

That's for two reasons: 1. Overshooting a balance task. Quite often, a balancer focuses on something that's OP or UP, and fixes that, but goes too far with it, and doesn't have time to investigate new strategies (that should still work, but that shouldn't always work). 2. Adding new features. Every feature added and even some bug fixes (like fixing the infinite chase issue) severely changes the balancing of the game. A19 won't be balanced very well either, as building capturing is completely new (and that determines gameplay for a big deal). It's hard for us to come up with a lot of new strategies, and compare them to each other to see which ones are OP or UP.

You can control domestic animals that you own (and you can own them via known cheat codes). Even some defensive animals (like elephants) can be controlled. Completely wild animals can't be controlled indeed.

Sorry, it's fixed now.

I have a feeling this thread isn't really about the gui bug anymore. But to answer your question: nothing. Only the auras that have defined stats in their description are implemented. For the others, we lack either inspiration on what stat should change, or we lack code on how to do what we want. F.e. the guerilla tactic could mean that units are hidden in the woods, but we don't have code to hide individual units yet.

We wouldn't be able to buy a lot, and I don't think players would actually benefit from it. Players would benefit more if someone could actually work long-term on some difficult part of the code.

Sorry, should be fixed now

The VFS is pretty simple. Mods have a loading order, and it takes the file that's available in the mod with the highest order. So you can overwrite any file in the public mod with your own content. Now, you can also combine this with the advantages of JS. In JS, classes are made of prototypes, and you can alter the prototypes at any point. So in your mod, you can make a file that's loaded after some existing component, and just modifies some small parts of the prototype. That way, when multiple mods are loaded, they even can all add their own custom part to the prototype, with less chance on conflicts. Or when we change stuff in our game, there's more chance that you won't notice a problem. Files are loaded alphabetically, so it's perfectly possible to predict which file is loaded first. As for the maximum size of the maps. There's certainly a maximum (by the data types we use), though I haven't seen a computer with hardware that was strong enough to load a map of our maximum size. 1 pixel translates to one vertex (the node between 4 tiles). When you have many entities, you will always have more lag, since you need to loop over all entities to determine certain things (like does it need to be rendered, does it still exist, ...). That looping costs time.

Game balance changes from version to version. In A16, the only way to win was by going for a rush, and the first one to rush his opponent won. That was even worse than the current situation, since successful rushes meant that nobody ever reached town phase, and thus a vast amount of artwork was never seen. Over-compensating isn't that strange, and we tend to go towards an equilibrium I think (as far as no new features are added, like capturing).

If you can formalise your requests (f.e. a storehouse should automatically gather a tickle of wood for every tree near it), then we can help you. It's best to focus on one thing at a time, so you can take some time to investigate in it, and find the best way to code it. Btw, larger maps are certainly possible. Take a look at the Eire and Albion demo map for example. It has no resources and only one ground texture, but the map itself is pretty huge. You can create such maps from modified random map scripts, or by importing heightmap images.

The best donations you can make is actually donating your time. You can try to fix bugs or annoyances you see (be it in the graphics or in the code), or even go further and make new stuff (again, either graphics or code). Money donations are welcome, though of less value. We would need a lot of money to actually hire someone, and only hiring a single person usually involves a lot of paper work, so we tend to lose more time than we win. We also need money for some resources (like the server hosting some stuff), though that's just maintaining a pretty fast computer with a good internet connection. So not that expensive either.

Currently, that doesn't even use the pathfinder. So it will not be an immediate result. But if the pathfinder is fast enough, and we can call it for every arrow, it might be possible. It won't be a priority though.

Yeah, units indeed shouldn't get trapped when spawned. Lets hope the next pathfinder makes this possible to a certain extent. Rotating buildings is possible by holding down the mouse, and dragging to select the angle. You can also use the [ and ] keys to rotate in jumps of 15 degrees.

Not all fortress models and defense tower models are equipped for this. And I'd rather invest artistic and programming resources in other work. It seems like a lot of work for little gain, and maybe even end-user confusion. Some champion or elite iberian cavalry already shoots flaming javelins. And some catapults shoot flaming rocks. So that's already implemented (note however that the advanced and elite units are currently disabled, to focus on good balancing for the basic units). All quinqueremes should be garrisoned with ballistas or catapults to increase fire power. So the Romans, Carthagians and Ptolemies already have this. Could be done via capturing. Though the stats will be hard to work out. It is already possible to build walls in shallow water (as long as your units can reach it). But sadly, the ungarrison code searches for the nearest passable position to spawn units. So this might mean that enemy units will spawn on the inside of your walls. It's not very easy to fix this. Remember that the timeframe of 0 A.D. part I, is between 500 BC and 1 BC. There's also a part II planned, to span from 1 A.D. to 500 A.D. But nobody started working on part II yet (we have enough work with part I first). All civilisations in 0 A.D. are also modeled after the point in history where that civilisation reached its top. So also if a civilisation existed in the given timeframe, but it didn't reach its high point in the timeframe, then the civ doesn't belong in 0 A.D. Furthermore, we also focus on civilisations from the Mediterranean, or from civilisations who came into contact with Mediterranean civs. The high point of Phoenicia was between 1200 BC and 800 BC. So well before the timeframe of 0 A.D. Besides, the Carthagians are included, and they're direct descendants of the Phoenicians. The Isrealites were also before the timeframe. Huns on the other hand, only rose after 1 A.D., so they're completely after the 0 A.D. timeframe. And Goths existed in the timeframe, but weren't very important. Their high point was at the fall of the Roman Empire. So a lot later than our timeframe.

I believe the string comes from the i18n library. I also see the full name, so I think that the library used in your case is outdated in some way. Do you use the windows autobuilder? That's normal, it's the name of the language as they write it in that language. Some languages use capitals to name a language (like English), others don't (like French in French is "français").

I tried it, and it works. Though it's indeed decaying fast. You're sure it didn't hit 0 and turned to gaia at some point?

Ok, seems like the general concensus is that people also want to destroy buildings. I'll try to bind a CTRL+right_click action to the default attack without breaking the AI too much, or the default UnitAI handling. @Lion: Capturing is just a different attack form. So you should get the normal attack message for it (though I notice that doesn't work currently). Gaia buildings have always been like that, but of course, we didn't have that many gaia buildings on maps before. It's perfectly possible to limit gaia buildings from firing arrows. It all depends on the structure. I just transitioned the decay from a Health to a Capture decay, while keeping the original stats. Most buildings lose 5 CP per second, so with every unit taking 3 CP per second, you can maintain that building with 2 units. The outposts decay 2 CP per second, or 1 CP per second after the technology research. So you can maintain it with one unit. The army camp was indeed defined to lose 10 CP per second, so you need at least 4 units to maintain a full bar. I can't reproduce the garrisoning issue. In my case, units can still garrison as long as the owner is an ally (which is shown by the player colour on the banner of the selection pane).

You should also make a skeleton.xml file for your animation. The skeleton file makes it possible to reuse the same animation on multiple models (so you can have multiple human models without having to redo the animation work). Here's how you can create that skeleton.xml: If you open the DAE file with a text editor (like notepad on Windows, or better, notepad++), you can search for the text "Armature". In your file, you bump into the armature at line 169. There you have an armature called "Armature", inside it, a joint called "Joint1", and inside that joint, another joint called "Joint2". I don't know if it's possible in your editor, but giving more descriptive names would help I think. Then you copy that hierarchy to a skeleton like you can see in this directory: http://trac.wildfiregames.com/browser/ps/trunk/binaries/data/mods/public/art/skeletons/ In your case, it should probably look like <skeletons> <standard_skeleton title="Custom Armature" id="my_armature"> <bone name="Joint1"> <bone name="Joint2"></bone> </bone> </standard_skeleton> <skeleton title="Custom Armature" target="my_armature"> <identifier> <root>Armature</root> </identifier> <bone name="Joint1"><target>Joint1</target> <bone name="Joint2"><target>Joint2</target></bone> </bone> </skeleton></skeletons>Do watch out that your root name (in this case, the rather generic name "Armature" needs to be unique for your animation set (you can't have two skeleton definitions with the same root name). So choosing "Armature" as root name isn't the best option.If that doesn't work, please tell us which skeleton you created.

Maybe a silly question, but we still have old PSA animations around (like around here: http://trac.wildfiregames.com/browser/ps/trunk/binaries/data/mods/public/art/animation/biped ). They seem to work with the engine, so perhaps you can export to that. Otherwise, all artists work with blender AFAIK, so to get better help, you should probably try to get those animations ported to blender as a start. Btw, I'm still waiting for you on IRC about some coding questions.

Nice start, but I would add some height differences in the roof. Making the "gate", the sides and the back all equally flat gives, indeed, a flat expression. I also don't know if there are examples of flat roofs resting on pillars in the hellenistic architecture. So you might want to prolong the triangular roof of the sides, or make the triangular roof over the front wider.

Please keep your posts on topic next time. I split off the posts about the marian reforms to a new thread.

The looks should indeed be improved. However, I don't think other players should be able to alter settings . That would cause problems with trolls dropping by. Improved chat (in the game and in the game setup) is also needed indeed. That's one of the main features of the game. Most soldiers in those days weren't professional soldiers, but only part-time. So they can do all economic tasks, just like citizens, but on some tasks (especially food-related), they're slower than women. There are also soldiers that can't do economic tasks, namely the champions. Didn't really understand this message. Actually, ranking was implemented in the past, but there were issues with it. So it's disabled again (it's just a test version, you know).

It's a gui bug, you need to press ENTER after changing each number (to confirm that field). Hope it works now.

If you protect your computer that's enough protection Our network model is made so that only the player commands are send. From those commands, a deterministic game state is made, and every few turns, the states of the different players are compared. Thus the state of other computers can't be altered directly from the network, but only by commands which are validated locally. And as a result, modifying the game state on other computers is practically impossible. Though having "unintended cheats" (valid commands that aren't meant to be valid) is always possible, it can be fixed quickly when we notice one. The only thing we can't prevent however, is data leaking. Since the entire game state is on the computer, and all data can be read without any part of the game noticing it, the game can be visualised completely, even when some parts should be fogged or otherwise unknown.

There's a setting for that in the gamesetup, under "more options". But I think cheats are disabled by default in multiplayer games. No, rams have the same lag. But you may have problems with your units trying to regroup in formation. Then they sometimes run back to the main group, which may be an issue if the main group is stuck after some obstacle. You may want to put your units in "no formation" mode to prevent this from happening. Apart from that, rams do indeed a lot of damage against buildings, so once a ram reaches a building, it's already too late. I think that's intentional. There were players postponing their loss by building roman siege walls everywhere, and just garrisoning units in them at random places. Now that the walls decay, such a strategy isn't possible anymore (or at least harder) Phase III is the phase that allows you to actually bring down cities. So the phase that gives you siege weaponry. If the army camps become available before that, they should have disabled siege units while in phase II at least. But I think army camps in phase II would be overpowered, as players don't have the means to bring down a building while they're in phase II. Ranks are disabled for now, to help with balancing. But this depends on how much stronger that higher-rank units actually are. If they're marginally stronger, it doesn't make sense to alter the gui for them. If the difference is big, that info might indeed be important. This doesn't sound so difficult, so if you can program a few lines, and want to help out, it's a good place to start I guess. That count is hard to explain, and can even depend on the structure. For now, AFAIK, all infantry and also ranged cavalry increases the arrow count by a constant, and buildings also have a default arrow count. If you select a building, you can hoover the "attack" icon (the sword and shield in the middle of the selection pane), there you can see how many arrows are fired per time, and how strong the arrows are. The tooltip is updated when you garrison or ungarrison units. So with a bit of trial and error, you can find out a lot. Thanks