In WatchWorldState, bug or intended?

[DarkXero]

inst:WatchWorldState("isnight", SpawnCheck)inst:WatchWorldState("isday", RemoveSpawn)

This code executes SpawnCheck when I arrive at the night time.

And it executes RemoveSpawn after night ends, NOT when the day starts, BUT when dusk starts.

 

However:

inst:WatchWorldState("isday", SpawnCheck)inst:WatchWorldState("isdusk", RemoveSpawn)

Executes SpawnCheck when day time starts, and RemoveSpawn when dusk starts.

 

What am I missing here?

 

 

Also,

inst:WatchWorldState("startnight", SpawnCheck)inst:WatchWorldState("startday", RemoveSpawn)

works as the first code should.

[rezecib]

@DarkXero, I'm surprised the "isx" ones work at all. I would use the start/stop ones instead. Since "isnight", etc, are not really events, it's not immediately obvious to me how they should be functioning.

 

Edit: Looking at worldstate, though, it seems like it would be getting pushed whenever "isnight", etc, get set, including if they're being set to false (although it passes the value to your watcher function). I'm guessing what's happening is that both your night and day functions are running when it transitions to day, and the night one is swallowing the day one's effects.

 

Edit 2: Vito too stronk!

Edited January 10, 2015 by rezecib

[Kzisor]

DarkXero, rezecib, the better question is why are there 7 states being used.

 

States:

phase

startday

isday

startdusk

isdusk

startnight

isnight

 

I personally only use phase as I don't have to listen to multiple state changes.

[V2C]

The different variations are just there so you can pick the most optimal one.

 

"phase": whenever phase changes, passes you the new phase

"isday": whenever phase changes to or from "day", passes you true or false

"startday": whenever phase changes to "day", passes nothing

 

In this case, you only need one listener to "isnight", and when it's true, do SpawnCheck, and when it's false, do RemoveSpawn.

 

[DarkXero]

Well, @V2C that was certainly helpful, it verifies what @rezecib said and it makes it clear when something gets triggered.

 

I thought the functions were easy to check by just watching what happened in the world, as I was spawning something then removing it, but indeed after replacing them with a few prints, the first one was swallowing the second one. I should have started there, but I tried with the starts and it worked so it left me confused.

 

Now I get it, thank you!

[Kzisor]

The different variations are just there so you can pick the most optimal one.

 

"phase": whenever phase changes, passes you the new phase

"isday": whenever phase changes to or from "day", passes you true or false

"startday": whenever phase changes to "day", passes nothing

 

In this case, you only need one listener to "isnight", and when it's true, do SpawnCheck, and when it's false, do RemoveSpawn.

 

Thanks for the information, but it seems to have raised more questions. In the long scope and the ability to increase the maximum number of players on a server, is having 7 variables worth the additional bandwidth and processing power of the server?

 

Example:

Would it not be optimized and more beneficial to update startday, isday, startdusk, isdusk, startnight and isnight on the clients/server machine through a function which is tied to phase?

 

Example:

startday = function() return phase == "day" and first_segment_of_cycle endisday = function() return phase == "day" end 

 

Curiosity has me looking into optimizing my code.

[V2C]

Good question!  It actually works similar to how you are thinking already.  Phase changes are the only network data that is sent.  When clients detect a phase change from network data, all the logic to trigger the corresponding world state events are local.

 

[Kzisor]

@V2C, that makes perfect sense.