I've got a few questions.

[Rosten]

Hey, as the title suggests, I've got a fair few questions about how to do stuff, mostly stuff that probably isn't handled in most tutorials you'd find here. I know a bit of Python, and I have a fair amount of experience when it comes to DS modding (I made This and This [With a lot of help from awesome people]) If you can, I'd like a sort-of in-depth explanation as to how the code would (or does) work. But as the title said, I have a fair few questions, so bear with me xD

 

=====================================================================================

Firstly, How can I create my own "value" that can interact with other things this is probably really badly worded, but think of it as something like how Health works. An individual value stored *somewhere* that can be changed by anything with the right code. I imagine just making a random prefab with the value in it won't work, the "list" of things I'd like to know is

- What folder would it need to be in? Does it need to be a prefab, widget, component etc. (Guessing component)

- How would I make it where other things can affect it, I.e. crafting something could decrement the value, interacting with something could increment it

=========================

Secondly, How can I create a custom building with it's own gui This one's a bit more tough, since as far as I know, I can't think of anything in Don't Starve that does this, nor can I find any mods that have something similar to it. Thinking of a list of what I need because I don't really know myself. But I can try

- How can I create a custom building from scratch, is there a certain template I need to use for it?

- How can I make the custom gui, and make it interactive

- How can I make actions in the gui effect outside entities (I.e., increment the previous value, spawn in items, etc.)

Bonus =

Is there anyway to lock and unlock options in the gui based on outside factors?

 

Right now it's only two questions, but there's a lot of things I'd like answered in them, thanks in advance for any help you can give me.

 

[Mobbstar]

1. You mean a stat, basically? Component is the way to go, you can listen for events and use PostInits (careful with the latter, don't be unnecessarily incompatible with other mods) to achieve the changes you want.
2. That's a huge one. I can only recommend you to look at other mods that have custom buttons and such, to learn how to use widgets. To assemble a proper interface, you should study the screens and player hud.

That's my oar, and I won't put much more effort into it. Because I am lazy and semi-busy lately.

[Rosten]

 

1. You mean a stat, basically? Component is the way to go, you can listen for events and use PostInits (careful with the latter, don't be unnecessarily incompatible with other mods) to achieve the changes you want.
2. That's a huge one. I can only recommend you to look at other mods that have custom buttons and such, to learn how to use widgets. To assemble a proper interface, you should study the screens and player hud.

That's my oar, and I won't put much more effort into it. Because I am lazy and semi-busy lately.

 

 

Yea, I knew that it'd probably be pretty hugely difficult to make my own gui. Um, can I ask what PostInits are? Sorry ;^~^

 

[Blueberrys]

Um, can I ask what PostInits are?

Post inits are functions that will execute a function that you pass in after something is initialized.

The common format is something like:

local function run_this_function(inst)    -- inst contains data of thing_to_initendAddSomethingPostInit("thing_to_init", run_this_function) 

See this mod, it explains about a lot of different post init functions.

 

 

Most of the things you mentioned in your first post can be achieved in some way using variable references. Just store your variables in an accessible place, then you can check or modify them as you wish using references. Using a component would be a good idea, you can store variables in it and make functions such as "GetVariable" or "SetVariable" to access it's content.

 

Example of parent-child references,

local variable_parent = {}local function do_something()    variable_parent.some_var = 1endlocal function get_value()    return variable_parent.some_varend

This is a very simple example, and you don't even have to use variable_parent here, but it's just to demonstrate how you can access the child variables of your components. (And similarly, access the components of your prefabs)

Edited February 2, 2015 by Blueberrys

[Rosten]

Post inits are functions that will execute a function that you pass in after something is initialized.

The common format is something like:

local function run_this_function(inst)    -- inst contains data of thing_to_initendAddSomethingPostInit("thing_to_init", run_this_function) 

See this mod, it explains about a lot of different post init functions.

 

 

Most of the things you mentioned in your first post can be achieved in some way using variable references. Just store your variables in an accessible place, then you can check or modify them as you wish using references. Using a component would be a good idea, you can store variables in it and make functions such as "GetVariable" or "SetVariable" to access it's content.

 

Example of parent-child references,

local variable_parent = {}local function do_something()    variable_parent.some_var = 1endlocal function get_value()    return variable_parent.some_varend

This is a very simple example, and you don't even have to use variable_parent here, but it's just to demonstrate how you can access the child variables of your components. (And similarly, access the components of your prefabs)

 

I'm still not entirely sure on how postinits work, but I'll definitely check out that mod when I have a bit more spare time.

 

I'm assuming that parent/child references are basically just tables? I.e. to reference something within the table you substitute "table1.key" to call up the value associated with "key" in the table "table1"

 

Also, this has confused me for a while now, what exactly does "return" do, and how is it to be used?

 

One more thing, would it be better to look at the teleportato or adventure door instead of the hud, since they're the only buildings in the game that open up a gui on interaction?

Edited February 2, 2015 by Blazingice26

[Blueberrys]

I'm still not entirely sure on how postinits work, but I'll definitely check out that mod when I have a bit more spare time.

I would highly recommend that you do, it's not just a mod, it's a bunch of sample code with commented explanation on how it all works. I often copy bits and pieces from there when making mods, or even just see it for reference when I forget something.

 

 

I'm assuming that parent/child references are basically just tables? I.e. to reference something within the table you substitute "table1.key" to call up the value associated with "key" in the table "table1"

 

Yup, exactly. Childs are just elements of tables. Components are basically like tables too, they contain elements that can be variables or functions. The reason that matters is because you can access things inside components through the player with "player_instance.components.component_name".

If you made your own component, you could access the variables in it using that from pretty much anywhere else.

GLOBAL.GetPlayer().components.your_component.any_variable_or_fn

Also, this has confused me for a while now, what exactly does "return" do, and how is it to be used?

 

Return statements generally pose two purposes, to end the execution of the current function, and to send back a value to whatever called that function. (Hence, "return", for returning some value)

 

For example, returning values.

local function do_stuff(var)    return var + 1 -- will send back a value that is one more than varendlocal new_var = do_stuff(2) -- Receives the value 3print(new_var) -- 3

or ending execution.

local function only_work_on_small(var)    if var > 10 then -- not small enough        return    end    print(var, "is small enough!")endonly_work_on_small(5) -- prints "5 is small enough!"only_work_on_small(20) -- does not print anything

Usually, if you can avoid using return too often in a function, you should try to. Some would say that it's bad practice to use it more than once, but that's not entirely true. You should use your best judgement to determine if it'll make the code harder to read or maintain.

 

 

 

Edit :

 

One more thing, would it be better to look at the teleportato or adventure door instead of the hud, since they're the only buildings in the game that open up a gui on interaction?

Personally, I would look through both. It will help you understand different ways to implement what you need (or give you more examples of the same way).

 

Edit 2:

Sorry, misread a part.

I think Mobbstar said to check out the hud for your interfaces you'll be making, not the building itself. Like the buttons to do stuff with it, etc.

 

Edited February 2, 2015 by Blueberrys