Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Mike_A36 on August 23, 2006, 04:56:19 pm
-
This relates to the "Poor man's newtonian physics" thread but it was a month old and I didn't want to bump it.
But I followed the directions from the thread I made a tbm that has glide (Yes) and x,y velocities in it. I also have a Saitek X36 throttle and Joystick combo that I programed to the controls and bam I can glide at the push of a button and skit sideways or up and down with a hat switch. It is to cool.
The only problem is I can't fire the guns while moving sideways or up and down. Probably something with the joystick mapping program.
When messing around in the game i was able to completely circle a stationary target with my guns never leaving the target. It took some doing but it worked! Well up until the game locked up from overheating of the GPU but thats another problem.
This could add a whole 'nother dimension to the game (pun intended)!
Oh well noob rant over. Back to your regularly scheduled forums.
-
Shivan ships can glide right (in FS1 anyway)?
-
The Scorpion can, as can the Dragon I think. One of the bombers can too.... think it was the Shaitan.
This looks interesting. Can you post the table?
-
O.K. remember you are talking to a complete noob. Please walk me through just how to post anything. I am ashamed to say I do not know how.
O.k. I found the additional options button and attached the file. I named it just like in the example on the "Poor man's Newtonian physics" thread.
I made all the velocities 1/2 of the max z. In the previous thread someone was going to try to make the x,y controls into a bindable axis instead of just buttons. That would be great if it could be done since my saitek can program hat switches as either buttons or axis(s). I am not sure what the slide does or how to get it to work though but I put in some numbers for it also.
Oh yeah it goes in the C:\Games\Freespace2\mediavps\data\tables folder and I have to turn off keylock on my keyboard because i set up the controls to be shift+pad3 (Right thrust) and shift+pad1(Left thrust) the Up thrust and Down thrust I left as default.
sorry for the delay in response I was at work when I posted earlier and Real Life takes over when I get home until the kiddo's go to bed.
[attachment deleted by admin]
-
I'm not sure that it's named correctly, but I'll try it out.
I've been wanting to slide ever since I found out I couldn't in Freespace (I'd played an awful lotta Descent beforehand).
EDIT: Good news, the table isn't crashing Freespace. Bad news, it's not doing anything else either.
I don't believe I have keylock on, but just in case: how do you toggle it?
-
Ok I had to rename with the .txt extension in order to post it. Rename it to glide-shp.tbm and stick it in the Freespace2\mediavps\data\tables folder. I do not know if you have to turn of your numlock on your keyboard or not I just had to to get it to work because changed the default keys to read from the keypad. The default keys in freespace are:
Glide = ALT+G
Up Thrust = SHIFT + PAD +
Down Thrust= SHIFT + PAD ENTER
Left Thrust = SHIFT + 1
Right Thrust = SHIFT + 3
Any more detail than that I will have to turn it over to someone else 'cause I simply do not know. I was just excited because I got it to work on my machine. Which considering I have no modding, or coding experiance at all, is a big deal. But I just followed the directions in the thread about newtonian physics. I didn't come up with this idea someone else did I just followed thier example.
-
Do the ships affected still retain their "retail" forward velocity? When I played around with it, I noted that adding the extra x/y's increased the overall foreward speeds. I had myrmidon's traveling at almost AB speeds without AB! (and when I did kick on the AB it only jumped the speed up 15)
-
I'll check that thread, cause it isn't working for me....
-
I haven't noticed the ships going that fast but hey I just got it to working without crashing. I will try to be more observant and let you know.
-
I'll check that thread, cause it isn't working for me....
If you are using media vp files, try to put the table into the mediavp folder instead (assuming you are using the MOD method). I suspect the table file may have been overridden by the tbm in the vps.
-
Shivan Ships that can glide dragon, basilisk, manticore, scorpion, shaitan, nephilim, and seraphim. in other words all fighters and bomners for the shivans in FS1.
-
NEAT ! :)
-
NOTE: In FS1, the "Dragon (terrans)" you fly doesn't have reverse. So anyone wanting to apply Glide settings should make sure that $Rear Velocity: 0.0. While it would be nice to change that and cheat, it fly's (no pun intented) in the face of the briefing.
-
I did notice that Retail forward velocity is modified. I've dingled a bit with some values to make sure that side to side still worked while retaining "OEM" (har har!) Forward Velocity. It also seems that most ships with a Rear Velocity have it at a formulae of Max / 3.2 = Rear (rounded), so I've applied that.
So, for "Retail" slide 'n' glide, grab glide-shp.tbm (http://zacam.ueuo.com/scp/glide-shp.tbm). Works best going into Freespace2\mediavps\data\tables.
For non-Retail FV, Mike_A36's TBM works just fine. In fact, I rather like the ratio of side-to-side percentage of forward and some nice deliniations on the slide accel and slide decel. If it were not for wanting a "purist" Retail Campaign compatible solution, I'd exclusively use his.
NOTE: This is for FS2 ships so far only. I'll release one for FSPort shortly once I fully test to ensure "Retail" FV's on all ships there.
-
Great to see the continued interest in gliding/sliding and all that! Fun innit :)
Good for you, Mike_A36. See how useful .tbm is! Heh, turns out your table values are exactly the same as what I chose for mine a few months ago.
Interesting, Zacam. Comparing your table to his makes the problem more apparent, so now I do think that the odd increased forward velocity is a bug. I'll look into it.
-
Yeah. I don't like how low the velocities have to go for side/side (in this case, first "side" is "left-right" and the second "side" is "up-down") in order to retain retail forward....side/side _should_ be capable of at max 1/2 forward _without_ bumping up the forward to an insane number.
Cramping it down to keep retail forward almost kills the idea save for the implimentation of glide and being able to go in reverse (finally!)
Also, I tried playing with the settings independantly of each other (IE: 0.0, 7.5, 75.0 and 7.5, 0.0, 75.0 ) and in either case, once you start going above 10% of the forward (75.0 in this case) you start getting an increase in forward max vel. (This isn't a "fixed" value, mind. 75.0 can range from 7.0 to 8.5 dependant on (apparently) some other variables with the ship. So a ship with a max of 90 can use up to 9.0-9.9 (setting anything to 10.0 is an immediate increase) )
Hope this helps in tracking it.
-
Aha! I found it!
Turns out it is using a vector magnitude to get the max speed, so the square root of (a^2 + b^2 + c^2). That's why you had to keep the slide speeds so low. Well, this is sort of not really a bug but an unintented consequence -- I may have to ask the team about this... I'm sure most of the time max_speed is supposed to only involve Z (forward/back), but are there situations where we'd want it to involve sliding?
In the meantime, until this 'bug' is fixed (if it will be), you can do this: increase the slide speeds and lower the forward speed, since technically the forward speed is ignored in favor of the magnitude of the whole. If you want the slide speeds to be half the official forward speed, if I'm doing the math right: N = sqrt((Z^2)/2), where Z is the 'official' forward speed, and N gives you the new speed to put in the table.
-
I had a feeling it was something causality related. Thanks for confirming that, back to playing with numbers. :-)
And to cover something mentioned in the first post: I too would like to be able to map HAT/POV to slide instead of it just assuming I want to change my camera view angle. I rarely change the camera and my current stick only has one HAT/POV.
-
Aha! I found it!
Turns out it is using a vector magnitude to get the max speed, so the square root of (a^2 + b^2 + c^2). That's why you had to keep the slide speeds so low. Well, this is sort of not really a bug but an unintented consequence -- I may have to ask the team about this... I'm sure most of the time max_speed is supposed to only involve Z (forward/back), but are there situations where we'd want it to involve sliding?
In the meantime, until this 'bug' is fixed (if it will be), you can do this: increase the slide speeds and lower the forward speed, since technically the forward speed is ignored in favor of the magnitude of the whole. If you want the slide speeds to be half the official forward speed, if I'm doing the math right: N = sqrt((Z^2)/2), where Z is the 'official' forward speed, and N gives you the new speed to put in the table.
Are you 100% sure? I made a script that shows the true lenght of ships velocity vector on screen and it is (a bit) different than the normally displayed velocity. Also if you try gliding the velocity indicator doesnt show the lenght of true velocity vector as you can alter the reading by rotating the ship which has absolutely no influence to velocity vector while gliding.
-
Zacam, can't you just map your hat to the thrust up/down/left/right controls?
Wanderer: 99% sure, because I'm looking at the code, not just the in-flight results. IMO it's kind of silly, because first it turns the vector velocity into a 'max speed' value, then it uses that max speed value for only the throttle (which is Z axis only). Thus the displayed value doesn't have much to do with your actual velocity.
(me digs up your script) Hmm. Well, the current implementation of gliding is semi-hackish; as a result I suspect the script is not looking in the right place for the value (or rather, it is looking in the right place, but while gliding the values in that right place are ignored anyway). An example in a related problem: try colliding with something while gliding. See how collision physics is completely ignored?
I'm working on a (still-hackish-but-hopefully-less-so) solution that will merge my semi-newtonian changes with a fix to this mentioned problem and a couple other things. The main thing slowing me down at this point is figuring out a proper acceleration model that takes the damping into account. Hey, any of you much good with math involving natural logarithms?
-
If I map the hat to thrust, I still only get camera changes. I haven't tried loading the saitek control software to do mapping on the stick end, preffering not to load additional overhead on my system.
-
Ok, I may have come up with something cool. I need anyone who is interested to help me test this.
Get the executable at http://myhome.spu.edu/calebjackson/FSO/fs2_open_physics.exe (http://myhome.spu.edu/calebjackson/FSO/fs2_open_physics.exe) and try it out. It's built on today's CVS, plus my test changes of course.
Basically, please test to see if the 'feel' of ships is right... whether acceleration/deceleration works at the rates you are used to. I've made a change to something that, with luck, will work exactly the same as before. :)
If this works as expected, I may be able to add this to CVS (if I can convince everyone ;)) which will open the door to even more cool stuff. :nod:
Btw, Zacam, hat mapping works for me. Course, your joystick is probably way more complicated, being a Saitek. When you map the hat to a control, what does the game say you pressed?
-
Question, though. If this uses Newtownian physics, does that mean that the longer you have your engines throttled up, the faster you go?
-
If this works as expected, I may be able to add this to CVS (if I can convince everyone ;)) which will open the door to even more cool stuff. :nod:
If it's optional then you can probably add it to CVS with no problems. We'd rather you were fixing bugs than adding new code to CVS but since you're even newer than I am (I.e you didn't introduce bugs so it's unfair to expect you to fix them) and aren't introducing new bugs to 3.6.9 (as long as you only commit to the HEAD branch rather than 3.6.9) you'd possibly get away with it :)
-
Question, though. If this uses Newtownian physics, does that mean that the longer you have your engines throttled up, the faster you go?
Yes.
And the longer you decrease, the faster you go - backwards.
-
If it's optional then you can probably add it to CVS with no problems. We'd rather you were fixing bugs than adding new code to CVS but since you're even newer than I am (I.e you didn't introduce bugs so it's unfair to expect you to fix them) and aren't introducing new bugs to 3.6.9 (as long as you only commit to the HEAD branch rather than 3.6.9) you'd possibly get away with it :)
:)
Actually I ran across this issue while fixing a bug. Problem with this particular issue, is it is NOT optional, and it may very well also BE a bug but one we've lived with forever. I'll explain more in a bit. Just so I don't throw everyone off, this is not the same thing as my newtonian physics changes (but it could end up tying into it later).
So... yes to CaptJosh, Newtonian physics would do that. However, that is NOT in the build I just posted, but is in the 'Poor man's substitute for Newtonian Physics' thread. The build I just posted is testing out some damping changes. (or, hopefully, "not" changes).
-
Btw, Zacam, hat mapping works for me. Course, your joystick is probably way more complicated, being a Saitek. When you map the hat to a control, what does the game say you pressed?
Found out I have to de-bound Hat Foreward, Down, Left and Right even though teh key bind registers them as Button 11, 12, 13 & 14 which doesn't end up entailing in a conflict.
Are we supposed to test the build you've posted with a modified TBM file or native vp's? N/M, stupid question moment.
I noticed the initial velocity indicator....NICE touch. I also like that it equates your rate of travel on the speed guage now (though it still does not indicate a direction). I also noted that once glide is enabled, you still can not "vector" the direction of travel. You can either glide or you can slide, but you cannot slide while gliding.
Otherwise, some _very_ nice improvements and thus far I do like the general "feel" of how things handle. Even at the established values to retain retail forward velocity it handles a good deal better than the RC's or other CVS builds.
-
Right. I've currently disabled the vectoring code because it's pretty hacky -- I'm kind of 'rebuilding' it to work better (more 'natively') with this 'new'/fixed damping code. Don't worry, it'll be back... :nod:
Good to hear everything else is working. Hmm, can you think of any clever way for us to definitively test whether the damping is handled the same? I'm slightly worried the $Forward accel (and decel) is now adding $Damp to itself, so for some ships it might be 2.2 instead of 2.0. (And I can't just increase $Damp to test that because $Damp behaves differently in my build than regular builds.)
Oh, forgot to mention... added bonus of this code: go try changing a ship to have a high value of $Damp, like 5 or so... ;7
-
Interesting indeed. This means I could literally "reverse engines" and stop in a hurry. This is something that should probably be restricted to a ship table entry on a per craft basis, but I can tell you right now that if it works with a minimum of issues, The Babylon Project will LOVE IT. Starfuries could be made to behave like they should per Babylon 5 on screen operation.
-
Josh... I've tried it . It makes it hell to actually fly; you can do it for fun, but you won't complete any missions that way any time soon.
That said, it can be done playable. All things we actually need are some additional HUD gauges, namely:
-Direction indicator, possibly a speed vector indicator - possibly integrated to radar globe, pointing into velocity's direction in relation to ship;
Those two would already help quite a bit, but Vertical glide and Horizontal glide velocity indicators would always be highly useful.
If you don't know your velocity vector, you're flying with Eyeball, Mark I sensor capacity, and as you can't effectively estimate distances and accelerations from 2d screen, it makes it all that more difficult.
-
Interesting indeed. This means I could literally "reverse engines" and stop in a hurry. This is something that should probably be restricted to a ship table entry on a per craft basis, but I can tell you right now that if it works with a minimum of issues, The Babylon Project will LOVE IT. Starfuries could be made to behave like they should per Babylon 5 on screen operation.
Starfuries already have limited reverse, Even going back half a year IIRC..
Just hold Z :D
-
Once scripting 'plr'/'player' thing is restored it will be rather easy to create such additional gauges
-
So what you're telling me is, we now have sliding controls fully mappable to a hat switch, a vector speed boost while sliding, and reverse thrust?
Hot damn...Descent mod, here we come! :D
(Provided you can give me trichording and mapping a forward/reverse movement to a throttle axis, of course. ;))
-
Indeed. In fact I have most of that code (for binding thrusters to any axis) done too :cool: ...we're just waiting on a big code fix taylor has been working on, without which my code breaks your pilot files. It's a big project so there's no rushing him (and you know how much other awesome stuff he's been doing, not even mentioning the amazing bugfixing), but once it's ready things will become even more awesome. :yes:
-
Sounds great. You coders never cease to amaze us lowly peons. :) I know absolutely squat about modding FS2, but if someone can point me in the right direction to learn what I need to after all of this is in code, I just might take a little crack at getting Descent in Freespace myself.