新人請益
現在想弄一個可以再多個不同房間(room)都能呼叫出來的通用介面
最初的思路是：寫一個script，呼叫他的時候就把這個介面需要的每個物件都在指定位置創造好
這樣無論在哪個房間都可以呼叫這個script來叫出介面。
但缺點是這樣必須把每個物件的位置都用xy座標指定出來，沒法方便的直接在房間編輯器中根據實際見到的位置拖曳調整。
為了可以方便在房間編輯器中拖曳調整介面中每個實例的位置，另一個想到的作法是：
專門開一個房間，把這個介面的所有東西都放在該房間某個特定的實例層裡，之後哪個房間會需要這個介面就直接把這整個實例層複製到需要的房間中。（之後再用功能呼叫）
但實際操作後發現好像沒法把實例層從一個房間複製到另一個房間裡。
所以在糾結，到底要怎麼實現可以在房間編輯器中拖曳編輯的通用物件。
不知道前輩們對此有甚麼思路或建議呢？

我个人应该会选择更类似前者的方法，毕竟游戏完成时所有实例的位置总会确定下来的，对我来说在房间编辑器里拖拽并不是特别必要。听说gms2里是有一个可以类似编辑动画的功能的，也许也能用来做这种？不过我不是很清楚，希望其他人能解答

你添加一个命名为system的obj，把呼唤系统界面的代码输入进去，然后把system的编辑界面的“保持”选项勾选，随后放在进入游戏的那个房间，这样你在切换其他房间的时候，system都会存在

GM引擎对于UI这块的支持，确实被大家吐槽了很久。理论上题主提出的方案可以用“保持”（Persistent）这个功能来尝试一下，但咱之前见到了太多使用这个功能导致的BUG，而且考虑这些BUG的修复和咱很多已知的逻辑框架相冲突，就没有深入研究。咱建议的方向是这样：
0、先进入一个房间，这个房间有摆放好的所有UI；
1、有一个主控object，负责解散掉所有UI object；
2、这个房间（可以叫UI房间）设置为保持；
3、跳转到正式游戏房间；
4、在触发唤醒条件时，UI的主控object负责解散掉房间内的实例，并重新激活属于UI房间里的各object；
5、退出菜单时，进行4的反向操作。
//此框架未经测试
另外如果需要暂停时仍然显示游戏正在进行的样子，可能需要在唤醒菜单时进行截图（或者其他什么方式）来留下一个静态图片用于显示。还有要补充的就是这个框架会使用激活/解散操作，如果游戏里其他地方也在用类似操作的话可能会冲突。
其实咱个人来说还是更推荐script的思路，制作的时候麻烦一点但用熟悉的方法来做可以减少预期外的BUG。用房间摆放再导出一些数据的方法也许可以简化一些制作流程。

感謝各位建言！
原來是用Persistent，之前看的時候還在想啥狀況會用到這玩意，沒想到是UI可以用 囧
請問如果照吧主建議，把整個房間設為Persistent的做法，是要在呼叫UI（步驟4.）的時候直接整個轉移到UI房間嗎
否則應該無法在［正式遊戲房間］中直接重新激活另一個［UI房間］的物件（吧？
不過可以請教一下Persistent會產生的相關BUG內容嗎？
感覺可以做為考慮實作邏輯的參考

咱知道的可以设置persistent属性的有object和room。之前看有人制作大地图分割小地图，是把obj_player设置成了persistent，运行的时候在不同小地图之间移动还算平滑流畅且位置正确，但每次回到初始区域时就会多出一个obj_player。
房间如果设置成保持，猜测在类似情况下也会触发类似BUG，比如显示出了两套UI，任何选项都会执行两次，弹窗也会弹两个……关于BUG的触发细节、避免方法、BUG触发后的弥补方案，咱这里没有具体的信息，毕竟咱是在第一次看到类似BUG的时候就决定避免使用相关功能了。
至于“是要在呼叫UI（步驟4.）的時候直接整個轉移到UI房間嗎？否則應該無法在［正式遊戲房間］中直接重新激活另一個［UI房間］的物件（吧？”，如果咱的推测属实，回答则是“绝对不要切换到UI房间”。因为UI房间的保持属性，房间内的所有物件依然是“存在”的，切换到UI房间会触发“所有东西增加一套”的BUG。当然，因为咱没有实际测试过，这些推测可能不对，可以按这个思路制作一个测试工程，分别测试房间跳转和不跳转，观察一下结果。

回UI房間會多一套聽起來怪蠢的...
感謝分享，聽起來還是避免這種作法安全些

自己写一条gui 毕竟gms2你早晚要有一套自己的