Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Backslash on June 19, 2006, 09:35:12 pm
-
:D I think some of you will like this.
First, make or modify a ship so that it can both slide and glide.
$Name: GTF Ulysses
+nocreate
$Max Velocity: 70.0, 70.0, 70.0
$Rear Velocity: 70.0
$Glide: YESfor example. Of course you'll need to set the controls too if you haven't already.
Now try my test build: fs2_open_thrust.exe (http://myhome.spu.edu/calebjackson/FSO/fs2_open_thrust.exe)
Move in some direction, then turn on glide. Now play around with the forward/reverse and slide thrusters. ;7
(Still needs some polish and tweaking... one thing I couldn't decide on was how to calculate how much to accelerate the ship per tic. For now it's prev_ramp_vel / 100 . Suggestions welcome.)
-
kickass!
-
how do i set the controls? :nervous:
i'm pretty much using the standard FS2 controls....
-
well you just need to bind the lateral thruster controls. they should be defaulted to 1,3,-,+ on the keypad (i think).
-
DAYM! :eek: :nod:
$Name: EA Aurora MK1
$Short name: OldAurora
$Species: Terran
+Type: XSTR("Heavy Fighter", -1)
+Maneuverability: XSTR("Very Good", -1)
+Armor: XSTR("Light", -1)
+Manufacturer: XSTR("Mitchell-Hyundyne", -1)
+Description: XSTR("Short Range Defense Operations" , -1)
$end_multi_text
+Tech Description:
XSTR("Used extensively in the Earth-Minbari War, the Aurora MK1, as it's commonly referred to, is
essentially the same craft as the current generation of Aurora StarFuries but with a less effective sensor
and targeting suite.", -1)
$end_multi_text
+Length: 9 m
+Gun Mounts: 2
+Missile Banks: 4
$POF file: aurora_line.pof
$Detail distance: (0, 100, 250, 500)
$Show damage: NO
$Density: 1
$Damp: 0.40
$Rotdamp: 0.65
$Max Velocity: 85, 85, 85
$Rotation time: 3.8, 3.8, 3.1
$Rear Velocity: 85
$Forward accel: 3.0
$Forward decel: 3.0
$Slide accel: 1.2
$Slide decel: 1.2
$Glide: YES
At last, a Star Fury!
Oh, I can see this feature having some use with BSG and TBP people... :yes:
Thanks for giving FS a new definition. The acceleration is really quite nice... Now we have to make every AI ship to glide as well, when the player changes the mode. Is that possible?
Yes, we are never content to what we get... :lol:
-
Considering that it would probably require a complete rewrite of the AI code to get computer-controlled fighters to make use of their new abilities, I don't think it's feasible.
-
:(
Well... the Minbari, Vorlon, Shadow and Centauri vessels don't follow the laws of inertia very exactly anyways due to their gravitational engine systems. Perhaps I just have to fly solitary missions against them... :shaking:
Nevertheless, it's cool.
-
As long as teh player can utilise the features he/she will appreciate it, TBQO FS2 fighters are all over the fraggin place anyway :D
-
can you say frontier mod?
-
FRONTIER MOD :D
Source guys work on a hydrogen powered hyper drive and realtime economy as well as a bulletin board and persisant galaxy code please :)
I'll be back by 17:00 GMT to DL it all......... :lol:
-
Everything is in place for a cracking Frontier mod now. Primary beams, non-linear campaign support. In fact I'm not even sure the glide stuff is necessary. Without it you have a Frontier mod that plays like Elite, which is much more fun in my book. Frontier played like crap. You'll have to remodel all the Frontier meshes though. You can download the Elite ones.
-
If the original Braben master piece can fit on a 1.44 MB floppy with quite a bit being taken up by midi's the "Fs2rontier project"tm should be a pizzofcaaaake
-
We have Kara's random number seed code now. Meaning we can generate all kinds of things. If someone would make a string concat function we could even generate silly names for planets ;7 All of which of course are anarchies inhabited by black, furry felines.
-
http://www.petrix.com/catnames/ (http://www.petrix.com/catnames/)
A few galaxies in there to start code crew off....coming up to 40 minutes left before i want "Fs2rontier project"tm on my HDD.
:nod:
fixed teh link
-
Was kinda cool after I got myself to go 700 m/s.
-
well you just need to bind the lateral thruster controls. they should be defaulted to 1,3,-,+ on the keypad (i think).
Close. Shift+ those. though depends on how new your pilot is. Anyway, look in Options, Control Config, in Ship; should be called "Right Thrust" "Up Thrust" etc. Once the new pilot code is in place, I can add bindable slide axes and a 'slide when pressed' button, too. :yes:
Oh, I can see this feature having some use with BSG and TBP people... :yes:
Now we have to make every AI ship to glide as well, when the player changes the mode. Is that possible?
Glad to hear it. :)
Yeah I might be able to make an option so the AI uses it. As for using it WELL though, hmmm... I dunno how to do that. Sid is probably right. As far as I understand, could be either reasonably easy to implement, or just about impossible. I mean, the AI does know about sliding, and I think it can compensate for high damp factors, so there might be some hope... but even if so I suspect it will be tricky. plus the AI code scares people already :p Heh, you think collisions are bad now? :lol:
Nice that we have an 'excuse' for Minbari, Vorlon, etc ships to stay the same... :D
I gotta play with Damp, Forward accel / decel and Slide accel / decel some... make it so differences have better 'feel'.
There's so much I'd like to do with this but don't know if I have the coding ability (yet). Frontier mod... heh, you guys are funny. Great concept, actually, but ouch -- you'd have to recruit some ridiculously creative SEXPers to start anything even close. Not it! ...A couple of my simpler ideas I'm working on: Some sort of HUD indicator for current flight direction would be awesome, and perhaps a better handling of showing the current speed... gotta think about how best to do that.
-
Just play around with motion debris effect. Make the debris a bit longer, a bit more visible and a bit less dense, and voilá,, you have direction indicator.
Actually, I can see my direction quite well from motion debris as it is, it could just be a bit clearer with edited version. What would be more important is to enable the speed indicator to show negative speeds as well as positive...
-
Would it bepossible using the motion debris code to generate an I-War style thing, (not just an extension of existing dusty bits) but a full laser-esque new hud feature?
-
there is code in place to make whole new scripted HUDs, just nobody uses it :rolleyes: maybe you can research that?
-
yea you can render the same lines that iwar uses with scripting, its just a matter of getting your inertial vector from the game.
-
Considering that it would probably require a complete rewrite of the AI code to get computer-controlled fighters to make use of their new abilities, I don't think it's feasible.
IIRC they do, on higher difficulties, already know how to slide etc. According to the BSG mod folks (who had this figured out already), the FS AI is extremely deadly when given these abilities.
-
One scripted HUD with forward/backward velocity indicator, horizontal speed indicator and lateral speed indicator, coupled with I-War-esque vector indicators.
Oh, and a possibility for limited fuel. I know it's no more Freespace, but I could see that very much fitting the BSG conversion and Babylon Project.
Oh, and... auto-targeting. The same way it's implemented in I-War, so that hitting small targets is not completely impossible... :nervous:
-
IIRC they do, on higher difficulties, already know how to slide etc. According to the BSG mod folks (who had this figured out already), the FS AI is extremely deadly when given these abilities.
AI has known how to slide since vanilla. But some say it sometimes gets little confused about it. Nothing new about that.
-
Sliding AI Starfuries = nightmare fighter from hell
-
Thats why they have aim assit in the series. And we should also have it...
-
One scripted HUD with forward/backward velocity indicator, horizontal speed indicator and lateral speed indicator, coupled with I-War-esque vector indicators.
Oh, and a possibility for limited fuel. I know it's no more Freespace, but I could see that very much fitting the BSG conversion and Babylon Project.
Oh, and... auto-targeting. The same way it's implemented in I-War, so that hitting small targets is not completely impossible... :nervous:
all you really need is the lindes, their length indicats the speed. if thats not enough just use a neumerical indicator which tells you how fast youre going alotn the inticated vector.
Thats why they have aim assit in the series. And we should also have it...
this feature has been requested sence day one of the scp and im suprised it hasnt been implemented. now that the code supports weapon normals, any chance in making them dynamic? the only table imput needed would be the cone of fire for each bank, could be done the same way as bank capacities. have a flag like $Dynamic Normal Cone: (10,20,25) after show primary.secondary models. alternatively is support for player triggered turrets, which would track targets normally, but requires a player triggerpull to fire. actually id like to see a general turret control interface anyway, for capship missions, which would allow mechwarrior-esc weapon grouping for the various turrets, the ability to control one directly, as a group, or delegate to ai.
-
An Elite/Frontier/First Encounters mod would be ace, if it could be pulled off :)
-
FRONTIER MOD :D
Source guys work on a hydrogen powered hyper drive and realtime economy as well as a bulletin board and persisant galaxy code please :)
I'll be back by 17:00 GMT to DL it all......... :lol:
I'm still waiting since then........... :lol:
-
An Elite/Frontier/First Encounters mod would be ace, if it could be pulled off :)
I'm too busy. What modding experience do you have :p
Seriously though most of the modders currently in the community are too busy. You could try stealing some from the Frontier/Elite community or you could start learning the skills you need yourself with some of the newer people who are currently attached. Colonol Dekker seems to have a lot of free time :p
-
Actually I did the Elite mod. I converted and uvmapped all the ships. I just didn't do much with the finished article because neither player beams, nor non-linear campaigns worked back then. I could see if I can dig out what I did. It could be on any one of 30odd DVDs though so don't count on it. Seriously it takes about 30 minutes to uv map and convert an Elite ship so it wouldn't be difficult for someone to reproduce the work. Hell I use the Cobra Mk 1 as the example in my ship creation guide. The frontier mod is less fun to do. The game engine handled curves quite cleverly and as a result the ships had a lot of subtle curves which would have to be recreated using lots of polies. On the other hand if someone wants to have a crack at the Elite thing then I will offer as much helpful advice as I can.
-
i wish i could be liberated from working so i would have more time to mod. this sucks.
-
Quit.
-
:) I'm just free of "obligation" at work right now, Delegation is a1 soopah !
-
Quit.
then how would i pay my net bill? no, i think il just be annoying as **** for the next few weeks and hope they fire me, then draw unemployment :D
-
What? You mean you aren't already annoying as hell? If this ISN'T annoying, everyone, be afraid. Be VERY afraid...
-
i dont try to be annoying, i try to be honest, people are very annoyed by honesty it seems.
-
Are there any mods out there that use strafing /gliding actually? I know that BTRL uses it, but it isn't out yet.
-
ive set alot of nukemod ships to straif and slide and glide and whatnot.
-
Limited fuel is easy, somewhat... just have a big afterburner tank and no recharge. That's what WCSaga does. ...course that's only afterburner, did you mean standard engines?
The vector indicators sound tricky. I don't understand the scripting system yet but I suspect it won't be easy. However I just had an inspiration of using similar code to the lead indicators... will see what can be done. Won't be quick.
Aim assist would sure be nice but there's a lot involved. Probably over my head but I'll take a look, someday.
Ok, I've updated the build on the first page with some new goodies: a slide-when-pressed control, and this: when gliding, hold the full throttle key to automatically point in the direction of travel. Hold the zero throttle key to automatically point in the opposite direction. A bit hackish but very useful. Oh, question on the slide-when-pressed control... when you push forward on the joystick, should it be sliding 'up', or 'down'; what do you prefer?
-
Definitely forward = down, backwards = up. Just like the nose does when you pitch the craft. It's more intuitive IMO. But if you want more work, implement some kind of "invert-x-axis-when-gliding" system or something like that... might be more worky.
Limited fuel would definitely add realism and challenge, but it's not a priority, as most folks would probably use unlimited fuel option anyways... the direction indicator would be more important. I think it would be easiest to do that by meddling with motion debris. Make them have a colour and a trail and that's it. More sophisticated system would involve having the modified motion debris only visible when gliding, for example.
And of course, it would be good to know one's backward velocity, vertical velocity (left/right) and horizontal velocity (up/down) as well as forward velocity.
And for the future: implementation of aerodynamics for atmospheric missions, thank you very much. :D
It shouldn't be too difficult, btw... We already have thrust, inertia and direction controls - what would be needed to upgrade the model to simple aerodynamic model is angular momentum (do we have that already?), lift and drag forces - and constant gravitational acceleration.
We don't need or even want absolutely physically accurate model, so it would suffice to have the drag and lift as invisible thrusters (or force vectors) that have variable strength.
Drag is almost directly derived from craft velocity and angle of attack and drag coefficient... AOA 0 gives the smallest drag, while negative or positive AOA's increase the drag. Drag is always pointing in the other way from air speed vector.
Lift is derived from air speed, angle of attack, and lift coefficient - it's easier to just assign a suitable value for ships rather than start counting values based on ships mass and lift area, air density and such...
If we want even more sophisticated system, it's possible to implement rough aerodynamic stability model by implementing more force vectors representing aerodynamic forces affecting different parts of the ship, like possible control surfaces and whatnot.
But first things first...
By the way - is Beyond the Red Line team going to implement retro-rocket thrusters for their spacecraft? Or in other words, a visible vector control system - or are they keeping the craft Freespaceishly miraculously self-turning? :)
-
any way to make use of the throttle when in glide? apply the same neutonian drift model, yet stil have variable control of the main engine.
-
I think, by adding that, it would no longer be a poor-man's substitue.
Unless you mean being able to change the speed at which you are gliding, and not implementing a thrust in a different direction during the glide.
-
I will somewhat agree... currently, the relative throttle does work but the absolute throttle does not. The reason for this is, when you first push glide, in almost all cases the throttle was at a certain position and you wish to continue at that speed. Were I to implement the absolute throttle, the moment you started gliding you'd start accelerating.
I've updated the build with a small tweak, the speed indicator now gives the absolute speed in the direction of travel no matter your orientation. A simple workaround while I work on the more complicated speed indicators. Also, all the 3.6.9 rc3 updates have been merged in.
Great discussion Herra Tohtori... lots to think about. I probably won't be trying that atmosphere stuff for quite a while myself, lots of other stuff to do anyway, but it's cool to see it's a bit more within reach than it was before.
-
I think, by adding that, it would no longer be a poor-man's substitue.
Unless you mean being able to change the speed at which you are gliding, and not implementing a thrust in a different direction during the glide.
no i mean make it work the same way it does in orbiter :D
also if you can implement axis based control for lateral thrusters that would be great too. my joystick has roughly 9 axes but freespace only uses 4 of them. i have a 5th assigned to relative throttle, but its of little use when you have an absolute bound. id also like to see that relative control to be of some use. it really doesnt have anything to do with this physics implementation but if youre gonna tweak the controls, might as well do this one too. make the relative throttle override absolute when you have match speed set. also is there any way to make the main throttle control retros as well. its sad that the only way to go in reverse with a joystick, is to hit z. :D
-
axis controls for lateral thrusters, you say? I've already done that a couple months ago :D ...but the problem is, the way the existing pilot files are, my build with those axes is not compatible and so previous versions of pilot files cause the game to crash. taylor is working on new pilot code that would fix this, but it's a big project, and you know he works on so much other stuff too, so I wait. If you want I can dig up my code and make a special build for you, but you'd have to make a new pilot and only use it with that build.
9 axes?? What joystick is that, and how do you keep them all straight?! Is that the saitek monster everyone talks about? I suspect I want to try it...
Whoops, you're right, relative throttle is not working as I had planned. I'll hammer on that later this week. Ideally it would behave just like A and Z. And I just had an inspiration for the absolute throttle...
I still think I need to tweak the acceleration rates. It's too easy to get going way too fast. And dang, multiplayer with this is really hard. Half the deaths are to slamming into destroyers :lol:
-
its the x52. it really has 7 plus a mousestick, which can be set up as axes, however there havent been any games that would make use of it. i have it set up in freespace as my shield controls, also i use it for lateral thrusters in descent 3 and d2xxl. its a nice stick, but i wish it was wireless, as the typical cuase of death for my joysticks seems to always be cable failure.
-
Has anyone tried using pedals for your relative throttle, and a normal throttle for absolute? I'm gonna be getting some pedals off a friend soon, and I'd love to implement them into my setup like that. This would be great for extra glide control.
-
you know i really wish this saitek stick had pedals with it. seeing as most games only support one stick, fs2 open included. getting pedals means using a second controll wich only a few flight sims really have support for. the ch controllers have this nifty little driver that allows you to group several controlers as one virtual controler. i have the feeling it would only work with other ch controlers. i really miss the good ol days of analog controlers before everyone went mouse and keyboard. there were some nice sticks on the market back then.
-
You mean, like these http://www.saitekusa.com/usa/info/e3.htm (http://www.saitekusa.com/usa/info/e3.htm)?
-
**** are those x52 compatable?
-
If you follow the link to the press release they explicitedly state the X52 as the controller that will be enhanced...
-
they say that, but will it be considered part of that controler or a second one. if its a second controller then you can pretty much screw the idea of using it in most games. as most games theese days have support for only one controler. then again if it works like ch controllers and can be setup with another controler as one logical controler then it will be good. what they said can be bent either way. the other thing is they really need to knock down the suggested price. i wouldnt spend more than a hundred bucks on it myself. especially if game support is virtually nil.
-
Most games? I actually thought Freespace was more like an exception. :nervous:
Many of the games I've played have had multiple controller support. Actually, most of them have it... tho only ones coming to my mind are X-Wing versus Tie Fighter, I-War and Freespace 1, 2 and Open...
For example, Il-2 Sturmovik (and Forgotten Battles and Pacific Fighters) at least has support for AT LEAST three controllers at any given time. It rules. I should get some pedals from somewhere, I think...
And, If I'm not gravely mistaken, on Microsoft Flight Simulator 2004 I could also use multiple sticks (I have two, I assigned the elevator trim onto other sticks throttle with great ease). I suspect that this applies to most other Flight Simulators too - and those rudder pedals, throttle levers and others from Saitek are probably primarily meant for flight simmers. Those fance X-52 extensions might not be usable in Freespace, but I still drool when I'm looking at them.
Heck, I can play Grand Prix 2 (with VDMSound) and THAT detects two joysticks... but on the other hand, that's an *old* game.
It would be nice to have two joysticks detected in Freespace, though.
-
mw2 had the best stick support of any game i think. but the trend seems to be moving away from joysticks. fewer games are being made to support them, an fewer sticks are being made. and they dont seem as accurate as they once were.
-
The sliding feature has been in FS2 since retail. I've been using it forever (was one of the first to discover it, I think, not sure).
If you want some real fun, play with the dampening. Then you'll get real newtonian.
EDIT: And yes, the BSG mod (which I'm tabling for), will be using these, and a dumbed down version of Newtonian physics.
-
i know that. i find using larger damp factors makes the existing physics more fun. ive also putting slide on a few of my ships. ive always liked to see true 6dof in space games, freespace had it all though it wasnt used much.
-
Sorry to bump this one but i thought this one might be rather closely associated with the topic... So something little that i scripted....
The second reticle is velocity vector reticle pointing towards the true direction where the ship is actually headed.
Only problem now is the impact on performance (60 -> 30 fps), with totally unoptimized version... and also the problem to get foolproof handle to player ship (i dont know how to do it) hinders it a bit
[attachment deleted by admin]
-
i take it that works about the same way as the indicator from frontier. thats sort of the type of indicator that newtonian flying needs.
any chance youl show us youre code?
-
Yeah... its not reserved (not yet atleast) for any purpose so sure. I'll try few things with it first.. Or rather try to fix some of the issues i noticed with it.
-
yea, ive come to the conclusion that i cant do scripting unless i see some functional examples. and i mean lots of them. when i did quake see i probibly did 50 tutorials before i tried any of my own code. sorry coders, but hello worlds dont seem to cut it for me :D
-
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
#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
-
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.
-
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
10PercentWidth = 0.1 * gr.getScreenWidth()
25PercentWidth = 0.25 * gr.getScreenWidth()
etc
etc
so the code was a bit easier to read.
-
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?
-
Yeah.. its executed every frame. Variables are carried between sections unless they are declared local variables (all variables are global by default)
-
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.
-
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.
-
http://www.hard-light.net/wiki/index.php/Modular_Tables
-
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:
$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
-
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.
-
_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.
-
Relative throttle doesn't matter. Absolute throttle should work as expected.
Oh! Just noticed: Make sure you have#Ship Classesat the top of the file.
-
is this gonna make 3.6.9?
-
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.
-
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. :confused:
-
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)
-
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:
$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*)