In rP23484#41415, @Imarok wrote:

Hmm, is it intended, that FXAA is not used on maps with PostEffect to default even when I enabled FXAA in the options?
I guess we will definitely get some reports because of that after the release...

Hmm, is it intended, that FXAA is not used on maps with PostEffect to default even when I enabled FXAA in the options?
I guess we will definitely get some reports because of that after the release...

Disable TLS option from rP21924 has not been rebased as well.

The following revisions are lost because of this:
r22460 | 2019-07-12 13:40:40 -0400 (Fri, 12 Jul 2019) Fix lineendings. (partially lost)
r21927 | 2018-11-07 12:32:21 -0500 (Wed, 07 Nov 2018) The files in this path were not marked as moved in rP21926...

why is the Schema moved?

I suppose that's out of scope, but I would recommend against get syntax when there is the choice.
If we call a function, it should be visible as such.
If we actually want to have a prototype property, then it should be expressed as such.
Storing literals in the prototype is a use case, for example UnitAI globals, or
BuildingAI.prototype.MAX_PREFERENCE_BONUS = 2;
And IMO it would be ugly to add a function call and making it impossible to assign a value to that property name.
(Its possible to have one value on a given property name on the prototype and another value on the same name on an instance of the prototype, so the prototype value can be used as a fallback.)
Especially if there were many literal values stored in the prototype, having a get function for each would accumulate function ugliness quickly. (If we want an assignment X = Y; then why make it a function. Just for the single class scope shouldn't be worth it if it simultaneosly has these other effects on code, possibly even performance due to the +1 function call)

Tested (also with D1960) and it works :)
Just one question, why is the Schema moved?

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

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

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

Use JS_HasProperty instead of JS_HasOwnProperty.

• SetInitGarrison.
• if (Garrison.size()).

(From https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey/Releases/45

SpiderMonkey 45 contains known security vulnerabilities.

CVE doesnt list spidermonkey, so I suppose that refers to a subset of https://www.cvedetails.com/vulnerability-list/vendor_id-452/product_id-22101/version_id-202242/)

http://irclogs.wildfiregames.com/2020-02/2020-02-26-QuakeNet-%230ad-dev.log
Re

20:03 < elexis> "SpecialVariant" what does special mean
20:03 < Imarok> different from the usual ones
20:04 < Imarok> fields are special, so they get a special animation variant
20:05 < Imarok> "special": just different from normal
20:06 < elexis> then define what is normal
20:06 < Stan`> Philosophy 101
20:06 < Imarok> normal is what you get when you don't add this component ^^
20:07 < Imarok> I thought about naming it BuildingDependendVariant, but it could also be used for other entities
20:07 < Imarok> So I stuck with special
20:10 < Imarok> I'm also not 100% fond with the naming, but please use constructive criticism and no philosophical questions...

I object to that notion that this wasn't constructive criticism and that finding a clear definition and name would be a philosophical and not development question, because the reader and template user must not guess what normal and special means.
We can see 60 variants defined in lists.xml, why are those 59 ones normal and the field one special?
Why are gather_treasure and syntagma_front_walk normal and not special?
Perhaps with normal variant you mean "default variant"? But there is no actual default variant I see.
Regardless of the distinction that one might find, is the distinction necessary or might it look better if theyre stored in one place?
It looks like the name of that new component would just be <VariantNames> storing the names of variants that can be used by an entity performing an order with the target entity of that template.

As reported by @ricotz it breaks the tests when running without the public mod, which was still possible in A23B.

Missing the new component?

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

Use an extra component for SpecialVariants

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

Reset roll and pitch, send message.

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

+1

Thx

Change the representation of floats in cas.fs.

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

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

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

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

Add an editing info to the cas.fs header.

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

Remove template change.

It is correct to allow templates decide if friendly fire is enabled instead hardcoding it.
Changes to code are complete and correct.
All required templates have been updated.
Test are passing.

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

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