[Wanderer]

WARNING... may not function on CVS builds (dunno why) but functions nicely with for example 3.6.9 RC4.. Atleast for me.. CTD with CVS r-builds but d-builds work nicely again. This is somehow related to plr but i havent got a clue what could be wrong.

scripting.tbl

Code: [Select]

#Global Hooks

$GameInit:

[

drawvelret = function(x, y)
   gr.drawGradientLine(x+20,y+20,x+5,y+5)
   gr.drawGradientLine(x-20,y+20,x-5,y+5)
   gr.drawGradientLine(x+20,y-20,x+5,y-5)
   gr.drawGradientLine(x-20,y-20,x-5,y-5)
   gr.drawGradientLine(x,y,x+6,y+6)
   gr.drawGradientLine(x,y,x+6,y-6)
   gr.drawGradientLine(x,y,x-6,y+6)
   gr.drawGradientLine(x,y,x-6,y-6)
end

]

$HUD:

[

position = plr.Position
velocity = plr.Velocity
vlenght = velocity:getMagnitude()
vvector = position + (velocity/(vlenght/2000))

gr.setColor(230,230,100,255)
if vvector:getScreenCoords() ~= false and vlenght > 5 then
   X, Y = vvector:getScreenCoords()
   drawvelret(X, Y)
end

gr.drawString("True Velocity:",435,750)
gr.drawString(math.floor(vlenght),575,750)

]

#End

To explain what that does...

First in $GameInit: it creates a new function named drawvelret (draw velocity reticle) that requires two arguments and then draws a X-shaped reticle with gradient lines.

Then in $HUD: it gets player (plr) position and velocity (both as vectors) and saves them as variables. Then it calculates the true lenght of the velocity vector (vlenght) and then creates a vector that points from (0,0,0) to a point 2000 units in the direction of the velocity vector from the ships current location (basic vector math really).

So after values are defined it sets the drawing color (atm sort of yellowish, RGBA) and if the ships velocity is higher than 5 units and the is seen on the screen it draws a reticle there. Then it additionally draws text "True Velocity:" and prints after that the rounded down lenght of velocity vector.

It is made for 1024 x 768.. but other resolutions may require some tweaks to the some of the values.

Made with the help of stuff from wiki (most usefull being the links... like output scripting.html and Lua-users wiki)
http://www.hard-light.net/wiki/index.php/Scripting.tbl


EDIT: I didnt include the I-War 2 stylish floating vector thing as it caused a severe hit to fps

[Nuke]

thats rather cool. it will give me something to play with later. now that i have something that works to play with i might learn someting. i need to adjust the code to my screen resolution. is there a script function to return the game resolution? maybe make it capable of autosensing.

[Axem]

Sorta, its two functions. gr.getScreenHeight() and gr.getScreenWidth() will return the height and width of your screen. When I was playing around with a scripted hud, I made a few lines that went along the lines of

Code: [Select]

10PercentWidth = 0.1 * gr.getScreenWidth()
25PercentWidth = 0.25 * gr.getScreenWidth()
etc
etc
so the code was a bit easier to read.

[Nuke]

i finally got to reading it and it makes some sence. now i dont see any loops, i take it this code is executed every frame. would that assumption be correct? also will variables get carried over between sections?

[Wanderer]

Yeah.. its executed every frame. Variables are carried between sections unless they are declared local variables (all variables are global by default)

[Nuke]

looking at this again, i still dont see why this code is resolution dependant, is that because getScreenCoords() only returns coorods for a 1024x786 resolution? it would then be possible to multiply x and y by whatever resolution i may be using / 1024x768. still id consider this a bug with the getScreenCoords() function. anyway i managed to make this code resolution independant by adding the following right above drawvelret(X, Y):

X = X * (gr.getScreenWidth() / 1024)
Y = Y * (gr.getScreenHeight() / 768)

i still consider this a bug, getScreenCoords() should take screen resolution into account.
next im gonna try to add in arrow indicators for when the gauge goes offscreen.

[Zacam]

I have no idea why, but I cannot seem to manage to get this to work. I defined the relevant entries necessary in the first post (output saved as Glide_def.tbl, stored in \Data\Tables) and selecting "Toggle Glide" (default Alt-G) and trying to use lateral thrust results in nothing.

Using both versions of fs2_open_thrust.exe and rcX builds (not cvs). New pilot created specifically to play around with this, no other pilot files present.

[WMCoolmon]

http://www.hard-light.net/wiki/index.php/Modular_Tables

[Zacam]

So, said file should be named glide_shp.tbm? Or even psn_shp.tbm (assuming 8.3 convention)? If so, that still doesn't work.

Editing ships.tbl directly doesn't work either, it complains about just about everything being moved, IE: I expected this and got that (where that is the next item up from what this is)

Here's the contents of said file, just in case I managed something wrong, though the provided example is pretty clear:

Code: [Select]

$Name: GTF Ulysses
+nocreate
$Max Velocity: 70.0, 70.0, 70.0
$Rear Velocity: 70.0
$Glide: YES

$Name:            GTF Hercules
+nocreate
$Max Velocity: 50.0, 50.0, 50.0
$Rear Velocity: 50.0
$Glide: YES

$Name:            GTF Hercules Mark II
+nocreate
$Max Velocity: 55.0, 55.0, 55.0
$Rear Velocity: 55.0
$Glide: YES

$Name:            GTF Ares
+nocreate
$Max Velocity: 50.0, 50.0, 50.0
$Rear Velocity: 50.0
$Glide: YES

$Name:            GTF Erinyes
+nocreate
$Max Velocity: 65.0, 65.0, 65.0
$Rear Velocity: 65.0
$Glide: YES

$Name:            GTF Loki
+nocreate
$Max Velocity:    75.0, 75.0, 75.0
$Rear Velocity:   75.0
$Glide: YES

$Name:            GTF Pegasus
+nocreate
$Max Velocity: 90.0, 90.0, 90.0
$Rear Velocity: 90.0
$Glide: YES

$Name:            GTF Perseus
+nocreate
$Max Velocity: 80.0, 80.0, 80.0
$Rear Velocity: 80.0
$Glide: YES

$Name:            GTF Myrmidon
+nocreate
$Max Velocity: 75.0, 75.0, 75.0
$Rear Velocity: 75.0
$Glide: YES

$Name: SF Mara (terrans)
+nocreate
$Max Velocity:    15.0, 15.0, 75.0
$Rear Velocity:   0.0
$Glide: YES

$Name:            GTB Artemis
+nocreate
$Max Velocity:    65.0, 65.0, 65.0
$Rear Velocity:   65.0
$Glide: YES

$Name:            GTB Artemis D.H.
+nocreate
$Max Velocity:    65.0, 65.0, 65.0
$Rear Velocity:   65.0
$Glide: YES

$Name: GTB Medusa
+nocreate
$Max Velocity:    50.0, 50.0, 50.0
$Rear Velocity:   50.0
$Glide: YES

$Name: GTB Ursa
+nocreate
$Max Velocity:    45.0, 45.0, 45.0
$Rear Velocity:   45.0
$Glide: YES

$Name:            GTB Zeus
+nocreate
$Max Velocity:    55.0, 55.0, 55.0
$Rear Velocity:   55.0
$Glide: YES

$Name:            GTB Boanerges
+nocreate
$Max Velocity:    55.0, 55.0, 55.0
$Rear Velocity:   55.0
$Glide: YES

#End


[Backslash]

You're very close... the _ needs to be a - .  So glide-shp.tbm should work.

Just for you, I've updated the build with some even more experimental code , hoping to get collisions working properly during glide (before, the ship would just continually slam into an object without changing trajectory).  Let me know if the acceleration doesn't seem right.

[Zacam]

_still_ not working. I even copied it to the FS2\data\tables (vs the vp's data\tables) and I get nothing.

I don't know what to chalk this up to. Fact is, it could just be my keyboard or it could be keyboard and joystick combo related.

Am I not supposed to have anything defined for Absolute Throttle, or am I supposed to have something defined for Relative Throttle?

Leaving the controls at defailt or assigning them doesn't matter either.

[Backslash]

Relative throttle doesn't matter.  Absolute throttle should work as expected.

Oh!  Just noticed:  Make sure you have

Code: [Select]

#Ship Classesat the top of the file.

[Nuke]

is this gonna make 3.6.9?

[Zacam]

Nuke: It's already in the RC builds and CVS builds. However, unlike these dedicated test builds, certain behavior that I've noticed (atleast in the 2nd build) don't occur. Example: In the second build, you could engage glide, spin about to face the opposite direction and then hit your afterburners and it would _slowly_ correct your course towards the direction you were facing. I have not noticed any CVS or RC build exhibiting that behavior, which is sad as it's damn nice.

Backslash: when ALT-G is pressed, is it supposed to switch the hud? Because the new version (version 3) you posted is doing that. Strange kinda of hud too.....half the stars, the nebulae are there, orb radar on the top left, but no other ships show themselves. "Strafe" controls still work. Hitting ALT-G again does nothing and changing camera views results in HUD displaying on a black screen.

*edit: in case it's not readily apparent, I got it working. #Ship Classes was indeed the final culprit. Thank you, Backslash.

[Backslash]

Yeah, sorry Nuke, it's a big change and 3.6.9 is in feature-freeze -- bug fixes only.  Gliding has been in for a while of course, but my lateral-thruster-course-correction-during-glide is not.  I'll commit it to the experimental CVS branch once I iron out one last bug.

Odd problem, Zacam.  It's not supposed to do anything to the hud beyond adjust the speed indicator to show vector magnitude instead of forward speed.  I did build it against a recent CVS build (today's), maybe there's some other bug involved.  So far I can't reproduce the problem. 

[Zacam]

Hmmmm. Interesting indeed. Does your "test" hud use the 3d orb model or change anything away from default on how the hud displays? I haven't "mod"ified the hud in any way, but did customize the color scheme some. I'm also running 1280x1024.

This could potentially be a video card related issue as well, since I have to run -disable_fbo to prevent nebulae corruption on continual play.

It's sad that the lateral-thrust-correction-while-gliding didn't make it in......that's damn sexy and I love it!

Also, here's the MD5 for the exe that I downloaded right after you mentioned you made changes: DB6F3BDC6C679A9781314247B098D35B does it match yours? (If you don't have a hash checking util, google HashTab for something small and easily removable, adds "File Hashes" as a tab on your Right-Click|Properties window)

[Zacam]

I've also noted that one has to be careful with the values they put in. Ex: The Myrmidon listed in my file above reached speeds of 130 _before_ afterburner was engaged (which only goes to 135).

To have the Myrmidon reach normal speeds but still have x/y and reverse speeds, this was the following end result:

Code: [Select]

$Name:            GTF Myrmidon
+nocreate
$Max Velocity:     8.0, 8.0, 75.0
$Rear Velocity:     20.0
$Glide:     YES

Still working on the rest of the ships but that one was the easiest. It now has retail forward speed with the ability to slide 'n' glide. (Rear velocity didn't seem to matter overly much, I decided on 20 because of "$Max Oclk Speed: 95.0" in the ships.tbl. 75+20=95. *shrugs*)