Ultroman

  • Content count

    647
  • Joined

  • Last visited

Community Reputation

203 Excellent

6 Followers

About Ultroman

Recent Profile Visitors

970 profile views
  1. Character mod help!

    This is kind of complicated stuff for someone's first mod. Congratulations on getting this far! I highly recommend looking at my newcomer post. The tips and links in there will save you a lot of time in the long run. Especially the LUA Crash Course and the Debugging section. The heater-thing looks right, except you're declaring the variables after using them. But you can simply do this (in your master_postinit): inst:AddComponent("heater") inst.components.heater.heat = 150 The code you posted doesn't make use of the MIN_HEAT variable, so I'm guessing you're missing some code from wherever you took it, but this snippet will let you set a static heat. The radius is controlled by the "observers" i.e. players by their temperature-component which only reacts to heaters within a certain radius.
  2. Abigail Sutter

    Drop rates are kind of a special thing, and they're specific to the individual prefabs which drop them e.g. a tree knows it's drop rates for the items it can drop, so you have to change the drop rate on every specific prefab you want to change. As an example, take a look at the marsh_tree prefab. It does this: SetSharedLootTable( 'marsh_tree', { {'twigs', 1.0}, {'log', 0.2}, }) and then in it's master_postinit does this: inst:AddComponent("lootdropper") inst.components.lootdropper:SetChanceLootTable('marsh_tree') SetSharedLootTable is a function which adds an entry to the shared loot table (one big table used for all prefabs in the game which use this mode of loot distribution), which links an identifier, 'marsh_tree', to a table of dropable loot and their chances of dropping. The lootdropper component is added to the prefab, and its SetChanceLootTable function is called upon to make it use the loot table with the given identifier. There are other ways of adding loot, which do not rely on a table e.g. static loot drops which always drop the same loot, is chance loot or a sort of open-ended way where you add loot with weights attached to each item, so you can freely add/remove loot dynamically, and it'll automatically figure out the chance of which loot should drop. The way I've shown above is probably the easiest to work with. Make a table of loot and chances, and tell the lootdropper to use it. You can change the loot table by just calling GLOBAL.SetSharedLootTable. Here's an example: AddPrefabPostInit("krampus", function(inst) SetSharedLootTable( 'krampus', { {'monstermeat', 1.0}, {'charcoal', 1.0}, {'charcoal', 1.0}, {'krampus_sack', 0.2}, }) -- Make sure the lootdropper component is on the prefab. if(inst.components.lootdropper == nil) then inst:AddComponent("lootdropper") end -- Set the loot table. inst.components.lootdropper:SetChanceLootTable('krampus') end) Have you tested this? Try putting a print-statement in both onload functions saying "onload 1" and "onload 2", and see if both are being called. I will eat...this...cake(?)...if that's the case.
  3. Some pretty good code there If OP ends up using a tag for this, OP could just put in that tag in the FindEntities call INSTEAD of "player" to save some iterations and therefore cycles. It's minor, but I felt I had to say it. Due to the tag limit, it might be better to just add a bool variable to the player inst called iAmCharacterName and check for that. Whatever floats your boat (and works).
  4. Abigail Sutter

    Doing AddPrefabPostInit is incredibly simple. AddPrefabPostInit("abigail", function(inst) -- Make your change. inst is an instance of the Abigail prefab. end) This, however, changes Abigail for players using Wendy, as well, which your solution also does since it's overwriting the original game files (which makes it incompatible with any mod that makes changes to Abigail). If you do not want that, you should change the name of your Abigail prefab (it's the first parameter in the Prefab() call at the bottom of her LUA file). Not sure if any other changes would be required, though. Just make sure that anywhere you use her old prefab name in quotes (e.g. when you spawn her), to change it to use the new prefab name instead of the original one. Concerning the onload functions, I don't think that's how LUA works. I'm pretty sure that if you declare something multiple times, like you're declaring your onload function multiple times, every declaration overwrites the previous one. Effectively, only the lowest placed onload function is being called right now, and "onpoad" is never called. I can't see anything that would specifically cause a stutter, but I might be blind.
  5. Abigail Sutter

    I don't know if it has anything to do with it, but kutsil.lua has an "onpoad" function right beneath its "onload" function...it doesn't look like it's being used, but it seems to do things with Abigail code. Why do you add the abigail.lua in your mod? Isn't it already part of the game? You actually also have two "onload" functions, so there's 3 in total, and one is misnamed.
  6. Abigail Sutter

    No. If you were hitting the limit, the game would crash and tell you. What exactly do you mean by "I added Wendy's Abigail code to my own character"? Can you post a zip of the mod so we can see what you've done? You can try turning off certain parts of the Abigail code, to see which parts make it stutter. Look for things like DoPeriodicTask, ListenForEvent and WatchWorldState calls, which might be "fighting" each other.
  7. need help with crash

    Yeah, there's nothing in the fail code there about consuming the items. You should be able to find the lines which consume the items in the original DoBuild function, and copy/paste them into the fail-if-statement,
  8. Fullmoon Perk

    That sounds like a great thing to study It actually isn't. They do Wolfgang's size in a completely different way. They rely on a change in hunger (which does happen all the time) to keep triggering mightiness checks, and they don't change his scale, they change his whole skin. Anyway, if you haven't figured out print-statements, take a look at my newcomer post. It explains it. I would just put print-statements everywhere, printing out both inst.Transform:GetScale() and inst.components.scaler.scale, and also what is happening e.g. put one in master_postinit, one in your fullmoon function, one inside the if-statement in your OnFullMoon function...everything. Just get as much information you can. I bet it's something simple and stupid. It always is, haha. Good luck, and welcome to the world of coding. It's 99% "why doesn't it work?!" or "why does it work?!?" and 1% "Yes, it works!!" Really, what you have now SHOULD work.
  9. Fullmoon Perk

    You've obviously tried a lot of things by now, which is all I ask of people; to try things out for themselves. You have something now that I can look at. I only try to not give people the whole solution, because they don't learn anything that way, and it makes me feel like a code-ATM I'll see what you have and get back to you This should work melium.lua Change log: I removed the savedscale component, since the scaler component saves the scale internally. You were still reading and setting inst.Transform's scale, which is a Vector3, instead of using the scaler component's scale variable, which is a float, and which saves automatically. Changed that. You were setting the scale directly on inst.Transform, like this, inst.Transform:SetScale(scale, scale, scale), where it expects three floats, but you gave it three Vector3's. I changed it so it just subtracts 0.1 from the scale each time. You can change it back to just multiply the scale by 0.9 if you want. Added the minimum size if-statement, to avoid it going crazy when it gets too small. Made it send isfullmoon parameter to your shrink function. Removed manual call to shrink function from the master_postinit. If it still doesn't work, you need to bust out some print-statements to see if everything is being called correctly.
  10. Fullmoon Perk

    Please just post your current code in a zip so I can take a look at it. It'll be faster at this point.
  11. Fullmoon Perk

    You should really take the LUA crash course. I can't describe the whole language in a post. You need a grasp of the language you're using, or you'll be wasting a lot of your time going back and forth with me. As I said, you no longer need the onsave, onpreload and onload stuff, if you're using the scaler-component. Only the code I posted at the bottom of my last post (put that in your OnFullMoon function), and adding the scaler-component to the player (put this in your master_postinit: AddComponent("scaler") ). The minimum size is not unnecessary in the least, and it's not complex code. You can comment out that if-statement if you want, but it won't make a difference for the problems you're having. I'm not entirely sure what the difference is between onload and onpreload, other than that they're called at different times during loading the prefab, but the data-parameter is the important part, since it holds the saved data, and onload doesn't have that, so you have to read the data in onpreload. As mentioned earlier, this is different for components, which do not have onpreload, and instead get their data passed to their onload function. But again, you don't need to worry about that anymore, since the scaler-component takes care of saving and loading the scale.
  12. Fullmoon Perk

    Well, even if it should work, it's all just written in this text editor, is not complete, and not tested at all. The theory should work, but in order to see why it doesn't work for you, I would need you to post your prefab LUA file, to see if you've done it properly. How does the game remember data? Every prefab and component is "scanned" for OnSave, OnLoad and OnPreload (the latter possibly only for prefabs, since components seem to get the data in their OnLoad function?) functions when the prefab or component is initialized. In the case of a player, whose character is basically also just a prefab, the data is compiled into a big pile when the player quits or the server is shut down. This is what happens in the OnSave function, so you are adding to that pile of data (the data-object). This data-pile is linked to their username or something, so when they log into the server again, the server sees their username, checks if it has a player character saved for that username, and if so, it instantiates the player character prefab, and loads the saved data which is passed to the OnPreload function. How do I decide what data is saved? Deciding is one part, and doing it is another. I'll answer about deciding in the last question, and just answer for this one, that you save the data by simply adding variables to the data-object, like you see me doing in my onsave example. How do I ensure it's loaded each time? The game engine takes care of that automatically, as long as you "hook up" your functions, like you can see near the bottom of woodie.lua. inst.OnSave = onsave inst.OnLoad = onload inst.OnPreLoad = onpreload Is there no way to just save the scale itself each time instead of this whole counting thing? You can just save the scale if you want, but that will not get you the functionality you want. You would have to read the scale from the scale-vector each time, then subtract whatever value you want, make sure it isn't under a certain minimum, and set the scale. Since you'd still be saving a variable, the complexity is about the same, but this way is just a bit neater, although it requires having the numberoffullmoons variable on the inst. You could use the Scaler-component instead. If you add that to your player with AddComponent("scaler"), it will save and load the scale for you, and you can simply call its SetScale function to set a new scale. It defaults (starts at) 1. It takes a single float, instead of a Vector3, so it's easier to work with. Then you can just do: -- Getting and changing the scale once per full moon change -- First, get the current scale. This is a float between 0.0 and 1.0 local currentScale = inst.components.scaler.scale -- Then make a change to the scale. currentScale = currentScale - 0.1 -- Do a minimum check if currentScale < 0.5 then currentScale = 0.5 end -- Set the new scale inst.components.scaler:SetScale(currentScale) If you use the scaler component, you don't need to do the save, load and preload stuff I mentioned earlier. I just found the scaler-component. Didn't know about it until now.
  13. Fullmoon Perk

    Well, you don't want to save the scale. You want to save how many full moons have passed since the character last died, right? Since the scale will be calculated from that number. Also, when you create a local variable, you don't refer to it using "self". Local variables are referred to simply by their name. If you look at my example above again, you'll see that i do NOT try reading data in onload, since there is no parameter called data. The loaded data is only passed to onpreload, which is where you should read the value and put it on the player. inst is simply your player prefab. Don't be afraid to use it. If you look at my example, try doing exactly that. local function calculateScale(numberoffullmoons) -- Just a fail-safe if numberoffullmoons == nil then return 1 end local scale = 1 - (0.1 * numberoffullmoons) -- Make sure there is a minimum scale if scale < 0.5 then scale = 0.5 end return scale end local function setScale(inst, scale) -- Just a fail-safe if inst == nil or scale == nil then return end inst.Transform:SetScale(scale, scale, scale) end local function onpreload(inst, data) -- Read the variable from the data-object and set it to a global variable on the player. inst.numberoffullmoons = data.numberoffullmoons end local function onload(inst) -- Do your scaling here, using the global variable on the player (use inst.numberoffullmoons). -- In the event that inst.numberoffullmoons is nil, we do not want to do any scaling. if inst.numberoffullmoons ~= nil then -- Do scale calculation and apply scale setScale(inst, calculateScale(inst.numberoffullmoons)) end end local function onsave(inst, data) -- Read the global variable from the player and set it to a variable on the data-object. data.numberoffullmoons = inst.numberoffullmoons end Then, in your OnFullMoon function, you'd do something like this: if inst.numberoffullmoons == nil then -- The first time we hit a full moon, inst.numberoffullmoons is nil, so we specifically set it to 1 inst.numberoffullmoons = 1 else inst.numberoffullmoons = inst.numberoffullmoons + 1 end Instead of all the nil-checking, you could just always set inst.numberoffullmoons to 0 in your master_postinit, but I'm not sure if preload is called before or after master_postinit, so there might be overwrite issues. Can't know for sure without testing. The approach I've put forth should work regardless (I hope).
  14. mod crashes on starting world

    Why didn't I think of that?