Don't use GetWorld()

[Silentdarkness1]

I see a lot of spam in my log regarding the usage of GetWorld() in DST mods. Perhaps use "TheWorld" instead?

 

EDIT: And in case you're wondering why this matters? Log spam can have a negative effect on CPU usage.

Edited December 8, 2014 by Silentdarkness1

[rezecib]

This also goes for GetPlayer(). Use ThePlayer now, instead, or AllPlayers to get the list of players.

[Silentdarkness1]

Yeah. Right. Well....some mod maker is still using GetWorld(). THere's Peter A....you....let's see who else's mods i'm using...

[rezecib]

@squeek's Minimap HUD and BetterConsole still have a few calls to both. None of the others in my mods folder have any.

[Silentdarkness1]

Besides your mods, the one i'm using are Cthulhu(DST), DST Freezer, Map Icons, and Soulmates.

[squeek]

It's weird to me that GetWorld has been deprecated. A benefit of abstracting it into a global function means that it can handle implementation changes, and TheWorld can be used exactly as the old return of GetWorld(), so I don't understand why there is a need for deprecation. This just seems like change for the sake of change; the devs changed all their GetWorld() calls to TheWorld, so now we have to as well.

 

GetPlayer() is slightly different, as calls to it in DST might need to be changed, and the deprecation helps to call attention to that, but I'm still unsure if that deprecation is necessary either

Edited December 8, 2014 by squeek

[Silentdarkness1]

Well, one of two things need to be done.

 

1. Modders learning to use TheWorld

2. Klei removing the warnings about using GetWorld(). Because this log spam is silly.

[DeathDisciple]

It's weird to me that GetWorld has been deprecated. A benefit of abstracting it into a global function means that it can handle implementation changes, and TheWorld can be used exactly as the old return of GetWorld(), so I don't understand why there is a need for deprecation. This just seems like change for the sake of change; the devs changed all their GetWorld() calls to TheWorld, so now we have to as well.

 

I was wondering the very same thing.

 

Also, while we're talking about naming, Recipes have been renamed to AllRecipes and all abstraction functions in it removed. Everything else in recipe.lua is same. What was the purpose of that is beyond me...

[rezecib]

@Silentdarkness1, I'm guessing the GetWorld() spam is from RPG HUD's zoom function. You can fix that pretty easily on your own.

 

As for the Status Announcements / RPG HUD incompatibility you posted elsewhere, you can fix it by increasing RPG HUD's priority by adding this to the modinfo:

priority = 1

Always On Status will continue to mess it up in the same way, though.

[Silentdarkness1]

As for the Status Announcements / RPG HUD incompatibility you posted elsewhere, you can fix it by increasing RPG HUD's priority by adding this to the modinfo:

priority = 1

Always On Status will continue to mess it up in the same way, though.

Oddly enough, I haven't run into that problem with Always on Status, but okay.

[SethR]

We moved away from the GetWorld() and GetPlayer() functions for performance reasons (and, in the case of GetPlayer(), because that function doesn't make sense in a multiplayer game). We had a conversation about this the other day and decided that instead of removing them completely, we would keep the functions in the game but add the print to the log that you've all discovered. Since we expect a lot of early-days modding for DST to be updating DS mods to run on DST, we decided that a function call that will cause performance issues but also explain why the issues are occurring is preferable to a function call that will crash the game without any explanation (which would also be mightily confusing for a veteran DS modder who was unaware of the deprecation).

[kraken121]

We moved away from the GetWorld() and GetPlayer() functions for performance reasons (and, in the case of GetPlayer(), because that function doesn't make sense in a multiplayer game). We had a conversation about this the other day and decided that instead of removing them completely, we would keep the functions in the game but add the print to the log that you've all discovered. Since we expect a lot of early-days modding for DST to be updating DS mods to run on DST, we decided that a function call that will cause performance issues but also explain why the issues are occurring is preferable to a function call that will crash the game without any explanation (which would also be mightily confusing for a veteran DS modder who was unaware of the deprecation).

how exactly is calling GetWorld() return TheWorld end be 'performance reason'?

a single function call that wraps a global object is a performance problem?

[SethR]

how exactly is calling GetWorld() return TheWorld end be 'performance reason'?

a single function call that wraps a global object is a performance problem?

 

That wasn't the performance reason I was referring to. The implementation of GetWorld() in Don't Starve (which, we should remember in times like this, is a meaningfully different game/code base under the hood) used FindFirstEntityWithTag. It's true that we could have made GetWorld() return TheWorld. While not having the function wrapper isn't a significant performance gain, it is strictly faster. Additionally, having the wrapper would make it inconsistent with the naming conventions established by other refactoring that was necessary (AllPlayers and ThePlayer). That said, there's nothing stopping you from having your mod overwrite the function to not include the print call.

[Silentdarkness1]

That wasn't the performance reason I was referring to. The implementation of GetWorld() in Don't Starve (which, we should remember in times like this, is a meaningfully different game/code base under the hood) used FindFirstEntityWithTag. It's true that we could have made GetWorld() return TheWorld. While not having the function wrapper isn't a significant performance gain, it is strictly faster. Additionally, having the wrapper would make it inconsistent with the naming conventions established by other refactoring that was necessary (AllPlayers and ThePlayer). That said, there's nothing stopping you from having your mod overwrite the function to not include the print call.

Thing is, why would you?.....it ends up just being more convenient to use TheWorld.

 

EDIT: e_e

Edited December 9, 2014 by Silentdarkness1

[simplex]

It's weird to me that GetWorld has been deprecated. A benefit of abstracting it into a global function means that it can handle implementation changes, and TheWorld can be used exactly as the old return of GetWorld(), so I don't understand why there is a need for deprecation. This just seems like change for the sake of change; the devs changed all their GetWorld() calls to TheWorld, so now we have to as well.

Exactly. That's why I reimplemented GetWorld in U&A (in wicker, actually) within the mod environment without the deprecation statement. Having a consistent interface cross-compatible with single and multiplayer is fundamental.

GetPlayer() is slightly different, as calls to it in DST might need to be changed, and the deprecation helps to call attention to that, but I'm still unsure if that deprecation is necessary either

The GetPlayer case is totally different, since usage of GetPlayer can lead to deep, hard to find bugs since it lends itself to the modder writing singleplayer-specific-minded code. In wicker, I replace GetPlayer with a function raising an actual error, not just deprecating it but altogether forbidding it. I reimplemented it (without the deprecation statement and for both single and multiplayer) as GetLocalPlayer, since the different and more accurate naming induces multiplayer-aware (but not multiplayer-specific) code.

 

 

We moved away from the GetWorld() and GetPlayer() functions for performance reasons (and, in the case of GetPlayer(), because that function doesn't make sense in a multiplayer game). We had a conversation about this the other day and decided that instead of removing them completely, we would keep the functions in the game but add the print to the log that you've all discovered. Since we expect a lot of early-days modding for DST to be updating DS mods to run on DST, we decided that a function call that will cause performance issues but also explain why the issues are occurring is preferable to a function call that will crash the game without any explanation (which would also be mightily confusing for a veteran DS modder who was unaware of the deprecation).

Performance reasons? That would make sense back when GetWorld was defined as

function GetWorld()     return TheSim:FindFirstEntityWithTag("ground")end

but for a fair while now it had been replaced by a memoized implementation, namely

local worldfunction GetWorld()     if not world then        world = TheSim:FindFirstEntityWithTag("ground")     end    return worldend

and the performance impact of calling a function which immediately returns a cached value is, for all intents and purposes, nil.

Thing is, why would you?.....it ends up just being more convenient to use TheWorld.

 

EDIT: e_e

Because singleplayer does not have TheWorld. If it did, then TheWorld would serve as a consistent interface and this wouldn't be an issue. Having to branch into two cases is far from convenient.

[SethR]

Don't Starve Together is a separate game and while there are certainly similarities between DS and DST (since DST grew out of DS), we can't realistically maintain sideways compatibility while still making forward progress on DST itself at a reasonable clip. Mods were never intended to be drag-and-drop from DS to DST. Peter's post here does a good job of explaining this in more detail. Apologies for not being clearer about that fact in my posts above.

[kraken121]

Don't Starve Together is a separate game and while there are certainly similarities between DS and DST (since DST grew out of DS), we can't realistically maintain sideways compatibility while still making forward progress on DST itself at a reasonable clip. Mods were never intended to be drag-and-drop from DS to DST. Peter's post here does a good job of explaining this in more detail. Apologies for not being clearer about that fact in my posts above.

I don't think any of us "serious modders" expected it to be "drag and drop" but that doesnt mean it should be intentionally non-backwards-compatible for the sake of it, forcing non-cross-compatiblity where it's completely unnecesary for the sake of it

[simplex]

Perhaps I should be more clear on the matter of cross compatibility. As kraken said, I don't think any reasonable modder could expect clean inter-compatibility between DS and DST. There is a plethora of incompatibilities, some of which are essential, and many others which are not, but which are at least understandable once we factor in time and resource constraints. But then there are some incompatibilities which are so artificial one can't help but question the design behind them.

The GetWorld case is minimal in face of the overall incompatibilities. So far, in the ongoing process of porting U&A to DST (without branching the code into two different versions), I have written about 1.6k lines of code as "library level" abstractions, separate from the mod code tree per se, just reimplementing singleplayer interfaces in a multiplayer context and, when that is not possible, providing a distinct but generic interface to single and multiplayer. And that's without counting the changes needed to the mod code per se. Wrapping GetWorld, whilst part of that effort, took minimal work. The GetWorld/TheWorld changes were only significant as a token, as a clear representative of that third category of incompatibilities which fall under the "unfathomably artificial and unnecessary" spectrum.

EDIT: If you saw this post before my edit, I claimed the deprecation statement had been removed from GetWorld. But as it turns out I just had diff'ed the files in the wrong order.

Edited December 10, 2014 by simplex

[UnderwearApp]

So I can just change all of my GetWorld(0 calls to TheWorld() and it should be fine? What about this case?

spawnplant = GetRandomItem(allvalidplants)        print("Plant to spawn is "..spawnplant.prefab)        return Vector3(spawnplant.Transform:GetWorldPosition())

Would I need to use "TheWorldPosition" here?

[rezecib]

GetWorld(0 calls to TheWorld()

 

No,

GetWorld()

to

TheWorld

The new one is a constant rather than a function.

[UnderwearApp]

 

No,

GetWorld()

to

TheWorld

The new one is a constant rather than a function.

 

 

Ahh thanks, I read that wrong. Looks like I have to do some reading.