Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Nuke on September 01, 2006, 03:32:42 am
-
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.
-
Ahah, you could simulate turret locking, withut actual firing, This is good :nod:
(remembers the CNV cruisers from I-WAr 1 fondly)
-
Problem is that until RL gives WMCoolmon some free time I doubt we'll be seeing much code from him.
-
I would be extremely happy to see 'plr' functionality restored...
-
I would be extremely happy to see 'plr' functionality restored...
yes, me too.
-
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. :D
EDIT: Has bump-mapping been publically implemented yet?
-
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.
-
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.
#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:
(http://fs2source.warpcore.org/temp/wmc/faust_small.jpg) (http://fs2source.warpcore.org/temp/wmc/faust.jpg)
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.
-
:eek2:
Wow... :D
-
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.
-
Anything in the TBL, yes. Any subobject on a model, not 100% sure.
-
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.
-
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.
-
i had some fun slaving the turrets to the mouse. it was cool. flying with my mouse, it sorta remindd me of freelancer :D
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 alot of complicated math (which i suck at).
-
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
-
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.
-
il probibly try playing with the physics stuff when i feel more mathematcally inclined.
-
just want a heads up, have any of theese changes made it into any recent builds?
-
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.
-
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.
-
the goal i think is to make a freelancer style control setup.
This is included in the pilot file upgrade (which also includes a large rewrite to the io code). Since adding a new set of control types breaks pilot files, it hasn't been added earlier. Just FYI.
-
oh ok. it was just a thought anyway. my real goal was player operated turrets, which seems to be working. aiming is a different matter, i wanted to render a crosshair on the screen that indicates which way the turret was pointing. is there an easy way to convert an orientation matrix to a vector? if i could do that then i could just get the screen coords of that vector.
another problem. the turret apears to rotate right no matter which way the ship is oriented. however when you fire it, if you have any roll whatsoever, the turren fires at a funky angle. both of theese problems come from the fact that i suck at calculus or whatever. oh heres the code, its based off the example in this thread, which i dont fully understand. it works with any bomber with turrets and this build.
#Global Hooks
$GameInit:
[
--all this stuff is for multires support, for getting true width and height, and for generating factors to scale coords by
w = gr.getScreenWidth()
h = gr.getScreenHeight()
if w >= 1024 then
wf = w / 1024
else
wf = w / 640
end
if h >= 768 then
hf = h / 768
else
hf = h / 480
end
dead = 15
--mousejoy function, returns a value from -100 to 100 depending on the mouse's position
mousejoy = function(deadzone)
local X = ((ms.getX() * wf) - (w/2)) * (200/w)
local Y = ((ms.getY() * hf) - (h/2)) * (200/h)
if X < deadzone and X > -deadzone then X=0 end
if Y < deadzone and Y > -deadzone then Y=0 end
return X, Y
end
--generic crosshair function
crosshair = function(x,y)
gr.setColor(0,255,0,200)
gr.drawGradientLine(x+20,y+20,x+10,y+10)
gr.drawGradientLine(x-20,y+20,x-10,y+10)
gr.drawGradientLine(x+20,y-20,x+10,y-10)
gr.drawGradientLine(x-20,y-20,x-10,y-10)
end
]
$HUD:
[
player = mn.getShipByName("Alpha 1")
mX, mY = mousejoy(dead)
gr.setColor(0,255,0,255)
gr.drawCircle(5,mX+200,mY+200)
gr.setColor(100,100,255,100)
gr.drawRectangle(100,100,300,300)
gr.setColor(128,128,0,200)
gr.drawRectangle(200-dead,200-dead,200+dead,200+dead)
mX = mX * ba.getFrametime(false) / 25
mY = mY * ba.getFrametime(false) / 25
if player ~= nil then
for i=1, player:getNumSubsystems() do
ori = player[i].Orientation
ori.h = ori.h + mX
player[i].Orientation = ori
ori = player[i].GunOrientation
ori.p = ori.p + mY
if ori.p > 0 then
ori.p = 0
elseif ori.p < -math.pi/2 then
ori.p = -math.pi/2
end
player[i].GunOrientation = ori
if ms.isButtonDown(MOUSE_LEFT_BUTTON) then
player[i]:fireWeapon(1, 1000)
end
if ms.isButtonDown(MOUSE_RIGHT_BUTTON) then --hold down y + mouse up or down to change your deadzone
dead = dead + mY
if dead < 1 then dead = 1 end
if dead > 99 then dead = 99 end
end
--lof = player[i].GunOrientation
--if lof:getScreenCoords() ~= false then
-- chX, chY = lof:getScreenCoords()
-- crosshair(chX * wf,chY * hf)
--end
end
end
]
#End
-
the goal i think is to make a freelancer style control setup.
This is included in the pilot file upgrade (which also includes a large rewrite to the io code). Since adding a new set of control types breaks pilot files, it hasn't been added earlier. Just FYI.
Mind, this Freelancer type control setup, at least from the code I tested, is not so easy with fixed-normal player primarys ;) It's too easy to overshoot, then undershoot, etc. Remember Freelancer's ships' guns all were turrets.
So... your idea is still good. Plus you've now inspired me to learn more about this scripting, I hadn't realized this much was possible. Good example to learn from. :yes:
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...
What do you mean by this? I might be able to help, I've been playing with the physics stuff lately... but I don't understand what you need.
-
Mind, this Freelancer type control setup, at least from the code I tested, is not so easy with fixed-normal player primarys ;) It's too easy to overshoot, then undershoot, etc. Remember Freelancer's ships' guns all were turrets.
I've never played Freelancer (unless something is for Linux, I don't really bother it), so I don't actually know how it's mouse control worked. The new code is from a patch generously sent in by someone else so I'm just trusting that it's appropriate. But if it's not, the new controls will be there and the code can be adjusted.
-
the main thing i liked about freelancer is that the guns could be aimed independently of the ship. as they always followed the mouse pointer. the ship controll was essentially like what you find in privateer 2 or newer versions of d2xxl (you wanted a linux example) with handle mouse as joystick option and the mouse position cursor enabled. likewise that example i posted but applied to ship rotation instead of turrets. normally its a pita to use, i get about it by creating a dead zone. freelancer made it tolerable by making the mouse pointer the center of attention and slaving the guns off of them, so you essentially aim, and your ship follows your guns. if youve already implemented that kind of mouse control and if turrets can be controlled like the example. then you can emulate freelancer gameplay (but youl have to use turrets).
frelancer had two modes though, the always track mode and the track when mouse1 is pressed mode. this was impotant in freelancer cause everything had a point and click interface. youd click off mouseflight to say pick a target or turn on your autopilot or formation mode. you could turn off mouse tracking to aim your guns while in formation or with autopilot on. i also found it usefull when mining, id fly straight and shoot all the little rocks that passed buy. this is less important to freespace, that is unless somone wanted to do a fl mod. you might want to throw that feature in anyway, incase somone did a point and click hud.
-
So... any news on the 'plr' front?
-
im just getting used to using
player = mn.getShipByName("Alpha 1")
-
I can't see that being much use in multiplayer though Nuke.
-
most of what ive been doing is stuff with the ui or the hud and some experimenting with stuff like subobject animation and whatnot. i havent even considered using scripting in multiplayer. is that even allowed? i thought scripting would have been disabled in multi to prevent cheating. then again it would be cool to script multiplayer gameplay types and stuff. youd probibly have to run a crc on the scripting table or any lua files to make sure everyones using the same script. so will scripts be able to communicate with eachother and/or have the possibility of server side scripts whitch would generate output and echo it to the pilot directly or communicate through a client script?
-
SoL needs scripts and subobject animation for the multiplayer. There is no way we'd agree on disabling it!
-
im curious as to how multiplayer compatable scripting will work though
-
I was discussing this with Axem last night. Validating scripting.tbl is about the only sensible option I can think of.
-
i think were gonna need broadcast vars. variables which are seen and accessible by any script running on any machine on a multiplayer server. some could be server global and persist on a dedicated server (for like running a stats ticker, or if somone did a trade engine with multi). some would only have the scope of a single game (capture the headz :D). it would probibly be best implemented as a stack varname.scope.clientindex. then you can make scripts somewhat designed to communicate with eachother.
-
So... any news on the 'plr' front?
I looked into it awhile back (couple weeks ago+) and IIRC I ended up expanding the 'Self' variable to cover more instances, because I couldn't easily recreate the 'Player' bug. I'm hoping it'll be nice and just disappear. It's on my to-do list.
Scripting is not disabled in multiplayer. Ironically, I think hud_gauges is, because people were worried about somebody moving around the escort gauge or something to give themselves an advantage. :rolleyes:
I think validating the scripting.tbl and assorted modular table files is the most efficient solution to prevent cheating at this point. I'm kinda curious how HL2 does it, though; if it's all done with the sv_cheats thing, or if there's something more going on under-the-hood. It'd be nice to have minor modifications that don't really upset balance to be possible (interface changes and such) but it'd be a hassle to do all that and still make it possible for mods to get the kind of scripting control that they'd want/need for the core gamplay.
-
Scripting is not disabled in multiplayer. Ironically, I think hud_gauges is, because people were worried about somebody moving around the escort gauge or something to give themselves an advantage. :rolleyes:
that is sorta whack. i dont think the hud would let you cheat in any major way really. unless youre displaying data which shouldnt be displayed. but theres no reason to prevent the script from running if all the players have to be running the same scrript.
then again i think the implementation of hud scripting could use some work. things like per gauge overrides. so that i can use a different lead indicator, radar, and scripted shield icons, without having to loose the other functions, mainly aspect lock and targeting. you really cant add new gauges because the huds pretty full already. also maybe better scripting - hud_gauges.tbl interaction. like being able to mix and match scripted gauges for built in ones.
-
Following are just my thoughts....
It would be just fine (if it is possible) to (multi) game simply refuse to start unless the scripting.tbls (and why not hud_gauges.tbls) are identical in every respect. Best might that above combined with something that dls the scripting.tbl and the assorted tbms from the host (that is, if they do not match) - quite like multiplayer missions are handled - and then prompts to restart the game.
And the player bug might be hard to replicate as i do believe (Warning: i aint a coder! ;)) it to be related to optimization settings used when compiling builds...
-
Great those are my favorite bugs. I always discover them right when I'm about to release something.
-
Um, Nuke, will you have available the ability to use the joystick for actually moving the ship around still while using the mouse (or even a second stick) for aiming the turrets? I personally hate the Freelancer control system; the only part of it that I liked even remotely was the Turret View option for firing turrets. I always missed my joystick in that game. ;-;
The reason I'm asking about a second joystick possibility is that I have a gamepad with dual analog sticks (PS2 style controller) and, for a capital ship control mod, I think it would be really neat to have the right stick control aiming the guns while the left stick controls the ship's movement.
Normally, i use a dual-hatswitched Logitech Strike Force 3D, though.
-
right now mu script barely works at all, mouse controls turrets and theres no real way to aim them. it only seems to work with the ship pointing one way. i still dont know the proper math to get them to fire straight no matter which way they point.
-
It would be just fine (if it is possible) to (multi) game simply refuse to start unless the scripting.tbls (and why not hud_gauges.tbls) are identical in every respect. Best might that above combined with something that dls the scripting.tbl and the assorted tbms from the host (that is, if they do not match) - quite like multiplayer missions are handled - and then prompts to restart the game.
Xfering the tables is something I've thought of and instantly rejected quite a few times. The main problem is that there is generally a very good reason why tables don't match.
Suppose I go online with TBP v3.2 and start a game with someone who has TBP 3.3. Right now we'll both get the hacked tables warning and can chat and sort out that I have to upgrade to play. If the tables xfered though I'd get the new tables but I wouldn't have the new ships. So when I tried to play online it would crash out for me. But worse due to the table changes when I went back to singleplayer it wouldn't load the missions any longer because some ship names were changed between the two releases.
And I dread to think what would happen if I hosted a game and someone with FS2 joined it :nervous:
I think we have a small enough multiplayer community as it is without people being scared to go online because they've heard that trying to play can screw up the game.
-
i personally like the way quake mods (2 and 3 mainly, some source ports of q1 and im not sure about the doom 3 engine) work. if you join a mod (with auto-download enabled) server first it downloads the mod binary, the game then sticks placeholder models and textures in the places of any missing data. then it downloads them while gameplay is in progress. it even makes sure to put everything in a certain folder for that mod.
that model of mod xfer applied to freespace it would work something like this. on load the playing mission, tables and scripts are transfered. gameplay relevant pof data (gunpoints, gocks, moi ect. everything but geometry) are transfered and appended to a compatable place holder model (geometry data only). you could use a model alias for a particular shipclsss, defined in a table. so for fighter it would use ulysses geometry and for a bomber it would use ursa geometry. as the game is played the full models are sent out one piece at a time on ny excess padding of the currently used packets. textures would also be trancfered one mip level at a time starting with diffuse maps before doing glows and specs. of course the idea is to keep a running server going. and that anyone can hop on and eventually anything custom would take the place of the placeholder models, gameplay uninterupted.
that said i must take into account what kara said. that not many people play online and that its a huge undertaking and wouldnt add that much to the engine. i think it might be a better idea to implement a simple mod versioning system. create a table or some kind of config file, with a mod version number a list of all required files, the crcs for relevant files. theese could be generated by the engine for a mod release. you could have a required list and an optional list. the optional list is for alternate versions of things, like high or low res versions of textures for different system capabilities. stack that with the ability to run an alternate stats trackers and you got a viable solution for multiplayer mod compatability.