• Hello [name]! Thanks for joining the GMC. Before making any posts in the Tech Support forum, can we suggest you read the forum rules? These are simple guidelines that we ask you to follow so that you can get the best help possible for your issue.

 Allow 'global' persistent instance creation

GMWolf

aka fel666
Hello,
I really like the 'global' pragma. I think it's great to automatically initialise all sorts of data.

But what is missing is the ability to create persistent instances in your global scripts.
The only options are to have an init room (but what if you have multiple libraries that need init rooms?), Or to do some funky room manipulation stuff (which is tricky at best, or somewhat buggy on html 5).

I understand we can't create instances because there isn't a room for those instances to live in yet. But persistent objects should be able to. Perhaps the introduction of a dummy global room could help with that too.
 
H

Homunculus

Guest
I guess you are implying that this could be useful for library / extension developers that want to create some persistent instances in gml_pragma without forcing the user to have an init room or manually calling a script.

I get your point and it makes sense, but doesn't the upcoming GML update with lightweight objects solve this issue already? I know it's probably months away, but at this point introducing something like this would probably be unnecessary.
 

GMWolf

aka fel666
I guess you are implying that this could be useful for library / extension developers that want to create some persistent instances in gml_pragma without forcing the user to have an init room or manually calling a script.

I get your point and it makes sense, but doesn't the upcoming GML update with lightweight objects solve this issue already? I know it's probably months away, but at this point introducing something like this would probably be unnecessary.
Unless you want objects that listen to events!
I was thinking of building the Ultimate input system...
 

Hyomoto

Member
@GMWolf - If the purpose is to create instances, there is a way to wiggle yourself out a "lazy initialization" in GML that might work in some instances by taking advantage of the fact you are creating an object, and that with ( noone ) {} is skipped. However, this only works with objects that can be explicitly needed at some point, rather than something that is needed without being called in some way. I struggle with your topic issue a lot, so I would be perfectly happy to see this functionality come in some form, though I'm not entirely convinced that the user won't always be forced to explicitly include it in some way. Even in this example, the user has to call the function.

Code:
/// @func myFunc();
gml_pragma( "global", "global.__my_initialized_thing = noone" );

with ( global.__my_initialized_thing ) {
  // do
  // return || exit

}
global.__my_initialized_thing = instance_create_depth( 0, 0, 0, myObject );

myFunc();
 

ZeDuval

Member
@GMWolf @Hyomoto Guys, I think I found a solution. I've often thought of a way to have a complex extension involving objects initialize itself. The problem I could never get around was the whole "There isn't a room yet to make instance_create work from a global pragma script". I don't know how bulletproof it is or if it is suitable for your specific cases. The script scr_init calls itself in the global pragma phase and adds an instance of my persistent object o_init to the first room. From there, you can work with game_start/room_start/create_event. Is this it or am I having a massive brainfart right now?
Code:
/// @func scr_init()
gml_pragma( "global", "scr_init()" )
room_instance_add( room_first, 0, 0, o_init )
 

Hyomoto

Member
That is certainly interesting, and while I can't speak for wolf, I'm a little surprised I've never thought of it. That's an excellent share and I'll give it a try. However, I'm fairly sure you can call that block without needing the script by just having the instance add call in the gml_pragma(). @ZeDuval
 

GMWolf

aka fel666
Yeah that is great, and will work 99% of the time.
But if that room has another object that requires your object to have been initialised but somehow runs before yours, then it doesn't work.

They the solution is to create a new room, and populate that, make sure it goes to the next room when it's done, etc.
 

Hyomoto

Member
I gave it a shot and it does indeed work. A clever solution! It opens up some very interesting possibilities I hadn't considered before.
 
H

Homunculus

Guest
But if that room has another object that requires your object to have been initialised but somehow runs before yours, then it doesn't work.
I agree, i’d prefer the user to manually call an initialization script wherever he thinks it’s safe to do so than to take any chance with this.
 

Hyomoto

Member
Well, there are two sides here. From an asset perspective, self including code is probably the worst idea you could ever come up with. Having the user explicitly place an object or run an initialization script is the very least they should need to do, and makes disabling your code simple.

On the other hand, if it's your own code, worrying about a hypothetical edge case is silly: you wrote the damn code, and you ought to know what order your instances are being initialized in. If there's a problem, you fix it. You can get away with "risky" implementation because you understand how it works.

For example, have your init scripts check for a global variable. If it doesn't exist, a priority queue is created and a global object is assigned to the starting room. Then the script adds whatever object at whatever priority to the queue, and when the room starts the global object creates your needed instances in order of priority. Voila. Your libraries can all coexist and self-include with objects created in whatever order you decide and it doesn't matter what order the pragma calls run in. I know @GMWolf is a clever guy, I've seen his channel. The problem here is hardly insurmountable or absolute.
 

GMWolf

aka fel666
The problem here is hardly insurmountable or absolute.
I don't like this attitude in the GMC.
By that logic I shouldn't be using an engine in the first place...

Yeah there are work around. I don't see how that makes the feature any less useful.

From an asset perspective, self including code is probably the worst idea you could ever come up with. Having the user explicitly place an object or run an initialization script is the very least they should need to do, and makes disabling your code simple.
I think that largely depends on the asset...
 

Hyomoto

Member
I don't like this attitude in the GMC.
By that logic I shouldn't be using an engine in the first place...

Yeah there are work around. I don't see how that makes the feature any less useful.


I think that largely depends on the asset...
Well, my tone may have stronger than I intended. But I still stand by both points. The first is that having an asset self-include is somewhat dangerous. GML already includes all scripts, so it's not an accessibility thing. It's a case of, if I cause my code to inject itself into the pipeline of someone's game, they lose control over it and it becomes difficult to trace interaction issues. I don't think it's bad to ask the user to run a script or add an object manually simply because they at least know what the point-of-interaction is and removal becomes simple. I added this, removing it fixed it. Other paradigms exist, but I think this one is helpful.

As for your first response, however. I don't see it. I've already said that this would be helpful, and then someone suggested a way to actually do it. You said it would work, except in a specific scenario, and I said it could be worked around, provided an example, said you were a clever guy, and that you would probably come up with something. I don't see that as a destructive attitude. It was a compliment, I've seen your channel, you have a lot of clever GML tricks. The day that's a attitude you don't like in the GMC is a day you need to read over the comment chain again, or elaborate a bit more on how they specific line is radical or insulting. If you thought I was being snarky or sarcastic, I wasn't.
 

GMWolf

aka fel666
Don't take it personally.
The attitude I'm referring to isn't a snarky, or insulting one.

It's the 'there is a workaround so why must it be a feature?' response.
I guess attitude might not be the right word.

What I mean is yes, there are workarounds and yeah they can work. But I think if people are using workarounds, it's a big indication that maybe that feature should be a thing... If it wasn't needed people wouldn't come up with those workarounds.
 

xDGameStudios

GameMaker Staff
GameMaker Dev.
EDIT: Forget it just read the whole thing and I guess you already realized what I was saying... you want the THING to just be there.. not attached to any room. Right?
 
Last edited:

curato

Member
I have seen a number of large games hide loading libraries and such while they are showing logo splash animations and if you cancel out you are looking at a progress bar. I know I usually hide my manager object on the title page and then it handles game settings and GUI stuff and stuff that is the same for every level though the game.
 

Hyomoto

Member
I can't speak for Wolf, but I believe at least some of issue he wants to solve is library dependencies and extensions. Being able to create objects at launch would allow you to set up features and components before the game begins to prevent crashes caused by being called before they are present. The changes coming later this year should allow lightweight objects to handle a big chunk of this request, but time will tell.
 

xDGameStudios

GameMaker Staff
GameMaker Dev.
For example, have your init scripts check for a global variable. If it doesn't exist, a priority queue is created and a global object is assigned to the starting room. Then the script adds whatever object at whatever priority to the queue, and when the room starts the global object creates your needed instances in order of priority. Voila. Your libraries can all coexist and self-include with objects created in whatever order you decide and it doesn't matter what order the pragma calls run in.
I kinda like this idea... pretty neat :D
 
Top