Jump to content

Where/How is Entity Rendering Handled in the Code?


Lexford

Recommended Posts

TL;DR - Does anyone know which file and code handles how the game loads/unloads entities and prefabs mid-gameplay? Entityscript doesn't seem to determine whether an entity should sleep based on player distance or not, and getting the camera to follow another entity doesn't seem to affect entity render distance, so that code must be elsewhere.


I've been working on a mod that features an entity who should be able to persist and remain loaded beyond the player's render distance. "inst.entity:SetCanSleep(false)" works well enough to keep the entity active off-screen... until they or the player teleports.

If I use a wormhole or telelocate the entity somewhere far, the entity is sent into a strange sleep state that isn't quite Don't Starve's "limbo" state. Their components still run and they're still visible (able to be seen from afar by making the camera follow the entity), but their stategraph and brain seem to be shut down until I (the player) come near them again. After which, the entity can function like normal again, until I travel through a wormhole or it gets telelocated again.

I believe the issue lies with how the game loads/unloads entities mid-game. The entity is able to avoid the "sleep" state when a save is initially loaded with it far away and off-screen, and it can only be put into this "sleep" state when ported into far distances in the middle of gameplay (reloading the save while it's far away will load the entity out of "sleep" again). Does anyone know which file and code determines entity states based on player distance?

Link to comment
Share on other sites

EntityScript handles limbo tag, brain, sg and things in lua.

Actual sleep is handled in c++, which you can't see.

From what you describe, maybe somewhere in lua the off-screen entities' brains are stopped by EntityScript? You can hook Brain.Pause to see who called it.

Link to comment
Share on other sites

21 hours ago, Rickzzs said:

Actual sleep is handled in c++, which you can't see.

From what you describe, maybe somewhere in lua the off-screen entities' brains are stopped by EntityScript? You can hook Brain.Pause to see who called it.

Ah, I see (or rather, can't see)... I have a bad feeling I won't be able to make my mod entity work to its fullest potential if sleep coding is handled engine-side. Well, unless I can find a way to safely tinker with those files as well.

Hmm, how do I trigger this "Brain.Pause" code? It's not DST-exclusive, is it? Even if I can't change how entity sleeping is handled, I would at least like to see the details on how my entity ends up in its sleep state. My only guess for now is that Don't Starve prefers handling gradual changes in distance between the player and entities over abrupt distance changes. That would explain why my entity can run from my render distance and still keep running, but teleportation (or leaving it in an indoor location in Hamlet) sends my entity to sleep mode. I can send screenshots if that helps narrow things down.

Link to comment
Share on other sites

How to hook a function and print its caller in lua using debug library?

 
ChatGPT

ChatGPT

Poe
 
 

In Lua, you can use the debug library to hook a function and print its caller. The debug library provides functions for program introspection and debugging.

Here's an example of how you can achieve this:

lua
-- Define a function to be hooked
local function targetFunction()
  debug.traceback("Caller of targetFunction:")
end

-- Create a hook function
local function hookFunction(event)
  if event == "call" then
    local callerInfo = debug.getinfo(2, "n")
    print("Caller:", callerInfo.name)
  end
end

-- Set the hook function for targetFunction
debug.sethook(targetFunction, hookFunction, "c")

-- Call targetFunction
targetFunction()

In this example, we have a targetFunction() that we want to hook and print its caller. We define a hookFunction(event) that will be called whenever an event occurs during the execution of targetFunction(). We're interested in the "call" event, which is triggered when a function is called.

Inside the hookFunction, we use debug.getinfo(2, "n") to obtain information about the caller of targetFunction(). The first argument 2 specifies the level of the caller stack frame, and the second argument "n" specifies that we want to retrieve the name of the caller function.

Finally, we set the hook function for targetFunction using debug.sethook(targetFunction, hookFunction, "c"). The "c" argument indicates that we want to hook the function on calls.

When you run this code, it will print the name of the caller function of targetFunction.

 
 
 

give a example that hooks a function and print who called it, including the caller's name, source and line defined.

 
ChatGPT

ChatGPT

Poe
 
 

Certainly! Here's an example that hooks a function and prints information about the caller, including the caller's name, source file, and line number where it was defined:

lua
-- Define the target function to be hooked
local function targetFunction()
  debug.traceback("Caller of targetFunction:")
end

-- Create a hook function
local function hookFunction(event)
  if event == "call" then
    local callerInfo = debug.getinfo(2, "nSl")
    if callerInfo then
      print("Caller Name:", callerInfo.name)
      print("Source:", callerInfo.short_src)
      print("Line:", callerInfo.currentline)
      print("----------------------")
    end
  end
end

-- Set the hook function for targetFunction
debug.sethook(targetFunction, hookFunction, "c")

-- Call targetFunction
targetFunction()

In this example, we have the targetFunction() that we want to hook and print information about the caller. We define a hookFunction(event) that will be called for each event during the execution of targetFunction(). We are interested in the "call" event.

Inside the hookFunction, we use debug.getinfo(2, "nSl") to retrieve information about the caller of targetFunction(). The first argument 2 specifies the level of the caller stack frame. The second argument "nSl" specifies that we want to retrieve the name of the caller function (n), the source file name (S), and the line number where it was defined (l).

If the callerInfo is available, we print the caller's name, source file, and line number. The short_src field of callerInfo contains the source file name, and currentline contains the line number.

Finally, we set the hook function for targetFunction using debug.sethook(targetFunction, hookFunction, "c") to hook the function on calls.

When you run this code, it will print the name, source file, and line number of the caller function of targetFunction.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

Please be aware that the content of this thread may be outdated and no longer applicable.

×
  • Create New...