kanetaka

Yes, the formation is also the factor and you know that is one of the performance killer. I am not familiar with the formation code, but a single turn consists of something like follows: Independent units move Formation leaders move Formation followers move Yes that sounds practical. I have never known executor pattern. You have more knowledge about multi thread than me.

I think giving threads to each pathfinding calculation for single unit is effective. The pathfinding calculation depends on previous turn, but doesn't depend on other units on-going movement. And some path results takes much longer.

Do you want to say arrows and fish are too small so they are hard to find?

Yes, it could be. The long path finder knows they have to detour, but the short path finder has a fixed sight range and when the units get close to the goal, they switch path finder from long one to short one then they forget to detour. You can set way points to work around by shift crick.

Now I replayed it and took the profile. Let's take a look. The replay was took on Windows 8.1, Core i3 1.8GHz, RAM 4GB. X axis plots 1 / 20 number of turns and Y axis plots milliseconds per frame. In ideal situation, one turn equals 200ms in single play and one frame equals 16.7ms at 60 Hz frame rate. Thus 34:50(2090sec) should be Turn 8320, which equals 416 in X axis. The total never exceeded 200 ms, but this is a replay so it doesn't include any graphics at all. On my machine, the total almost always exceeds 16.7ms, means I can't expect 60 FPS anytime. At 416, I can't find any prominent peaks. I guess there were temporal lags before 34:50 so actual 34:50 was somewhat earlier. At 379, FindEconomicCCLocation stands up to 97.98ms and ComputePath makes plateau from 384 to 392. From these heavy load the total constantly exceeds 100ms so I conclude 34:50 was around 379. Maybe total simulation update should not exceed 100ms per turn. http://trac.wildfiregames.com/wiki/EngineProfiling maleg's_profile.txt

Hi maleg. Thank you for reporting. I am also concerned about lag from path finding problem. You can find commands.txt by date and time you played. Open C:\Users\your_account_name\AppData\Local\0ad\logs\sim_log and you will see many folders but the timestamps are the end of games so you can distinguish them easily. And you can open those files by text editor and you can read map names and match settings etc. like following: start {"mapType":"skirmish","map":"maps/skirmishes/Acropolis Bay (2)","settings":{"CircularMap":true,"Description":"Each player starts the match atop a large flat plateau, otherwise known as an acropolis.\n\nTo the East lies a large bay with fishing opportunities. To the West is a rugged hinterland with an unclaimed acropolis commanding the valley below.","GameType":"conquest","Keywords":[],"LockTeams":false,"Name":"Acropolis Bay (2)","PlayerData":[{"Name":"Player 1","AI":"petra","AIDiff":3},{"Name":"Player 2","AI":"petra","AIDiff":3}],"Preview":"acropolis_bay.png","RevealMap":false,"mapType":"skirmish","AISeed":0}}turn 0 200With commands.txt we can replay the game and it would help the development . But multi player games are hard to replay for me, so single player games are appropriated.

Japanese and Chinese(Taiwan) Language MODs for Alpha 18 are also available. jalang-0.0.18.zip zhlang-0.0.18.zip

I recommend Ρόδος / Ródos(Rhodes in English), where is famous for Colossus of Rhodes, one of the Seven Wonders of the World. The Siege of Rhodes (305 BC/304 BC) was one of the conflicts in Battles of the Diadochi. And Rhodes is also renowned by "hic Rhodus, hic salta", a quote from Aesop's Fables.

Strings in lobby aren't translatable yet. See http://trac.wildfiregames.com/ticket/2489 for detail.

IME support is an important progress for Asian users. Good job!

My previous post was wrong. The problem still exists. But the mod works fine if it is unzipped. I am sorry to report late.

I tried the mod and it worked fine. Thank you.

Recent svn can't display East Asian fonts. I doubt this has been since mod selector is introduced. East Asian fonts are distributed as mod(http://trac.wildfiregames.com/wiki/Installing_East_Asian_Locales) so we launched pyrogenesis.exe with -mod option in Alpha 16. Now we get the screenshot below. I use a laptop with Windows 8.1 for your information.

Very interesting.　Good performance measurements demands asceticism of you, no web browsing, no game, etc. Good job!

Thank you niektb. I don't know that the spam filter is a strict spell teacher like him

Today I tried to post a message to this site but the post was rejected by spam filter. The post is as follows: No, 300Mc gain means only 1/6 seconds per game. Other games may gain more or less, I am not sure. Yet I haven't got total understanding about whole engine, I think the bottlenecks are other compornents. Are there any stupid thing in my post? How do I avoid such annoyances?

Does fogging affect long range pathfinding? For example, an enemy builds wall in FoW, what happens? Our troops suddenly notice new wall on the way as they approach, or they detour as if they know there is wall in the beginning?

I played your commands.txt on r15637 and got debug output. The Following messages appear repeatedly: WARNING: Petra baseManager problem with accessIndex 6 while metadata acess is undefinedERROR: CCmpPosition::GetPosition2D called on entity when IsInWorld is falseAnd other messages. these appear only once.Turn 9620 (200)... ERROR: JavaScript error: simulation/ai/common-api/map-module.js line 35TypeError: p is undefined m.Map.prototype.gamePosToMapPos@simulation/ai/common-api/map-module.js:35 m.Accessibility.prototype.getAccessValue@simulation/ai/common-api/terrain-analysis.js:327 m.AttackPlan.prototype.updatePreparation/<@simulation/ai/petra/attackPlan.js:530 m.EntityCollection.prototype.forEach@simulation/ai/common-api/entitycollection.js:196 m.AttackPlan.prototype.updatePreparation@simulation/ai/petra/attackPlan.js:514 m.AttackManager.prototype.update@simulation/ai/petra/attackManager.js:87 m.HQ.prototype.update@simulation/ai/petra/headquarters.js:1933 m.PetraBot.prototype.OnUpdate@simulation/ai/petra/_petrabot.js:85 m.BaseAI.prototype.HandleMessage@simulation/ai/common-api/baseAI.js:85debug_output.txt

Could you tell me which revision you played? I assume you played the latest svn, because I also noticed the result of pathfinding was changed a couple of days ago.

Nice to meet you, Chris. Your Japanese looks almost perfect! 「じゃないけど」を「ではありませんが」に直せば、文全体の丁寧さと調和してさらに良くなります。日本語の勉強頑張ってください。

こちらこそよろしくお願いします。Nice to meet you, hhyloc. I am happy to know that you studies Japanese.

Yes, here I am Japanese, and I like Gỏi cuốn, or summer roll, it tastes good!

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.

When you mouseover on an info icon for Iphicratean Reforms, you see: This text is wrong of course, the actual text is null in civs/athen.json: "Name":"Iphicratean Reforms", "History":"", "Description":"Athenian triremes can train Marines (Epibastes Athenaikos)."

It looks acceptable, yet I haven't seen on the UI, only the source code. By the way, I made mistakes in my previous post.