Discussion How many people want instance_create() back?

[Sam (Deleted User)]

In other words, for 1.x project compatibility purposes, there should be a way to make a script named instance_create in the resource tree without it saying "Oops! You are using a deprecated function" error. How many of you want this for convenience? It wouldn't take much work for YYG to remove that error for this particular function, so we could make a script, that essentially does what instance_create() did in 1.x releases. This could fix a few projects broken by 2.x quirks.

 

[BaBiA Game Studio]

How many people want instance_create() back?

No thanks. Anyway, if you are importing a 1.x project then according to YYG it will automatically create the compatibility scripts for any deprecated commands.

 

[xot]

I don't get such an error. Go nuts.

Here, I'll even get you started:
%PROGRAMDATA%\GameMakerStudio2\Cache\runtimes\runtime-2.0.1.16\lib\compatibility.zip

 

[Sam (Deleted User)]

No thanks. Anyway, if you are importing a 1.x project then according to YYG it will automatically create the compatibility scripts for any deprecated commands.

Ok cool problem solved xD I had no idea

Go nuts.

Not sure where you are going with this one.

 

[hdarren]

Wow yes I did not know you cannot make your own instance_create script. That's awful!

Could we not have option in the object properties to set a default layer or depth? Then you don't need to remove instance_create because it will use the default setting. 99% of the time when I create a object I want it to use the same depth so having to set the depth every time I create a object is pointless and not to mention what happens if I later wanted to change the depth of a object type.

 

[alexandervrs]

It's a compatibility script now because you are now required to provide a layer/depth for the instance that you're creating.
You can use a global to hold a default depth and use a script like scr_instance_create(x, y, object) which would take care of that, and you'd write it kinda like the old way.

 

[hdarren]

The point is why can't I turn off compatibility script error messages? I wanted to use instance_create() for my own script as a workaround because for some reason they decided to get rid of it.

 

[csanyk]

Wow yes I did not know you cannot make your own instance_create script. That's awful!

Could we not have option in the object properties to set a default layer or depth? Then you don't need to remove instance_create because it will use the default setting.

Deprecating instance_create() feels like a move on the part of YYG to get everyone used to thinking in terms of layers, and making use of the new layer system.

Certainly, allowing us to create our own script named instance_create, and to code it to work however we would like it to work, should be allowed. But I also think it makes more sense to keep the old function around, seeing as how it was a reserved name in GML for many years.

Since we can't import 1.4 projects to see what it does to them, can someone from YYG comment on what the compatibility script is like for instance_create()? How ever it behaves, this should probably be the model for how a retained instance_create in GMS2 should work.

Without knowing what the compatibility script solution looks like, I would think the solution of allowing instance_create() to stick around, and it giving everything a default layer makes sense; in old GM, everything has a default depth of 0. A GMS2 room has a default instance layer for Instances. So, it seems reasonable that if we were to keep instance_create around, it would essentially work like instance_create_layer(x, y, INSTANCES, obj) where INSTANCES is hardcoded to be the layer named Instances.

Alternately, instance_create could work like instance_create_depth(x,y, 0, obj).

The only weirdness about this is that objects no longer have a depth; only instances have depth, and really to emulate the way GMS1.x works, it would need to respect a default object depth property that could vary, object by object.

 

[rwkay]

There is no way that you will get instance_create back, the main reason for the change is that objects no longer have a depth setting in the IDE but the instance keeps its depth variable, so instance_create does not know what depth the instance is to be at so you need to provide that bit of info for instance_create_depth at the very least, though we would encourage you to think in terms of layers

You will find that we provide all these things with Import in the full product (not the Trial) and the compatibility scripts gives you an instance_create script that looks up the depth of the object from a map that we create for you from the initial 1.4 project.

Russell

 

[FrostyCat]

There is no way that you will get instance_create back, the main reason for the change is that objects no longer have a depth setting in the IDE but the instance keeps its depth variable, so instance_create does not know what depth the instance is to be at so you need to provide that bit of info for instance_create_depth at the very least, though we would encourage you to think in terms of layers

You will find that we provide all these things with Import in the full product (not the Trial) and the compatibility scripts gives you an instance_create script that looks up the depth of the object from a map that we create for you from the initial 1.4 project.

Russell

Please check, we are NOT asking for instance_create() back. We are asking for the ability to write our own replacements for instance_create() and other obsolete functions instead of using the built-in compatibility scripts, without being blocked by the IDE.

 

[csanyk]

There is no way that you will get instance_create back, the main reason for the change is that objects no longer have a depth setting in the IDE but the instance keeps its depth variable, so instance_create does not know what depth the instance is to be at so you need to provide that bit of info for instance_create_depth at the very least, though we would encourage you to think in terms of layers

You will find that we provide all these things with Import in the full product (not the Trial) and the compatibility scripts gives you an instance_create script that looks up the depth of the object from a map that we create for you from the initial 1.4 project.

Russell

I hear you; I'm not sure why a "assume default instance layer" solution isn't a reasonable way to handle instance_create() (as opposed to deprecating it), though? What was YYG's reasoning to deprecate rather than assume a default layer, if you don't mind my asking? Was it necessary in order to avoid mishandling legacy project code that was written at a time when objects did have depth? If so, then it makes sense to me to do what you guys did.

Really, getting used to instance_create_layer takes next to no effort. So I don't see this as a big deal. It just seems like it at first because instance_create is such a commonly used gml function.

 

[rwkay]

@FrostyCat - you can just create a script called instance_create now there is nothing stopping you...

@csanyk - we did have this for a long time but it had lots of issues with this and did not act in the way everyone expected (and it had lots of hidden performance problems, and caused a lot of complaints), so we took the decision to take the pain early on in the product cycle rather than limp along with something that obviously did not fit.

Russell

 

[csanyk]

@csanyk - we did have this for a long time but it had lots of issues with this and did not act in the way everyone expected (and it had lots of hidden performance problems, and caused a lot of complaints), so we took the decision to take the pain early on in the product cycle rather than limp along with something that obviously did not fit.

Russell

Thanks for elaborating! I really appreciate the way you, Mike, and Shaun have been so open since the beta was released. It gives me a lot of confidence in the product to know that you guys are standing behind it, accessible and accountable to us.

 

[xot]

Since we can't import 1.4 projects to see what it does to them, can someone from YYG comment on what the compatibility script is like for instance_create()?

%PROGRAMDATA%\GameMakerStudio2\Cache\runtimes\runtime-2.0.1.16\lib\compatibility.zip

 

[zendorf]

Is it possible for the GMS1.4 - GMS2 importer to look at the depth level of the object (set in the object gui) and just change any instance_create() commands to instance_create_depth(x,y, z, obj), where z is the depth obtained from the GUI in the original project? Otherwise, I will have to go through the whole project and do this manually. Does the inbuilt compatibility instance_create script use instance_create_depth or instance_create_layer in it?

Ideally I would go through and add layers to all rooms. Is there a way to globally add layers to a series or rooms? If I have 50 rooms, can I assign the same 5 named layers to all of these? I know I can do this at a code level, but what about at the GUI level?

 

[icuurd12b42]

Is it possible for the GMS1.4 - GMS2 importer to look at the depth level of the object (set in the object gui) and just change any instance_create() commands to instance_create_depth(x,y, z, obj), where z is the depth obtained from the GUI in the original project? Otherwise, I will have to go through the whole project and do this manually. Does the inbuilt compatibility instance_create script use instance_create_depth or instance_create_layer in it?

Ideally I would go through and add layers to all rooms. Is there a way to globally add layers to a series or rooms? If I have 50 rooms, can I assign the same 5 named layers to all of these? I know I can do this at a code level, but what about at the GUI level?

I think it it's sort of why they left the implementation to you!!!

Why dont you create and instance_create that peeks at the object_get_depth(), hopefully it's still there, and have your code create it at the right layer. I mean its 4 lines of code...

 

[zbox]

Just use a find and replace program over your game files to replace the function with the name of your own custom one?

 

[zendorf]

I think it it's sort of why they left the implementation to you!!!

Why dont you create and instance_create that peeks at the object_get_depth(), hopefully it's still there, and have your code create it at the right layer. I mean its 4 lines of code...

The problem being that once it is imported into GMS2, the object no longer holds a reference to the depth info like it did in 1.4. That is why I was suggesting that the converter/importer looked at the depth of each iobject and used that depth for each instance_create conversion that relates to that object. I have hundreds of objects and instance_create commands in my game and don't relish the thought of doing it manually. If I have to bite the bullet, I will, but I will redo it and use layers, not depth.

 

[Nocturne]

Ideally I would go through and add layers to all rooms. Is there a way to globally add layers to a series or rooms? If I have 50 rooms, can I assign the same 5 named layers to all of these? I know I can do this at a code level, but what about at the GUI level?

Yes, you can do this EASILY in GMS2!!!! Create a single "base" room with the layers setup as you want then make your other 49 rooms "child" rooms. They will then inherit the layers and properties of the base room which you can then modify as required. Room inheritance is designed just for things like this.

The problem being that once it is imported into GMS2, the object no longer holds a reference to the depth info like it did in 1.4.

Yes it does. the "depth" variable still exists and it still works. You can use depth exactly as you did in 1.4 too. It won't be as efficient since it now creates "managed layers" (ie: unique layers for each depth setting that you, the user, have no access to and that will be created/destroyed by the engine as required), but you can still use it and it'll still work as it always did...

 

[Ethanicus]

Yes, you can do this EASILY in GMS2!!!! Create a single "base" room with the layers setup as you want then make your other 49 rooms "child" rooms. They will then inherit the layers and properties of the base room which you can then modify as required. Room inheritance is designed just for things like this.



Yes it does. the "depth" variable still exists and it still works. You can use depth exactly as you did in 1.4 too. It won't be as efficient since it now creates "managed layers" (ie: unique layers for each depth setting that you, the user, have no access to and that will be created/destroyed by the engine as required), but you can still use it and it'll still work as it always did...

So, as redundant as it sounds, you could have something be in layer 26, but have the visible depth of, say, -57?

 

[Nocturne]

Yes, exactly. There are still cases where depth is useful, even if it's not recommended... the typical scenario is the pseudo isometric games that require depth = -y, but there are other cases.

 

[icuurd12b42]

Yes, you can do this EASILY in GMS2!!!! Create a single "base" room with the layers setup as you want then make your other 49 rooms "child" rooms. They will then inherit the layers and properties of the base room which you can then modify as required. Room inheritance is designed just for things like this.



Yes it does. the "depth" variable still exists and it still works. You can use depth exactly as you did in 1.4 too. It won't be as efficient since it now creates "managed layers" (ie: unique layers for each depth setting that you, the user, have no access to and that will be created/destroyed by the engine as required), but you can still use it and it'll still work as it always did...

Problem is there are no object_get_depth()...

So he cant designate/route the instance create layer without a huge case statement

 

[Nocturne]

Objects don't have depth... depth and layers are dynamic and assigned at the instance level. You can't do "object_get_image" to get the image index of an object either, because this is dynamic and set at runtime, not in the IDE.

 

[icuurd12b42]

Objects don't have depth... depth and layers are dynamic and assigned at the instance level. You can't do "object_get_image" to get the image index of an object either, because this is dynamic and set at runtime, not in the IDE.

Ok, we know. the problem is he wants to route his instance create, making a instance_create() function, that would call the right instance_create_layer() so that object of depth 0 can go on layer of depth 0....

the only solutiuon now is a huge switch
///instance_create(x,y,obj)
switch(argument2)
{
case obj_Player: instance_create_layer(argument0,argument1,argument2,"Layer0");
break;
case obj_Ground:
case obj_Grass: instance_create_layer(argument0,argument1,argument2,"Layer1")
break;
....
}

 

[zendorf]

Yes, you can do this EASILY in GMS2!!!! Create a single "base" room with the layers setup as you want then make your other 49 rooms "child" rooms. They will then inherit the layers and properties of the base room which you can then modify as required. Room inheritance is designed just for things like this.


Yes it does. the "depth" variable still exists and it still works. You can use depth exactly as you did in 1.4 too. It won't be as efficient since it now creates "managed layers" (ie: unique layers for each depth setting that you, the user, have no access to and that will be created/destroyed by the engine as required), but you can still use it and it'll still work as it always did...

Ok thanks, good to know. I just hunted down the compatibility script suggested by xot and realised it is only 2 lines of code. Good to see that object_get_depth does the trick

Does having lots of "managed layers" created automatically by using the instance_create_depth slow down the engine? I would imagine that the engine performs better with a minimum number or layers?

 

[gnysek]

Instead of complaining here, wait for full version beta, I can assure you, that after importing project instance_create() works as it should (at least until you add new object, as you need to extend global array with depths to have this object too, or remember to use instance_add_layer for new ones ).

I've make a test with YYG staff with my very big project (500+ sprites, 250+ scripts, 100+ objects, 20+ rooms) and they it imported and game works without problem in GM:S2, without even one line change in code! So for most of games, making them to work in GM:S2 should take less than minute.
I cannot wait for desktop beta to pay for full version, after I know my game will work when imported, and I can also use all those new features!

 

[icuurd12b42]

I think the main thing everyone should consider is to forget about it... Frankly stick to Studio for your old project and use GMS:2 for your new project. Problem solved. That's what I'm doing and I have no problem with that.

 

[rwkay]

Is it possible for the GMS1.4 - GMS2 importer to look at the depth level of the object (set in the object gui) and just change any instance_create() commands to instance_create_depth(x,y, z, obj), where z is the depth obtained from the GUI in the original project? Otherwise, I will have to go through the whole project and do this manually. Does the inbuilt compatibility instance_create script use instance_create_depth or instance_create_layer in it?

Ideally I would go through and add layers to all rooms. Is there a way to globally add layers to a series or rooms? If I have 50 rooms, can I assign the same 5 named layers to all of these? I know I can do this at a code level, but what about at the GUI level?

I believe I already said that this is exactly what happens

the compatibility scripts gives you an instance_create script that looks up the depth of the object from a map that we create for you from the initial 1.4 project.

We have endeavoured to make the import of a GMS1 project into GMS2 as pain free as possible, and most projects should just "run", the problem projects are ones using extensions that rely on DX9 or use an HLSL9 shader.

Russell

 

[Sam (Deleted User)]

Thanks Russel for the info, its good to know, and I'm really looking forward to purchasing the desktop edition when it comes out.