HomeWildfire Games

Slight cleanup of fogging OnDestroy and some comments
AuditedrP22247

Description

Slight cleanup of fogging OnDestroy and some comments

Following rP22029 I dwelled in the fogging code. Some confusion could have been avoided by some comments.
Also early-exit the loop to avoid doing un-necessary js->c++ transitions.

Reviewed By: Itms

Differential Revision: https://code.wildfiregames.com/D1737

Details

Auditors
Itms
Stan
Committed
wraitiiMay 4 2019, 3:49 PM
Reviewer
Itms
Differential Revision
D1737: Slight cleanup of fogging OnDestroy and some comments
Parents
rP22246: New Texture: Persian Units
Branches
Unknown
Tags
Unknown
Build Status
Buildable 7358
Build 11983: Post-Commit Build (Code)Jenkins

Event Timeline

Stan raised a concern with this commit.May 5 2019, 11:16 PM
Stan added subscribers: wowgetoffyourcellphone, Stan.

I just tested a game after a PM @wowgetoffyourcellphone sent me, and this new code indeed triggers warnings.

WARNING: JavaScript warning: simulation/components/Fogging.js line 202 Script value conversion check failed: v.isNumber() (got type string)

Here is a replay

This commit now has outstanding concerns.May 5 2019, 11:16 PM

this.mirages is an array.

/ps/trunk/binaries/data/mods/public/simulation/components/Fogging.js
195

for (let player = 0; player < this.mirages.length; ++player)

Stan added inline comments.May 6 2019, 12:58 AM
/ps/trunk/binaries/data/mods/public/simulation/components/Fogging.js
195

for in should work, and return the indices, but maybe we need to early return if (!this.mirages.length)

You are right but it's not easier and usual to use length form to iterate in an array?

wraitii added inline comments.May 6 2019, 7:50 AM
/ps/trunk/binaries/data/mods/public/simulation/components/Fogging.js
202

I think we need to change to +player on the right here now. JS is a pain

Stan added inline comments.May 6 2019, 7:52 AM
/ps/trunk/binaries/data/mods/public/simulation/components/Fogging.js
202

Yeah might be.

Itms added a subscriber: Itms.May 7 2019, 9:24 PM

I think it would be better to revert to the original for style like Polakrity suggests. for...in is better suited for dictionaries, and adding a + everywhere player is used in that function sounds like a pain and people might make the mistake again.

Should we discourage for...in on plain arrays in the coding conventions in general? It sounds saner to use it on dictionary-like objects only.

Stan added a comment.May 7 2019, 10:29 PM

I guess we only need +player on 202 that's where the warning comes from.

Itms added a comment.May 7 2019, 10:35 PM
In rP22247#33237, @Stan wrote:

I guess we only need +player on 202 that's where the warning comes from.

It's not a good idea to base oneself on the warnings, which are not always the root cause. Here indeed only this line will break because this is a call to a C++ component (so calling GetLosVisibility(..., "1") will fail), but on the other lines we are still calling stuff like this.mirages["1"], which, even if it is allowed in JS, is bad. player should just not be a string, which means we shouldn't use for in here.

I mean, in JS every key of an object is a string.

Though:

Should we discourage for...in on plain arrays in the coding conventions in general? It sounds saner to use it on dictionary-like objects only.

Sounds fair enough to me. The behaviour is a tad counterintuitive.
TBH I'm not sure where our up-to-date coding conventions are though.

Itms accepted this commit.May 8 2019, 9:55 PM
Stan accepted this commit.May 8 2019, 10:21 PM
All concerns with this commit have now been addressed.May 8 2019, 10:21 PM