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...
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Feed All Stories
All Stories
All Stories
Feb 28 2020
Feb 28 2020
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.
[i18n] Updated POT and PO files.
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...
Feb 27 2020
Feb 27 2020
elexis added a comment to D2644: Support JS class syntax / non-enumerable entity component message handlers.
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)
Freagarach added a comment to D2644: Support JS class syntax / non-enumerable entity component message handlers.
Tested (also with D1960) and it works :)
Just one question, why is the Schema moved?
Vulcan added a comment to D2645: Fix tests without public mod following globalscripts tests rP22970 and mapscript tests rP23455.
Build failure - The Moirai have given mortals hearts that can endure.
Harbormaster failed remote builds in B11207: Diff 11441 for D2644: Support JS class syntax / non-enumerable entity component message handlers!
Vulcan added a comment to D2644: Support JS class syntax / non-enumerable entity component message handlers.
Build failure - The Moirai have given mortals hearts that can endure.
Successful build - Chance fights ever on the side of the prudent.
elexis updated the diff for D2644: Support JS class syntax / non-enumerable entity component message handlers.
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/)
elexis added a comment to D2362: Allow for building-specific build/repair animations and use seeding animation for fields.
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.
Fix map always being set to circular in rP23374 / D2483.
elexis raised a concern with rP22970: Adds a "properties"-property to resources and let mods be able to prevent….
With the patch:
Feb 26 2020
Feb 26 2020
Stan added a comment to D2362: Allow for building-specific build/repair animations and use seeding animation for fields.
Missing the new component?
Vulcan added a comment to D2362: Allow for building-specific build/repair animations and use seeding animation for fields.
Build failure - The Moirai have given mortals hearts that can endure.
Imarok updated the diff for D2362: Allow for building-specific build/repair animations and use seeding animation for fields.
Use an extra component for SpecialVariants
Harbormaster failed remote builds in B11202: Diff 11437 for D2453: Allow Flying objects to be stationary!
Build failure - The Moirai have given mortals hearts that can endure.
Reset roll and pitch, send message.
Stan added a reviewer for D2644: Support JS class syntax / non-enumerable entity component message handlers: Itms.
Successful build - Chance fights ever on the side of the prudent.
+1
Change the representation of floats in cas.fs.
Vulcan added a comment to D2644: Support JS class syntax / non-enumerable entity component message handlers.
Build failure - The Moirai have given mortals hearts that can endure.
Vulcan added a comment to D2644: Support JS class syntax / non-enumerable entity component message handlers.
Build failure - The Moirai have given mortals hearts that can endure.
elexis updated the test plan for D2644: Support JS class syntax / non-enumerable entity component message handlers.
Harbormaster failed remote builds in B11199: Diff 11433 for D2644: Support JS class syntax / non-enumerable entity component message handlers!
Vulcan added a comment to D2644: Support JS class syntax / non-enumerable entity component message handlers.
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.
Feb 25 2020
Feb 25 2020
Allow buildings to autobuild themselves.
Harbormaster failed remote builds in B11196: Diff 11430 for D2492: Allow buildings to autobuild themselves!
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.
Harbormaster failed remote builds in B11195: Diff 11429 for D1973: Support friendly fire for projectile attacks.!
Build failure - The Moirai have given mortals hearts that can endure.
Successful build - Chance fights ever on the side of the prudent.
Wildfire Games · Phabricator