[Scooby_Doo]

This whole section has devolved into an ungodly mess, time for a restart.

• Check to see if current mission time is or exceeds X time  mn.GetMissionTime () > nextTimeFrame + .1
• Grab the ships current P,B & H values
• Convert these (at least P) to the 0->360 values (code you gave me plus some of mine do this
• Create the Delta P by subtracting the current P with the previous P (adjust for the 360 to 0 in case)
• Go through all the subsystems, if one has a thrust vector flag do this:
  
  • Multiple the deltaP by some factor so the animation will be visible, apply limits if needed, same with H & B
  • Assign this delta P/H/B to the subsystem's pitch (since all subsystems are (0,0,0) based that should be the pitch for it)
• Store the ships orientation as the previous version

[Scooby_Doo]

Great... I had the pitch rotation degrees working perfectly... 0->360 and 0->-360
But guess what! Banking throws everything for a loop 


Hmmm I'm going to try and reset the bank/heading back to 0 and then calc the pitch.

[Scooby_Doo]

Ugh.. this is insane.   I was just looking at the banking angle.  Say I bank to some degree (can be even minor) then pitch the ship.  Guess what the banking angle changes! 
Is this one of the reasons why eulers are so disliked?  Also is there any other way to obtain the ships orientation?

Edit: I'm going to skip thrust vectoring for the moment and thrust acceleration/deaccleration animations 

[Scooby_Doo]

OMG we were doing this the hard way!  Go look at the scripting.html  Now look at the ship "class".  It's an OBJECT object, now go look at the object "class".  There's a "physics" member.  And in the physics class guess what! "Rotational Velocity"  Value: Rotational velocity, or null vector if handle is invalid

A quick test show's it seems to be accurate.  Doing a full 360 pitch show's no major change in delta values.  Looks like we might actually have thrust vectoring soon! 

[Nuke]

oh yea, i forgot about that.

[Scooby_Doo]

LULZ... it only took less than a day and some small code to get thrust vectoring to actual work. 

Now back on to thrust acceleration/deacc. (think air brakes, thrusters that can open up or clamp down depending on speed.

[Scooby_Doo]

Figured out how to do "classes" so time for some cleanup.  Sorry nuke your example was a bit too complicated 

[Nuke]

its really not complete either. there is no set in stone way to do object oriented programming in lua, there are a hodgepodge of methods and im only really familiar with a few of them.

[Scooby_Doo]

Here's how I'm doing them:

Code: [Select]

ThrustVectorType = {
vectorFactor = nil,
minAngle = nil,
maxAngle = nil,
otherAxisEffects = nil
}

ThrustVectorType.__index = ThrustVectorType

function ThrustVectorType:Create ()
local newEntry = {}
setmetatable (newEntry, ThrustVectorType)
return newEntry
end
Then use setters and getters for the members.

Doing some parameter check coding now and converting to class, then I'll continue on to thrust velocity checking.

[Scooby_Doo]

Thrust vectoring in action!
https://www.youtube.com/watch?v=GqiCbwL13-Y&feature=youtu.be

[Nuke]

pretty cool. have you had a chance to test what that does to collision detection?

[Scooby_Doo]

pretty cool. have you had a chance to test what that does to collision detection?

No clue.  If there's a problem I think the solution would have to be in the engine.  Hmm I don't suppose you can activate/view collision boxes in-game?

Also nuke since you probably have the scp source code there, can you check to see if  Subsystem.Position is read only?  I can read it but I can't seem to modify it.  Since I'm on a roll here I want to test future ideas.

[Nuke]

as i understand it if you enlarge the bbox and radius of the parent to contain all possible rotated positions of the child, then collision detection should be preserved. but ive never tested this idea at all with scripted rotations.

[Admiral MS]

Also nuke since you probably have the scp source code there, can you check to see if  Subsystem.Position is read only?  I can read it but I can't seem to modify it.  Since I'm on a roll here I want to test future ideas.

Generally any virtvar like "object.value" can be set to a new value (as opposed to functions like "object:function()" that may do different things). What the game does with this input is another story. If it decides to write something else into that variable (for example because your input is not within the accepted range) before using it the next time you are out of luck.

[Scooby_Doo]

as i understand it if you enlarge the bbox and radius of the parent to contain all possible rotated positions of the child, then collision detection should be preserved. but ive never tested this idea at all with scripted rotations.

The old tiny triangle trick.  I did that with some of the kilrathi capships for blown-off subsystems.

Also nuke since you probably have the scp source code there, can you check to see if  Subsystem.Position is read only?  I can read it but I can't seem to modify it.  Since I'm on a roll here I want to test future ideas.

Generally any virtvar like "object.value" can be set to a new value (as opposed to functions like "object:function()" that may do different things). What the game does with this input is another story. If it decides to write something else into that variable (for example because your input is not within the accepted range) before using it the next time you are out of luck.

Ah ok.. i'll have to do some more inspecting... would be very cool if I could make it so we can do translations too instead of faking it with super wide angles.

Also good news, a subsystem's children will also be effected by the rotation.  I was kinda concerned there for a moment.

[Nuke]

now heres the thing with doing long animation hierarchy chains. you have to have containment all down the chain, each parent's bbox must completely contain everything that is a child of it all the time. if the animation causes something to rotate out of its parent's bbox (or its own), it may be missed by collision detection. fortunately instance depth is only like 5, so you can only have hierarchy that deep, including the hull model. i havent attempted anything that complex, so this is all just in theory.

i mean ive done this kinda thing:

and had it work in game, but the collision detection never worked, and i dont think i understood it enough at the time to attempt boxing it to hell and back.

[Scooby_Doo]

Also this is more meant for small stuff where collision detection wouldn't be that big of a deal.   If you want to move a massive chunk of a 5km ship around, you'll probably want a better solution.

Also this increases your subsystem count up quite a bit, depending how detailed you get.

[Scooby_Doo]

Thruster nozzle resizing now works.  Basically roughly source orientation->dest orientation based on (speed/maxspeed)  {its more tweakable than that but that's the jist}

[Dragon]

That sounds really nice. Are you going to release a public beta?

[Scooby_Doo]

Ya, and i'll include a demo ship along with it.  Just want to get it as full featured as possible.
Unfortunately it looks like translation doesn't work.  Seems like the engine only gives you the position and never reads from it (basically you can read it but never modify it)