Remove the TaskManager destructor change, merging once green.

In D4673#198809, @jprahman wrote:

Looking at the details, the ip and port values inferred in the three conditional blocks are not used in the actual connection attempt. But rather those two values are only used to establish a Stun tunnel.
For that reason, I'm not convinced that QueryConnectionDetails() would be semantically accurate for the name. Instead, something like SetupStun() would more accurately reflect the intent.

You're right, I forgot how this bit worked.

In D3877#198820, @jprahman wrote:

Hey @wraitii are you planning on cleaning up and landing these changes soon? Asking since I'd like to pull in changes with the AddRecurrentTask API and can either wait for this to land, or put up a diff with an updated version of TimerThread :)

In D4672#198721, @marder wrote:

generally I think not _everything_ needs to be a setting, especially when looking at the complex setup that we have already, but since there is no consensus about what the right way is, I guess that might be ok.

I need to get some more time to actually think about the implications here, but I think this looks generally workable.

Hey, thanks for the patch. This does simplify the control-flow, particularly the last block that is kind of awkward.
I think however it would be more natural to have a QueryConnectionDetails function that encapsulates the ip/port finding logic, and call that (which can return immediately if g_xmppClient is not there), then simply setup the connection in the flow. That method should probably be a class method of CNetClient.

In D4662#198715, @vladislavbelov wrote:

What happens if there multiple spaces in the end? It needs at least tests.

Only remove the 'player defeated' plot twist.

*L" " to L' '

Thanks for fixing this Stan, didn't have time

I realise this is getting somewhat bikesheddy, but a more complete response:

General high level notes:

I need this information in game to set a default rotation during the game. The current "reset camera" feature resets the camera rotation to the default values present in the config but these values are not available in game for the user to set.

Unrelated, but this sounds like you could just read the config values?

In D4660#198512, @edoput wrote:

Should I open another differential with only that changes?

In D2938#198471, @asterix wrote:

Will there be an update on this, since it was committed for a minimap?

It sounds like this is just reporting those warnings, yeah, so I think you can go ahead

I ran into an actual bug while updating the tests following rP26889, gonna add tests in the fix for that instead.

In D4661#198340, @marder wrote:

hm actually, what about a diplomacy with no last man standing?
Imagine you're playing with a large wonder holding time and you decide to add a new ally after building a wonder. Doesn't it seem unfair that you get punished for doing so?

Mh, yes. The scenario I had in mind is the reverse: you are allied to some guy, then you remove that alliance at the last second, and you instawin because the timer isn't reset.

The tests now show an asymmetry between the left & right align, which I don't think was there before. Need to investigate.

In rP21441#46499, @Freagarach wrote:

Has a topic or a ticket for this been made? For I could not find it.

There is some related code in D3507.

In D4653#198209, @Stan wrote:

How about the projectile code ?

In D4653#198191, @Stan wrote:

That still sounds like something that should be tested. I wonder if the speed loss going through JS interfaces would not be mitigated by having a very fast component.

Yes, that's a bit of a question.

(This is exactly why I push for D3886)

In D4653#198028, @Stan wrote:

So it's not worthwile at all?

Recap of a talk with Mozilla SM devs today on their Matrix chat:

• JS-WASM & JS-C++ interop can ultimately be expected to have about the same 'cost'. A dev said that the large cost was that IonCompiled code needed to dump registers in a GC-aware manner, in case the C++/Wasm call triggered a GC.
• C++ <-> WASM interop is currently not implemented, and would have to go through JS, which I think makes the whole idea too inefficient right now. Though implementing c++ <-> wasm direct interop might be relatively easy to implement.
• Given that we're gonna need the above in any case for the engine, this sounds like a somewhat complex path to optimisations.

In D4530#197931, @vladislavbelov wrote:

In D4530#197910, @wraitii wrote:

God this code is a mess.

You're talking like other code is significantly better x)

God this code is a mess.

This one should work

Still learning lua

More debug

Debug

Fix premake

Fix cross-compilation, run with ARCH/HOSTTYPE=x86_64

Proper fix this time

Fix xwwidgets

In rP26881#57875, @Stan wrote:

Question how do I build a X86 build on my M1 now ? I can pass arch to the libs, but not to updateworkspaces.sh, nor premake for the game

Will be invalidated by D4646, which seems easier given the rest of code changes, and since this is old/stale I'll abandon directly.

For Demo purposes, add a RunThreaded function to run some threaded javascript. This highlights that a web-worker like API is doable, but doing it efficiently would take a little more thought.

Rework, upgrade & make actually functional.

In D4575#197726, @wraitii wrote:

• If used in the GUI, we'll need to do some work to expose the init function, unless we have a non-module file to describe page entry points. Something like import { init } from './HotkeysPage.mjs'; globalThis.init = init; works, but it's kind of ugly.

Tested this quickly today:

• The '.mjs' syntax might be useful to differentiate in the engine. So maybe let's keep that.
• If used in the GUI, we'll need to do some work to expose the init function, unless we have a non-module file to describe page entry points. Something like import { init } from './HotkeysPage.mjs'; globalThis.init = init; works, but it's kind of ugly.

Fix last comments.

Change #elifdef to #elif defined()

This is included in D4607 & seems to bug for other people as well (see phosit on IRC today). I think it might be a Python 3.10 thing instead of a mac thing.

Reworked using an upstream patch of mine (but largely the same fixes). Tested to work on my mac.

Raise error, handle errors in the C++ (fail to autostart)

In D4575#197572, @wraitii wrote:

Do you have something specific in mind as to not really interchangeable?? I think they generally are.

In D4575#197559, @smiley wrote:

Either /, ./ or ../ at the start I guess. None of those would mean start at the current directory.

In general I'd rather not have a leading / unless it's necessary for disambiguating. In frontend development, absolute paths usually refer to node_modules and the root source directory is aliased to something (I think @ is most common).
However, we don't have node_modules and likely never will, and C++ vfsPath just start at the VFS root in general. I think it makes sense to have three types of paths:

• Absolute paths (from VFS root), no specific syntax.
• Paths that start with ./, which are relative paths.
• Paths that start with ../ any number of time, which are also relative paths.

For the record -> This is intended as a temporary fix that nevertheless won't result in massive technical debt if it remains like that for the next 15 years, which I think is somewhat likely given that despite several tries, nobody's found a much better way yet.

In D4575#197178, @wraitii wrote:

In D4575#195007, @smiley wrote:

Notice that it won't be possible to resolve out of VFS root.

Definitely the only sane move.

Read-through review:

• I think we should use .js over .mjs in the interest of tooling support, and I'm not convinced that .mjs will actually take off.
• There's a bunch of duplication with LoadGlobalScript & such in ScriptInterface.cpp. I think it's time to merge those together in a single ScriptCompile file or something.
  • In particular, there's a question of entry points -> Once we're compiling as modules, we can import submodules, but we can't import modules from non-modules bits.
• Your tests are missing an absolute path, and I think it's broken in the current implementation. I think it should work, and should start from the VFS root as one would expect. Relative paths are quickly unwieldy when you get into folders-of-folders.

Always load the network JSI functions.

Think this approach is workable, will let freagarach take over :)

In D4643#197432, @Mercury wrote:

So If I add changeOrigin to Reduce and to RegisterHealthChanged then I could add it to the HealthChanged message.
Does this sound good? If so should I pass attackerOwner along with it?

Hm, hadn't though of loot. Your right, that's more annoying.