Using Different PRP's

[Grogyan]

I did that which you suggested and this is what I have noticed
When you are standing on the rotating ramp and turn flymode on, the rotation vector of the building is adopted by the avatar (this we already knew, hence we weren't able to pickup markers becaszue you were in essence part of that object not a seperate entity, were we able to pick up markers in UU in Gahreesen's rotating portions?)
When you jump off the rotating ramp, the avatar is no longer associated with the rotating building, and therefore doesn't adopt the rotation vector.
You suggested that when you have adopted the rotation vector, the momentum vector is disabled, I theorized this a number of times because when you jump towards the building when on the ramp, the ramp should have moved closer to one edge of the avatar.

What I don't know with flymode, is does it disable the rotation vector of the avatar when one is adopted by the avatar?

As much as I don't want to be convinced that Cyan went back to the dark ages of game programming, when the physical world was moving about you (simple car racing game as an example), I really want to know if this is the case?
Do other big games on the market do the same thing, eg Unreal Tournament, Crysis?

Why on earth would Cyan do this anyway, to me this even less sense than having the entire world split into several different and non interactive parts apart, when its much more sensible to have the all the parts of the world occupy the same point in space, and have the avatar(s) move properly and sensibly through correct 3d space with proper 3d physics.

This is causing me conflicting thoughts and confusing the life out of me, from what I thought and knew, all I need to know to prove the point is with flymode when the avatar was previously standing on a rotating object, does flymode also disable the rotation vector adopted by the avatar?

[Grogyan]

Where I think the confusing part is that Nad suggested

3) Then it inserts you into a subworld, which contains the rotating portion of the building. When you are in a subworld, the game is pretending that you are moving relative to the rest of the world, while you're "really" standing in one spot, watching the rest of the world move around you.

When what really happens I think, is when you're on a sub world component that is rotating, it passes to the avatar ( I call it adopting) a rotation vector and relative 3d distance from the point of rotation vectors which is also synchronized or is suppose to be synchronized to the animation of the object rotating on a polar co-ordinate system.

And flymode works only with the relative 3d distance vectors, the rotation vectors and 3d distance from point of rotation vectors still remain.
This is what I think is causing the problem in Prologue and noted that people were often falling through the pinnicle as they jumped off the ramp

[Lontahv]

I don't see why it matters, really, with virtual worlds there is no real anything.

If we didn't know more about plasma, cyan could have scripted the worlds to wheel around and the avatars to move with it. In uru there is no up and down, only you local node's settings. Flymode turns off a lot of things. As I see it, the avatar stands still in it's own node while it does the walk anim and moves the WHOLE node forward.

The worlds don't move past the avatar(the whole world would have to be animated and it's clearly not). So, I like to think of it from the camera-man's POV so that I can see the world as cyan meant it to be. Hey, if you where a rock on the ground in Kemo who knows what you might see. O.O It's all about how you look at it. From what i've seen cyan doesn't seem particularly fond of doing crafty trick-of-the-eye things(except in Gahreesen ). Their worlds seem solid as 3d games go.

~Lontahv

[Paradox]

. . .
[Nadnerb] well.. it was done with subworlds... which are more of a graphics trick than a physics one.
[Brice] actually iirc the subworlds were a physics hack
[Nadnerb] though, the way it's implemented is not .. optimal. <.<
[Nadnerb] it shouldn't be.
[Brice] depends on what you think they are for
[Brice] the idea was when you are in a moving space you are in a subworld for that space which is Not moving
[Brice] so the physics thinks you are still
[Nadnerb] subworlds would be areas that are static..
[Nadnerb] yes
[Nadnerb] exactly
[Brice] so often the avie has to move between subworlds
[Brice] sometimes with limited success....
[Nadnerb] and when you shift subworlds, it warps you to the equivalent spot in another area.
[Brice] y
[Brice] its hard to remember this stuff...
[Nadnerb] it's a graphics hack because of the way they're drawn on top of each other.
[Nadnerb] when the physics engine doesn't see anything moving..
[Brice] i guess but if it were not for physics they would not exist
[Brice] you can decide which one is doing the hack i guess
[Brice] I would be surprisde tho if the word subworld appears in the graphics code
[Brice] it really should only care about nodes with transforms with animations
[Paradox] The subworld is essentially present so that a "moving" location such as Gahreesen's inside, can exist as a "static", non-moving space
[Brice] yes
[Paradox] Was there any reason that the interior couldn't just rotate?
[Brice] aslo iirc you can specify a list of things that are included in each subworld
[Nadnerb] right.
[Nadnerb] and everything that is in the same subworld you are exists, and everything else... doesn't.
[Paradox] basically
[Nadnerb] which causes problems when they intersect.
[Brice] we had trouble (again iirc) with the avie sitting on a rotating object that was really rotating. Force would get imparted to the avie
[Nadnerb] like markers
[Paradox] ah
[Brice] we did the sw's initially i think for elevators for a similar reason
. . .

[Grogyan]

Thanks for that clarification.

So the central polar co-ordinate that is for the rotation vector is what defines everything else outside of the sub-world to rotate.

I can easily visualise this for single player, but for multilayer, gee whiz, I reckon some more tricks would be needed.


Something to bear in mind when we do rotating or moving sub-world components

[andylegate]

Okay, topic got derailed here: IE, I don't CARE about the rotation at all. Period. I'm not trying to rotate a building. And yes, I've used flymode, way back during the day, and observed when I tried to go into the Training center, it was an empty shell.

Now, back to what I was talking about: warping to your different location is what I'm interested in.

Here is what I'd like to achieve, and I'm using Gahreesen because it's a great example of what I'd like to do:

Upon jumping to the large bridge going to the training center and walking up to one of the air locks:

A) Camera snaps to a different location and you loose control of your Avie.
b) Said avie is shown in a animation of moving forward into the airlock door.
C) Camera snaps to the new area inside the building, where Avie has been teleported to (yes they use that word in the script)
D) Avie is animated as walking into the hall.
E) Camera is cut back to first or third person mode
F) Player is given back control of the Avatar.

I've read the above in the python scripting. Problem is I don't know how to put this into effect for a personal Age.

[Nadnerb]

Well, the teleportatation of the avatar and camera are both possible, the "airlock door" animations are the real sticking point at the moment. I suppose that you could force third person, and have the avatar walk around a sharp corner. I don't know if that's what you want in your effect, but it would work..

As for the python.. you'd need a region for the inside and outside, and two point empties to perform the warp to, two cameras and camera regions, a python script to do the warping and camera juggling, and an alcscript to call the python code when you enter the regions. If I have time today I'll try to put together some sort of example file.

[Owehn]

Out of curiosity, what would happen if you didn't force third-person? Would your surroundings just change jarringly, or would something else (unwanted) happen?

[Chacal]

It would depend on how similar the teleport destination would be to the starting position. The only case the teleport would NOT be noticeable for the player would be:
- the destination room is entirely similar to the origin (same textures, lighting, ambient sound, etc);
- the position and angle of the avatar is entirely similar too, so the view doesn't change even one pixel;
- the client computer is able to draw the next frame after the teleport with no delay at all.

Anything else and you have a jarring change of view on the screen.

[Nadnerb]

It's been a while, but I suppose I probably ought to mention that I did make an example file, but it had a slight issue with the camera. (not being able to restore normal first person after setting it with the python) but anyway, it might be instructive.

Here