sanderd17

You probably shouldn't bother with LODs, those will be most useful on entities that are used very often (like different types of trees, or rocks). Currently, we also lack any way for the user to select an attack. It would also be necessary for the charge attack. And boarding would be very hard in any case. We'd probably stick with ranged attack and ramming.

It will be theoretically faster (the JPS algorithm is a lot faster than plain A* on grids). But it will lack a lot of optimisations, which might bring the practical speed about equal to the speed of the old pathfinder. However, the optimisations needed will probably be simple things like avoiding memory copies, or recalculating stuff a bit more clever. The old pathfinder couldn't be optimised any further. Moreover, it should be consistent now. With the old pathfinder, it was possible that one part of the pathfinder believed that a unit could fit through a hole, while another part knew it didn't fit. Which caused problems like units getting stuck in obvious situations. This was especially noticeable in forests, where there are many small clearances.

I'm currently working on some engine changes so that for compatible actors (actors with the same bones), it will be easy to switch animations and props all together. So we can easily switch in the future, no matter what is chosen now.

I think no matter how it's implemented, formations to place units will make the game too slow. Perhaps it's better to include a "move" formation for all units (even females). When tasked to a point (rather than a target), units will go in that move formation (probably a 16:9 rectangle, as that's a very natural-looking ratio). When they are tasked to a target, that target can be economical (buidling, gathering, ...) and then they don't use a formation (or perhaps check the distance to see if a formation would be useful). And when tasked to attack, I'd keep special formations as an option for certain civilisations / unit types. Then loose units should fight a formation like they fight a building, deal damage to the formation, and the formation should distribute it logically over its members. So perhaps we first need to focus on the "move" formation, make sure that long walks are fluent, and the distinction between targets., before we focus on battle dynamics of a formation.

Apparently, there are some fan-made games, but these are only based on the novel. The games that use design or music from the TV series apparently have a license from HBO: http://en.wikipedia.org/wiki/Works_based_on_A_Song_of_Ice_and_Fire#Video_games So if you make a mod, it should probably follow the same rules and not include elements of the TV series.

The cheering animations were the first ones I tries. But no matter what animation + prop combo used, it looked very weird.

Should be fixed now.

Using Gaia doesn't work right now, but making them work wouldn't be very hard. And if you do that (and test) I think it would be a nice addition to the main game too.

For future readers, apparently it's related to http://trac.wildfiregames.com/ticket/3072#comment:15 On that issue, it's explained that the problem only happens occasionaly in the summary screen.

Note that "Capture Attack" is not an alternative to Hack, Pierce or Crush, but it's an alternative to "Ranged Attack", "Melee Attack", "Slaughter Attack" and "Charge Attack". However, the stats of the Capture Attack are more simple than the stats of other attacks, because I didn't need those differentiating stats AFAICS, and simple stats make balancing simple. For me, the objective of the Capture Attack was that units wouldn't do their normal attack actions against buildings. They won't shoot arrows at a building, and they won't hack it with a sword. So their regular attack stats don't count. Units never try to demolish a building, but they try tot make it theirs. That's why my original patch had the regular attack of units against buildings disabled. The capture attack is a complete replacement of the regular attack, so it must look like an attack, and the player must use the same commands. As for how to display it. There was the option to let units go inside the building (like garrisoning), and reduce Capture points that way. But this would make capturing a bit dull. Units inside buildings can't be attacked from outside anymore. If the attack capacity is limited (like the garrison capacity is), then either the defender or the attacker can always win. With the current case, of keeping units outside, the defender and the attacker have to react to each others choices. As it's a complete replacement attack against, I looked for attacks that were like physically attacking the structure. Using ladders, a piece of wood to ram a door, ... But due to lack of existing animations and suited props, some pitchfork animation was the closest I could find. But it starts to look like I'm the only one with this idea.

The problem is that Ubuntu grabs the alt+click combo, so it doesn't reach atlas. This is actually a problem with ubuntu, as no os should grab the alt+click combo. I think there should be a setting somewhere to configure these hotkeys. If you can't find it, it might be easiest to open the map.xml file with a regular text editor, do a search for "actor", and delete those actor entities (do make a backup of your map first).

Yes, we will include the new pathfinder soon, but the new pathfinder will have more bugs and hiccups than the old one. Like a few days ago, we saw that games with the AI had lag spikes of turns that took around 300ms (while singleplayer turns should be completed in 200ms of calculation) every time a building was constructed. The structure of the new pathfinder is better, so it can be used to allow faster code in other places. But the new pathfinder itself isn't optimised or bug-free yet.

A bit of delay is normal. In a multiplayer game, every turn lasts 0.5s. During that time, players can send commands to the host. Then at the start of a new turn, the host distributes the commands to all players. So taking around 0.5s to see a reaction is normal. If you have more delay, it's either because the network is slow (which is not that likely on a LAN), or (more likely) that the calculation of the simulation state takes longer than the give 0.5s. I assume you want to play for fun, so you want to stick with a stable version. But if you guys would be willing to cope with a few bugs (sometimes minor bugs, sometimes major crashes), you could also test the development version (http://trac.wildfiregames.com/wiki/BuildInstructions). But as that requires you to install it on every computer, and update it for every game, and usually makes games less fun due to bugs, I would understand if you don't want to do this. But it would be a great help if you could test it (certainly after we committed the new pathfinder in the next weeks).

You know saved games are not supported across updates. You should save load a saved game with exactly the same version as you saved it with.

Well, I can't reproduce it. I tried adding a Health RegenRate to the CC, attacked it with a ram and some soldiers (to reduce both the CP and Health), but only the health regenerated.

When did you experience this problem? At the start of a game? Or when doing some action?

It's sad to see you go. As a programmer, I found it great to see what you could do with our code. Especially as the code is still made mainly with 0 A.D. in mind, and not with futuristic or fantasy renderings. Showing what other stuff can be done with code is both a motivation and a test. I'd prefer to see renderings done with our engine of course, but I have nothing against people showing their work. So that's fine for me (though starting a new thread in the off-topic section might be better for that purpose, as it's not related to the engine any more).

I doubt that. According to Wikipedia So I think ships would need to be a lot bigger to fit 200 of our oversized units. If you'd try to fit a believable number of units on the ship, then the ship would be massive. I still think that it would be best to have simple animated models on the deck, where the size of these units is a compromise between the ship size and the unit size (note that for an attack animation, you can have some units stand up and shoot an arrow). Similar to how doors and windows are a compromise between the building and the unit size.

The Roman faction used in game are indeed the Republican Romans: http://trac.wildfiregames.com/wiki/Civ%3A_Romans_Republican. Part I of 0 A.D. will only cover civilisations between 500 B.C. and 1 B.C.

Making bigger ships will be hard, as it would also need bigger maps to work well (ships already get stuck very often). And bigger maps means heavier for the computer, so more lag (longer paths to search, more stuff to render, ...). They indeed look a bit empty now, and it would probably be better to have units on board, but it won't work well with real units. Real units are scaled up to make them easily selectable between buildings and trees, so they are too big for ships. It would be better to make a model with a few (small) units that are animated and row. Your model looks very nice though.

As you have an integraded grahpics card, there's not a lot we can do to speed up the rendering. Most users complain about CPU calculation speed, which can indeed be improved a lot (or so we hope). But rendering can only be marginally improved. Transferring differences still requires players to start with the same state. If the state deviates at some point, all subsequent states will be different. So it's just the same as only sending the commands. Wrt the pathfinding. Most things you say are already implemented, or don't work. Caching paths is no option, too many paths are calculated, and obstructions change too often (think about units moving, buildings build and trees cut down). The long-paths calculated are already static, they're only calculated once, without taking units into account. Then the short paths are calculated between long-path waypoints. The short paths have to be calculated on the fly, as they also take other units into account. There's no guarantee that a local circumvention will result in a valid path. It's perfectly possible that you get in a dead-end path. So you need to re-evaluate the entire path (at least between two valid points) to guarantee a valid path. Formations already only calculate one long path, and units do short paths to their new formation position (which is most often a straight line). Crossing formations indeed aren't taken into account, but this doesn't happen that often.

The correct link is https://kiwiirc.com/client/irc.quakenet.org/0ad-dev

@DarkReaver: Strong buildings are indeed stronger. Small buildings (houses, dropsites) have currently 300 cp, regular buildings have 1000 cp, and the fortress and CC have something like 3000 or 4000 cp. So capturing a small building is easy, but not of big use either. There's no difference between units yet. As I'd first like to see what these initial stats do. Currently, all units take 3 cp/second. @wowgetoffyourcellphone: Well, we wanted some physical animation, as the cheer animations didn't look too good for this purpose IMO. I was actually looking for some ramming animation with a club or a piece of wood. But I couldn't find anything that suited. Hence the fork.

@Karamel, you can attack buildings by using the attack hotkey (which is rather inconveniently set to the default CTRL+ALT+Right_Click). @zippy: not when the attack starts, but when the attacker is halfway. In regular attacks, first the attacker will gain momentum, as it takes a while for the defender to see what the attacker is doing, and go defending the right building. But as the attack goes on, attacking units get killed by the fire from the building they attack, or by defending units. While defending units stay rather safe in their buildings. So it's perfectly possible (and even likely) that the attacker first brings the amount of capture points to about halfway, and still isn't able to capture the building. As such, deleting your own building, when you still have a pretty big chance to keep it, would be a shame. Of course, that being "halfway" is just an estimation of where the odds turn. If playtesting reveals other estimations, we don't have to stick with the halfway boundary.

Entities can be made undestroyable without a problem. Next to that, there's still the herding food source, and traders provide an infinite source of everything.