[Zacam]

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.

[Backslash]

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 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.

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?

[CaptJosh]

Question, though. If this uses Newtownian physics, does that mean that the longer you have your engines throttled up, the faster you go?

[karajorma]

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.

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

[Herra Tohtori]

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.

[Backslash]

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).

[Zacam]

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.

[Backslash]

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...

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...

[CaptJosh]

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.

[Herra Tohtori]

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.

[Colonol Dekker]

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 

[Wanderer]

Once scripting 'plr'/'player' thing is restored it will be rather easy to create such additional gauges

[Mongoose]

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!

(Provided you can give me trichording and mapping a forward/reverse movement to a throttle axis, of course. )

[Backslash]

Indeed.  In fact I have most of that code (for binding thrusters to any axis) done too ...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.

[Mongoose]

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.