sanderd17

You need to enable it in the settings: http://trac.wildfiregames.com/wiki/Manual_Settings

I guess we can close the "how women look" topic, and get back on track with the original post.

All animations, the boar related ones are last changed 2 years ago: http://trac.wildfiregames.com/browser/ps/trunk/binaries/data/mods/public/art/animation/quadraped The boar actor: http://trac.wildfiregames.com/browser/ps/trunk/binaries/data/mods/public/art/actors/fauna/boar.xml The skeleton: http://trac.wildfiregames.com/browser/ps/trunk/binaries/data/mods/public/art/skeletons/boar.xml And the model: http://trac.wildfiregames.com/browser/ps/trunk/binaries/data/mods/public/art/meshes/skeletal/boar.dae I see nothing changed since A15.

In short, adding behaviour isn't easy, else we would have done it too. If you get one of the things working, be sure to tell it to us, it can become part of the official game.

Can you try if it also happens without your mod? It looks like something related to your installation.

Did this happen only once? I can load random maps without problems as the viking faction.

The tower must show that it doesn't cause any territory when the CC isn't close enough. So yes, it could represent the army camp, or an outpost where another CC build around. The main limitation of the "not causing territory changes" is that you don't see territory blinking anymore. So we'd probably need an other visualisation for decaying buildings.

Currently, we have a single decay. I propose to have a possibility to have multiple decays, where it would be possible that f.e. you still can't build in allied territory, but if an allied CC is placed next to yours, and it cuts off some buildings, your buildings don't start to decay. Also, a possibility to let f.e. the Roman army camp decay faster when in enemy territory, and slower when in neutral territory (but still decay).

Can you upload the mod?

"Overwriting" is just a way to explain it. In fact, the virtual file system takes the file that exists in the mod with the highest priority. The default "public" mod has the lowest priority, so if you also define the athen.json file f.e. in your mod, the VFS will read that file, and not the file from the main game.

https://en.wikipedia.org/wiki/Celts#Gender_and_sexual_norms They had at least more power than Roman women.

A mod can only overwrite files that are in the public mod. And a civ is defined by its json file. So in any case, you need to overwrite the json file to disable the civ. Either that's possible with just overwriting it with an empty file, or you could set that flag.

I mean more flexible from a code POV. In a sense that we could differentiate between ally territory and enemy territory without adding a bazillion lines of code. For now, almost every building is always on "own" territory. It just sometimes happens the "own" territory is not connected, (see first screenshot). Calculating in which territory the tower would have been if the tower wouldn't be there is tedious. If you have to do it for every building, the lag will become even bigger again. While in the last screenshot, we can immediately see that the tower (owned by blue) is on green territory. So we can either let it decay or not, or change the amount, depending on how friendly green is to us (neutral, ally, enemy, mutual ally ...).

But Territories are only calculated when they change (every time a building is added or removed), so you can't expect too much performance improvement. But given I didn't add any code, only removed stuff and placed stuff out of the loop, it will be a bit faster. Performance isn't the main goal here. The main goal is that the scripting side should just be able to query the territory a building is on, and shouldn't bother with connectedness. Edit: these are the (not cleaned up) changes I did: http://pastebin.com/Z1b2VehK To clean it up, I should also remove the connectedness methods and stuff.

Currently, the territory is a bit complicated. Mainly from a code point of view. There's a territory owner and a "connectedness" to a root. If your territory isn't connected, it's hard to find out, from a code POV, why it isn't. Because it's too far anyway, because an ally or an enemy build a CC too close, because your CC was destroyed,..? Current ambiguous possibility: Current non-ambiguous possibility: We can't have separate decay values for when f.e. an ally caused the unconnectedness, because we can't detect that. So I propose a simplification: Only root entities (CCs) cause territory. When you place something in a neutral zone, and it isn't a root entity, no territory will appearOther entities can still enlarge the territoryThis way, we can very easily query the owner of a tile, and compare if it's an ally, an enemy, gaia ... And change the behaviour accordingly. I'd also want to remove the "weight" concept from territory. When you just use the radius as weight, it becomes a lot more intuitive IMO. And it allows you to calculate territory faster (currently, a floodfill algorithm is executed for every entity, while you could reduce it to one floodfill per player if you don't use weights). Future possibilities: I have code ready that does this behaviour, the code is a lot more simple than the old code, and it's more flexible gameplay-wise.

It's a bit related to FF versioning. Until FF4, they had lots of sub versions, just as the JS engine had. From FF4 onwards, they released a new FF version every few weeks, this included a new spidermonkey version too. Every now and then, there's a long-term release. v24 is such a long term release, and the next one will be v31. We will probably try to keep using the latest long-term release after v24 is in.

General discussion (i.e. not related to a specific code change) is best kept on the forums. Trac is more for .. keeping track of stuff. I don't know exactly what you want to do. But if you will work on optimisation, you'll have to make sure your code is really better than the existing code, show it with a game replay, some profiling,...

I never had that unwanted movement option when I want to type something (except in Atlas). For team chat, you can just press 'T' instead of 'Enter', as explained in the "Learn to play" manual. The box won't become the default formation, but behaviour should be a fair bit better now. The guys in formation should run around less than before, and the rotation your new formation will have should be more predictable. Letting groups join has also changed. They're now clustered per distance. If a group of units is too far away, it will just form a formation on itself, and move to the target. The cutoff is currently 60m. Which is an average vision range. And you're right that we should show a lot less info on the explored but not visible territories. Not only new buildings, but also stats like building health, attack/armour values ...

That's mainly because of the total number of polygons. When you just replace a texture, it doesn't make any difference. The polygon was going to be rendered anyway. Next to that, we also do quite a lot on the CPU. Like calculating the position of every entity before rendering, distance-sorting some of the entities, calculating the prop positions ...

It's not really about the effect of closed walls. If walls are used like they are supposed to be used, there's no problem. The real problem arises from people who only want the wall towers, and use them as defense towers instead. They don't have a minimum range (and it's hard to give one without limiting the length of walls), they shouldn't be attackable by regular soldiers, they have a bigger armour, they cost less, ... The plan is to, in some way, bonus the usage of walls like they should be used. With suggestions s.a. non-shooting connectors when you're not using long wall pieces, not letting towers stand allone, ...

I think they still want a structure to hide the seems (a connector), but it should be garissonable, or shoot arrows. I think having two sorts of towers (one real tower, and one mere connector) would be possible.

Extra textures won't make the game a lot slower. It will only slow down the first time the texture is used (so on the first dead), and it will use a bit more memory (but we're not really having memory problems either).

I can't reproduce this. When I kill boudicca, the stats are back to the original values.

Ah yes, Atlas has some graphics that are always disabled.

Did you enable advanced graphics?