Leonardo Cox

  • Content Count

  • Joined

  • Last visited

Community Reputation

621 Excellent

About Leonardo Cox

  • Rank
    Senior Member


Recent Profile Visitors

3569 profile views
  1. How is this working as intended when they don't do this in the surface
  2. The difference between this one and that one is that this is a suggestion to improve said lighting rather than claiming its a bug. We were asked to make a seperate bug report specifically for this suggestion by a dev.
  3. The issue just fixed itself after hours of retrying. I don't know what in specific was wrong.
  4. I haven't played a genuine game of Don't Starve in over 2 years.
  5. 10kb is the filesize for all the modinfo.luas as expected. The size of the mods I'm updating varies greatly from 10mb to 120mb (not compressed, current mod is 22mb). There is a workshop filesize limit, but these mods do not reach these heights (the update actually reduces the filesize since its carrying optimizations, so its definitely not filesize cap ). Updating the OP with a bit more information that I've found in just a sec.
  6. h, I'm just wondering if anyone else has encountered this issue recently and knows how to beat the mod tools back into submission: I'm in the midst of updating several mods which kind of need to be updated to work together, alas ds mod tools broke on me with this error message: Pretty standard error message that doesn't tell you anything, so I went to the log for more details on why it failed: 13:38:44: Progress: Writing mod data file... 13:38:44: WriteFileToCloud() Writing [C:\Users\Leonardo\AppData\Local\Temp\modA31A.tmp] to [mod_publish_data_file.zip] 13:38:44: Steam file exists. 13:38:45: Steam FileWrite ok. 13:38:45: Start FileShare [mod_publish_data_file.zip] ... 13:38:45: Progress: Uploading mod data file... 13:40:49: OnShareModFileResult 13:40:49: EResult 16, ffffffffffffffff 13:40:49: EndProgress FAILED: Failed sharing mod data file. 13:40:49: MainFrame::OnUpdateComplete FAILED: Failed sharing mod data file. Nothing too helpful here besides EResult being 16 (it was 10 before) but I don't know what these errors actually mean. I've looked through the log to see if it was having difficulty with any specific file... and nope, it zips everything just fine. I've tried uploading a new (basic 2-file mod) to see if I was just having trouble sending large mods to be uploaded. Alas, same error message. I've also tried the following: Restarting mod tools Verifying file cache Uninstalling/Reinstalling mod tools Restarting PC Restarting Internet Changing Download Region At some point there was a brief period where it fixed itself for seemingly no reason and I was able to update again. But it broke again shortly afterwards. If anyone has any ideas of what I could try to make it work again, please let me know, I'm in a pretty awkward spot with these mods. Update 2:37 PM According to fellow modder hornet EResult 16 is timeout error, after some more tests it seems like after getting EResult 16, you are blocked from any further attempts (which results in EResult 10) for about 30-45 minutes. Still don't know why I'm getting the timeout as my internet, while not spectacular, should be more than sufficient to upload mods (30-35 mbps download, 1.75-2 mbps upload as of writing these). Will be attempting to change download region as a suggestion from someone. ModUploader.log
  7. Looks very interesting, I don't get to play much but I'll be sure to spread this around to some friends.
  8. Strange that those last few lines weren't in my log. Let me ensure its not a client mod of some sort.
  9. Upon entering the Item Collection screen and leaving it idle for a few seconds, it will crash and close the game. No Error was reported in the log, but I will attach it below:
  10. 2021 is off to a great start ain't it
  11. Before players could adhere to min_attack_period in their combat component to allow attacks to have cooldown. They no longer pay attention to attackperiods and can attack regardless if CanAttack runs true or not. While this only causes issues for mods, it is a pretty big bug for things like Playable Pets where some mobs have attackperiods for balance purposes.
  12. in stategraphs/commonstates.lua: name = "run_start", tags = { "moving", "running", "canrotate" }, onenter = function(inst) if fns ~= nil and fns.startonenter ~= nil then fns.startonenter(inst) end if not delaystart then inst.components.locomotor:RunForward() end inst.AnimState:PlayAnimation(get_loco_anim(inst, anims ~= nil and anims.startrun or nil, "run_pre")) if fns ~= nil and fns.startonenter ~= nil then fns.startonenter(inst) end end, fns.startonenter gets called twice for the run_start state (line 305 in my current build of DST). As far as I'm aware, none of the vanilla mobs make use of fns.startonenter, but it can causes issues to modded mobs that might use them.