I'm having some serious problems programming lifts.
The problem is that the character always, despite in whatever manner i code it, gets sunk 1 or more pixels down into the lift.
But that shouldn't be happening.
I use a custom platform engine with fastloops that moves the character and all detectors 1 pixel at a time as long as they don't overlap the lift, I move the lift using regular loops. Are these two manners conflicting in any way?
The lift is moved 1 pixel if the character is not standing on it, the lift + the character are (in the same event) moved 1 pixel if the character is standing on it.
I thought that method would make it so that they are moved simultaneously.
Are there any old examples of this? I still use MMF 1.2 not 1.5 or 2. I have an example from Phizzy made in the old TGF, "Mario platform something", it works perfect there, but not for me! I really don't get it. So if someone has any experience with lifts, by all means.
It's hard to tell what the problem is without seeing the source code in some way., but it could be the order of your events. If you're moving the platform up on line 4 and the guy on line 28 (especially after any detector collision events) then there's a chance that he'll sink into the lift.
If it matters here, some of the lifts in Hasslevania had problems with them until I changed where my "lift code" group of events was located in the event order. Sounds weird, but maybe that would help?
--
"Del Duio has received 0 trophies. Click here to see them all."
"To be a true ninja you must first pick the most stealthy of our assorted combat suits. Might I suggest the bright neon orange?"
DXF Games, coming next: Hasslevania 2- This Space for Rent!
Events will execute in the event editor in a specifically TOP-to-BOTTOM matter. This is dead necessity to understand. This is, however, bypassed by calls to loop objects. When a loop event is called, imagine it as if the "On Loop Trigger X" events you have further down in your code are moved to directly after when you called it, and copy/pasted enough times to satisfy the loop. In essence, this is what it is doing.
After this, actions taken within each event are stored in a direct TOP-to-BOTTOM list of their own in order to run through the read/eval/print of the compiler. So lets take a look at a single frame of gameplay:
(your player is currently 1 pixel above the platform, not overlapping it)
Your code is structured in this order:
+If player =/= Overlapping Lift
=Set Y of Lift up by 1
+If player == Overlapping Life
=Set Y of Life up by 1
=Set Y of Player up by 1
So when this is fed into the system, and it trys to run through the frame, this is what happens:
Frame 1:
Player =/= Overlapping Lift? (TRUE)
so sets Y of lift up by one
THEN IT READS THE NEXT LINE:
Player == Overlapping Lift? (TRUE*) *Now that the lift is 1 pixel higher, it is overlapping the player
So sets Y of lift & player up by one
Frame 1 total: Lift moved up by 2, player moved up by 1.
Frame2:
Player =/= Overlapping Lift? (FALSE)
Player == Overlapping Lift? (TRUE)
so sets Y of lift/player up by one, again
Frame 2 total: Lift moved up by 1, player moved up by 1.
After this point, "Frame 2" keeps repeating, over and over. Since in order for your last event, the "Player == Overlapping Lift?" to be true the player must be stuck at least 1 pixel into the lift, when the entire frame resolves, the player will appear 1 pixel down. Add to this that the frame where you initially *hit* the lift, it should appear to jump by 2 pixels instead of 1.
Hey guys thanx for all the ideas!
But I am very aware of the event order issue and have tried swapping the event positions to no luck. Pixelthief's thorough run-through of the event is exactly what happens, but the problem must be something else!
My code is:
+Always
= Start loop 0 for one loop
+On loop trigger 0
+Detector is not overlapping lift
=Trigger loop 1 for "Y velocity of Player" loops
+On loop trigger 1
+Detector is not overlapping lift
=Set player Y to Y+1
=Set detector Y to Y+1
That's the fastlooped player movement, events high up in the editor, that should be excecuted first.
+Detector is overlapping lift
=Set Lift Y to Y-1
=Set Player Y to Y-1
=Set Detector Y to Y-1
+Detector is not overlapping lift
=Set Lift Y to Y-1
Those are the lift events, ordinary, not fastloops. These events occur way after the fastloops.
Anyone? It's higly illogical, the Vulcans won't be too happy when I release it.
Actually, no Vulcan should be happy since they don't have/express emotions...
Sarek maybe, but not anyone else...
Advertisement
Post Reply
