Oni Central Forum

A forum for the Oni community

You are not logged in.

#1 9/6/12 16:04

EdT
Moderator

Obstacle Climbing discussion

In review from the Movies thread.

Loser posted a video on youtube which demonstrated obstacle climbing: http://www.youtube.com/watch?v=bC3B6WKEngw

Explanation of the climbing process:

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:

func void tr_jump7_enter(string ai_name)
{   
chr_wait_animtype(0, Jump)
  chr_animate 0 KONOKOtestjump2
}

This is the result: http://www.youtube.com/watch?v=F9lpcxrTdAY


paradox replied:

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. ^_^

Offline

#2 9/6/12 17:13

EdT
Moderator

Re: Obstacle Climbing discussion

Loser:  I tested this level using the community patched PPC version of Oni, which does not have Gumby's code hack and the results were the same:
www.youtube.com/watch?v=mjOzij9HTFY

This program is so old, it did not have the command chr_debug_sphere, so I could not use it in the video smile

Here are the files (bsl and dat) using level7 (PC version only) and a level0 plugin for the modified jump TRAM. Please test this out. http://edt.oni2.net/files/climbdemo.zip

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.

Offline

#3 9/6/12 22:49

Loser
Member

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.

Last edited by Loser (9/6/12 22:49)


"I am just a mere reflection of what I would be."

Offline

#4 9/6/12 23:45

Gumby
Member

Re: Obstacle Climbing discussion

It should be possible to make a BSL command that sets the Y velocity for a character.


Iritscen: roll
Iritscen: it's amazing this program even works
Gumby: i know
Iritscen: and that statement applies to my code, not just yours

Offline

#5 10/6/12 0:23

EdT
Moderator

Re: Obstacle Climbing discussion

Loser:  Well I tried...   smile

Gumby:  I'll be keeping an eye for that command.

Offline

#6 10/6/12 0:43

Loser
Member

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).


"I am just a mere reflection of what I would be."

Offline

#7 10/6/12 1:01

Gumby
Member

Re: Obstacle Climbing discussion

EdT, you're gonna make me do all the work? neutral 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: roll
Iritscen: it's amazing this program even works
Gumby: i know
Iritscen: and that statement applies to my code, not just yours

Offline

#8 10/6/12 9:02

EdT
Moderator

Re: Obstacle Climbing discussion

Loser:  Thanks, I have an idea on how to use the climbing OBANs in the china level, hopefully I can make it work.

Gumby: It was your idea...  besides we need you to be back and updating the Daodan with cool stuff big_smile

Offline

#9 10/6/12 19:32

Gumby
Member

Re: Obstacle Climbing discussion

uint16_t ONICALL bsl_setVelocityY(sl_callinfo* callinfo, uint32_t numargs, sl_arg args[], int* dontuse1, int* dontuse2, sl_arg* ret)
{
	int index;
	if (numargs != 2 || args[1].type != sl_float) return -1;
	else if (args[0].type == sl_str32) index = DDrGetCharacterIndexFromName(args[0].value_str32);
	else index = args[0].value_int32;
	ONgGameState->CharacterStorage[index].Velocity.Y = args[1].value_float;
	return 0;
}

	SLrScript_Command_Register_ReturnType("chr_set_velocity_y","Sets velocity", "[ai_name:string | script_id:int] velocity:float", bsl_setVelocityY);

Don't have the daodan codebase installed at the moment so I can't test, but this should work just fine for you once you change the appropriate variable names.


Iritscen: roll
Iritscen: it's amazing this program even works
Gumby: i know
Iritscen: and that statement applies to my code, not just yours

Offline

Board footer

Powered by FluxBB