In D4970#211945, @real_tabasco_sauce wrote:

By "Bog down" is that the slowdown when units clump while moving? If this is already slightly in effect currently, I think players will dislike increasing it. I think we should avoid introducing any sluggish movement as much as possible.

I did some actual testing -> I maintain my 'needs revision'.

In D4970#211872, @real_tabasco_sauce wrote:

Have you tried these values? I think they are pretty good, closer to the status quo, but perhaps there are still improvements to be made.

No I need to actually do it. I think I should get the time this week.

Yeah trying to improve is certainly fair, as I said. I guess I'm saying it's probably better to end of the side of 'smooth, clumped-up pathfinding' over 'slow, spread-out'.

Sure, seems sensible. Testing on a wide scale would definitely be a good idea.

(For what it's worth I remain convinced that we should give up on proper ship movement and just make them clip each other like Age of Empires does, or alternatively just prevent players from directly controlling ships or something.)

I think you're likely to break some things here, because you're bumping everything at once, and with somewhat large changes. I would recommend just changing one thing at a time with pushing, because movement literally affects everything in the game.

I have the same testing behaviour as Langbart, so it's Working As Designed from my perspective.
I seem to get about 2x FPS in general, but that will depend on a variety of factors. I think we still have a huge draw-call overhead on several maps which probably limits the effectiveness of Vulkan.

In D4911#209767, @Langbart wrote:

It seems to solve the problem described in D4905 (the small pyrogenesis processes), but I am still able to trigger all the processes described in #6699. I also noticed that when playing the tutorial (around the 25th minute), an ~18GB memory spindump process amassed in the background, making the PC unusable if not manually killed. How to trigger these processes in a regular game is not clear, the steps to reproduce them remain obscure.

---

These processes (spindump, sandboxed,,ReportCrash) do not take place when a bundle is used, e.g. the one uploaded to D4905.

irrelevant now, too many related & unrelated changes since.

Include hotload in the try-catch

I'm assuming you're doing two things here:

• Removing a layer of indirection by just having one component for the interface for system components (makes sense to me)
• Doing some allocator-locality thing like D4718

I tried something similar in D3186 but never got around to finishing it. Your approach seems maybe slightly less invasive at a glance (though I commented on my patch that I thought my approach was 'neater' than a separate allocator, so your mileage might vary), and doesn't break the requirement that components aren't movable once constructed.

Remove Future::Cancel(), seems too dangerous to use properly from outside code.

You should probably add a comment that this function should only be called for entities that are currently explored, but not visible or things will bug out. The C++ code seems to work fine for that

In D4773#203378, @phosit wrote:

Does anybody know why it was called m_HostId before?

In D4769#203037, @lyv wrote:

Finally, I think this may introduce an OOS because the GUI Interface calls this function and that might be in a different pattern across clients. The PRNG only guarantees the same sequence, but that might lead to one generator being ahead other ones because there is one more function call on one client who called an extra GetEntityState or something.

Can't think of a reason why we don't need to wait here, guess this is indeed just a typo. Good catch.

Good diff.
Quick note on the ENSURE -> I'm assuming schema verification would make the engine fail at loading badly-formed XMLs, and thus the ENSURE is indeed only triggered by code flaws and not possibly by bad data ?

In D4428#206031, @jprahman wrote:

@wraitii any update on this migration to SM91? Would be great to move to the newer SM version

In D4758#205064, @Mercury wrote:

Trying to maintain fps at all costs rather then trying to manage and smooth performance degradation as system stress ramps up is what causes GC shrink to run.

In D4758#204929, @Mercury wrote:

200ms is the length of time which the turn is simulating. 50ms is the processing time for the turn plus one frame. 150ms is the maximum amount of time that can be given to slice without introducing simulation lag.

But those 150ms aren't free ! They're being used by the renderer to get as close to 60FPS as possible. You can't just run the GC during that time.

This looks clean, but I'm not sure if it has performance implications or anything thereof ? Does it change anything? Or are you just fixing my code now that we can presumably use std::optional because we upgraded Xcode since I wrote my code

Could you rebased D4730 to only contain its own changes? Obviously the patch won't apply, but it'll make it easier to understand why e.g. this patch is necessary

In D4758#204851, @Mercury wrote:

Imagine a turn + frame which take 50ms to process and simulates 200ms. The slice budget is 200ms - 50ms = 150ms. The back-pressure equation is only relevant for when there isn't enough time to do everything and simulation is being allowed to lag, for example if sim context is 70% full while the simulation turn took 170ms to compute then 40ms will be budgeted instead of 30ms, potentially creating 10ms of lag.
Note that this leaves no time for animation frames if the whole budget is consumed, meaning graphics will run at 5 fps but 100% of available time is being given to slice. If we reserve some of that time for animation frames (32% if we assume 16ms per frame render at 20fps) then we aren't clearing out the excessive JS garbage and getting back on track as quickly. This is where the priority trade off between frame rate and simulation lag is: the tension between keeping it smooth in low stress and keeping it playable at high stress.

Dove deeper into the issue this morning, things are more complicated than I anticipated but this patch still needs some changes.

In D3877#204452, @phosit wrote:

I don't understand your comment. To avoid wake up costs you restrict how long the task can take or to avoid wake up costs you introduce a new thread?

Rebase

Rebase & fixes:

• Make the Linux 32-bit patch apply only on i686 (which I believe is only linux 32 bit?) to work around windows compilation issue.
• Improve bash script per stan's comments
• Update to 91.13.1, which is the last ESR for version 91. This requires a different virtualEnv fix for me which I've provided below (it's tied to Homebrew but I assume it won't hurt on mac os anyways).

In D3877#204125, @phosit wrote:

I have a different idea:
A ThreadPool::runAfter(timePoint, timedTask) which pushes the timedTask to a new queue priority_queue<pair<timePoint, timedTask>>. Ordered only by .first.
So there is no need for a extra timerThread and there is no restriction in how long the task can take.

In D4786#204108, @phosit wrote:

If I run it with this comments it does compute the hash (the hash are print to the console) but the profiler(1 and 2) does not show the time it takes. There are some "empty frames" were were the state hash check would be.

You can actually execute this in a replay with -hashtest-full=true and -hashtest-quick=true if you make it an MP replay.

I think changing the GC scheduling is a good idea, but I feel like this overcomplicates things (the current code is IMO also overcomplicated) while also not necessarily doing enough:

What menu is that?

See forum post -> I think this is the wrong direction, because average load matters little compared to peak frame load. Maybe the difference doesn't matter a ton here, but I think it's unlikely to be much better either.

Looks neater. I don't think I had a particularly good reason to use recursion here.

Think this looks fine.

I didn't realise we had this feature... I'm in favour, random should be random.

TryToConnectWithXmpp -> TryToConnectViaLobby to match the SetupConnection call (and because XMPP is basically the lobby client).

GetCameraDirection -> GetCameraOrientation for consistency with C++

@edoput How do you want to appear in the credits?

In D4682#199519, @Stan wrote:

Oh my bad then. Just thought it'd be nice if someday we decide to have proper dependency injection.

Seems like you could fix a few listing problems while at it, but this gets a +1 for being a good idea.

Per https://trac.wildfiregames.com/wiki/Coding_Conventions, we have Prefer global variables over singletons, because then they're not trying to hide their ugliness. It's definitely something I kind of like, because singletons by design make it annoying to have two of something, and that can occasionally be useful.

In D4679#199184, @Freagarach wrote:

That sounds like good play then? And reckless play from the defender? There are walls to fend off these kind of raids?

Think this is generally a fairly good first use case, but I believe you could write simpler code, particularly since this bit doesn't really require us to optimise it to death.

In D4676#199132, @chrstgtr wrote:

Maybe this is too simple, but why don’t we just switch default unit behavior to destroy instead of capture and adjust health and control metrics to reflect how we want them? [...] It seems like it an all around win.

I'll make a minor tweak to avoid double-messages but I think this looks good

Lint

This should fix that case as well.

Thanks Stan

Probably won't have time to fix it until Monday FYI

In D4681#199032, @vladislavbelov wrote:

It doesn't fix the ticket, so the ticket must not be closed. But the fix might be committed as soon as accepted until we have a proper solution.

I've written about this fairly extensively, and I think the main problem with capturing is that it's boring as hell. Your units don't even fight. I actually think the only legitimate use is sneak-capture. We need a complete revamp of the 'capture' logic to represent breaking-in, defender vs attacker losses, and control of the building as a non-abstract concept IMO for it to work.

default in the cpp

In D4675#198841, @phosit wrote:

The = defaultwas ok but not in the header file.

Add a specific test for multi-space words. It is indeed not collapsed.
I've de-activated the 'ignore space' logic in those cases, kind of arbitrarily. It seemed more coherent.