ติดตั้ง Steam
เข้าสู่ระบบ
|
ภาษา
简体中文 (จีนตัวย่อ)
繁體中文 (จีนตัวเต็ม)
日本語 (ญี่ปุ่น)
한국어 (เกาหลี)
български (บัลแกเรีย)
Čeština (เช็ก)
Dansk (เดนมาร์ก)
Deutsch (เยอรมัน)
English (อังกฤษ)
Español - España (สเปน)
Español - Latinoamérica (สเปน - ลาตินอเมริกา)
Ελληνικά (กรีก)
Français (ฝรั่งเศส)
Italiano (อิตาลี)
Bahasa Indonesia (อินโดนีเซีย)
Magyar (ฮังการี)
Nederlands (ดัตช์)
Norsk (นอร์เวย์)
Polski (โปแลนด์)
Português (โปรตุเกส - โปรตุเกส)
Português - Brasil (โปรตุเกส - บราซิล)
Română (โรมาเนีย)
Русский (รัสเซีย)
Suomi (ฟินแลนด์)
Svenska (สวีเดน)
Türkçe (ตุรกี)
Tiếng Việt (เวียดนาม)
Українська (ยูเครน)
รายงานปัญหาเกี่ยวกับการแปลภาษา
In the loading room creation code:
Now right click on each item object that you place in the room and go to "Creation Code" and add:
Wherever you have the code for the item being "picked up" (probably the item's step event) you need to add:
And finally (also in the item's step event, but outside of the "pick up" check):
There are other ways to do this, but this is the simplest way I could think of.
Note that the game will crash if you forget to give an object an id number or if the object's id number exceeds the length of the array in the creation code (the 20 from earlier).
There's an easy enough fix for that first one, I'd wager; you should be able to declare item_id in the object's create event and give it a default value (probably zero), and then have the instance creation code overwrite that and set the value to something else. Any item you neglect to tag will be marked the same and all go at once, but it'll prevent a game crash well enough.
Ah, I wasn't sure whether the creation code or the create event would be parsed first. If that's the case, then yeah -- easy fix!
The global variables are not reset when you leave the room. They remain persistent throughout your project (they also stay in memory all the time, so you should only use them when you have to).
global.item_collected[n] = false;
do I actually type in 'n'
############################################################################################
FATAL ERROR in
action number 1
of Step Event0
for object obj_item_parent:
Push :: Execution Error - Variable Get -1.item_id(100044, -1)
at gml_Object_obj_item_parent_StepNormalEvent_1 (line 1) - if (global.item_collected[item_id] == true)
############################################################################################
basically when I want to put the object somewhere out of the inventory slot, something cancels it out
And above, you asked if you actually need to put the 'n' as the array index -- yes! The value of 'n' will change each time the loop iterates. In my example the loop runs 21 times. 'n' starts at 0, and will eventually have a value of 20.
EDIT: And it might help if you post some of your actual code, so we can see specifically what you're trying to do.
in item parent;
left pressed event
///Pick up selected item
///Make sure you have NO item
if(global.item == -1){
global.item = object_index;
global.item_collected[item_id] = true;
}
in step event;
if (global.item_collected[item_id] == true)
{
instance_destroy();
}
In obj_syrup right pressed event
action 1;
if(mouse_check_button(mouse_button) == true){
show_debug_message("healed player with syrup")
instance_destroy ();
}
mouse_button = vk_right
(irrelevant)
I know it looks messy but it does work
My general rule with parent objects is to declare defaults for every child object; if every single item uses item_id, then in the parent's create event, declare item_id. If your child objects don't need to change that information, you don't need to declare or alter it so long as the parent has it and it's not overriden (if a parent and child share an event, ie. a Step event, the child event takes priority, but you can call the parent's event from the child with a certain d&d action or line of code). This is actually a pretty serious time saver, so long as you're using your parenting properly.
I'd also argue against the use of persistent objects generally, and rooms... ever. There is very little reason to ever need a persistent room; it causes more problems than it solves, proper use of globals can work around almost any reasonable use, and it bloats GM's default save method's files like nobody's business (one old GM RPG famously wound up with 400+ meg save files due to every room being persistent, making the file larger and larger as you progressed through the game and causing some pretty serious hang time whenever you saved). Object persistance does have some use, but you need to handle it carefully.
And this ties into what the rooms are doing; GM isn't "reloading" the previous room when you leave it, it's dumping it all together. Persistent rooms would stay in memory, but that accumulates over time and ends up taking a lot of space simply to avoid having to code in a simple flag system, which is what we're trying to do here with the item_id business. For now, though, the items come back because GM is reloading that entire room from its default state; if item_id is implemented properly, the items will then be removed immediately, and barring any room transistion animations the player shouldn't even see that happen. As far as you can see while playing, it'll be as if the item was never there in the first place. How fancy.
Watch that mouse button click near the bottom though. You're assigning it's key variable below the check for the click, and also you're assigning it to check for a keyboard key. You're also missing the "pressed" so it's going to fire off every frame that you hold the mouse button in (30-60 times every second; that's a LOT of syrup).
You should write it like this: