sanderd17

It's a bit a messy thread to pin (with the most important messages in the middle). If Gallaecio wants to start a new thread on how to translate the software (with that link and some explanation), I think pinning would indeed be good.

The terrain alteration should be selectable per building. Some buildings might want perfectly flat ground. Others might want a straightened ground (but not brought horizontal), and there can be special cases, like we could use for the slope walls, or maybe stuff like trenches (for WWI games or in front of a siege wall). Next to that, it should be graphical only, and not influence pathfinding. And finally, it should be reversible (if you destroy the building, the terrain is also restored). But I believe Philip has that covered. And sorry for going off topic like this. If we want to continue this discussion, we should probably use a new thread. Although I don't know what's to discuss when nobody studied the code.

Not that I know. If you have a link, throw it in. Updating to work with the current game really isn't a lot of work. I only found this demo: http://www.moddb.com/mods/rote/downloads That only has the barracks and some infantry. None of the other buildings that are found in the screenshots.

Fixing it to work with the current code is only a small bit of work, as they didn't add any real code (only art and some statistics). The main problem is that their progress this far isn't public.

As a mod can change about everything (even the GUI). So adding a GUI to the public mod to choose mods might be a bit weird, as the mod you chose can decide to not have that GUI Also, changing the mods would most likely require a full reload, because you can change almost everything.

As the terrain restoring problem happens in all cases (also when you just place a building that simply requires flat terrain), it should be solved right away. And judging from the demo, it is solved. But remember it's only a demo implementation, and Philip is rather busy now, so it could take a while before someone continues it.

Ah, ok. We already have another application going for sound lead: http://www.wildfiregames.com/forum/index.php?showtopic=17491 But it looks like Tim is a bit busy, and doesn't have a lot of time for the project. Someone of the art team should come to you soon to give you some kind of test. You can read the other thread to see what Tim had to do, and what the comments were.

It looks like you're more applying for music lead instead of sound lead (sounds are things like selection sound, destruction sound ...) while music is the background music. We plan to separate those two more, as they don't require the same skills. We have an active music lead already (Omri Lahav), so you'll have to discuss with him what you can do, or in what ways you can help. I'll point him to this thread.

Very nice. Maybe you could ring more action in it by bringing the head closer to the camera, and the body further away (which happens when you sling real hard). His face also looks a bit sad instead of aggressive to me, but I don't think that will matter on icon size.

lol

Walkable meshes aren't planned for part 1. Although I see a way around it for the gallic walls. Philip has made a prototype where a building alters the terrain. This could be altered to make is slope the terrain instead of flatten it. With a model and obstruction on the sharp side of the wall, and maybe a decal on the rest. I think it would be very nice. For walkable meshes. You'd need a way to pass extra tiles to the pathfinder (like saying tile[i,j] is connected to the north with some tile not in the grid). So the pathfinder can keep searching from that. Once that's possible, there should be no problem with JPS, as JPS can handle non-flat graphs as far as I see. It only needs a uniform cost. Letting the pathfinder check for tiles not in the grid could slow it down a bit though. As it won't be enough to check passability of tile[i+1,j], but it needs to query first if there are no others connected.

Some "guarding" is planned (and a patch is on the way). So I think it could be used for healers too. Guarding means that a unit will always follow an other unit in a certain range. And normally, attack enemies that come into his vision range. In that way, healers could guard a certain unit, but heal that unit when he's damaged instead.

If you have no specific knowledge, best might be to start with gameplay logic. This is quite easy if you know the game. Every entity (unit, building, plant, mine ...) has a template (in binaries/data/mods/public/simulation/templates). That template consists out of components that describe the behaviour and statistics (a health component, an armour component ...). When you want to fix something in gameplay, you search the right component to edit, and edit the code for that. Note that performance critical components are defined in C++, while other components are in JS. Also look for the easy tickets in trac: http://trac.wildfiregames.com/report/16

You should get the original meshes from svn. You can download one by one via your web browser http://trac.wildfiregames.com/browser or download the complete svn at once.

For me, there are two ways of upgrading a building. One is via a technology (like upgrading a CC when you phase up). The other is via a button for individual upgrades (like army camp to fortress or CC). The individual upgrade would indeed need some work. It would probably need to cooperate with the productionqueue to show the elapsed time etc. It needs a way to define the cost, the time, the icon ... To differentiate it in XML, I'd use something like <Upgrade> <Entity>templateName</Entity> <TechPhase>2</TechPhase> </Upgrade> Or <Upgrade> <Entity>templateName</Entity> <Button> <Time>25</Time> <Icon>blabla.png</Icon> ... </Button> </Upgrade> Some of the button child nodes should be optional, and fetched from the entity template when undefined. But I'd think you want to edit some of those, so they should be definable too. Now, as the technology upgrade is easier, I'd start with that. What you need for that is listening to the TechnologyModification message. When a technology enlarges the TechPhase of a certain building (like the town phase technology can add one to the TechPhase of civil centres), you upgrade the buildings. The code should look something like Upgrade.prototype.OnTechnologyModification = function(msg) { if (msg.component != Upgrade) return; var techPhase = ApplyTechModificationsToEntity("Upgrade/TechPhase", 1, this.entity); if (this.techPhase < techPhase) this.UpgradeStructure(); };

You can also use a download helper, like the DownThemAll Firefox extension. That allows resuming download of arbitrary files.

Does this happen every time? Does it happen with maps included in the game too, or only with your map? In the latter case, can you upload your map? Also, can you provide more logs? See http://trac.wildfiregames.com/wiki/GameDataPaths

Similar to the garrison-to-heal thing (the buffHeal tag in GarrissonHolder). It couls have a BuffExperience. I wouldn't be too difficult to add it, so if anyone feels like doing it, you can give it a try.

Well, in that case, open a ticket, and place your code there. I want to see what you've done. For that, I need a diff file (so I can exactly see what lines you modified). But if you modified every line (by using spaces as in the code here), I can't review it.

What's this?

We should just implement it and be done with it I can make a "wonder" victory condition, it wouldn't be a lot of work. I just need to know in which cases there is a victory (like what when you have killed all enemies, but didn't build a wonder?)

The game is very moddable (in fact, almost everything is moddable). You should just take into account what amount of work you'd need for something. Of course, you need all-new art (models, animations, textures, sound ...). After that, you need to search similarities. There's not a lot of difference between an archer and someone with a musket (they aim, shoot and hit or miss). Or between rockets and ballistas. You will probably have problems with fast-moving vehicles though. That's something that isn't implemented yet. Car's aren't supposed to stop immediately, and have a turning circle.Those are things that would require major modifications. Luckily for you, we also need parts of that (like turn circles for ships).

Well, it's just easier to start balancing when you start with everything the same, and then bring in the differences. Though I think the ram health isn't meant to be higher. I thought all rams would have the same health for now.

Currently, wonders are useless, so it's better to not build them. A fortress ads just as much grounds, while it's cheaper, smaller (except for Carthage) and more functional. We indeed plan to have wonders as a victory condition.

First some little mistakes in your report, and things that are in the pipeling: On dogs, I'd want a dog specific limit, that's determined by the number of kennels (like you get 10 dogs per kennel). This is doable (I have a patch), but I don't know if the rest of the team wants that. About your statistics, it looks like celtic rams have more hp than Roman or Iberian ones, while the same armour and attack values. And celtic spearmen have about the same statistics as hoplites. For the random rotation, this isn't really possible, as the obstruction is still square. So rotation does matter. I disagree about the celts being better armed though. In the early timeframe of the game, armies were mainly composed out of elite troops (the swordmen you see), while in the later age, armies were bigger, and mainly consisted out of lightly armoured spearmen. http://en.wikipedia.org/wiki/Celtic_warfare That said, I like to see statistical results from lobby rankings to see which civs lose against other. Instead of just guessing. Of course, it all depends on the play style. IMO, every civ should have its weak spot (like the celts are very weak against to Romans, but quite good against the Iberians), but every civ should also have its equal.