Інсталювати 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 (в’єтнамська)
Повідомити про проблему з перекладом
This seems to be the full-proof way to do it, where +33 is one pixel more than the length/height of my player object (in my example, the origin is set to 0,0.
Oh hey, code tags. Didn't know about that.
Anyways, what you want is specifically the first part...
It should be pretty self-explanatory, but pretty much it's not enough to test for an overlap because the overlap tests every point on the block. I don't know the actual effect of modifying x and/or y when specifying a position to test, I just know that it tests the whole block when unmodified.
So, in addition to testing an overlap, you need to test whether or not your object will meet with the object that it's landing on/bumping into at the location specified by the overlap. This way you can give specific instructions based on where they meet.
EDIT: If that doesn't work, I might have to do some coding of my own with a movable block. Not really sure what could be going wrong.
EDIT: Just noticed, I seem to be able to jump off of the spot where my 'character' block begins as well, so it seems that neither object is being tracked correctly for one or both of the statements in the check.
EDIT: Try changing your physics world update rate?
I have iterations and update speed both set to my room speed.
This was the code that made the block zoom all over the map. I finally realized that the 'all' keyword includes 'self', meaning the object is checking to see whether it will overlap with itself. I can make this stop by changing y+1 to y+33 to make the check occur outside of the sprite's box; however, even though the sprite's origin is set to the top left of the sprite (0,0) this change will cause the character block to jump even when it is 33 pixels away from the ground. I want this character block to be able to utilize any physics object present in the room so 'all' seemed like a good, clean keyword to use, but is there any way to subtract 'self' from it? I could always check for each object individually but I was hoping someone knew of a more elegant solution.
Also, Mattchu, curious to know whether replacing '0' with 'phy_rotation' would help your rotation issues at all? It might not make any difference, though; I can't test it myself yet since I'm still having the block issue.
Thanks for reading and sorry for asking so many questions!