Leaderboard

do you mind, this post is for me, if you dont like that i add resources, dont download my mod, i dont care now stop trying to tell people what to do, excuse me if i can manage more resources then you, i am proud to do so. now please leave your criticism to yourself, if you dont like what people do, tough keep it to yourself

You are disrupting several topics with off topic comments back off stay on the topic. Enjoy the Choice

Hephaestion, it looks great! It's just as I imagined it, I just think the entrance would look better at the middle, but I liked the model a lot . As for the fort, we can use the Castle, wich would be a very versatile building, able to train cavalry, lancers (mounted and infantry), archers and heroes. The dojo is something as a "elite barracks" for swordsmen and fast hand-to-hand fighters.

I read an interesting article about pathfinding in Japanese. Let me show you their ideas. They also published about it in English, Precomputed Pathfinding for Large and Detailed Worlds on MMO Servers (Fabien Gravot, Takanori Yokoyama, Youichiro Miyake), so you can read the details from that book. They are developers of FINAL FANTASY XIV, a famous Japanese multiplayer online RPG. There are about 1,000 NPCs in a single map so they couldn't use real time pathfinding. Instead they use tables to store precomputed pathfindings. To reduce memory footprint for tables, they devide the map into grids and make hierarchal tables. The result is drastic. If a map has 20,000 locations for destination, the single table costs 1.1GB. Then dividing to 100 locations for each grid, the cost reduce to 11MB. I hope this could help.

I was wondering if we could script it to be realistic. I was thinking of adding 10 prop points, (prop-sheep00n), and making the player able to garrison 10 sheeps in the building. The hardest part would be to have only the number of garrisonned sheep showing up. Ie if you have three sheeps garrisonned, three prop points are used, and you see three sheeps. Would be nice to have that for towers too.

The GUI scripting reference might be helpful. The only feasible way to do a graph with the current system would be by using the <repeat> element with some size manipulations similar to what options.js does during initialization. That said; at best the graph drawing code would be a mess. The best solution would be a C++ extension, but if you aren't familiar with C++ this might work in the mean time.

Hi everyone, I have followed 0 A.D. for a while and after A16 release I think I have some ideas for a more realistic formation system: Currently, I find that units are moving at normal speed in formation (it is really fast because soldiers have to maintain formation while moving), they also break formation easily when engaged plus formations have not yet offered bonus in armor and attack (i think programmers are already working on it) So my suggestion is that we can employ a kind of officer unit that each individual unit can deploy and mainatin a formation (i.e testudo and Syntagma). - In these separately identified formation: units will not break formation without the death of the officer or the whole team it is also easier to give bonus on armor and attack for units in a formation: testudo guys can have superb protection against missile troops and pikemen dont have to bear unrealistically strong armor as now (pikemen are only strong in formation, individually they represent easy target - Am I right ?) I saw this feature long ago while playing Cossacks: EU wars - For those officers: they are troops of higher health, armour and attack (i.e a nice centurion for the Roman) they can have their own building and tech they can form the formation of different sizes (16, 25, 36 ... units each). Place them near the troops and the options will appear in control panel. to avoid being abused as a super strong type of stroop, I think they should be made expensive or tied with condition(s) (i.e one officer available for one barrack built) or both. This could make them strategically important. P/S: It is possible to see soldiers garrisoned onboard ships for realistic naval combat and landing ?, on the wall also. I know it is a burden for programmers but it looks cool !

Awesome find. The first time I found a topic of you via trac. Last time happened for Philips pathfinder. I like it's automatic now. I wonder why one should be able to mod MaxDistance of a trader? To get damaged ships out of service, there should be other ways than reducing the MaxDistance parameter ... thx for fixing.

According to André Pena Granha, archaeologist (http://www.estudosceltas.org/pessoais/andre-pena-granha/andre-pena-granha.html), the Lusitanians be Proto-Celts, belonging to castrexa culture, also called atlantoaxial -Western origin of the megalithic culture of Atlantic-western coast. More information: http://www.calameo.com/read/001292957c64929433ad8 Of all sorts, the Lusitanian Wars are extended from 155 to 139 before christ.

Just want to share some fun I'm having with a new group for Hannibal: Scouts. Their goal is to explore the whole map and record geographic features like water, impassable terrain, resources, shores etc. I hope I get them clever enough to detect they are on an island and build a dock + ship to continue exploring the rest of the archipelago. The concept I try to fulfil is: Bots don't cheat. However clouded the map is a bot can easily analyse any part of the map and locate the opponents head-quarter. Hannibal is not like that So here's a first result: If you look closely the dots mark a spot where the scout took a snapshot. While testing I gave the scout three points to visit. If detected idle he moves to the next and so on. Which made another group appear on my list: Patrol. Now that the grainpickers can deal with buildings and scouts with the terrain, the next group is close: miners. After that I have utilized nearly the whole API and will make progress very fast. Here the map to compare: PS: If you think now winning against Hannibal will be easy, just kill the scouts and he's blind - no chance, they reproduce in growing numbers and avoid any violence.

The part of code that finds the best path for the units when you task them to move. So not through trees or buildings, but around those. It's quite complicated as different units have different sizes (compare a soldier with a siege ram). Sometimes a small unit can fit through a gap, but a big unit can't. Then you also have the fact that there are lots of units moving at the same time. So you might have calculated a path, but when you arrive, you see it's blocked with other units. Currently, it does too many calculations when it collides with moving units. And unless you know how to program, I fear you can't help in solving the lag. We're already discussing it in several places.

Right, found it. It's an issue we had before with garrisoning, constructing, and now with trading. The point where trading can happen only depends on the target obstruction size, and not on the trader. There's an arbitrary range added (2m for traders, 10m for ships). But a ship has an obstruction radius of 8, which is (for performance reasons), calculated as an axis-aligned square of 16x16m. Thus when the ship arrives at a 45° angle (relative to the terrain grid), it can't come closer than 8*sqrt(2) ~= 11.3. So it can never reach that 10m requirement. I'll make a ticket with the patch added. Made the ticket: http://trac.wildfiregames.com/ticket/2556

I have no clue how packaging works and I am always when I see what you are doing. Just one note on the translations: Since I'm not sure what you mean by "approved+reviewed", I hope you dont mean set to "reviewed" on Transifex, because we would lose a couple of languages right now. Use whatever the i18n team has committed to SVN, all those translated strings should be good enough. If I understand correctly, they have only added the languages that have hit the 90% mark and everything has been submitted to a quick check to see that there are no problems.