[Nuke]

getSubobjectAngle(ship_object, sobj_name, angle_type)
setSubobjectAngle(ship_object, sobj_name, angle_type, angle)

explanation:
the first 2 vars in both functions are pretty much self explanitory. angle_type is a string, if set to "absolute" returns the angle of sobj in world angles (degrees in a vector object), "ship" returns the angle in ship coords, and "parent" retuns the angles sobj-parent relative. only the first function returns the coords, the second one sets them with angle, a vector object, in whatever mode angle_type is set to. the functions need to be pretty fast as id intend to use them on a frame by frame basis.

why
to allow scripting of player operated turrets, blindfire, complex animation, working pilot controls, 3d indicators, and many other intresting ideas that havent even crossed my mind yet.

why not just use animation code:
because it can be cumbersome to use it for complicated animations, also it restricts you a handfull of binary trigger events. you dont get persise control on a frame by frame basis. my idea means you can do very complex animation, with very little code. also it frees up coders from needing to implement another trigger event every time a modder gets another cool idea.

[Colonol Dekker]

Ahah, you could simulate turret locking, withut actual firing, This is good 
(remembers the CNV cruisers from I-WAr 1 fondly)

[karajorma]

Problem is that until RL gives WMCoolmon some free time I doubt we'll be seeing much code from him.

[Wanderer]

I would be extremely happy to see 'plr' functionality restored...

[Nuke]

I would be extremely happy to see 'plr' functionality restored...

yes, me too.

[WMCoolmon]

This actually touches on a couple of internal design debates I had ~a month ago when I was working on scripting

1) Predefined global variables
Should things like "Player", which will be available in almost every hook, have some kind of way to differentiate them from user-defined variables? In addition, should global variables have different syntax from hook variables? A quick thought that I had would be to prefix predefined global variables with "g_", ie "g_Player", and hook variables with "h_", ie "h_Ship".

There's no real good way of putting these in the meta output without constraining programmers to modify code in multiple places to add global variables/a hook.

2) Switches in functions
It's a waste of processing power to use strings for 'switch' variables. I was thinking of implementing what would be the equivelant of C macro definitions. This would mean, for example, that instead of "absolute" you would use ABSOLUTE_ANGLE, RELATIVE_ANGLE, RELATIVE_PARENT_ANGLE or somesuch. This would require a separate macro class and some additional meta-code to output the macros, but would be a boon for speed. Did this.

Four-day weekend FTW.

EDIT: Has bump-mapping been publically implemented yet?

[taylor]

EDIT: Has bump-mapping been publically implemented yet?

Nope, been too busy working on 3.6.9, and dealing with RL.  Right now I'm just trying to get the Theora player working and ready for 3.6.9.  Bump mapping is lower priority.

[WMCoolmon]

The new enumeration system affects the following:

isButtonDown
setCursorImage
setOpacity
ship.Shields
createTexture
createParticle

ie scripts making use of the above functions will almost certainly fail, unless they are updated with the new enumeration functions. I haven't committed them to CVS yet.

In addition, on the actual topic of this thread, I implemented Orientation and GunOrientation variables. These work with the code about as directly as possible - I did not implement the functions, because I feel it's better for scripters to understand how much math is going on so that they can better optimize it (and so it doesn't seem like a magic fix is to change the enumeration for the angle type).

I saw the writing on the wall, and so implemented a "fireWeapon" variable for subsystems.

http://fs2source.warpcore.org/exes/latest/C09022006.zip

Here is a sample script that will cause all turrets on a ship named "Faust" to be slaved to Alpha 1; left mouse button will fire them. Note that it only works properly for dorsal ship turrets.

Code: [Select]

#Global Hooks
$HUD: [
--Get hooks for controlling ship, "Alpha 1"
--and controlled ship, "Faust"
player = mn.getShipByName("Alpha 1")
faust = mn.getShipByName("Faust")

--If both hooks are valid...
if faust and player then
--...iterate through all subsystems...
for i=1, faust:getNumSubsystems() do
--...match the heading of the player and gun base...
ori = faust[i].Orientation
ori.h = player.Orientation.h
faust[i].Orientation = ori

--...match the pitch of the player and gun muzzle(s)...
ori = faust[i].GunOrientation
ori.p = player.Orientation.p + math.pi/2
--...while limiting them to the upper hemisphere...
if ori.p > math.pi/2 then
ori.p = math.pi/2
elseif ori.p < -math.pi/2 then
ori.p = -math.pi/2
end
faust[i].GunOrientation = ori

--...and fire if the left mouse button is pressed.
if ms.isButtonDown(MOUSE_LEFT_BUTTON) then
faust[i]:fireWeapon(1, 1000)
end
end
end
]
#End
Here's a screenie of it in action on a Hecate. Note the forward turrets:



EDIT: Another note. The scripting system combines both rotational values, Orientation and GunOrientation, for fireWeapon. Since single-part turrets won't have a 'gun' part, you can just use that to direct the fire without visibly changing the subsystem.

[Wanderer]

 

Wow... 

[Nuke]

cool, i didnt expect such a fast implementation of this. this definately opens up the possibility of capship command mode and definately controlling the turrets on a fighter or bomber. can this still be used on non-turret subobjects? theres still a few things i want to do that dont involve turrets, like working cockpit controls.

[WMCoolmon]

Anything in the TBL, yes. Any subobject on a model, not 100% sure.

[Nuke]

well thats good enough. i can make anything a subsystem, and just make it non-targetable.

anyway for the controls, is their any way to get the applied turn rates into scripting? could be straight off the joystick axes positions. or the roll, pitch,  yaw, and throttle rates, perhaps a percentage of the maximum rotational force that is being aplied. the latter probibly being better, as youd see the controls move if you were flying on mouse or keyboard. you could do flight controls, control surfaces, thrust gimbals ect. with it, would really bring the models to life.

[WMCoolmon]

The simple answer is no, for now.

More complex answer is that there are a couple of ways, one involves a lot of learning of the joystick/mouse input code, the other involves expanding some scripting variables, but I have to decide how I want to do that, since I can either choose to risk duplicating a bunch of code in the future with slight modifications, or adding an extra bit of complexity into the code.

Way 1: ship.OrientationSpeed / ship.MaxOrientationSpeed
Way 2: ship.physics.OrientationSpeed / ship.physics.MaxOrientationSpeed

It's a slight change, but I feel that if it's going to be the norm, then I may have to re-evaluate the way I've arranged the rest of the stuff in Lua so far. I don't want to have everything be sub-variables of the handle, but then suddenly require an extra layer for the physics.

[Nuke]

i had some fun slaving the turrets to the mouse. it was cool. flying with my mouse, it sorta remindd me of freelancer

i could probibly get away with compairing the ships orientation in a frame with the one in the previous frame to gauge how fast a ship is rotating. but its messy and would require of complicated math (which i suck at).

[WMCoolmon]

I've been looking into SEXP variables and fixing the ship.vector.x = ??? bug. But I haven't gotten around to actually diving in and coding anything.

New stuff in CVS (QA tested):

model
Mass
Radius

ship
Model

fireCountermeasure
firePrimary
fireSecondary

[WMCoolmon]

Update on Things:

1) Predefined (ie application) variables

Plans are to move these (Player, Self) to a separate 'scripting variables' (sv) library. This will keep the global userspace free of variables, and allow a certain level of access control to the library from the Lua environment. It may also allow easy enumeration of the current variables in it, without having to keep a separate list in C/++.

2) Physics variables

Roughly 80% of the (formerly internal) physics variables for objects are in lua. (in my local CVS tree) The remaining 20% are mostly timestamps, or miscellania for AI. This will ruin the day for any scripts that use object.Velocity or object.VelocityMax. I should have a hook in to override the physics of an object more or less around the time that #1 is fixed. ie so someone can implement Newtonian physics themselves.

3) SEXP Variables
Requires a small overhaul of the lowlevel Lua interface code to get them working so that I can have arrays of SEXP variables as library variables. I don't totally understand the process yet, further research & testing is needed before the final implementation, so this will be a bit.

4) 'vector' and 'matrix' object types
The simplest solution is to make both of them handles, so pos = ship.Position would give you a handle to the ship's position, rather than copying the vector data. So if you were to then say "pos.x = 24", that would affect the position of the ship that the variable is derived from.

[Nuke]

il probibly try playing with the physics stuff when i feel more mathematcally inclined.

[Nuke]

just want a heads up, have any of theese changes made it into any recent builds?

[WMCoolmon]

No, they got derailed when I decided that the best course to go with for the scripting system was to redo the entire lowlevel interface rather than to hack in the necessary code for the above. It gave me a lot more versatility to work with, and I think I've finally gotten the hang of Lua tables in the process.

[Nuke]

thats good. i was writing a script to improve the mouse controlled turret script i wrote before. it handles the mouse more like a joystick and will also show a reticle for the turrets. the goal i think is to make a freelancer style control setup. i was curious as to what build i would test it in. if it works and  find a way to change the phisycs rotational forces from the script, it would be exactly like freelancer's mouse control. if it works. i finished coding but havent run it yet to see if its working.