• Content Count

  • Joined

  • Last visited

 Content Type 




Klei Bug Tracker

Game Updates

Hot Lava Bug Reporter

Everything posted by Serpens

  1. thank you very much, looks much better now But I'm not sure if it is intended to keep the following local variable outside of functions: local HEALTH_PER_DAY = TUNING.EYEOFTERROR_HEALTHPCT_PERDAY*TUNING.EYEOFTERROR_HEALTH 1) The problem with mods remain for this local variable (same for local MAX_GAIN_DAYS) 2) This HEALTH_PER_DAY seems to be also used for the twins, while it based on the health of eyeofterror -> not sure if this is wanted, but I doubt?! Will open a new bugreport in few days if I receive no response here, to make sure it is seen.
  2. Hello, I'm the author of "Automatic Health Adjust" mod: This mod automatically adjusts the health (TUNING and current/max health component) based on the current player number. Unfortunately your new eyeofterror.lua script uses alot of local variables that are filled directly at gamestart (EYE_DATA, TWIN1_DATA,TWIN2_DATA) which can not be altered at runtime. This makes my mod unable to change the health of Eye of Terror / the twins based on current player number (without heavy "hacking"/overwriting big parts of the script), since changes to eg. "TUNING.EYEOFTERROR_HEALTH" at runtime, do not affect EYE_DATA and other local variables. Of course you can design your code as you want, but it would be much more modding friendly to use another design without local variables, so mods work better. Giving the twins a health value independent of EYEOFTERROR_HEALTH would also be better, but is a minor detail. Serp
  3. Regarding starting worldjumping within caves: I'm no shards expert and it is too long ago to remember all consequences... Not sure if some code is only possible at master server or what the reason was for only adding worldjump component to the master server... So if you are no expert on it as well, I would suggest to try workarounds. So either give the player in caves an item/recipe that they need to enable on the master server. Or use some slave to master communication code, so the Gateway in caves notifies the master server to start the worldjump (in this case you would need GEMAPI mod, to make sure the jumpdata from players in caves is saved)
  4. Thanks, you should REALLY read all of my text in the tutorial linked above. I think nealry everything (except jumping within cave) can be done this way, without copying modifing anything of my code. For example the last post in this tutorial describes how you can save and load your personal "jumpdata". So you could save and load the equip slots this way, regardless of my code elsewhere. And the first post in that thread describes how you can create predefined worlds the player will hop one after the other (just like in adventure mod). do you already know how to do that? I'm not aware of a way to achieve this, without copy/pasting alot of code from that mod.
  5. Hi (link to my mod link to tutorial how to add your own stuff ) so I think it is best if you first describe exactly what your mod should do. I still don't understand it 100%. From what I think I understand so far: a) You want the ancient gateway work like a teleportato, so worldjumping to a new world. -> in my adventure mod you can also jump with maxwells door in the first world, so the teleportato or the parts are not mandatory. It should be possible to replace it easily with the ancient gateway. b) Since this gateway is within caves (non master) and my mod currently only allows worldjumping on master shard (forest) we need an adjustment here, right? -> I can add this to my "API" to allow this. Open questions: 1) What kind of worlds should be generated when worldjumping with the gateway? 1.1) Should the previous world be destroyed and a new world generated, like my mod currently does? Or do you want to create new worlds that exist next to each other (more shards), which would be beyond my knowledge? 1.2) And how should the worlds look like? Are they just a random world/based on game settings ? Or are they predefined worlds, like in my adventure mod? 2) at the mod page you mentioned "health caps" no clue what you mean by this: Max health for mobs? Or for players? And what will these caps do or are they a requirement? 3) What do you mean by "body slot" and those equipment slots? For what purpose do you "take them into account"? As requirement of jumping to the next world is possible? Or are you talking about transfering items to the next world? Please tell me more about your plans. Only then I can decide if I add the needed changes on my side to the API (see tutorial above) or if they are by far too much and we need another solution.
  6. The current function in consolecommands.lua looks like this: -- Despawn a player, returning to character select screen function c_despawn(player) if TheWorld ~= nil and TheWorld.ismastersim then --V2C: need to avoid targeting c_spawned player entities --player = ListingOrConsolePlayer(player) if type(player) == "string" or type(player) == "number" then player = UserToPlayer(input) end if player == nil then player = c_sel() ~= nil and c_sel():HasTag("player") and c_sel() or nil end if player == nil or player.components.playercontroller == nil then player = ThePlayer or AllPlayers[1] end ------------------------------------------------------------------- if player ~= nil and player:IsValid() then --Queue it because remote command may currently be overriding --ThePlayer, which will get stomped during delete player:DoTaskInTime(0, dodespawn) end end end -> when entering a string or number as player, it tries to do: player = UserToPlayer(input) while input is not defined.
  7. Feature Request: Could Klei please add a way for mods to change existing settings? For example add more season-length options to the season settings. Currently this is not possible without again alot of work and overwriting game functions, while it would be so damn easy for Klei to add this option. I could write you the few lines code you need to add, to also allow replacing/merging existing settings. edit: was not too complicated, but only thanks to upvaluehacker. Following code in modworldgenmain.lua: -- ## Add more options to existing game settings. -- this is an example to add 3 and 6 days to all season lengths. Requires upvaluehacker (google for it if you dont have it) local UpvalueHacker = GLOBAL.require("upvaluehacker") local customize = GLOBAL.require("map/customize") local WSO = require("worldsettings_overrides") local RefreshWorldTabs = UpvalueHacker.GetUpvalue(customize.RemoveCustomizeGroup, "RefreshWorldTabs") local customize_descriptions = UpvalueHacker.GetUpvalue(customize.GetDescription, "descriptions") local new_seasonlengths = {{ text = "3 days", data = "3__daysseason", pos=1 },{ text = "6 days", data = "6__daysseason", pos=2 }} for _,length in ipairs(new_seasonlengths) do table.insert(customize_descriptions.season_length_descriptions,length.pos,length) end UpvalueHacker.SetUpvalue(customize.GetDescription, customize_descriptions, "descriptions") RefreshWorldTabs() -- refresh to display new settings local seasons = {"autumn","summer","spring","winter"} for i,season in ipairs(seasons) do local old_fn = WSO.Post[season] WSO.Post[season] = function(difficulty,...) if string.find(difficulty,"__") then local diff_split = difficulty:split("__") -- this way we det the desired length number from aboves data string GLOBAL.TheWorld:PushEvent("ms_setseasonlength", {season = season, length = diff_split[1]}) elseif old_fn~=nil then return old_fn(difficulty,...) end end end ---------------------------
  8. The final solution to the question: How does a mod change Pre/Post settings on world-generation, without forcing them on every load is the following code. We (penguin0616 and I) spent over 50 hours for this, while it would be a "one liner" for Klei to simply add modsupport, so mods can easily change them... And my teleportato mod is still not completely made compatible to that QoL update, guess it will take several more hours.. now you see why I thought about abandoning my mods...) In modworldgenmain.lua: local overrides_forest = {dropeverythingondespawn = "always"} -- put your Pre/Post settings you would like to load here local overrides_cave = {dropeverythingondespawn = "always"} local WSO = require("worldsettings_overrides") local savedata = nil local new_game = true local function GetSaveData() if new_game then if savedata then return savedata end local i = 1 local stack_i = 3 -- we increment this in case another mod is overwriting a function, to make sure getlocal still works. while true do if stack_i>20 then --give up return nil end local name, value = GLOBAL.debug.getlocal(stack_i, i) -- Level 1 is where we are now, Level 2 is our Pre function calling this, level 3 is gamelogic.lua:362 or gamelogic.lua:367 depending on the savedata. if name then if name == "savedata" then if value.meta.SERP_MOD_HAS_OVERRIDEN then -- only do it once per world new_game = false -- do not try it again, it is no new game, so no need to find savedata again. return nil end savedata = value savedata.meta.SERP_MOD_HAS_OVERRIDEN = true return savedata end i = i+1 else stack_i = stack_i+1 i = 1 end end end end for i,PrePost in ipairs({"Pre","Post"}) do for name, fn in pairs(WSO[PrePost]) do if overrides_forest[name] or overrides_cave[name] then local old_fn = WSO[PrePost][name] WSO[PrePost][name] = function(difficulty,...) if new_game then if not savedata then -- only when it is a new game GetSaveData() end if savedata then if"forest" then if overrides_forest[name] then[name] = overrides_forest[name] difficulty = overrides_forest[name] end elseif"cave" then if overrides_cave[name] then[name] = overrides_cave[name] difficulty = overrides_cave[name] end end end end if old_fn then return old_fn(difficulty,...) end end end end end
  9. thank you. but none of them is a good solution, making it incompatible to other mods that want to change seasons... My mod should change the season once when starting the world the first time. After that, all other mods should be able to do whatever they want (eg. an item which is able to change season length or whatever). So I guess I will do a PostInit for the world, then call WorldSettings_Overrides.Post["autumn"]("noseason") or similar (or directly the PushEvent) and try to remember, that I called it once, to not call it again on next loading. Still no good solution, but better. edit: ok, only calling this does not work, because the change is not saved O.รด really mod-unfriendly (because it means an item can not easily change season length or so midgame). Will see if I can instead override the setting... ... but this also won't help -.- because it seems when loading a game, it will always take the settings chosen in the worldscreen. All in all I come to the conclusion, that your code is indeed the only viable way to achieve my goal, but it still makes it incompatible to other mods doing the same... edit2: Ah no, it would be better if my mod could change the settings on the worldscreen after world was generated. This way the game would save the setting and the users are able to change them, if they don't like them. But how to do this!? edit3: Solution: because of steam apiv2 I forgot to look at your (Zarklord) worldsettings mod (because I did not find the new location of mods). But I will now do it, like you did it there, simply changing eg. and then reload the world once per game. This will change the settings on the worldscreen and if the user is unhappy with it, they can simply change it to whatever they want. Modding after that QoL update:
  10. try to surely reproduce it and disable mod by mod to find out which is causing it. Then report it to the author. Most likely a mod that deals with clock, like nightmare pahse indicator or combined status.
  11. I really dont know why the devs changed that without any anouncement or sth like that. I'm very disappointed about the latest update and the bad communication. See here:
  12. maybe this mod can help, but it crashes for clients, see my post in the comments there:
  13. maybe look instead at the worldgeneration code from stuff that spawns in the ocean? Then generate a setpiece there with a boat and a spawnpoint on it. And look at the wilderness-mode code, to see if it is possible to spawn your character there, instead of the portal (if not you can teleport him after game start to the boat) it is still quite difficult, so I won't help you more. But you may tkae a look at some of my mods which add/change setpieces: but you will also find some functions like "SpawnPrefabAtLandPlotNearInst" here, maybe you can rewrite them to your use:
  14. thanks. @zarklord_klei Could you please add this anywhere in your tutorial from this update? I mean it is a little bit important for modders to know where mods are stored. And it is important to be able to unpack this new "xyz_legacy.bin" folder. (edit just like a zip file) I first thought you are hiding your own mods, when I did not found them after subscribing, sorry for that. But still, everyone needs to be able to unpack and read mods, also from others. And how should modders proceed now? Still store their unpacked mods in the previous folder? Or store it somewhere save, because they might get deleted? Any guidance about this change would be helpful.
  15. any news on this? is this a bug that will be fixed or do I need new code to force specific settings?
  16. I think you made everything correct, but this new mechanic is still bugged. not 100% sure though.
  17. use my mod as example: search for the line "AddComponentPostInit("finiteuses",function(self) -- unlimited weapons/tools" to change the duration only for your prefab. My code changes it for everything with "finiteuses" so also weapons. If you dont wan to change weapons you need to add an if condition to catch all weapons. Depending on the modsettings the duration can be unlimted, but it can also be higher/less than default. And for faster work (less needed hits), you can do in your postinit of your character this: inst:AddComponent("workmultiplier") inst.components.workmultiplier:AddMultiplier(GLOBAL.ACTIONS.CHOP, multiplier, "your_unique_naming")
  18. you just need to make sure that all players have the same version. So either send them the files directly (without steam) or make sure all of them are your steam friends, so they can download the hidden mod (edit: thought "hidden" already means "friends only"). And make sure that the version on your PC matches the version you uploaded to steam/gave your friends.
  19. you can also link the most important mods here and maybe someone is going to update the mods.
  20. thanks for this tutorial: so regarding bugfix from the DST devs I can only quote penguin0616: which is still present it seems.
  21. ok thanks. I still don't get why my code version does not work (when remobing the replica), but this container stuff is really specific and really terrible , so I will just accept the new solution One thing you mentioned elsewhere, but you should add it here to your tutorial: The name of the containerparams, so currently above "my_container_params", needs to match the prefab name you want them to use on. That means if you want to add 3 things with container, while all of them should use the same size of container, you still need to add all three of them to the containerparams. And you dont need that big code if you just want to use and exisiting size/typ of container. You can also do: containers.params.my_prefab = deepcopy(containers.params.chester) to use the same like chester. edit: deepcopy is important, because otherwise you would also change chesters container, when you change your new one, since they would be linked)
  22. thanks, but is the new code complete? I guess at least a line like: inst.components.container:WidgetSetup("my_container_params") is missing in the prefab function, isn't it? And of course, even if overwriting the widgetsetup is now deprecated, please still correct it. The return of the old_widgetsetup is missing data: return old_widgetsetup(container, prefab,data) -- do not miss data, important! Now some more questions: 1) Why was the replica.WidgetSeutp call previously necessary? And how did this change? I see no call of this replica in containers, where is it done, why wasn't it done before? 2) If I only wan't the same widget like eg. chester for my anything. Then many mods try "inst.components.container:WidgetSetup("chester")". And I wonder, did this work before? Does this still work? Because when I made my shadowmaxwell mod, I remember that this caused problems and I had to copy paste the params of chester... In addition, if this "chester" line now works, why is the replica WidgetSetup still needed? It will crash on clients on opening, if it is not there.
  23. thank you. and can you provide examples which code simnplifies know to what with help of this? Is it for mod-containers? I currentlyknow 2 ways to add mod containers, while both of them are really too big hassle: 1) Override containers widgetsetup for your specific prefab, return old function for others. 2) Don't override, but pass your params to the widgetsetup call as data. current problem: you need to copy paste the params,if you want the same like already existing -> I guess this is the place where the containers.params kicks in? So now you can do sth like: inst.components.container:WidgetSetup("shadowBMduelist",containers.params.chester) ? But unfortunately, all those mods which are using the first attempt, always forget to return "data" in their "old_widgetsetup" call, which makes all mods using the second method incompatibel to them =/
  24. @zarklord_kleimore and more mods suffer from this and it is related to the latest QoL update, before everything worked. But it is also quite likely, that the code from those mods is not the best. But the reason for this is like mentioned above, that there is no game code you could copy for your own containers and there is no tutorial. So everyone is using that code, regardless if it is good or not. ( I mean, why do mods at all need that line "inst.replica.container:WidgetSetup("chester")" while the original files never use this...) So I would suggest that you check if there was a bug introduced and/or if you can improve the way modders add container widgets (or simply use exisiting ones).