ZupaleX

Registered Users
  • Content count

    582
  • Joined

  • Last visited

Community Reputation

187 Excellent

3 Followers

About ZupaleX

  • Rank
    Senior Member

Badges

Don't Starve Together
  • Contributor
Oxygen Not Included
  • Alpha Contributor

Recent Profile Visitors

1,155 profile views
  1. The order is not always important. It doesn't matter when defining "methods" for instance (Combat:DoAttack is a "method" to give an example). This is maybe why you never noticed it before.
  2. PLEASE HELP.

    The only issue is that eventually, each time a mod gets updated the issue will arise again. Only one windows account which has the admin rights, steam running as administrator, DST running as administrator, permission granted to the user for the steam folder and all the sub-folders (even though anyway the user is already in the list of allowed users since it's in the admin group), but no, it just locks the folder. Very annoying. EDIT: and thanks for the LockHunter tip @Paxtonnnn, I did not know that software.
  3. You did not pay close enough attention to what I was saying Maybe it's my fault though and I was not clear enough. Here is a copy paste of your dragonblade.lua function addUltCharge(item) return function(inst, data) if inst.components.fueled and inst.components.fueled:GetPercent() < 100 then inst.components.fueled:DoDelta(5) else inst.components.talker:Say("Test failed") end end end local function ownerSet (inst) inst.components.talker:Say("Test.") local owner = inst.components.inventoryitem:GetGrandOwner() inst:ListenForEvent("onattackother", addUltCharge(inst), owner) end As I was explaining, the "inst" in a callback function is the source pushing the event. The source in your case is "owner" which is the player. So inside you addUltCharge which is your callback function, inst is the player. The player has no component fueled. This is why you add a layer to this function by adding an argument "item" to pass your dragonblade You need to operate on the fueled component of "item" and not "inst". If you do not understand why, let me know and we can discuss about it. In any case, it means you did not blindly copy/pasted what I posted and you actually tried to redo it by yourself which is good
  4. I just made a typo. The function is the one ptr copy/pasted. You said you tried it and it did not work? Could you post the function you used? What exactly did not work?
  5. How to Start Coding

    PlayAnimation reset the animation queue and plays the animation you specify. PushAnimation push the animation at the end of the queue. Which means it will wait for all the previous animatios in the queue to be played before playing the one you just pushed.
  6. Could you post the error log you get or if you do not have any more crash but it just does nothing, could you post the complete mod? Thanks
  7. How to Start Coding

    The way DST works is not very complicated. The first layer for modders I would say is the prefab/components one. Each entity in the world (a tree, the players, monsters, a spear, meatballs, ...) is a prefabs. You have in the don't starve folder, a subfolder named data/scripts/prefabs All the entity which exist in the game have a prefab script in this folder. It's called prefab because these scripts are just blueprints to create a new entity in game. When you craft a spear for example, a function is called to use the script data/scripts/prefabs/spear.lua and execute the constructor for the spear inside that script to create an instance of the spear prefab (usually referred as inst in the code). How these constructors works? First a new generic entity is created. It has nothing attached to it and is not doing anything. From here the prefab functions will populate that entity with various things, like C-side elements which we don't really have access has modders (we can merely use the functions exposed to us) like an AnimState (to handle the animations), a Transform (the position of your entity in the world), a Physics (which function is obvious), ... And then comes the main part for us modder as these are pure lua scripts so we can do whatever we want with them: the components. Components are the bricks you use to build you entity. You will find the Klei's built-in components in data/scripts/components In your spear prefab constructor function, you will add to your generic entity the following things a InventoryItem component which has functions used to handle the fact that this entity can go inside a container or in the player inventory. a Equippable component which handles the fact that it can be equipped by the player and be used a Weapon component which indicated it can be used to deal damages etc... You should look at a few basic prefab scripts by yourself and you will understand the logic behind this. Then you have additional layers which are irrelevant when you begin with modding and as long as you don't have a good understanding of what's happening at the lower prefab/components level. These are the Stategraphs, the Brains, the Behaviours, the Widgets and are a discussion for another time. I would advice to use a tool like http://stefanstools.sourceforge.net/grepWin.html which is free and allow you to search for a string in all the files of a specific folder. Let's imagine you want to make an item which is a hat with an integrated pickaxe that would allow you to mine while still having your hands free. You would look at the components: components/inventoryitem.lua components/equippable.lua (the hat is an equippable item) components/tool.lua From here you identify function which look interesting/promising/the name suggest it would be useful for you, you open grepWin in the data/scripts folder and search for this function. It will return you all the files where this function appear. You could then try to see how it is used in Klei's prefabs. Hope this helps
  8. Which line of code are you referring to? If you break down GetClosestEntityWithTag, you see that the only thing it is doing is find you all the entity with a specific tag in a radius around an origin point and return you the entity which is the closest to that origin (excluding the entity "inst" which is the one use to determine the origin point). So it just looks for the tag and is not doing anything else.
  9. How to Start Coding

    And that's how you should start I guess. I think that modding is not an abstract thing and is best to be learnt on concrete things. If you don't really have an idea of what you want to achieve right now, then maybe the simplest would be to take a random recipe in game and modify it to see how that is done. Then move to do a simple decorative item which has no purpose. Then try to do an equippable item following the tutorial about these. Even if what you will produce is not what you want to do and you will never use it, you will learn how to do these basic things. Once you have successfully accomplished that, you are ready to do more advanced stuffs and then the forum will look much more helpful.
  10. There is no glaring mistake in your functions if that can make you feel better. The issue is how the ListenForEvent works. So if we go back to my explanation of ListenForEvent, you specify which event you want to listen to, then give a function to execute (the callback) and then the source of the event. When an entity pushes an event, it is done through a line of code which would look like that some_entity:PushEvent("some_event", table_with_info_about_the_event) Let's take the onattackother for instance in the Combat component lua script self.inst:PushEvent("onattackother", { target = targ, weapon = weapon, projectile = projectile, stimuli = stimuli }) you see that the information passed about the event are: the target the weapon the projectile the stimuli type So the structure of a callback function should be like that local function SomeCallbackFn(inst, data) -- inst is the source of the event -- data is the table you passed in the PushEvent function -- So if we assume this callback is for "onattackother" event you could retrieve local target = data.target local weapon = data.weapon [... etc ...] end So your AddUltCharge function is malformed, it should be local function AddUltCharge(inst, data) [... do something ...] end Now the trick here is that "inst" is not what you think it is! Because as I said, in the callback, inst represent the source of the event which is the player. So now you will tell me "that's really nice but then all of these bollocks won't solve my problem and everything I'm doing for 2 days is useless". Well you could use a wrkaround like the following local function AddUltCharge(item) return function(inst, data) -- reminder, inst is the source of the event so here it's the player inst.components.talker:Say("Test2.") if item.components.fueled and item.components.fueled:GetPercent() < 100 then item.components.fueled:DoDelta(5) end end end And when you setup the ListenForEvent inst:ListenForEvent("onattackother", AddUltCharge(inst), owner) Does that make sense? This might not work as is as I did not test it, and wrote it in 2 minutes in the web browser so there might be typo, etc... But this should give you the idea. Btw you could have noticed that inst was actually the player currently as it was the player who was talking "test2" when the function got executed and not the item (I would presume) PS: And I don't mind helping. Usually it's stuff which can also help other people eventually. If it was boring me I would not be here at the first place
  11. Are you doing this mod for DST or DS? If it is for DST you are missing in your entity initializer a very important part. The one which says when the client and server side entity stops to be identical. DST has a network layer (obviously) and all the important things run on the server only. The client just has the part which is required for the entity to be displayed and all the local stuffs to work. So on both the client and server, the entity need to exists local inst = CreateEntity() The entity need to have on both sides informations about its position in the world inst.entity:AddTransform() The entity needs to be displayed on the screen on the client side as well as on the host side inst.entity:AddAnimState() The network utility and functionality needs to be present on both the host and the client inst.entity:AddNetwork() The physics is as well initiated on both sides MakeInventoryPhysics(inst) Then you give informations about the appearance of the object by seting build, banks and animation to your AnimState and that needs to be done obviously on the client and host so everybody can see the entity. inst.AnimState:SetBank("dragonblade") inst.AnimState:SetBuild("dragonblade") inst.AnimState:PlayAnimation("idle") Finally you add tags to your entity. Tags are network variables which are shared by the server and the client version of the entity. It allows to do quick checks when you have a dialog between the server and the client without having to perform complex operations inst:AddTag("sharp") After that almost everything is exclusive to the host! All the components will be present for the host only and for most of them the client don't even need them. Your fueled component for instance. The client does not need to have that component on its side of the entity. Imagine if the fueled component was present on both client and host. You add fuel to your item. The client tries to set a new value for the fuel locally, then send the information to the server so it updates it on it's side? But your host was busy consuming fuel from your item and trying to update the info for the client. Both tries to access the component at the same time => you are in big trouble. This is solved by having these components only on the host. In the end the host performs all the "calculations" and handles everything and redistributes only the useful information to the clients. Much less data traffic and no risk of multiple access to the same thing by different processes. There are though a few exceptions to this, like the talker component. The talker is present on both the client and the host because this component is not modified. It is just here to display text so no risks here. And then you just need to send signals to tell to the client to display something instead of sending a complete string of character over the network, which is expensive. In conclusion in your case you will now have that part as well common for the host and the client inst:AddComponent("talker") And then you tell the client that he's done and what happens after that is none of its business inst.entity:SetPristine() if not TheWorld.ismastersim then return inst end And finally you will add the part of the code which will be only executed on the server side (because if you are client you finished the execution of the initializer function at the previous line with the "return inst") inst:AddComponent("inventoryitem") inst.components.inventoryitem.imagename = "dragonblade" inst.components.inventoryitem.atlasname = "images/inventoryimages/dragonblade.xml" inst:AddComponent("equippable") inst.components.equippable:SetOnEquip(OnEquip) inst.components.equippable:SetOnUnequip(OnUnequip) inst:AddComponent("weapon") inst.components.weapon:SetDamage(55) inst.components.weapon:SetRange(1, 1) inst:AddComponent("fueled") inst.components.fueled:InitializeFuelLevel(TUNING.TORCH_FUEL / 2.5) inst:ListenForEvent("onputininventory", ownerSet) return inst Eventually your item initializer function should look like that I hope this is clear and helpful. Cheers
  12. Crash when entering caves

    I did not have time to check it out yet sorry. I'll try to do that tomorrow.
  13. 2 Problems

    Your welcome. Yes please let us know if this works
  14. So the issue is that when the entity is created, it doesn't have an owner yet. But another event is pushed by the entity itself when put inside a container (the inventory is a container). So you could in the constructor: Listen for that event pushed by inst when it is put in the inventory. Execute a function which would initiate the ListenForEvent with the onattackother, because now GrandOwner would actually return the player. EDIT: by the way, I hope you don't mind me giving you information one by one instead of just spitting a premade function to do what you want to achieve. I believe that you will learn much more like that.
  15. Making switchable weapon

    Putting 18-20 items in a single lua script if they are all different is a bad idea anyway.