• Announcements

    • JoeW

      UPDATED - Studio Note & Rhymes with Play Streams Temporarily Canceled.   03/06/2020

      UPDATE (3/19/20): Just a quick note regarding the team at Klei Entertainment. As noted previously, everybody at Klei Entertainment is working from home due to the Covid-19 outbreak. Many of us have been working especially hard to help maintain operations as we all move out of the office and into our homes and with everything being done online, extra time must be spent in organizing conversations and trying to maintain communication. As some of you may know, we have a very open office and we are almost always in contact with each other as we go about our days. Some of us work across multiple teams and that work has become a bit more challenging for everybody.   That being said, at this time the transition has not caused any major disruption in our operations, but it would be overly optimistic to expect that we won't have any delays at all. We're going to have to be especially mindful about this in the coming weeks and make sure we don't take on too much work so we can keep things running smoothly.  We will let you know as we see how these changes affect our timelines.  Thanks UPDATE (3/10/20):
      The test yesterday went well. We got the whole office (mostly) to work from home without significant issue. As a result, Klei Staff that can work from home have been asked to do so until further notice.  This means that we will have to cancel the Rhymes with Play stream until we are all back in the office. This shouldn't affect anything else at least in the short term, but if things change I will update you all here.  Original Post: Hey everybody,  This Tuesday March 10th, 2020 the entire staff at Klei will be working remotely for 1 day in an effort to prepare the studio to work remotely for a little while if the need arises.  Klei is already set up pretty well to allow for working remotely, however we are going to have a one day "dry run" with the whole studio so that we can identify and avoid any issues or downtime that may arise should choose to implement a work from home policy due to COVID-19 outbreak concerns. Unfortunately this does mean that we will be canceling the “Rhymes with Play” Art stream this coming Tuesday, however unless the situation changes we expect everything at the studio to be back to normal Wednesday and we’ll continue our regular stream schedule Thursday March 12th. If the situation changes at all, we'll let you know. Thanks for your understanding.

Mr. Tiddles

  • Content count

  • Joined

  • Last visited

Community Reputation

1,020 Excellent

About Mr. Tiddles

  • Rank
    the Maxwell main


Chester Kickstarter
  • Tweeted support for Chester
Chester Kickstarter
  • Supported Chester - Snow
Don't Starve Together
  • Contributor

Recent Profile Visitors

32,434 profile views
  1. My bad. The fix is just this: local fx = SpawnPrefab("diseaseflies") if fx ~= nil then fx.entity:SetParent(inst.entity) fx:SetLoops(loops) end
  2. Seems like there's an issue with the diseaseable component where latency can cause a crash with the error listed above. I was able to fix it by adding : local fx = SpawnPrefab("diseaseflies") fx.entity:SetParent(inst.entity) I added this part --> fx:DoTaskInTime(0, function() < -- Simply delaying it seems to fix the issue. Adding an "if fx ~= nil then" may also help just in case the flies fail to spawn? fx:SetLoops(loops) end) into the diseasable command within the DoFX function - I think it's pretty safe to assume WHERE in the function Seems like I didn't fix it. Here's the log. server_log.txt
  3. Maxwell Memes: The Sequel

    Stop. Hold the phone, I'm about to blow everyone away: The fences are exactly the white fence skins from ingame - given to us in this year's Year of the Carrat event via random drop or available for purchase in the Builder's Belongings Chest Bundle for $11.50 AUD or regional equivalent. What else is ingame? Abigail. Abigail is white and vaguely fence-shaped. Now notice there are missing fence posts where either the rock dislodged them or perhaps they were built around the rock. Surely there's no logical reason to leave such a large hole in fencing for just a rock, though, right? Abigail is the missing fence post, people. WAKE UP!
  4. My house has not burnt down in the bushires (yet!) and production has continued! Almost finished - just working on the examinations and having to do the voice to fit all the new DST sound effects.

  5. Maxwell Memes: The Sequel

    How it feels to play Maxwell
  6. A possible workaround may be to add another function that's triggered on any right mouse input and makes sure if Warf should be able to dash, but doesn't, it forces them to. My only problem there is figuring out how to check for that specific input as this is newish territory for me.
  7. The issue is actually in the combat action. Actions.lua: ACTIONS.ATTACK.fn = function(act) if act.doer.sg ~= nil then if act.doer.sg:HasStateTag("propattack") then --don't do a real attack with prop weapons return true elseif act.doer.sg:HasStateTag("thrusting") then local weapon = act.doer.components.combat:GetWeapon() return weapon ~= nil and weapon.components.multithruster ~= nil and weapon.components.multithruster:StartThrusting(act.doer) elseif act.doer.sg:HasStateTag("helmsplitting") then local weapon = act.doer.components.combat:GetWeapon() return weapon ~= nil and weapon.components.helmsplitter ~= nil and weapon.components.helmsplitter:StartHelmSplitting(act.doer) end end act.doer.components.combat:DoAttack(act.target) <LINE 962 return true end May I see the rest of your mod to see what's up?
  8. Ah- that would explain it! Changing lag compensation causes the ability to be lost as well, as does relogging into the game. Which sadly, it's still happening. There's also a strange thing that happens - if I have "inst:AddTag("candash") into the OnSetOwner function, you're able to dash after spawning but not after relogging, but the opposite is true if the "inst:AddTag" is in the common_postinit. Regardless that only makes it more stable as picking grass can randomly break it still, but it gives that initial stability. Adding "inst:AddTag("candash")" to both the common_postinit and the OnSetOwner did make it work on both fresh spawns and relogging! Though sustained stability still needs to be adressed. It's an improvement at least. the game was making it seem like it helped to mess with my head.
  9. Really? That was a recent addition and it was happening then. Let me try... And was it working specifically on predictive or even on none?
  10. Like it says on the tin, occasionally performing certain actions (like picking grass) will cause my character Warfarin to be unable to use their dash ability while moving via direct input (holding WASD or mouse 1, clicking to move is fine - only holding the buttons stops it). Relogging also seems to break it. I've noticed Wortox has the same issue even with no mods installed but Warfarin seems to break alot more frequently. Even when I directly copied all of his code into Warfarin's. I've spent a good month or so trying to troubleshoot this, and all I've came out with is: A) It's not a stategraph issue as it doesn't even trigger the pre-act state; B) It doesn't seem to be the test of whether Warf meets the criteria to dash at that moment (IE, doesn't have the "nodash" tag); C) Forcing the character to double-check they've abandoned any failed/succeeded actions doesn't work D) It's really annoying. If any smarter folk than I could pitch any ideas to work around this bug - because it has to be a bug if it's affecting an official character - I'd be much appreciative! And of course, the mod will be attached below. Please excuse some of the sloppy remnants to try and fix the issue littered around the place I may have missed during cleanup. Warfarin.zip
  11. inst.components.projectile:SetLaunchOffset(Vector3(3, 2, 0)) That's the line from the blowdarts you're looking for! It positions the projectile on an X,Y,Z grid. So it's 3 forward(X) and 2 up(Y), and 0 to either side
  12. Maxwell Memes: The Sequel

    I found an oldie-goldie
  13. That's because the tops and bottoms of the arms share the same sprite as far as I can tell.