RSX / RCX & REX Files {Scripting}

[QuadCoreMax]

Hm, AI racing yesterday & guess what, none of the AI cars have the 'dynamical' wing code assigned automatically, so yeah I append some more code....Copying & pasting the same code for AI cars seems from my first testing quite buggy, AI dynamical wing is completely offset from its 'original' position...

Also, with my code, when enetring garage, no wing either....

That's 1 of the reason, for more events => ingarage.rex for example.
I like the rex files, because you don't need to execute scripts automatically (racer.ini) + you don't need to trigger them (triggerlines), reducing some of the work to make scripts work.

Also, if Racer crashes from scripts, you just have to comment out the 'run data/...etc..' command from your rex, & the game/level will start normally, you would then just re-compile the file rsx again & re-activate the rex command ingame...& restart race/free driving to actually see the scripts update.

 

[camsinny]

Weird...wing worked on ai cars for me...

 

[QuadCoreMax]

LoL !

Could you explain what's your actual setup ?
No reasons why we should have different results when using the same animation technique...

 

[camsinny]

Cause i'm using:

rcar $car=get scriptowner car

whereas you're using:

rcar $car=get local car

Knew the problem before I checked haha

 

[QuadCoreMax]

Weird...wing worked on ai cars for me...

Right, that wasn't working because I exported the wing at 0,0,0 WC (world coordinates) in my 3D, so it was hidden inside my car somewhere not visible by the camera...

I still don't understand the purpose of 'get scriptowner car' + 'set (rcarmodel) scriptcontrolled (int)', since they're used in scripts, it's 'implicitly' logical that they're script controlled...

Strangely, using rcar $car = get scriptowner car instead of rcar $car = get local car, doesn't work as you showed in your code.

 

[camsinny]

I still don't understand the purpose of 'get scriptowner car' + 'set (rcarmodel) scriptcontrolled (int)', since they're used in scripts, it's 'implicitly' logical that they're script controlled...

Strangely, using rcar $car = get scriptowner car instead of rcar $car = get local car, doesn't work as you showed in your code.

The scriptcontrolled thing had to be added because when scripting was introduced the generic models wouldn't be placed properly. Now they assume that the position isn't set in scripting so that they work as they used to, but we can also adjust the position of them through scripting if we choose.

Hmmm I thought it would be the difference between scriptowner and local...apparently not.
I believe it's best practice to use scriptowner, though i'm unsure... I believe Mitch had some code somewhere that used this, but it may cause some problems with LAN possibly? Who knows... haha

Anyway...I have a problem...
I want to do something over 21 frames, so I figured I'd make a framecounter:
while 1 {
++$fCount

interrupt
}
yeah that's good and works...so then I have a trigger at which point I want to record the frame number, the problem being that I can't figure out how to "lock" the frame number...i.e. I copy the $fCount to a new var but then as soon as the next frame comes around that 2nd var updates to $fCount again. Help? haha

 

[MitchVL]

yes, there is a big difference between "scriptowner" and "local", just as you would expect it...
Don't know why it wont work than. I checked the code and everything seems ok..
"scriptowner" is the car where the script is loaded from ..

Are you sure about the problem ?


I don't understand your problem camsinny.
We have very complex scripts running here, so there should be no problem with any basic scripting functionalities.

 

[Stereo]

When I'm creating new variables, is there some way to make their scope scriptowner instead of every script?

For example if I am scripting a door opening key, I want to store the current state of the door. So I can just set it to open/closed when they press the key once, then toggle it back when they press it again.
But I also want this key to only affect the current car, not every car, of course.


Another idea I had for script use would be in-game setup of auto-X / car safety courses. Drive to a certain region and flash up a menu. (1 = figure 8, 2 = moose test, 3 = slalom, etc.) Press the right key and it could reset the track movables (cones or other things) to a particular layout, change timing lines, etc.

 

[QuadCoreMax]

But I also want this key to only affect the current car, not every car, of course.

Yeah conditions could be useful, for example Camsinny wing code doesn't check anything e.g. I thought some code that checks if the generic model name contains a string with wing or struts then apply the script, else don't execute the code...

I also have all kind of ideas, as you know Shift2 got a graphical 'telemetry' which could be done in Racer with the rtex types as I have recently tried to play with them....

Anyway, the idea of placing dynamically/randomly the movables on the terrain is great, the only big worry, I wouldn't like to set 'manually' the pos values, therefore some kind of a terrain function which we spawn the object over it, could ease our work.

 

[camsinny]

Yeah conditions could be useful, for example Camsinny wing code doesn't check anything e.g. I thought some code that checks if the generic model name contains a string with wing or struts then apply the script, else don't execute the code...

I just named the generics whatever I wanted for ease. You reference them by the generic object number...It's impossible atm to check the filename.

rcarmodel $struts = [B]get generic model 1 of $car[/B]

It would be easier if you could transfer things across cars easier though, I guess that's why making the wing rotate through code instead of through skinning is preferable?
Hmmm.

 

[QuadCoreMax]

I know Cam, but you didn't understood what I meant. Your code (if scripted in the track scripts folder) executes for whatever cars who owns generics parts (in our example 0 + 1), so that's why...Imagine you have another car with generics 0 & 1 assigned to front bumper + rear bumper, then the code will execute on those parts, which isn't what we want to achieve....so that's why you would need some-kind of conditions in the code.

I guess transferring the code to the car scripts folder would fix it...hm car scripting & track scripting are definitely 2 distinct things...

 

[Stereo]

Hey, I'm just trying out some basic scripts to start with.

Documentation says variables can be shared between scripts, but I can't get this to work.

Example 1:
- In script1 you initialize the shared variable “score”.
- In script2 you also initialize the shared variable “score” and the script paints the variable each frame.
- In script1 you alter the variable “score”
- script2 paints the value for “score”, and without changing the value of “score” explicitly in script2, it matches the value of “score” in script1

I have a couple scripts running.
scripts/trunkinit.rsx:

int $trunkpos = 0

scripts/paint/trunk.rsx:

int $trunkpos
paint $trunkpos at float[2]{30,10}

scripts/physics/trunkupdate.rsx:

int $trunkpos
$trunkpos += 1

But the variable (trunkpos) is always set to 0 when I do int $trunkpos.

Really I want to use this to open the trunk smoothly. The script that does work looks like

rcar $car = get local car
rcarmodel $trunk = get generic model 8 of $car
set $trunk scriptcontrolled 1

set $trunk position float[3]{0, 0.35, -1.31}
if is key 84 pressed
{
  set $trunk rotation float[3]{0.0, 1.2, 0.0}
}
else
{
  set $trunk rotation float[3]{0.0, 0.0, 0.0}
}

trunkpos would replace the rotation variable, so I have it smoothly open instead of just being off/on.

 

[Mr Whippy]

Would there be a cool way to reference a script that interpolated (with varying curve types options) between the start/end variables you define (ie, opened and closed), over a requested time, or at a specified rate?

That way it would mean authors could set their start and end points and trigger to move to one or the other...

I guess that is what you are working towards here. I think Cam had issues doing things across multiple scripts. Do you have to define a global var differently to a local var?

Dave

 

[MitchVL]

if you want to share variables accross scripts you must use the keyword "shared"

shared int $trunkpos = 0

 

[Stereo]

Hrm. Even when I do that, the value doesn't seem to be preserved.

I've cut back the scripts to only have one running, and the only values it ever prints are 0 and 1:
scripts/paint/trunkupdate.rsx

shared float $trunkpos
if is key 84 pressed
{
  $trunkpos = $trunkpos + 1
}
paint $trunkpos at float[2]{30,20}

And trunkinit.rsx:

shared float $trunkpos = 0.0

 

[MitchVL]

dont forget that those scripts will run each frame, so the variable will be loaded and set to zero each frame

if you dont want that you can put this in a script

set kill after run 1

 

[MitchVL]

try this

shared float $trunkpos
if is key 84 pressed
{
  $trunkpos = $trunkpos + 1.0
}

paint $trunkpos at float[2]{30.0,20.0}

And trunkinit.rsx:

// set to 10 to show that it makes it to the other script
shared float $trunkpos = 10.0
set kill after run 1

 

[Stereo]

Oh, thanks, I must have missed how the interrupt works. Seems to be working alright now.

Current code looks like
scripts/paint/trunk.rsx

rcar $car = get local car
rcarmodel $trunk = get generic model 8 of $car
set $trunk scriptcontrolled 1
shared float $trunkpos
shared int $trunkopen
int $keydown = 0
while 1
{
  if is key 84 pressed
  {
    if $keydown == 0 // make sure it only happens once per keypress
    {
      $trunkopen = 1 - $trunkopen // toggle open/shut
      $keydown = 1
    }
  }
  else
  {
    $keydown = 0
  }
  //paint $simtime at float[2]{30,10}
  set $trunk position float[3]{0, 0.35, -1.31}
  set $trunk rotation float[3]{0.0, $trunkpos, 0.0}
  interrupt
}

scripts/physics/trunkupdate.rsx

shared float $trunkpos
shared int $trunkopen
while 1
{
	if $trunkpos < 1.2 
	{
	  if $trunkopen == 1
	  {
	    $trunkpos += 0.002
	  }
	}
	if $trunkpos > 0.0 
	{
	  if $trunkopen == 0
	  {
            $trunkpos -= 0.002
          }
	}
	if $trunkpos < 0.0
	{
	  $trunkpos = 0.0
	}
	interrupt
}

Trunk opens/closes on keypress, nice and smooth since the physics step is consistent.



Now that I've got it all working, I'll try to package it into something easy to adapt to different uses.

 

[MitchVL]

the function "interval" returns in ms how long it has been since the script has been lastly executed.. much more efficient than using physics update

 

[Mr Whippy]

Tinkering with a power steering emulation script...

Intended to go in scripts\paint folder of a car.

//Focus on the car used by the script owner
rcar $car=get scriptowner car

//Defining the variables we will use
string $cmd
float $nm
float $ff_friction

//Define a few tuning variables
//How heavy we want our steering dead ahead
int $weight = 5250
//How heavy we want our steering when the tyres are doing their maximum work
int $residual = 500
//How heavy our Mz is at peak work (CTRL 1 readout screen to watch Mz as we drive)
int $max_mz = 14
//How resposive we want the power steering to feel (50 > 250 are probably ideal, 50 is good for a high end sports car, 250 for a comfy car maybe)
int $response = 200

//Do this all the time a frame is painted (possibly best somewhere else?! Where?)
while 1
{
//Normalising Nm value to be always positive
$nm = sqrt(pow (get $car nm) to 2)

//Calculating how much friction to generate relative to the Mz forces from the tyres
$ff_friction = $weight - ((($weight-$residual)/$max_mz) * $nm)

$cmd = "ff friction " + ($ff_friction)
send $cmd to console

wait $response

paint ($nm) at float[2]{650,100}
paint ($ff_friction) at float[2]{650,75}

interrupt
}

If people can see a way to improve it feel free to let me know!

Basically it looks at peak Mz, and blends friction out as Mz increases, this gives a nice linear weight to the steering feel, much like having power steering might feel.

Use with car.ini settings like this

ff_factor=0.5
ff_gain=1
ff_stickfriction=1
ff_inertia=0
ff_damping=0
ff_friction=0

Tune car.ini ff_factor for the basic 'weight' when cornering etc, stickfriction for when stood still, and then use the Nm Mz value from CTRL1 debug screen in the script to tune.

Use "reload scripts" console commands to test the change in-sim!



Main improvement I'd like to make is have it run in the right scope (currently is FPS dependent I *think*), and also a nicer way to 'dull' the response of the script. Currently using a wait command, but would be nice to somehow damp the Nm value that is read so the steering isn't instantly responsive. Feels fairly good right now though, but sure it can be improved

Dave