Hard Light Productions Forums
Modding, Mission Design, and Coding => The Scripting Workshop => Topic started by: WMCoolmon on March 18, 2007, 04:21:48 am
-
Since this is what kicked off scripting in the first place, what are people's current plans or thoughts regarding redesigning the HUD with scripting in FS2_Open?
-
Well for 3D HUD.. to be honest unless (certain) current HUD elements can be 'extracted' into scripting and from there via RTT put back on screen a full scripting HUD is going to be pretty massive and probably pretty slowly running monstrosity given that everything that is used in the HUD would have to be rewritten in Lua..
As for 2D.. an option to 'allow' graphics to be drawn 'beyond' the screen limits would be welcome as otherwise moving hud elements either have to be restricted into working only in 'center region' to avoid odd element disappearance (left/top edges) or scaling events (right/bottom edges).
Some new 'gauges' have been tested and also used in some measure (though afaik not in mods or tcs.. just locally either by me or Nuke).. I have made something simple like 'escort reticle' and 'bomb reticle' both to highlight respective objects ingame without actually targetting them.
-
How about 3D targeting brackets? The lead indicator's throwing me off my aim because my HUD is "crapped out."
-
i havent worked on my hud much lately. but one thing is for certian, we need alot more vars. if experimented with drawing 3d gauges using drawTechModel(), i think. its been awhile sence ive scripted anything. been busy with work and stuff, sisters moving in in a couple weeks and all the preparations are eating up all my time.
3d gauges through drawTechModel can be rather cumbersome, as that was designed for tech room interfaces and loadout screens. not actual hud use. it requires table entries for any models used. also the system for manipulating orientations for the models is kinda wierd. id rather just be able to give it a matrix. id like to be able to give it a pof file directly rather than use up table space. actually a 3d hud element object would be nice with fields such as .Model, .Texture, .ori and so on. should be streamlined to be as fast as possible. defining objects in lua is incredibly slow so having it done in c makes it faster.
im also concerned with the time it takes to render a fully functional hud. ive had cases where calling too many un/rotateVector() functions droppedme to 15-30 fps (on a 8800gts, where i usually get 75). this case was using my remote turret funcs on a deimos, so it called unrotate 6 times per turret, every frame. most of the time this can be avoided but if youre doing something like a custom radar, where you need to call rotateVector() multiple times in a loop, it could drop you to a slide show.
2d huds can probibly be sped up my using more bitmap elements to reduce loops requiring alot of math (drawing curves uses alot of trig functions). bitmaps also look better. is far as 2d rendering goes i think we got everything we need. target boxes can be drawn easily in lua, as we can get an objects radius and distance. though a size on screen var would be better, as it would more accurately conform to the ship's footprint on your screen.
another annoyace is that getScreenCoords doesnt return offscreen coordanates. i want to draw flightpath boxes on the hud (like the kind you see in frontier, orbiter, some flightsims) which indicate a path you must follow. parts of theese boxes may only be partly on the screen in some cases and i still want to draw lines that are at least partly visible. you can also render a scripted subspace node or any line based representations of 3d objects on the hud.
i also want to do rtt panels and animated controls, some of which ive done already. the rtt stuff has given me problems though, usually not working and slowing the game down.
id like to see more hud table-scripting integration. main reason would be to be able to mix and match c based gauges with lua based ones. say i want to keep the com menu, but rework everything else. or what if rendering a radar in lua is too slow and i need to use the orb radar.
-
how about repositioning, redisining? i would like a directive box that looks like a post-it note.
-
Oh, and have the pong hud thing become a toggle-on-off feature for those long escort missions. ;)
-
can do....if i have time with all his making of overpowered weapons to stick on the NGTSVRBT spiky fish shaped watergun (AKA colathanasheput).
-
oh no, he found the scripting board
-
Hmm, that reminds me, I still have a build to release sometime...
-
ive been busy with work and re-learning c :D
-
i fixed your wacky pong physics nuke. now it behaves like the arcade original. all i need to do is make the ball a mara and tha paddles erinyes.
-
Can you release the scripting.tbl of pong before you change them to Erinyes and Mara?
-
#Global Hooks
$GameInit:
[
--HudPong (tm)
w = gr.getScreenWidth()
h = gr.getScreenHeight()
poneh = 0
ptwoh = 0
gameh = 200 --you can change this to what
gamew = 220 --ever resolution you want. changed to the shape of a ping pong table.
gamex = w / 2 --set what coords to draw (now set to above reticle)
gamey = h / 5 --the game at here (game center, Y axis).
ballx = gamex
bally = gamey
ballxvel = 2 --changed to make
ballyvel = 3 --it act more like a ping-pong ball
balla = 255
deathmsg = "GAME OVER"
drawpongarea = function(x, y, sx, sy) --pong box here
gr.setColor(0,200,1,255) --pong green
gr.drawLine(x-sx, y+sy, x+sx, y+sy)
gr.drawLine(x-sx, y-sy, x+sx, y-sy)
gr.setColor(0,100,1,20)
gr.drawRectangle(x-sx, y+sy, x+sx, y-sy) --now featuring a transparent back, which is even better now.
end
drawpongpaddle = function(x, y)
gr.setColor(0,10,200,255) --change these number values and change how the paddle looks
gr.drawRectangle(x+5, y+15, x-5, y-15, true)
end
drawpongball = function(x, y, a)
gr.setColor(200,10,10,a) --change these and change the ball
gr.drawCircle(10,x,y)
end
--im nuts
]
$HUD:
[
--HudPong
drawpongarea(gamex,gamey,gamew/2,gameh/2) --draw playing area every frame
if w >= 1024 then --compensate for resolution
maxis1 = ((ms.getY() / 769) * (gameh * 0.9)) --paddels, fixed by takashi to act slightly more realistic
maxis2 = ((ms.getX() / 1019) * (gameh * 0.9))
else
maxis1 = ((ms.getY() / 490) * (gameh * 0.9)) --paddels, see above comment, now in lowres!
maxis2 = ((ms.getX() / 640) * (gameh * 0.9))
end
poneh = (maxis1 + (gamey - (gameh / 2))) + ((gameh - (gameh * 0.9)) / 2)
ptwoh = (maxis2 + (gamey - (gameh / 2))) + ((gameh - (gameh * 0.9)) / 2)
drawpongpaddle(gamex + (gamew/2) - 5, poneh)
drawpongpaddle(gamex - (gamew/2) + 5, ptwoh)
ballx = ballx + ballxvel --move and draw the ball
bally = bally + ballyvel
drawpongball(ballx, bally, balla)
if bally < (gamey - (gameh / 2)) + 5 or bally > (gamey + (gameh / 2)) - 5 then
ballyvel = ballyvel * -1 --bounce off borders
end
if ballx < (gamex - (gamew / 2)) or ballx > (gamex + (gamew / 2)) then --tell the player when he gets castrated and reset the game
gr.setColor(200,200,100,155)
gr.drawString(deathmsg, gamex - (gr.getStringWidth(deathmsg) / 2) , gamey)
balla = balla - 8
if balla < 1 then
ballx = gamex
bally = gamey
balla = 255
end
end
if (ballx < (gamex - (gamew / 2)) + 15 and bally > ptwoh - 15 and bally < ptwoh + 15) or (ballx > (gamex + (gamew / 2)) - 15 and bally > poneh - 15 and bally < poneh + 15) then
ballxvel = ballxvel * -1 --bounce off paddles
end
--nuts indeed
]
#End
small math fixes. nothing more. and a few color tweaks....
-
al you really did was change a couple numbers.
-
see previous statement.
-
:bump:
I didn't see this till now, but would it be possible to work the HUD into (or onto) a cockpit, like for Wing Commander Saga? Or is that basically what Wanderer said?
-
In theory, yes, if RTT stuff is working.
-
ive never managed to get it working. i was under the impression that i had to wait for shaders to have it work fast enough to be playable. on the other hand ive already got ships with working throttles/stickcs, ect. but im still pretty much just testing it. theres still the matter of every little lever and gismo slowing down the renderer though.
-
That's a modeling issue. You should be UVmapping all the HUD components to a separate texture. One separate texture. There's no point in having more textures than necessary, but whatever texture is used for the HUD will have to be redrawn each frame.
Although if you wanted to reduce the workload, you could use a static texture and only redraw the HUD components every 5 frames or so. I don't know what the best number of frames is to use; Bobb is more well-versed in the differences between static and dynamic textures.
And you'd probably be best off storing a variable of the setting that actually controls model movements (Eg a Throttle_pct variable) and only changing the model's submodel positions when that changes, to reduce the calculations done each frame that the HUD is drawn.
-
id probibly go for a refresh every 15 frames, drawing the gauges on the 14th frame so that all the 15th frame needs to do is draw that info to the texture. i actually created a simple plane once and tryed to get hud pong to draw to it, but it never really worked. can you by any chance update your old hello world example script?
-
I assume you mean this page (http://www.hard-light.net/wiki/index.php/FS2_Open_Lua_Scripting) in the wiki? Done, and I tried to update the rest of the examples to reflect the new scripting system capabilities as well.
-
thanks :D
but wheres the render trargets example?
all i really got to go on is this old example (http://www.hard-light.net/forums/index.php/topic,37992.msg774478.html#msg774478) which didnt work last i checked. i never really understood the whole thing in the first place and the fact that i was never able to generate any working code doesnt help much either. i need to see a current working example that i can mess with and understand how its working. not neccisarily a panel, but at least painting foul words on the side of an orion will do :D
-
Well, I haven't been able to get a working RTT example going; apparently there's a bug with the RTT code which taylor is looking into. (I don't know when the fix will be committed)
-
What is RTT?
-
Render-To-Texture
-
will taylors fix include rtt under open gl?
-
It sounds like the fix will only affect OpenGL.
-
How practical would it be to use scripting with the HUD available now to produce a disturbed reticle gunsight? This is a form of early gunsight in which the reticle itself moves to account for the bullet path under G at a given range. In effect, unlike the targeting reticle in FS2, which is a director sight (it knows the target course, velocity and range) it is a targeting reticle set to a fixed range. The reticle 'floats' across the screen as the craft maneuvers to display where the projectiles will actually be traveling.
-
how good are you at math? :D
that means it can be done, ive done my own lead indicators (based off some of wanderer's script). be nice if you could make a lead that indicates hit probibility and takes the target's evade potential into consideration.
-
That actually would be pretty cool. :nervous:
That thrill of almost-satisfaction you'd get as the reticule pulsed red when you catch a Dragon flat-footed...
-
flat-footed
That term is reserved for D&D, not FS2 :P
-
ideally id use a reticle like the one i already completed, a simple circle with a radius and color indicating hit potential. evade potential can be figured out by determining the travel time for your shots to get to the target, how fast the ship can go/manuver, and in some cases max deflection angles (for weapons that use them). using that data you could determine it would require doing complicated math every frame though.
-
Heh, that stuff sounds cool, director sights do have a "SHOOT" indicator that would be interesting.
I am interested actually in a primitive F-86 style gyro sight. Basically a reticle that precesses opposite to whatever turn you are making.
The disturbed reticle sight takes the ballistic data, combines it with aircraft pitch and roll inputs, and then computes a picture of what the bullet path looks like. Essentially, the disturbed reticle sight says to the pilot, "Here’s what the bullets are doing…now it is up to you to get the target to fly into this area."
(http://www.simhq.com/_air9/images/air_268a_017.jpg)
Of course it wouldn't precess down as there is no gravity in space. I presume I would need to get the vector describing the flight path of the player craft and then in effect reverse it to get the projectiles' vector. That in turn would need to be converted into an on screen coordinate. Does that make sense?
-
try this
#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()
cx = w/2
cy = h/2
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
--now that were done with that ****, we can define some more important vars
xtarg = cx --this is where our crosshair will want to be
ytarg = cy --same thing but a bit more vertical
wepvel = 450 --set for thrasher for testing, wel do what wanderer did later
chr = 50
chg = 50
chb = 50
cha = 50
--now a crosshair, il make this much more detailed later, with target direction and orientation, target iff and maybe ammo gauge and locked/locking indicators
drawgunsight = function(x,y,r,g,b,a)
gr.setColor(r,g,b,a)
gr.drawCircle(25,x,y)
gr.setColor(r,g,b,255)
gr.drawGradientLine(x+18,y+18,x+5,y+5)
gr.drawGradientLine(x-18,y+18,x-5,y+5)
gr.drawGradientLine(x+18,y-18,x+5,y-5)
gr.drawGradientLine(x-18,y-18,x-5,y-5)
end
--and finally lets jack wanderers code, because i really dont feel like plotting vectors in 3d space
leadreticle = function(weaponvel)
local targetpos = target.Position --tweak theese
local targetvel = target.Physics.Velocity --looks like nothing else needs to be tweaked here
local lenghttargetvel = targetvel:getMagnitude()
local playerpos = player.Position
local plrtotrg = playerpos - targetpos
local lenghtplrtotrg = plrtotrg:getMagnitude()
local trgangle = plrtotrg:getDotProduct(targetvel)
local a = (( weaponvel * weaponvel ) - ( lenghttargetvel * lenghttargetvel ))
local b = ( 2 * trgangle )
local c = -( lenghtplrtotrg * lenghtplrtotrg )
local discrim = ((b * b) - 4 * a * c)
local leadx = 0
local leady = 0
if discrim >= 0 and a ~= 0 then
multipl1 = (( -b + math.sqrt(discrim)) / ( 2 * a))
multipl2 = (( -b - math.sqrt(discrim)) / ( 2 * a))
if multipl1 >=0 and multipl1 <= multipl2 and multipl2 >= 0 then
targetmult = multipl1
elseif multipl1 >=0 and multipl2 < 0 then
targetmult = multipl1
elseif multipl2 >=0 then
targetmult = multipl2
else
targetmult = nil
end
if targetmult ~= nil then
local leadvel = targetvel/(1/targetmult)
local leadpos = targetpos + leadvel
if leadpos:getScreenCoords() ~= false then
leadx, leady = leadpos:getScreenCoords() --rather than just simply draw the coords, il scale and return them so my code can **** with them
leadx = leadx * wf --drawleadreticle(leadx,leady) pft, my way is better :D
leady = leady * hf --theese factors make things so much easyer
return leadx, leady --yep, thats what i need there
else
return -1, -1 --return -1-1 if this all fails, so it doesnt tweak my math
end
end
end
end
]
$HUD:
[
player = mn.Ships["Alpha 1"]
if player:isValid() then
target = player.Target
banks = player.PrimaryBanks --work on this
wep1 = banks['1']
wepvel = wep1.WeaponClass.Speed
end
if target:isValid() and player:isValid() then
if target.Position:getScreenCoords() ~= false then
xship, yship = target.Position:getScreenCoords()
xship = xship * wf
yship = yship * hf
xtarg, ytarg = leadreticle(wepvel)
if xtarg >= 0 or ytarg >= 0 then
xtarg = cx + (xship - xtarg)
ytarg = cy + (yship - ytarg)
else
xtarg = cx
ytarg = cy
end
else
xtarg = cx
ytarg = cy
end
else
xtarg = cx
ytarg = cy
end
if target:isValid() == false then
if chr > 50 then
chr = chr - 1
elseif chr < 50 then
chr = chr + 1
end
if chg > 50 then
chg = chg - 1
elseif chg < 50 then
chg = chg + 1
end
if chb > 50 then
chb = chb - 1
elseif chb < 50 then
chb = chb + 1
end
elseif target.Team.Name == "Hostile" or target.Team.Name == "Traitor" then
if chr < 255 then
chr = chr + 1
end
if chg > 0 then
chg = chg - 1
end
if chb > 0 then
chb = chb - 1
end
elseif target.Team.Name == "Friendly" then
if chr > 0 then
chr = chr - 1
end
if chg < 255 then
chg = chg + 1
end
if chb > 0 then
chb = chb - 1
end
elseif target.Team.Name == "Unknown" then
if chr < 255 then
chr = chr + 1
end
if chg > 0 then
chg = chg - 1
end
if chb < 255 then
chb = chb + 1
end
elseif target.Team.Name == "Neutral" then
if chr > 0 then
chr = chr - 1
end
if chg > 0 then
chg = chg - 1
end
if chb < 255 then
chb = chb + 1
end
else
if chr > 128 then
chr = chr - 1
elseif chr < 128 then
chr = chr + 1
end
if chg > 128 then
chg = chg - 1
elseif chg < 128 then
chg = chg + 1
end
if chb > 128 then
chb = chb - 1
elseif chb < 128 then
chb = chb + 1
end
end
drawgunsight(xtarg, ytarg, chr, chg, chb, cha)
]
#End
this should work in recent head builds
-
Could something a little more modern be made? As in, a gunsight pipper with a line trailing to a circle - you place the circle on the target and squeeze? Basically like the one in an F-15? (Kinda like a different looking F-86 sight :) ).
-
well you could swap the procedurally rendered pipper i mad ewith a graphic pipper instead, then just get the screen coords of the ship and draw a line from those coords to the sight's. ive done this before its rather easy.
-
Is the magnitude of a vector in FS2 a value expressed in meters (yes, I was an English major)? For instance, the F-86 gunsight doesn't know anything about the location of the target. It is calibrated to assume that the target is at a certain distance -- say 500m. Thus instead of this code snippet:
local targetpos = target.Position --tweak theese
local targetvel = target.Physics.Velocity --looks like nothing else needs to be tweaked here
local lenghttargetvel = targetvel:getMagnitude()
local playerpos = player.Position
local plrtotrg = playerpos - targetpos
local lenghtplrtotrg = plrtotrg:getMagnitude()
local trgangle = plrtotrg:getDotProduct(targetvel)
[\code]
Could I not simply use
[code]
local targetvel = player.Physics.Velocity --use the player's own craft's velocity
local lenghtplrtotrg = 500 --fixed distance
local trgangle = plrtotrg:getDotProduct(targetvel)
and continue with the rest of the code? I will need to flip the x/y coordinates of the gunsight, as this is a trailing and not leading indicator.[/code]
-
before the radar gunsight was used they used a gyro gunsight, which compensated for g-forces, gravity and attitude (as this data was already available to the instruments). that would require entire code entirely.
the whole function for generating the lead was designed by wanderer (though i added some tweeks too it) and i barely understand how it works. what i did know was that if i knew where the leadpoint was (generated by function), i knew where the reticle was (w&h / 2), and i knew where the ship was, then i could draw a pipper on the screen by subtracting the lead's screen coords from the ship's screen coords, then add the result to the screen center. all i did really was change how the data was represented.
btw, what sim is that?
-
My lead function is basically just 101 trigonometry.. namely usage of the extended Pythagoran law.. the cosine rule. It constantly calculates interception point for the given primary weapon and the target in 3d space. Most of function is just a verification process that it uses the correct root (from 2nd degree function) and that the root may not be imaginary. Most of the stuff i added just in case Lua would be unable to automagically handle 'double' results and imaginary values and also to make sure that i get the result i wanted from the function.
But to get a low tech 'lead reticle' for fixed distance firing you need to use something totally different as Nuke said.