Hard Light Productions Forums
FreeSpace Releases => Scripting Releases => Topic started by: Nuke on February 16, 2007, 07:44:32 pm
-
by sorta i mean it obeys the law of inertia. it doesnt take mass into account yet. this only deals with velocity so rotations are the same as normal. i want to convert max velocity to max thrust output in newtons. in other words a ship at full thrust with the max thrust of 100 will produce 100 newtons of force at full throttle. then i can have acceleration rates based on force vs mass. il deal with that later. my current concern is in making flying newtonian playable. so now im focusing on making the nessicary gauges.
also this only works on the player, need to figure out how to deal with physics on a ship by ship basis, so that all ships operate them. im hopping i can tag objects with custom varibles, then its just a matter of loopong through the ships. the other thing is that it breaks the lead indicators, cause im setting the position directly rather than changing the velocity, which doesnt work. could probibly just use wanderers lead code, which ive butchered into my scripts till i wright my own.
anyway heres the code, id advise using a ship set up for 6dof flight (with slide and rear thrust enabled). you can use any ship but youl have to come about to slow down.
#Global Hooks
$GameInit:
[
--[[=============================]]--
--[[======= function defs =======]]--
--[[=============================]]--
setscreenvars = function() --scalers and constants for multi res support
local w = gr.getScreenWidth()
local h = gr.getScreenHeight()
local cx = w/2
local cy = h/2
local wf = 0
local hf = 0
local awh = 0
local hires = false
if w >= 1024 then
wf = w / 1024
hf = h / 768
awh = (wf + hf) / 2
hires = true
else
wf = w / 640
hf = h / 480
awh = ((wf + hf) / 2) * 0.625
hires = false
end
return w,h,cx,cy,wf,hf,awh,hires
end
round = function(number) --rounds to nearest whole number, for some stupid reason, lua doesnt have this function
local W,F = math.modf(number)
if F < 0 then
if F <= -0.5 then W = W - 1 end
else
if F >= 0.5 then W = W + 1 end
end
return W
end
prograderet = function(x,y,vel)
x, y = x*wf, y*hf --round theese, our vector gets jumpy
gr.setColor(72,192,72,222)
gr.drawGradientLine(x + (12*awh), y + (12*awh), x + (6*awh), y + (6*awh) )
gr.drawGradientLine(x - (12*awh), y - (12*awh), x - (6*awh), y - (6*awh) )
gr.drawGradientLine(x - (12*awh), y + (12*awh), x - (6*awh), y + (6*awh) )
gr.drawGradientLine(x + (12*awh), y - (12*awh), x + (6*awh), y - (6*awh) )
vel = tostring(vel)
gr.setColor(128,192,128,222)
gr.drawString(vel, x - (gr.getStringWidth(vel) / 2), y - (2*awh) )
end
w,h,cx,cy,wf,hf,awh,hires = setscreenvars()
]
$Simulation:
[
player = mn.Ships["Alpha 1"]
if player:isValid() then
if lvel == nil then lvel = ba.createVector(0,0,0) end
lvel = lvel + ( player.Physics.VelocityDesired * 0.01 * ba.getFrametime() )
wvel = player.Position + lvel
lmag = lvel:getMagnitude()
lmag = lmag / ba.getFrametime()
gr.drawString( round(lmag), 100 ,100)
Vx,Vy = (wvel + (lvel*lmag) ):getScreenCoords()
player.Position = wvel
end
]
$HUD:
[
if player:isValid() then
if Vx then prograderet( Vx, Vy, round(lmag) ) end
end
]
#End
-
i set it up for real newtonian but its buggy as hell so im not gonna post it. it takes the models mass field into account. a ships max velocity converts over directly to max thrust in newtons. i did find out that to get space shuttle ohms burn equivelant acceleration on a ship with a mass of about 7500 thakes about 3800 newtons. this is a huge geuesstimation though. i figure combat will reqire about twice that much thrust. might up the conversion to kilonewtons to make it more compatable for the average freespace fighter.
the major bugs are that i cant just directly modify the physics.velocity, seems freespace still wants to run its own physics on top of everything. i can change it but freespace just ignores it. so icheat and change the position directly. this breaks anything from lead reticles to collision detection. it also stutters alot. cause freespace wants to put the ship in one place and i want it somewhere else. i need a way to override the submarine-physics freespace uses to implement this right.
-
I noticed that there's a cheat code for FS2 that enables Descent physics. Would this possibly be helpful to you?
-
Eh? How come no one else ever heard of this?
-
It's always been there, heh, it's on most sites that have cheats for FS2. :)
-
I think if you were to set the $Damp of all ships to 0, you might have what you need (FS not interfering with its own 'momentum' physics as much). Give it a try.
-
It's always been there, heh, it's on most sites that have cheats for FS2. :)
I dont recall ever seeing them :wtf: Only the usual ones... Bizarre I'd miss it...
-
http://cheats.gamespy.com/pc-cheats/freespace-2/
10th one down
-
if it doesnt follow all 3 newton laws its not newtonian :D i think i got 2 down, but im not gonna mess with it for awhile. actually i did set damp and all acceleration values to zero, which prevented freepace physics from coming full on, and that in combination with forcing the ship to may own position variable. it still stutters, like the ship wants to be much further behind where it actually is.
i think this actually has something to do with the max velocity of 3800 (which my code interprets as force in newtons) i was using. the ship wanted to jump 4 clicks before getting told where it needs to be. come to think of it converting the force to kilonewtons so that my max velocity is only 18 might work. i wouldnt mind having Ship.Physics.VelocityApplied, which is essentially a direct line from the imput device. would also make cockpit controls work smoother. right now we have Physics.VelocityDesired, which is really just the axis imputs ramped by acceleration.
flying newtonian is much more about thrust timing than throttle position. contrary to popular belief its incredibly fun if you use a sci-fi based engine thrust characteristics, such as using an orbital incertion engine for orbital manuvers :D a couple space shuttle oms engines are enough to make a small fighter incredibly fun to fly. but you must consider that in the future we will have engines that can throw you back in your seat at about 9 gs. :D
as for the descent physics, im sure they would be usefull if people wanted a descent mod. actually i thought they were in fs1, i never could get em working in fs2. technically the engine is better suited for a battletech mod, which can be done with scripting by the way. get me a fully textured 10,000 poly timberwolf and watch me not implement it :D
-
Mechwarrior 5 here we come. Sign me up!
-
Mechwarrior 5 here we come. Sign me up!
Mechwarrior 5? WHERE?
This mod (http://www.hard-light.net/forums/index.php/topic,47069.0.html) works on all the ships ;)
-
Stupid question: a ship at full throttle that collides with another it will transfer its energy?
-
it shoud, i think, but my script breaks collisions. full throttle just means your accelerating, turn it off and you stop accelerating but you continue your flight path. if your momentum cant carry itself out, as in it hits something. well that energy needs to go somewhere. and if you smack into a ship it will more likely blow up both ships and send pieces in all directions than transfer momentum. if its at slow speed, youl hit, transfer some of your energy, and the other object should slightly change its speed. sorta like what you see when they try and couple train cars.
-
...which is realistic. Excellent work, Nuke! :D
-
well i wouldnt say that. this is a flopped implementation of physics through scripting. id need a +override tag for physics and a replacement for colision detection. for newtonian tourque id need to have access to the moi tensor and alot of knoledge of physics math. which sucks because i can barely manage to do transformations. also it turns out my physics is only a cheap aproximation of what really goes on.
-
But it appears to be something interesting.
Can you do this for beams? I mean...
I want to know if you can recreate a strange-real beam effect, with the beams influencing the way you move compromising everything(meneuverability, speed)if you're close to them.
-
i dont know about that. getting hit by a beam is one of the few occasions where freespace actually uses proper physics.
-
Let me use a simple scheme:
Spacecraft
-------------------------
Beam
-------------------------
Is there a way to compromise speed and meneuverability of a spacecraft close to the beam? It would be perfect in an atmospheric environment, for example.
-
not sure. you need to know where the beam is in space first. you can get the gunpoint, but im not tu sure about the other end of the beam. ypou can calculatre where the turret is pointing using the turret object's .gunOrientation field. its a matrix so use it to unrotate some arbitrary vector. i did this before with my turret script but it probibly works way different for single part turrets, and the beam might not fire along that vector, depending on the type of beam, turret and so on. once you have that you can use some math to determine how far you are from the closest part of the beam. i think theres a hook for weapon impacts so you can hook into it, then check your distance from the photon shaft, and apply some amount of random distortion the your ships velocity vector. so what you want is somewhat possible.
-
Which, translated, means:
No, you suck. You can't. :)
-
lets just put it this way, i could do it if i really wanted to, but i dont. id be much more intrested in an atmospheric/gravitational flight engine. :D
-
I was refering to me, I know you're good ;)
-
im not that good. :D
-
You came out with this idea, you must be good. :D
-
(...) atmospheric/gravitational flight engine. :D
What's the difficult part in that if you have working newtonian flight model? You just add gravitational acceleration component towards a certain point to all ships in the area. Then you add drag as function of ship's drag coefficient, airspeed velocity and altitude (or actually, static pressure, but that translates from altitude...).
Finally - and this is obviously the most difficult part as it affects not only position but attitude - you need to add lift and control surface forces. These are easy enough to determine - lift is the function of angle of attack, airspeed, lift coefficient and altitude, control surface forces are similar but the lift coefficient can change depending on control input.
Cake! :lol:
...not. Most likely the problem would be to make the control surfaces work according to the controls input, and meanwhile disabling the code built-in attitude control. You have already described problems that sound like the engine mkes the ships want to be in different place than the script makes them to go... imagine if the same problem would also appear on the attitude controls. ==unplayable as such.
But honestly, I'm eagerly anticipating the introduction of alternative physics models for FS2_Open, including atmospheric flight. Especially because it will enable the Adama Maneuver in BtRL... :mad2: :cool:
-
the main problem i see with the engine is that theres not enough space. youre not gonna have enough of it to make the space>atmoshpere interface.youre gonna have in atmosphere missions and youre gonna have in space missions. sorta the way nebulas work. there is just no means of transition between environments other than going to the next mission.
also the feel will be wrong. people arent comfortable with the newtonian in space flight, and going from freespace style spaceflight to newtonian style atmospheric flight will just feel kinda wierd. i havent really been able to get newtonian to work through scripting. maybe backslash will add an option to force glide mode on all ships, which would spare us the hassel of coding newtonian physics in script. this makes adding gravity and lift alot easyer.
id mainly use an atmosphere gradient and a gravitational gradient to go calculate drag, lift, and gravitational forces. theese forces will all take the form of vectors and will be summed up for each object, along with that object's induced forces, like thrust. seeing as not many ships in the fs universe posess aerodynamic traits, i want to have support for vtol based lift systems as well (as in strong vertical thrusters). the gradients are based on a 1-0 scale of ground level to the altitude of max attenuation. so using earth as an example. on the ground you have 1 atmosphere and 1 g. at 100km you have the edge of space and tharefore youd be at 0 on the atmo gradient (im not sure how gravity attenuates).
ships with lift surfaces will have a lift profile, which will be a rough approximation of lift producing parts of the ship, mainly wings and lifting bodys. essentially a list of very basic flat polygons discribing the shape, area, and position of the wings. the face normal representing the direction of the lift force, and its position representing the point on the hull upon which force is applied. each lift surface will have other attributes as well, such as lift per square meter (at sea level, and attenuating to zero based on the atmosphere gradient), as well as positive and negative varience range to simulate control surfaces (theese are added to the l/m^2 value). a control axis by which the amount of user induced varience can be shifted, based on control imput (through abstraction of Physics.RotationalVelocityDesired). 2 more vars for min and max angle of attack. the force is calculated for each one of theese surface objects can be calculated and added to the vector sum of all forces applied on the ship. its at best a very rough approximation.
-
What you need is a proper physics hook. The only reason I didn't implement that before my last build is 'cause the physics code is fairly complex at a certain level. I didn't know where, exactly, to put the hook to do the most good. (After all, if you override physics, do you also want to override collisions? How will the player's controls be translated into physics values, since right now it's done directly from control_info to physics_info? And many other questions I forgot about.)
-
i really dont understand the inner workings of the game physics as it stands. reading physics.cpp usually gives me a headache. so its difficult to name exactly what needs to be changed. idealy we shouldnt have to reinvent the wheel when it comes to collision detection. now i have a rough understanding of how that works and im assuming all you need is a position and a velocity vector (as well as some model data, but that isnt changed buy script).
take the way my newtonian script works. for some reason i was unable to get the proper effect by changing Physics.Velocity. i had assumed all i needed to do was to take the velocity vector, and add an acceleration vector (scaled by frametime) to it. but no matter how i did it it behaved erratically. either i didnt understand how the velocity vector worked (i had always assumed it was where i was gonna be in one second time from the current state), or the game was doing further modification to it, or now that i understand how games work better, that physics was operating in another space (even though world space makes the most sence and is what i assumed in the first place). anyway i still dont understand why that didnt work.
so i then hacked in my own physics, and told the ship exacly where it should be. and it worked. this killed collision detection, but it worked. the reason colision detection no longer worked was (i think) because freespace would move the velocity vector all over the place based on the game physics and the ship position went where i told it to go, and you no longer draw a line between you and where you were going. my way of implementing those physics was rather cheap and hackish.
there are alot of parts of physics to deal with. linear physics and rotational physics to name a couple. and even if the colision detection is handeled internally, what do you do with the data it generates. for the colision you could have a Physics.ColisionForce and Physics.ColisionTorque. theese would be 0'0'0 unless something colided with the object in question, and if a collision occured in the last frame, they would be abstracted down to an acceleration vector and a rotational acceleration. theese could be added to Physics.Velocity and Physics.RotationalVelocity as desired, or modified as needed to do other things.
now with colisions taken care of, i think 2 overrides are in order. a linear override and a rotational override. theese overrides would disable anything in c that tries to change an object's physics vars, mainly your velocities (linear or rotational). your position and collision would be delt with by the engine. so then all the scripter and the lua interpreter has to do is tally up acceleration vectors, scale them by various vars and build a new velocity vector based on the data. this makes both newtonian and non-newtonian physics models easy to create, as well as other cool things like atmospheric flight.
there are a few things i dont like about some of the existing vars. one thing i noticed which is a real pita is the way Physics.VelocityDesired and Physics.RotationalVelocityDesired seem to be pre damped by the time they reach scripting. when i think see those var names i think "what im telling the ship to do" as in where my controls are positioned, rather than "as close as i can get to what i want to do based on what the ship can do". but the purpose of scripting in alternate physics is to decide what the ship can do, and do do that i need clean, unmodified control imput (though it can be scaled and sensitivity increased as per the options in the control panel). but pass the damp and rotdamp vars to use in a manor decidable by the scripter. infact pass all relevant physics data from the tables to supply us with tweak factors.
somewhere along the line after the controls update that, iirc, taylor has planned, and when we get things like axial control over lateral and vertical thrusters, id like lateral velocity desired and vertical velocity desired. infact make them work in the same way as the main thrust. i never really understood the current implementation of Physics.LateralThrust and Physics.VerticalThrust. the script output.html file gave them a value from 0-1 and i never got why it wasnt a -1 to 1 setup. at some point i want to do an engine accurate flight model that uses engine positions, normals and radii to determine what acceleration vectors should be applied to what parts of the hull. theese give ships with things such as vectored thrust some rather intresting flight characteristics.
-
LateralThrust and VerticalThrust might be -1 to 1. I felt the same way about some of the :V: comments (They said 0 to 1 where -1 to 1 would make more sense).
Depending on where you're applying the scripting stuff, you might be making your changes after the physics code has run for that frame. If you're using $Simulation that's certainly true. +Override, on the other hand, will run before the default code or hook. You could put your code in it like so:
$Simulation: [
--la de da
]
+Override: [
--doo bee doo clean the droids
--(Physics code)
return false
]
That would keep the behavior of just $Simulation, as you would always be setting override to false, but you could set desired_* values and they would automatically be fed into the physics code for that frame. OTOH they might be overriden by something else in that frame, which may be what the problem was in the first place.
-
I know a bit of lua, but I don't know the math behind newtonian physics. Wing Commander had a physics model like this, but the only difference was that your speed was limited to your set speed and you were not able to pass that limit. (If you ever played WC1, 2, or WCP you'll know what I mean) and I want to do the same with this script. Can I have some help, please?
-
newtonian physics is mathematically very easy, at least the lateral part. im still not totally clear on how to deal with torque. ive taken the idea as far as it can go. the atmospheric flight script has a better newtonian system, but theres still some issues with collision detection that break the whole thing. i may have an idea to get around it but it is untested.
-
If you have questions about Newtonian physics, ask away. There's never going to be a better time for me to be able to answer them than in the next few months, as most of the stuff I'm dealing with classes is on the level that you'd want for this, and there are people that live and breathe physics that I see on a semidaily basis.