Took the exporting of the half-vector out of any conditional switches in model_common.vs.

Patch works for me, can't reproduce the bug anymore. Thx

Successful build - Chance fights ever on the side of the prudent.

In D3303#156448, @Freagarach wrote:

Catafalque.

Successful build - Chance fights ever on the side of the prudent.

Nice one! I like the idea and the clean-up in the templates.

Catafalque.

Successful build - Chance fights ever on the side of the prudent.

Successful build - Chance fights ever on the side of the prudent.

Minor fixes.

Yeah this is definitely still WIP because of that issue. I think there are a few possible switcheroos:

• make it so that changing ObjectEntry is really fast, by not needing to copy much
• Have multiple objectentries in parallel per Unit (definitely takes a bit more memory, but possibly preferred solution)

I think it is slow because you are constantly acting like reloading whole actor when switching lods, what I was trying to do is to keep all used lods as separate models and just to return the correct one, cost there was I needed to sync animation frames on all lods when updating currently used, but they were ready to use instantly. Although my last test was bugged animation when switching them so I moved it to backup milestone for time being.

is it possible to use file= in actor tag? esle they will be mess if everything will be in one file

Successful build - Chance fights ever on the side of the prudent.

Minor code optimization in model_common.fs; saved one sqrt() call.

Build failure - The Moirai have given mortals hearts that can endure.

Build failure - The Moirai have given mortals hearts that can endure.

Fix a number of bugs, support a max # of LOD levels per actor to 5, account for prop LOD correctly.

Change name of function "get_white_dimming_factor(tex)" to "get_needed_white_dimming_factor(tex)", in terrain_common.fs.
Fixed a few more comments not capitalized, or not ending with a period.

Removed leftover code from attempting to use skybox as enviromap.

More cosmetic fixes.

I think this is overly complicated to be honest. I don't think there is a need to #define the CPUID implementation - the previous code worked fine.
I would simply revert to the previous version of the patch and merge that.

Successful build - Chance fights ever on the side of the prudent.

Successful build - Chance fights ever on the side of the prudent.

More proper fix + warning about hack.

I think the issue is that when translateScancodes is false, the function should return an array (which is really a bad API lol, I need to double-check why I did that).

What's wrong with my I386 detection macro?

Carried on style fixes to the other shaders.

Figured out how to diff from root while skipping /sources.

Updated the patch again after fixing style 'mistakes' at Stan's request. What I was not able to do is diff from the root folder, as then svn diff wants to include all the stuff from sources, which amounts to more than two megabytes. I'm sure there must be a command to skip a folder, but I was a Tortoise user for many years; never learned the command line.

Looks like I made a mistake in my hotfix in rP24856

I tested this patch and it seems to fix the issue. I found another way to reproduce. (It works both in packaged an non packaged and triggers a stack overflow)

Any opnion @Nescio ?

I agree here with @Nescio.

Okay so here comes the frustrating and tough part :/ So bear with me cause we're in for a ride. Just know that it's not against you :)

Define CPUID_IMPLEMENTATION_* in x86_x64.h and use them in x86_x64.cpp and topology.cpp

Attached codeblocks from x86_x64.cpp
Version 1 (Windows version): Probably this version correct in all CPU/architectures/compilator options/etc. I don't know if this assertion is possible there.
If another user (on Windows) receives this assertion, this is 99 percent a different issue.

I see now

In D3575#156310, @Stan wrote:

Well your patch does it anyway :)

Successful build - Chance fights ever on the side of the prudent.

Well your patch does it anyway :)
And not for all only for x86_x64::Family() == 6 if IA32 is detected

In D3575#156260, @Stan wrote:

Hey thanks for the patch ! You might want to move that into the check for IsHyperThreading capable.

Successful build - Chance fights ever on the side of the prudent.

Successful build - Chance fights ever on the side of the prudent.

(with stan's permission).

I feel like you might have an easier time with "Enable"/"Disable" instead of Toggle, but otherwise this looks OK :)

Jeez we've forgotten a lot of stuff in messages.json . Refs D3535 (should be merged independently to close the revision)

Should be merged once A24 is released :)

Hey thanks for the patch ! You might want to move that into the check for IsHyperThreading capable.

I agree, but that is not what the code says ;)

In D3113#151609, @Freagarach wrote:

• The projectile tries to hit an invulnerable target next to a vulnerable -> The former plays the blocked sound whilst the latter plays the hit sound.

so if they dont use parabolic query, then query they use is wrong compared to the range checks in js

• Added nickname to credits

Can you add yourself to the credits? :)

• Added TODO

For me it's A25 material. I will ask maintainers about it but so far the people I asked were really mitigated about it.

For my end, I think distributions/maintainers are free to patch if they want to (this seems something they could be concerned with). Not planning to merge this for A24.

Sure. :)

Could you add tests for this bug? (So that we prevent regressions ;)
Ofc not for A24.

any news or decision?

I no longer get error codes for Spanish (or any other language) when I open the "Manual".