Reality Factory

just a thought, but using negative values for gravity might work...

If you mean for the velocity = 0 thing, then I don't think that would work for what I want. A force such as negative gravity accelerates, and would therefore be more of a gradiant type thing, which I can just get by using the Jump function or the ForceUp function, but I want an instant stop for a couple of reasons. First, it would provide for a much smoother double jump experience. For example, if I'm falling from a very high place, when I'm near the ground, my velocity will be so high that my mid-air jump will be much less effective, it might not even push me up at all and might just slow my falling.

if you mean for the player falling and taking my camera with him, I don't think it's a gravity problem, and a negative gravity wouldn't work anyway since it would affect the pawn as well, which is currently working fine for this part of the script. I think it has something to do with the PlayerToPosition function. If that function worked as I imagine it does, it should keep the player where the pawn is regardless of any sort of gravity, so long as it is called every frame. But it seems it doesn't for some reason. It works in keeping the player on the Pawn x and y coordinates, but not z while in mid air. It does work for z when I do a jump, but there is always a small difference between the player and pawn z positions. I think this difference just becomes larger and larger each as I keep the player levitating, and is only able to reset when the player hits the ground. What I imagine is happening is that first, the PlayerToPosition function only checks Z coordinate if a change has been made to the pawn's Z coordinate. And somehow when no changes are made to the pawn's Z, the function changes the player's Z by a small amount every frame. Just a guess tho

I can't seem to find documentation on how to pass variables to functions without using global variables.

Like for example, if I have a function

Function[()
{

}

And call it as so:

HighLevel("Function");

How do I pass variables to it? I'm assuming they go in the parentheses when defining the function, but not sure where they go when calling it.


Also, in regards to the ShowText command, I have the command:

ShowText(0,"JuryPawn","","Current Target",12,"",0,0,"center",255);

In my main RunPlayer Order (for testing purposes, to be used in a targeting system I'm making), yet it doesn't do anything. The way I have it typed it seems that it should attach the text "Current Target" to "JuryPawn" which is the scripted player, and yet, I see no text!

More problems:

GetEntityScreenX and GetEntityScreenY functions, what exactly is up with them? I assume it's supposed to give me the position that a given entity is located at on my screen. It somewhat works, in that the numbers seem to change correctly as I move the camera about, but I see no consistency in the values. Sometimes when the entity is at the edge of my screen I get values of 19 and sometimes of 13240 or some other absurd number It seems to depend partly on how fast I rotate the camera too, and if I rotate it fast enough, I get even more absurd results. Sometimes it even breaks the trend and I'm at a value of say 140, and I rotate every so slightly, and it jumps to negative 90459 or something like that.

Gahh! All I'm doing is the command debug(GetEntityScreenX("entity1"));

EDIT: Apparently using StaticMeshes was causing the problem. I changed the entities to pawns and the functions are working correctly, yay. Too bad though that when the entity is off screen it doesn't return something to let me know, and still seems to cycle through the same values, because I wanted to mainly use these functions to check if something is on the screen or not Oh well, I'll have to think of another approach. Suggestions welcome, as I think this script will end up being useful to anyone trying to make an action adventure game.

EDIT2: The CheckArea function is my new best friend Does exactly what I want when using the correct settings.

More questions!

So is there a way to do wild card characters in RF?

Let's say I want to check if an enemy named "enemy_?" is in an area using the CheckArea function, where ? is a number or a letter. I realize I can loop through all possible values that ? can take, but if a level can have up to say, 100 enemies or more, this is extremely inefficient.

Woah! You learn incredibly fast!

Well, about the functions:

You can call functions from other orders i know it works with LowLevel functions inside LowLevel functions but with HighLevl-functions i don't know. Here is an example function:

Function1[ (arg1,arg2)
{
//do stuff
} ]

and somewhere else you can call it very simply:

Function1(argument1, argument2); //this function does not return a value

You can also use the return command to return thinghs:

Function2[ (x,y)
{
if(x>y)
return 0;
if(y<x)
return 1;
} ]

and then somewhere in the script

A = Function2(x,y);

You can also use

if(Function2(x,y)) //if Function2 return greater than 0
{
;


EDIT:
Try not to use too much HighLevel functions in your scripts. First, HighLevel is slower, and second, LowLevel is far more versatile.

So I don't need to do stuff like:

HighLevel("function") and LowLevel("Function") and self.think="Function" in order to call them? I've just been doing this because that's what I've seen in the scripts that come in the demo. And what's the difference of calling them this way vs just writing Function()? Thanks for all the help

Well those thinghs are actually quite different from another.

When you use
self.think=...

You change the function entirely. Meaning you must switch back at the end of the function. But this way, you loose an entire frame. (The frame in which the function is executed) This feature of changing the fucntion entirely is very useful for thinghs like menus and inventories, where you don't know when the player will get out. (Thy will have a totally different behauivoir so you don't have to care about the rest of the code)

One thing to add:
You might come to a problem when your functions get really big (512 lines is the limit i think). You will get parse errors that don't exist. Because of this you MUST call functions with the 'Function() method' to lower the line count if the function gets too big.

Oh and another thing:
When you know the Name of the pawn that has a specific script you can also use thnghs alike:

Dioran.DamageTarget(...);

Where Dioran is the name of the pawn, and DamageTarget is the function. But this method has some pitfalls and it will execute the function on the pawn that calls the function (not the pawn that 'owns' it!!!)

With HighLevel orders i believe you have no other choice than to use HighLevel(...); and LowLevel(...); to get back.

Good to know As soon as I get done with this part of my script I'm working on I'll go back and make functions out of everything. I didn't know you could normally call them and I didn't want to keep losing the frames which I read about in the manual, so I barely used any.

Of course, having to work around the lack of a break; command and the lack of a wildcard character (at least I can't find it or how to use it) is not allowing my logic to work. Stupid brain! Think!! *hits head*

Well after trying to battle with the RF gravity system I decided to just turn it off and write my own simple little one that gives me direct control to player velocity, so that I can set it to zero whenever I want (when doing a second jump!). I still use the RF gravity system when I am not in the air (sounds strange huh? ) because the self.IsFalling command seems to actually return false slightly before you hit the ground and not WHEN you do, and without being able to check when I have collided with the ground it is very hard to handle slopes. So basically I let the RF gravity system handle gravity whenever self.IsFalling = false and have my system do it when true. Yay!

I also solved my camera dropping problem. I made a Camera pawn and attached the camera to that and made that pawn take on the angles of the player but the position of my scripted player pawn, so while the player continues to drop, the camera pawn does not, and neither does my camera, and I can still use my mouse to control the camera without having to write a bunch of extra code. Yay again!

Next step = Melee combat! I foresee this taking a while and causing many problems.