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

From past experience, there is no attitude that will make Klei want to work with us. They (and by they I mean one Klei developer at most at any given time) work with us only when and if they want to, independent of our 'attitude'. Perhaps I'm just a curmudgeon when it comes to modding Don't Starve, but this is nothing new.

Very true. To be clear, Minecraft has no autodownloading features at all for mods (mods are all third-party, there is no official modding API, and there is no singular trusted host for mods). I think I really bungled up my post back there, and I take it all back. Adding support for autosyncing mods uploaded to these forums would indeed be nice.

@Silentdarkness1, for mods not on the Workshop, clients would just need to sync their mods with the server before joining it. Note that this is how Minecraft handles things to this day and it seems to do alright in terms of modding. It's convenience-based functionality you're talking about, not core functionality. Everything will still work fine if mods are not on the Workshop; it'll just be less convenient for clients, as they'll have to manually download/install the mods that the server is using in order to be able to join it (hence the rise of modpacks within Minecraft modding).

Another thing: The worldstate component does not listen for the "clocksegschanged" event, thereby making it impossible for mods to access that information (meaning the current seg values) without writing our own listener. Example fix: scripts/components/worldstate.lua | 6 ++++++ 1 file changed, 6 insertions(+)diff --git a/scripts/components/worldstate.lua b/scripts/components/worldstate.luaindex 7161be9..c389326 100644--- a/scripts/components/worldstate.lua+++ b/scripts/components/worldstate.lua@@ -70,6 +70,10 @@ local function OnMoonPhaseChanged(src, moonphase) SetVariable("isfullmoon", moonphase == "full") end +local function OnClockSegsChanged(src, segs)+ SetVariable("clocksegs", segs)+end+ local function OnSeasonTick(src, data) SetVariable("season", data.season) SetVariable("issummer", data.season == "summer", "summer")@@ -129,11 +133,13 @@ self.data.isday = true self.data.isdusk = false self.data.isnight = false self.data.isfullmoon = false+self.data.clocksegs = {} inst:ListenForEvent("clocktick", OnClockTick) inst:ListenForEvent("cycleschanged", OnCyclesChanged) inst:ListenForEvent("phasechanged", OnPhaseChanged) inst:ListenForEvent("moonphasechanged", OnMoonPhaseChanged)+inst:ListenForEvent("clocksegschanged", OnClockSegsChanged) --Season self.data.season = "summer"

I PMed this to @PeterA, but it belongs here. Okay, a few things I've noticed so far: The new networked components (seasons, clock, weather) suffer from the age-old mod kryptonite: file local functions/variables. I know that there is some give and take in this area (file local can help developers), but it kills moddability, and therefore I think it should be used very sparingly. For example, seasons.lua defines the SEASONS and SEASON_NAMES tables as file local (actually, Class constructor local), yet those are clearly tables that would be useful to modders (# SEASONS is a useful thing to know). Them being file local means that we'd have to copy the definition into our mod files to be able to use it, which makes things infinitely more prone to breakage down the line. See the GROUND_TURFS table in components/terraformer.lua for a really glaring example of this problem (and one that has existed forever). The new componentactions.lua totally breaks mod backwards compatibility and is completely mod-unfriendly in general. As far as I can tell, it's not possible to insert new component actions from a mod without some major hackery (hooray for file local tables!). This'll likely need a new mod API function or something. I'm not sure why the CollectAction stuff was moved out of the component files, but I'm sure there was a reason. Most simutil.lua GetX() functions are broken, and only a few have obvious solutions. I've written a bit of code to allow some backwards compatibility: http://privatepaste.com/60889df448 (those old SeasonManager/Clock member functions were very useful). I can't stress enough how often these GetX functions were used in mods.

Nice work. Added to the The Big List Of Mod-Related Code Suggestions.

G) See LocoMotor:UpdateGroundSpeedMultiplier in components/locomotor.lua. Changing the player's locomotor component's slowmultiplier variable to 1 should remove the slowness on creep (webs). E) AddPrefabPostInit. See the API Examples mod.