View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0021921||Runner Suggestions||Functions||Public||2016-06-15 10:13||2017-03-07 15:07|
|Reporter||Stewart Bishop||Assigned To|
|Summary||0021921: Suggestion: Functions: instance_create_layer() doesn't use the target room set by layer_set_target_room()|
|Description||If you specify a target room for your layer functions using layer_set_target_room() this will work for most functions. However, if you use it for instance_create_layer() then it will not work, as this isn't built to use the target room but instead the current room.|
|Steps To Reproduce||1) Create two rooms|
2) Create an object
3) Create another object
4) Within the second room create an instances layer
5) Inside the object add in a create event which uses layer_set_target_room
to set the next room as the target
6) Place some instance_create_layer function calls for the second object on the instances layer we previously created
7) Add in a step event to check for input to move to this room
8) Run your project
9) When you go to the second room you'll see that there have been no instances created
|Tags||No tags attached.|
LayerSetTargetRoom.zip (25,076 bytes)
Could have sworn I'd added a comment on this one yesterday...
Anyway, it's not meant to work like this (instance_create_layer will always use the current room), so I've assigned this one to you Mark just to call out in the manual that layer_set_target_room() will have no effect when doing instance_create_layer() and that instance_create_layer() will always target the current room, regardless of which room is being targeted by other functions at that time.
||Manual has been updated to reflect this, but I can see no reason why this shouldn't work from a users point of view... if you can set everything else related to layers in a room, then omitting instances seems really absurd and is a glaring omission (imho).|
||Assigning on to see how feasible it is that this can be added for the instance_create_ functions.|
After further thought there's a bit of an inconsistency with how this would work compared to 1.x. There, you use room_instance_add() to add instances to other rooms - should we not instead have room_instance_add_layer() then?
Or should we ditch room_instance_add() in GMS2 and *just* use instance_create_layer() to add to both the current *and* other rooms (dependent on what your target room is)? I don't think room_instance_add() will actually work just now in 2.0 (although I haven't tested it it looks as if instances added this way won't be drawn, though their steps events etc will still be called).
And how does instance_add_depth() fit into this? Should that also be affected by the target room?
Why not create an alias function "layer_instance_create" (maintaining the naming convention for layers, as we have layer_sprite_create, etc...)? this would essentially be the same as "instance_create_layer", but work for rooms other than the current room (it could also be used in the current room?). Having a new function makes it more explicit that this is for different usage, but I see no reason why people couldn't use it instead of instance_create_layer() if they choose to.
Alternatively, couldn't we adapt the current function "layer_add_instance" for this? So, if you are in the current room you supply an instance ID, BUT if you have set the target room to something other than current then you can supply an OBJECT ID so that an instance is created on that layer when you enter the room?
As for instance_create_depth, I think that for adding instances to other rooms, this can be forgotten. Depth can be set easily enough at run time, or you could have the layer function for creating instances return the instance ID and the user can use THAT to set the depth.