phosit

In Acropolis Bay(2) which is kind of the default map some Red Deer start in impassable terrain. It's a skirimish map so somebody had to place them explicitly there.

Do you have a clue why there are the two spikes in `OnUpdate`?

Shorter turns will yield a smoother game play and less latency but add more "overhead": even if the range-queries are fixed there will be some constant factors. Regarding smoothnes: IMO the biggest problem is that when the AI does recalculate their diplomacy, frames sometime take multiple seconds. If you reduce turn length this will be much more noticable. The AI in general does lead to long turns. Anolog to what you propose the AI could be run more frequent. I don't know if there are constant factors in the AI code. Regarding latency: I don't think of 0ad as a fast paced game so I don't value latency that high. If we still care there are better solutions: make the "turn count untill the input take effect" dynamic in MP games. I'm more in favor of split rendering from simulation. That would make the game a lot smoother by increasing latency (since the simulation or the draw commands have to be buffered somewhere).

That's an two player map how did you manage to place eight players on it?

Good to know. Thanks for testing.

I uploaded a fix for fmt 10 can you try with this patch applied.

What if the researcher fail to research a technology? Oh... nope... they never fail in the game. Yep also in favor of queuing. Keep in mind that if there are multiple blacksmith they should not research ranged damage 1 and ranged damage 2 at the same time.

Did you use a mod?

Was there a error message when it crashed? Can you upload the logs from the old pc?

Did you enable vulkan without the spir-v shader mod?

We should make the network-error messages more detiled. e.g. Detecting that a ISP does block UDP should be possible.

Thanks sternstaup IMO that's a great idea. A simple use case would be to send the userreport over GNUnet to the server. So that the server can't tell from that IP the report is comming. Idealy we use GNUnet in-game to hide the address to the host. Generaly anonymisation-networks like tor have bad latency but GNUnet seems to have a replacement for udp i don't know how that works. First we should encrypt the existing infrastructure and look at QUIC. GNUnet isn't "production-ready" but we are also in alpha

Do i get you right: When you order a unit to do something the voice line and a timer is started. As long as the timer is not reset no other sound-track will be played. What do you mean by reset? does some process have to reset the clock, or does the reset happen when the timer reaches zero. I don't know how it's implemented. It would be nice that the voice line sets the unit to mouth-idle when the voice line ends. There would be no timer required.

What do you (all) think about adding a layer between the simulation and the renderer. That layer would use the data from the simulation to calculates the data which are not syncronized (corpses, interpolation, sound...). The renderer and the audio-system den does use thous data. In other words: Splitting the simulation in a global and a local part. That will be simpler to implement when there is a clear boundrary between simulation and renderer.

It is implementable (i think). It could be a hidden setting (only in the user.cfg). @Stan` also mentioned make the syncronize per turn ratio variable for a28 or so.

Did you profile it? https://trac.wildfiregames.com/wiki/EngineProfiling#Profiler2 I experienced the same thing: https://code.wildfiregames.com/D4786 No. It is costly to copy JS-objects (the simulation components) to an other thread. JS cant reference data on an other thread. There has to be some kind of OOS check. It isn't done every turn. It's done that way: only commands and sometimes a hash of the simulation-state is shared.

Ne, damit ist gemeint ob die KI ein Bonus/Handicap beim Sammeln hat.

Hallo Newbee Nur um sicher zu gehen: Bist du in "Einzelspieler" > "Kämpfe" dort auf das Zahnrad gedrückt und die KI auf "Sandkasten" gestellt?

This will encourage to play with more units. Which then does decrease performance. Would it be possible to make units on the walls stronger instead? more resistance and propably more damage.

IMO a defensive AI should realy build walls if the terrain allows it. If no top player's do build walls, walls should be made stronger (or siege and ellephants weaker). Walls are a part of the game.

You can disable "Filter compatible replays" then all replays are visible... But you can't run them When starting pyrogenesis with "--replay-visual=" it's possible to run them.

I also got some errors. I just atach the interesting log. interestinglog.html Isn't there a bether solution than asking the users to report all missing shaders? Surely it will not be tested exhaustively and some shader will be missing in the release.

I might have formulated it a bit to harsh. We should still use multithreading but for now (for me) making the game more cache-frently has higher priority. When i wrote that i didn't know that each core has there own Prefetcher Yes, don't optimize prematurely. But what is an optimization‽ I use reduce over fold when possible. For some people that's already an optimization. Yes, Manual prefetching is hard... I think... never done it. I don't say we should do it manualy but we should design the datastructure in a way that the compiler / the cpu can do it. I don't think that the data-access-pattern will be remembered after a frame. The linked-list is not the only datastructure which does get iterated / has to be remembered and the linked-list might be mutated. No, the compiler doesn't do that much devirtualization (we haven't enabled LTO). Which also prevents furture optimization. If the v-table is in the cache it does use some valuable cache space (that's bad to my understanding). Aslo when i profiled many cpu-cycles are "lost" at virtual function calls. I would like to talk further with you and get some tips how to profile but that's easier on IRC. Feel free to join

I made a patch which does remove `COMPILER_FENCE` in some places: D4790

Interesting... I thought the 64-bit executable will be slower, since pointers are bigger. Apparently more register and the use of mingw outweight that.