• Content Count

  • Joined

  • Last visited

Community Reputation

4665 Excellent

About CarlZalph

  • Rank


Recent Profile Visitors

14109 profile views
  1. Translating text can be a hard job to do since all of the nuance existing in languages. Some things can't be directly ported over since the society's context is lost like jokes or phrases common said in one area but not another. Having it for a game is even more so context sensitive as some details are very important while others are there for fluff. I think I'd rather have a modder do their best and let the community amend to it than a potentially third party translation studio as the modder (should be) already invested in the game itself to know what is or isn't mandatory information. But yeah I can see where you're coming from. It might be feasible for Klei to get some official translations done, but that's a large time and capital sink. Perhaps with Tencent's stake it might be more feasible now to do it.
  2. I feel that there's still a large stigma for character mods in specific that deter players from giving them a go. Seems to me like a waste of time to make something that only such a small fraction of players would want to experience.
  3. Upvalues are from the debug library and are used for when you can't access a variable directly. Take for example: somefile.lua: local a = {} a.val = 27 local b = {} b.test = function(self) return a.val + 2 end return b You don't have direct access to 'a' and must get it through upvalues from the function 'b.test'. What you've describe is function hooking where you either alter the arguments or the return value. -- Given a = function(b, c) return b + c end -- Do local a_old = a a = function(b, c, ...) -- Prehook to edit arguments b = b * 2 -- Call original local rets = {a_old(b, c, ...)} -- Posthook to edit return values rets[1] = rets[1] * 3 return unpack(rets) end Reason for the '...', the table packing and unpacking is to help future proof the function hook. If Klei added more parameters then your mod won't break, assuming the parameters you're messing with didn't change order. You could also freely not call the old function entirely if you wanted to block it, too. Definitely is a slow going thing, lots of parts to understand and look over.
  4. I learned everything I know about DST's codebase by looking over it. There really is no API documentation other than the code there. Events happen on both sides but you have to look where they're generated from. If it's a server-side component that's pushing the event, then the client won't know of it at all. It's a loop of 'I know what I want to do' to 'searching in files recursively' over the scripts folder to try to lure out what you're after.
  5. ThePlayer is the client's version of the player entity they have control over. For the server side you never use ThePlayer in any part of the code. In your case here, the argument being passed in the function "player" is what you would use.
  6. Currently there's no wall that would block the bats. Like DonCubone there stated they do try to path first and if there's a path they try to follow it. I used this to make butterfly traps a while ago: Now, they do collide with creatures. So if you can trap creatures in a barrier around the hole using walls that the bats won't attack, then you could trap them. I don't know of any creature that won't attack the bats or the bats won't attack, so I don't think that's useful information. I find the best solution for bats is to have some bunnymen houses around the holes.
  7. It's because the combat component has EngageTarget which when the player is starting to punch is considered engagement, and it tries breaking the leader-follower relationship. Then there's a case in the follower component that also tries to clear the relationship. But there's a handy function that stops both cases in one call: hound.components.follower:KeepLeaderOnAttacked()
  8. Which hasn't changed for a long while, I made an infographic showing how you can extend a flingo to have about 6.32 times the area coverage given 4 lure bulbs since the bulbs have highest priority to start smoldering- they will smolder first if available. Good for bigger bases.
  9. Aye that's a good one, I had to do this for one of mine: I wonder if we could compile a list of these 'private' vars that there could be a pass done to make them no longer 'private' since it really makes it harder for modding. Like there's 81 components that have the private-public system in place, most of them from carry-overs from DS. But there are a bundle of DST-exclusive ones that also follow this backwards system. Doing this would inevitably break all mods currently using upvalues to try to find these 'private' vars, but the upvalue method is already prone to breaking if Klei ever edited any of the functions being used as a basis anyway. Could preserve the mods by having a dummy local variable point to the new ones: -- Old local b = {} local bobs = "your uncle" b.a = function(self, ...) print(bobs) end return b -- New local b = {} local bobs = "your uncle" b.bobs = bobs -- "public" accessor for mods b.a = function(self, ...) local bobs = bobs -- Dummy for upvalue print(self.bobs) -- Use new interface end return b To add to the list: A real keybind picker for mods to use instead of the usual "scroll through a list of user-defined keys" with the mod config menu. Mods that define the available keys are not the same between mods, some support F# keys and others do not for example. Having a central means to let mods have a bind menu popup in the config would stop the inconsistencies while adding easier functionality.
  10. For other functions, look at modutil.lua, this file contains the default sandbox environment for all modmain files. env.RemapSoundEvent = function(name, new_name) initprint("RemapSoundEvent", name, new_name) TheSim:RemapSoundEvent(name, new_name) end For example on seeing how the remap works.
  11. Entities that have data on the C-side are hard to get at. Animation, Tags, etc. I propose some LUA proxy functions to output the appropriate datums being hidden but are exposed using the ent.entity:GetDebugString(). Currently to get a networked entity ID, useful for uniquely identifying an entity as a client, a table of tags, an animation, or an animation frame number you have to use the GetDebugString function. It's not efficient and could be done more directly without having to dump a blob of data to parse. ent.Network:GetID() -> Returns either the number index or a string holding the unique identifier. It's not used anywhere else in the code base but it is useful for client mods to keep track of unique entities. Having it as a number or string doesn't matter. ent.AnimState:GetAnimation() -> Returns the currently playing animation string if it is, else nil. ent.AnimState:GetAnimationFrame() -> Returns the currently playing animation's frame number if it is playing an animation, else nil. ent.entity:GetTags() / ent:GetTags() -> Returns a table of all of the entity's tags that it has, or an empty table if there are none.
  12. It's much easier here in DST. In your item's equippable's OnEquip: owner.components.playervision:ForceNightVision(true) owner.components.playervision:SetCustomCCTable({}) You can set the custom colour cube table to something else if you want some display effect like Woodie's sepia tone or moggles/etc. Then with OnUnequip: owner.components.playervision:ForceNightVision(false) owner.components.playervision:SetCustomCCTable(nil)
  13. I had a similar situation and thankfully the other party decided to take actions to resolve it from being publicly available on the workshop. I share your sentiment entirely with the DMCA telling the offending party your information to be a harsh overreach. With today's technology at peoples' fingertips and how easy it is for someone to make a false accusation to ruin one's reputation and job standing, it's just bad form. I feel like Valve should force the other party to also provide the same details if they wish to fight the DMCA and ensure that both parties are who they say they are before arbitration occurs. As it stands by the wording, it makes it out like you're going to offload your information to the other party upon sending the DMCA form. I don't know if this is the case, I'm going purely off of the form Valve has. Further, if the other party just lies about it and they're in another country entirely where these laws and such don't really exist, then it gives them more power to extract such information out of anyone they see fit. Edit: I have went by and notified a handful of affected users that their mod was reposted in their mod's comment sections. If either of these parties take action, then it could be a domino effect to get the rest just wiped as repeated violations of DMCA can get your entire Steam account terminated. Edit2: So it begins.