pickleplayer

  • Content Count

    441
  • Joined

  • Last visited

 Content Type 

Profiles

Forums

Downloads

Klei Bug Tracker

Game Updates

Hot Lava Bug Reporter

Everything posted by pickleplayer

  1. Do you know how to look at the game files? It was a little easier back when I started modding, but the scripts are tucked inside of a zipped folder now. It's still a great thing to have access to, and essential for anyone learning to mod. Using notepadd++'s "find in files" feature centered on the scripts folder is the best way to quickly learn how things are used in the game's programming. There are a few things that are built into the engine that we can't see, but it's pretty rare.
  2. If you take a peek into freezable.lua, I see there is a function called Unfreeze() You might want to give that a try. Looking into component files is always a good way to get an idea of what you can do with them. inst.components.freezable:Unfreeze() Alternatively, I believe the frozen state is, well, a state. Meaning that you could force someone out of it by simply forcing them into another state, like inst.sg:GoToState("idle") I'm unsure if there could be consequences to doing this manually, like if frozen values would build up if not removed properly, but it's something to consider. EDIT: Oh, I just noticed you were trying to call freezable component functions on inst by itself. I'm surprised this doesn't just crash the game. You're probably looking for inst.components.freezable:AddColdness(10) But yea, RemoveColdness() doesn't exist. Buuut, I think you can put negative values into AddColdness()
  3. I always get paranoid about showing my mods before release, but I don't want a repeat of what happened with my first person mod, so I should get this over with. I'm looking for a small group of people to try out a closed-beta of my mod and give me some feedback. I'm not quite ready to throw it out to the public, though. If anyone is interested, send me a message and I'll get you started. This just makes it easier for me to keep tabs on how many people have it. All I ask is that you try not to post public screenshots/videos/streams of the mod. I have trailers ready and I want some things to stay a surprise. I'll delete this post once I have enough testers, but anyone who might be interested can message me even after this post is gone.
  4. Unfortunately, since this is part of a local function within the crabking's prefab file, it looks like you might need to edit it's code directly in order to disable it. That would mean just copying crabking.lua into your mod's prefab folder and simply removing that line of code. This is generally considered bad modding practice because it will prevent other mods from changing the crabking's code, and it also won't get updated if Klei changes the crabking's code in the future. But hey ¯\_(ツ)_/¯ sometimes sacrifices must be made in the name of science
  5. Oh my god I can't believe I never thought to try that. I had to put it in a very specific spot and add a blank collisioncallback to get it to work but it works! Thank you guys so much.
  6. Oh boy, it's pretty huge. I replicated the issue and pasted it into an outdated esctemplate mod for you to look at instead. You can see the yellow circle that spawns when first loading into the world is given a velocity, and the second one that spawns isn't. A few more fun things I found while testing these. The physics objects spawned on initialization also loses the ability to change velocity if: They don't have a physicsCollisionCallback function (even a blank one will fix it) During the first frame of existence; they are placed within 1 square unit of point 0,0,0 on the world map, and any player spawns close enough to see it on screen. fun.
  7. Maybe not all of the unique perks. Some of his powers might require a bit more behind them than just tags. His storyteller perk also requires a component inst:AddComponent("storyteller") and a few local functions in his character file would need to be copied over. Woby also has quite a bit of custom code required in his character file. You could probably replicate it by copying it over to your character's file.
  8. There's always a chance I could be overlooking something, but I've spent quite a bit of time breaking down this issue into it's most basic components and trying different physics objects. It seems to me it boils down to this: local master_postinit = function(inst) --A player's master_postinit --This one works fine inst.components.hurtboxes:SpawnPlayerbox(0, 0.7, 0.35, 0.7, 0) inst:DoTaskInTime(0, function() --This one doesn't inst.components.hurtboxes:SpawnPlayerbox(0, 0.7, 0.35, 0.7, 0) end) It doesn't seem to matter what other factors are at play, as long as the physics object was spawned at least one tick after a player has, it's velocity can't be changed. I had wondered this as well, but it shows that they are active.
  9. I've tried SetMotorVel as well and that has the same result, unfortunately. I hadn't tried the physics version of teleport until just now, but that seems to work just fine, much like Transform:SetPosition() does. Strangely enough, print logs show that the frozen physics boxes "think" they have a velocity that matches the players, despite them staying perfectly still.
  10. Ok, so I have a set of physics objects that move around screen and follow the player like hitboxes, but I've recently noticed some issues with some of the hitbox physics properties. Every tick, the hitbox's position is snapped to the player and it's velocity is supposed to update to match the player's current velocity as well. The player starts with a single hitbox that spawns as part of their initialization, and continue to follow them around. But for any hitbox spawned after that, attempting to change it's velocity "box.Physics:SetVel(x,y,z)" does nothing, yet it can still be moved around the map with "box.Transform:SetPosition( x,y,z )". Strangely enough, it's not just "any hitbox after the first" that has this issue, it's any hitboxes spawned after the player has already spawned. If you put a single frame of delay on the creation of the first hitbox, the same issue happens. So I loaded the mod onto a multiplayer world and joined with a second account and what did I discover? The first person to join the server had a normal functioning hitbox, but any player who joined after that had a frozen hitbox that couldn't change velocity. UNLESS both players joined at the exact same time, then both of their initial hitboxes work fine. Basically, if anyone is online at the moment a physics object is created, that physics object's velocity can't be changed, if it's mass is 0. (well, it can also be fixed by changing the Physics:SetMass to 1 instead of 0, but that means overlapping hitboxes collide with each other and gravity also applies to them, so I don't want that) It's kind of an obscure bug and I'm guessing this is something with the physics engine that we might not have access to. But just curious if anyone else actually works with physics objects out there and knows a solution to this.
  11. Last I checked, the spriter file does contain a preview "animation" to show what your assets will look like in-game, and it's called "BUILD_PLAYER". It's not any of the actual in-game animations, but a replica of the 3 different idle poses. Unless they removed it in a recent update or something, it should still be there. But if you're looking specifically for actual in-game animations, I think we're out of luck. The sprite sizes used in esctemplate are resized, and so trying to paste them over exported DST player animations will probably look distorted in spriter (as you mentioned above) And I don't know if there's any easy solution to that.
  12. Oh, yea that would be a pretty simple way to do it. Thanks! I'm sure your method would have worked, but I realized recently that despawning the player after joining would cause other issues with other parts of the mod, so I had to find an alternative. I did finally figure out how to despawn them as they leave though. Attaching "DeleteUserSession(inst)" to a the playercommon's OnDespawn function does the trick for everyone except a local host. Luckily, this doesn't need to apply to the host, so it works out well for me.
  13. So I'm trying to create a scenario where anyone who joins the server, even if they have played on the server previously, is forced to pick a new character and respawn as if it was their first time joining. I imagine the cleanest way to do this would be to run TheWorld:PushEvent("ms_playerdespawnanddelete", player) as the player disconnects, but haven't been able to get this to work because TheWorld:PushEvent("ms_playerdespawn", player) is already pushed as soon as the player disconnects, and so I'm pretty sure it's trying to delete the player twice. It doesn't crash, but the main menu becomes frozen in time and breaks the game until you restart. If I can't get the character to be removed on disconnecting, another lazy alternative would be to just despawnanddelete a player whenever they connect to the server with an existing character. Unfortunately, "ms_playerjoined" happens any time a player spawns, regardless of if it's their first time picking a character, reconnecting to an existing one, or respawning as a new character within the same session. So I'm kind of unsure where to go from here. Maybe there are some other events that I'm not familiar with, but I don't do a whole lot with server events so I'm hoping someone will know more than I do.
  14. In the singelpayer version of Don't Starve, there are world generation settings that generate the world into islands. But last I heard, the devs were unable to bring that feature into the DST version. That was some years ago though, so maybe there have been changes or ways around it discovered since then, but that is the last I heard on that topic.
  15. It looks like one of the anim files I was relying on was removed a while back and I never noticed. Does anyone happen to have a copy of corner_dude.zip?
  16. Each character has their special properties code in their prefab files. so in the games files you'd find it in scripts/prefabs/wortox.lua You'll notice a lot of similarities in the way it's structured compared to the extended character template, like how it also has a common_postinit and master_postinit function. you'll pretty much have to make your template's code look like his. and he has a lot of code to copy over.
  17. Give it a try and see what happens! Don't be afraid to get messy with things that may or may not work. Trying things out and running them in-game to see what they do is the best way to learn how to mod. There's a good chance that what you have is a step in the right direction.
  18. Things are looking pretty good with this change! To test it out I ran the sim at double speed while running a youtube video, rendering a video, and screen-capturing to get the game down to 20 fps. But the result is a 100% hit rate compared to a 30% hit rate without the change. And all without bloating hitbox lifespan under normal conditions. Thanks!
  19. I think Abigail's AOE is more of a health drain than an actual "attack." I think a better place to start would be to look into special attack abilities that characters have. Wigfrid's file (which is wathgrithr.lua for some reason) has a "heal on hit" mechanic would be a great starting point, since the "battleborn_onattack" function has pretty much all the data you'd need there already, minus spreading damage out to nearby enemies. For splash damage, groundpounder.lua has some basics about damaging nearby entities in it. Something like this is a basic start local x, y, z = inst.Transform:GetWorldPosition() local ents = TheSim:FindEntities(x, y, z, 3, nil) for i, v2 in ipairs(ents) do if v2 ~= self.inst and v2:IsValid() and v2.components.health ~= nil and not v2.components.health:IsDead() and self.inst.components.combat:CanTarget(v2) then self.inst.components.combat:DoAttack(v2, nil, nil, nil, self.groundpounddamagemult) end end This was mostly just copied and pasted scraps from that file, so you'd have to replace any of those variables with whatever they would be in your case
  20. Oh man guys, I gotta be real, I'm not so hot with coding terminology but I'll do my best So basically forego the physics collisions for just checking for entity proximity every frame? I guess that would be one way, but I really like being able to use physics entities because you can attach motors and stuff to them. Also with all the varieties of shapes hitboxes can take, mathing them all out would be rough. and I just finished the 3rd hitbox rewrite, i would hate to do another one. But yep, it's for that mod. Things are coming together, now I'm trying to polish off these rough edges that have existed since the beginning. Ok I'm pretty sure I get what you're saying. Spawn a dummy hitbox on top of every hitbox for the purpose of detecting a collision so that it can then be marked as eligible for removal? I was thinking of something similar at one point but I was worried doubling the number of active physics detections on screen would reduce performance. But I've been tinkering around with it for a while and I think I got something started. So this physics partner attaches itself to the hitbox, and as soon as it collides with it once, it marks it and removes itself. Once I'm done messing with it I'll let you know how it turns out, but I think this might do the trick
  21. So I created a hitbox system that spawns an entity with a given shape and size that uses physics collision callbacks to determine if it has come into contact with anything. The hitbox is given a "lifespan" for number of frames it will exist before it gets removed. This has worked pretty good for the most part, but there is one flaw. For cases where the hitbox needs to exist for a very brief period of time (1 frame) if the game goes through a lag spike during that time, it can cause the hitbox to "skip" it's physics collision check before it gets removed on the next frame. I've been trying to think of ways around this, like if I could somehow tell if a physics entity has been active long enough to run at least 1 physics collision check, but I haven't had any luck so far. Currently, making lifespan a 2 frame minimum seems to help, but it's such a lousy solution and is still not 100% safe from lagspikes. Does anyone else have any ideas?
  22. That's quite a few mods... I'm not that surprised it crashes. It's likely there are at least a handful that are causing issues because of incompatibilities with each other. If you can figure out which ones are crashing, you can disable them one by one until you have a set that works. Since you aren't getting a crash screen, you'll probably need to check the crash log for clues. If you're on a pc, it's usually Documents\ klei\DoNotStarveTogether\client_log.txt If you can post that text file in here, that might help
  23. Can you show us some of your code so we can get an idea as to what you're going for? It can be hard to troubleshoot coding issues without the code