Struct

D

DarthTenebris

Guest
Hello everybody,

I recently got to try out the new features, and the new structs made me think a bit.

I have a script called EngineUI, which I intend to house all the GUI elements I'm going to make programatically. Previously, I made an object for every button I added. With the new structs, I think I can pull off something more flexible and expandable. Here's the part of interest:
GML:
function Button(x, y, width, height, absolute, parent) constructor() {
        step = function() {
                // logic
        }
        
        draw = function() {
                // render
        }
}
An object called obj_gui_manager handles interaction with the UI script, such as the step and draw "events". On a classic object, I can use the events to detect input that would otherwise require complex GML code to detect, such as double taps, drags, and pinches. Is it possible to have structs detect such events as well, or do I have to detect them manually via the struct's step event?

Thank you for your time.
 

Joe Ellis

Member
It seems like structs can be handled in the exact same way as instances, 2nd person. Meaning you always have to use struct.variable = value, or with to go into 1st person.
Using structs for gui instances is a very good example of using their strength opposed to instances, due to the fact that they just sit there the whole time doing nothing until interacted with. And when that moment comes you can easily code it so it affects them in 2nd person from the instance that controls all the clicking on the menus.

Probably a good way to think of structs is that they're instances, but they don't have any events, so they're the same as an instance when it's deactivated, or the same as an instance of an object with no events at all. Before structs came about I had an object called obj_none that I used for this. But now you can just create them by doing str = {}; Then add any variables you want doing str.variable1 = "Hey"
 
Last edited:
D

DarthTenebris

Guest
It seems like structs can be handled in the exact same way as instances, 2nd person. Meaning you always have to use struct.variable = value, or with to go into 1st person.
Using structs for gui instances is a very good example of using their strength opposed to instances, due to the fact that they just sit there the whole time doing nothing until interacted with. And when that moment comes you can easily code it so it affects them in 2nd person from the instance that controls all the clicking on the menus.

Probably a good way to think of structs is that they're instances, but they don't have any events, so they're the same as an instance when it's deactivated, or the same as an instance of an object with no events at all. Before structs came about I had an object called obj_none that I used for this. But now you can just create them by doing str = {}; Then add any variables you want doing str.variable1 = "Hey"
So I guess there isn't a way to make them be able to react to event based input? For example, with a classic object I can just add a Global Rotate Event for example, and do whatever I want to there. Alternatively, such an event could be detected manually with GML in the step event, for example the classic keyboard_check() functions. However, not all events are as simple to check by GML, such as the Global Rotate Event, and therefore I would like to be able to have my structs be able to check for these like I can with a classic object. In this case, I actually hope I missed something, and that there is a way to make them detect input easily.

There's so many different ways these new GML structs work that I have no clue what I'm doing. I'm stuck, frustrated and don't even know anymore where to begin.
I started out not knowing what I'm going to do with structs too, but I really wanted to try working with them, so I used it for whatever I could think of, and eventually landed here. Make up an excuse to use them somehow, and as you gain more experience with them, you'll be able to recognize the appropriate use cases for them. d: Also, if you have a specific use case that you're having problems with, perhaps make a new thread about it. The more information you give, the better people can help you.

Thank you for your time.
 

Joe Ellis

Member
In this case, I actually hope I missed something, and that there is a way to make them detect input easily.
No, they would need to be instances if you were to check input this way with an event. But if you simply had this event in a controller instance, you could then loop through all gui structs and find which one the mouse is over, which'd normally do the trick.
The thing is though, if you find it easier doing this with instances instead, I'd just do that for now. Both ways will work, and it's not like performance is an issue.
 

NightFrost

Member
While it is very possible to create a UI system without instances, I don't think it is hugely necessary. You won't have a massive amount of UI elements, and what little you have won't impact your game very much. My current UI system (which features all major elements from buttons to dropdowns to textboxes) is entirely instance-based. In fact I wrote it to be able to work without any central controller. It can have one, but its purpose would be to centrally house element definitions and spawn them at room start events, and to bind navigation between the elements if such thing is required. But any element can also be spawned at any given time through an appropriate script call.

If you're going to support various types of standard UI elements you're going to have lots of code. I feel it is more appropriate and easier to separate that to purpose-built object types, which also makes the code more manageable.
 
D

DarthTenebris

Guest
No, they would need to be instances if you were to check input this way with an event. But if you simply had this event in a controller instance, you could then loop through all gui structs and find which one the mouse is over, which'd normally do the trick.
The thing is though, if you find it easier doing this with instances instead, I'd just do that for now. Both ways will work, and it's not like performance is an issue.
Well, alright then. Thanks for the input.

While it is very possible to create a UI system without instances, I don't think it is hugely necessary. You won't have a massive amount of UI elements, and what little you have won't impact your game very much. My current UI system (which features all major elements from buttons to dropdowns to textboxes) is entirely instance-based. In fact I wrote it to be able to work without any central controller. It can have one, but its purpose would be to centrally house element definitions and spawn them at room start events, and to bind navigation between the elements if such thing is required. But any element can also be spawned at any given time through an appropriate script call.

If you're going to support various types of standard UI elements you're going to have lots of code. I feel it is more appropriate and easier to separate that to purpose-built object types, which also makes the code more manageable.
A lot of the code is boilerplate, just to get the basic thing up and running. While it may not be convenient, or maybe even a hassle, I feel like throwing it all out and using classic objects is going to be a waste of effort. As for the input detection, I ended up writing a passthrough from my controller object, which seems to work fine so far.

Thank you for your time.
 
Top