Here are some new wm-friendly entities: pin triggers and blockers.
demo here
source here
EDIT: version last updated on 2012.03.21
1 decade ago
by Xaan
Nice!
Possible bug: when I stay on the mover the whole way through the loop, when it goes back to the top left corner, when it moves to the right again the player "jumps" and almost always falls off despite not having touched the keyboard.
Unless that's intentional...
I had noticed that but I thought no one else would. :)
The included player is actually the one that's in the biolab entity pack. I'll try and tweak its settings some more.
Great plugin. Finally figured out I had to set my mover to type "B" and have the waypoints check for B. But for some reason it only delays the first time around. Can you think why this would happen?
Finally figured out I had to set my mover to type "B" and have the waypoints check for B.
Yeah. I know it's not explained very well. I think I'll push my test level file to github to give a concrete example.
But for some reason it only delays the first time around.
Not sure why this would happen. Let me check.
In the meantime, I found/fixed the bug reported by Xaan, so I recommend that you pull from git at the earliest convenience.
It might have something to do with my other entities from the biolab pack. I noticed some code in my mover was slightly different than yours. I may have an old set of biolab entities.
[EDIT]
My trigger entity was different than yours. I copied your and now it works.
And I got the "jumping" fix too. Thanks.
@stahlmanDesign
Hmm. Blocker durations work fine on my side, repeatedly.
Did you set a duration for each blocker in WM? If none set, the default would be 1 second. As of the second pass, are there any delays , or none (1 sec default, or 0 secs)?
Found it. I had modified trigger.js with a wait time of 1. Big mistake to touch someone else's class. I'm updating waypoint.js to make it a direct descendant of Entity. Will push in minutes. Thanks for catching this.
While we wait for a new waypoint.js, if anyone wants to use the plugin as it is now, change one line your trigger.js file:
wait: -1,
change to
wait: 1,
However, this could of course affect any other entities that use trigger.js
To confirm, there is no more need to modify trigger.js. Waypoint is independant of that now.
I've just tried this out, for some reason it's gradually slowing down my game's FPS.
Nothings coming up in the console (I've disabled the ig.logs), and I can make a simpler demo that doesnt seem to be affected, but when I've got about 50 waypoints it draaaags.
Any clues as to how I can stop that? I'm guessing clearing EntityWaypoint's 'visitors' might help or something?
I haven't tested it with that many waypoints. Are you using blockers too? I'll set up a level with that many (or you could send me your level file, or send in a pull request via git) and see what profiling shows.
As you know, each waypoint keeps track of its visitors. Few visitors, few checks. I'd be curious to see your level, or a screengrab thereof. I can try to replicate that on my side and see what gives.
Hey Alexandre, I've just made this level and it still happens after about 2 minutes.
Red is blocker, blue is point and yellow is mover. :)
Okay. I'm a moron. Stupid mistake. Just saw I had an invisible entity spawning when they hit the points too.
DERP.
I had an invisible entity spawning when they hit the points too
Spawning every time? That would indeed explain it. :) <phew>
Is it okay now?
By the way, I think this EntityWaypoint should be renamed. Its really more of a precision trigger. The current name is misleading.
But I don't want to rename it to EntityTrigger as that's taken.
If you have any ideas, let me know.
alex
Yeah, works great now. You're a star.
I've called it EntityPoint. Works for me. :)
I'll rename it EntityPinTrigger. Your mention of point triggered that. :)
When I add this in WM, it doesn't appear and I get this error:
TypeError: 'undefined' is not an object (evaluating 'settings.checks.toUpperCase')
Fixed and
pushed to git. Thanks for catching that.
Confirmed that it now works.
[EDIT] at least I don't get the error, but I'm not getting the blocker to delay the mover.
[EDIT] OK, just needed to change my mover to type A
type: ig.Entity.TYPE.A,
But now I have to get my enemies from killing it :-)
The blocker doesn't care about collision types. It just blocks whenever its triggeredBy method gets called.
At the top of point-trigger.js you will see a brief explanation of what it does and how to use it. One of the parameters is "checks", just like in the original biolab pack's trigger.js.
You could leave your mover as type.NONE, and add a checks property with a value of NONE to your pin triggers.
Crap. I see the problem. NONE won't work. So the mover has to be of type A, B, or BOTH.
1 decade ago
by paulh
I noticed on your demo that the character still jumps at the top of the vertical platforms waypoint end .. and ideas how to fix this?
That's the elevator effect. Not a bug per se. The mover (part of the biolab entity pack) is a fixed collider type. The character is moved by it. When the platform reaches the top-left pin-trigger and stops abruptly, the character's momentum carries him upwards for a while.
To avoid this side-effect, you could tweak gravity and/or gravityFactor properties, or reduce the mover's speed.
@paulh You could make it a parameter of mover.
Sticky: true
That would make the mover like glue so your entities wouldn't be thrown up in the air when the acceleration ends abruptly.
Then imagine a mover that could go upside down. If you have sticky:true, the entities could also go upside down, say if on a conveyor belt.
1 decade ago
by Jerczu
Nice...
