Obstacle Climbing discussion

Anyway, a bit off-topic regarding the climbing. Of course the mechanic is OBAN/TRAM/TRIGVOL/BSL. It works for both player and the AI.

For player: player enters the "climb area" trigger volume, which switches an enabler variable in BSL. Then if player taps jump, corresponding OBAN and TRAM are played.

For AI: similar, but since AI does not have that advanced alorithms, it has to be told when it makes sense to use climbing machanism. Thus another TRIGVOL is place on top of the furniture, that trigvol is player trigger only. If player is inside, AIs are allowed to use climb mechanism when they enter the climb trigvolume.

This mechanism works like a charm, however it has a few drawbacks.The biggest one is a need for a dense net of TRIGVOLS/OBANs. One OBAN has to be placed circa each 10 units along the furniture edge to make the mechanism look at least somehow user firendly while not confusing TRIGVOLs (trigvols must NOT intersect, otherwise the BSL conde gets confused).

It would be the best if Oni allowed "fromhere" parameter for OBANs, something similar to FILM playback parameter "fromhere". That would be enough to enlighten the resource burden. Instead of dense net of OBANs (each place in space required its own original OBAN) the set of OBANs with rotated facing would be created (let's say one OBAN per 30°) and then the corresponding OBAN would be triggered by one long trigvol palced along the whole edge. Much cleaner solution in my opinion.

And so I ask, does anybody here have an idea how to do this feature without that annoying need to have one OBAN placed each 10 units?

EDIT:This mechanic is one of possible feature designs for EdT's China level, so I didn't bother releasing the package. In case someone would like to try this feature out, HERE is a rar with oni files.

EdT replied with a modification:

Added height information to the jump TRAM, for the triggervolume script I used:

An idea. (Still includes TriggerVolume and FILM.)Let's cut the TRAM into two parts. First part has fast accelerating hights, second part is of type Fly.Would the upwards velocity remain so that the second part take it over and then the characters lands on the obstacle?

Edit: Oh wait, are we talking about the same thing, Ed? Or does your modification use OBANs?

Loser replied:

On a serious note EdT, you are using Gumby's code hack, which unsticks origin of TRAMs, thus allowing characters to move over obstacles even when those characters are not jumping. That will work for modified exe and app files, but in vanilla Oni your TRAM modification fails, because the origin keeps sticked at the height where TRAM started. That is why in vanilla Oni characters cannot be thrown over railings. And why I used OBANs ^_^

Indeed, if somebody somehow solves this annoying issue nad globally releases fix which allows TRAMs to pass over obstacles (like in your case), then this whole mechanics reduces to only a TRAM animation (or maybe better is to use FILM which fontains the TRAM animation) and TRIGvolumes. And also such a fix means characters will start to be thrown over railings and through windows.

I don't have access to *certain accessories*, but in case some of those guys who have decides to help the community, here's a tip- unstick the origin of characters- add a variable to the character class which will be used to store object character's height at the moment any TRAM starts.- during the TRAM execution till its end check if the height of the origin position is higher than this archived value. If yes, that means the character is passing over some obstacle. This pass would cause sudden change of character's vertical position. That change happens beacuse origin of the character object (the point to which animation is related) moves to a higher place than it was when the animation started.- If the the check is positive (origin si higher the it was), then subtract the difference of heights from incoming TRAM height data (to compensate fo the origin height change in order to avoid sudden character position change) before redrawing the character on scene. If the check is negative, leave it, as that means either the vertical position of the origin didn't change or the change is negative, i.e. character is falling down.- keep checking for the difference and subtracting if needed till this TRAM ends- Load new value into the variable as some new TRAM starts.- Rinse repeat this all the time for each executed TRAM.

If THAT code (of course properly tweaked) was in effect, it would allow thrown victims to fly over obstacles and it would also allow climb mechanics to be a whole lot lighter on resources - on need for OBANs then, just long TRIGvolumes along furniture edges and a few FILM files which contain properly rotated TRAMs.

EDIT: Dox, vertical positioning of TRAM is not expressed in velocities but directly in heights. Seems like Bungie West folks had similar idea to the one described in this post, but somehow "forgot" to implement it. ^_^

I believe the reason this works is that only with the TRAM type of fly, the character's collision sphere is attached to the bottom of the feet. The rest of the TRAM types the sphere remains attached to the ground. So by going from the jump move to the testjump TRAM, the fly state takes over so you can go over the crate

Paradox: I did not use OBANs for the animation, as mention above I used this code:func void tr_jump7_enter(string ai_name){ chr_wait_animtype(0, Jump)chr_animate 0 KONOKOtestjump2}

As long as you are moving forward when jump key is pressed, you will move over the crate.

Re: Obstacle Climbing discussion

Nice testing level EdT ^_^.

AnimType Fly does not seem to have our desired effect, but AnimStates "Flying" and "Falling" do. However, this looks like extension of jumping mechanism, similar to jump-flip. While it is certainly interesting that height adds (so character can jump higher), it is not suitable for obstacle climbing as it relies on each ONCC's unique jump parameters.

Re: Obstacle Climbing discussion

Re: Obstacle Climbing discussion

EdT, you have done enough: whole level creation testing/feedback to Neo + tutorials on how to create levels ^_^.

Gumby: well, extension/fix of TRAM code via Daodan would be better, but if it is not possible, then the BSL command could be useful. Question is, if Y position is set by BSL, what about XZ? When lifted above the ground, characters lose ability to move in XZ, they keep pacing at the last applied velocity till they land again (at least that's how it looks).

Re: Obstacle Climbing discussion

EdT, you're gonna make me do all the work? Also, they don't lose all XZ ability, just like 90% or so. I can make a command to set all three velocities, if you like. I'd love to be able to edit TRAM code, but the last time I looked at it, it was too messy to do in daodan.

Iritscen:Iritscen: it's amazing this program even worksGumby: i knowIritscen: and that statement applies to my code, not just yours