Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Swifty on September 25, 2011, 09:05:50 pm
-
As I continue working on the Freespace source code for my fourth year, the number of projects and requests I'm fulfilling has increased almost exponentially. I've had a couple of major features under my belt so far, namely TrackIR support, the HUD code rewrite, and soft particle rendering. I've also written several optimizations to the collision detection code which aren't as noticeable as the previously listed features.
But the question is, what am I working on now? In an effort to make Freespace engine development a bit more transparent, I've decided to make a comprehensive post detailing the current projects planned or underway by me.
Render HUD to Texture: Render to texture is currently a feature that's available using the scripting system. You can easily render pretty much anything to cockpit models and ship models using the Lua subsystem. However, a common request despite the availability of script-based render to texture is the capability to render-to-texture existing HUD gauges that have already been built into the code.
The HUD code has been rewritten to be flexible enough to feature this capability. And as a result, Diaspora is currently testing this feature using the DRADIS radar as shown in various video previews. The plan is to open this feature up to all HUD gauges and not just the DRADIS radar once it's definitively stable and ready.
More HUD layout features: I know it's a pain in the ass to build new HUD layouts and have to use a one size fits multiple resolutions dichotomy. It was really the best I can do while preserving the old method of using retail HUDs for differing resolutions. As a result, I've been thinking of instituting some better features and syntax. Users should be able to build more flexible layouts that take into account of relative positions (positioning a gauge relative to a proportionate sector of the screen) while also giving the option to always render HUD elements in it's native resolution rather than being scaled.
It'll be funny if I end up reinventing CSS without even realizing it.
Collision Detection Optimizations: This is a pretty big one. On top of that, it's also the most frustrating. At the moment I'm continually experimenting and playing with the collision detection and rendering code to see if there are any savings to be had with the engine.
Some collision detection changes I have already made is making sure ship submodel orientations are being set once per frame instead of per collision using Polymodel_instances. I've also made sure that submodel orientations are being calculated once per frame which reduces a lot of redundant calculations as a collision tries to propagate itself up the model tree.
I currently have in progress a build of Freespace which revamps the bookkeeping the engine does to keep track of pairwise collision relationships. The engine at the moment creates a data object for each potential collision and brute forces through them all to find out which ones are colliding. A solution I worked up is to gather all the endpoints of everything in the mission space, ships, lasers, beams, asteroids, debris, etc. I sort them first on the X-axis, do a pass to find any overlappers which are then sorted on the Y-axis and sorted for the third time on the Z-axis. Using quicksort, this broad phase does a fast job of eliminating all definitive non-colliding pairs in the mission space. As a result, the memory requirements have been reduced and we've now eliminated a bunch of excessive distance checks between all objects.
Another collision optimization in the works is the realignment of BSP nodes for models. I've been experimenting with storing BSP nodes in certain orders to improve cache performances. At the moment, the game stores BSP nodes depth first. I've been experimenting with storing BSP nodes breadth first which slightly improved the performance of doing model collision checks.
Rendering Optimizations: Rendering performance is something I'm struggling with as a member of the Diaspora Development team. Our art team produces some pretty demanding models which has prompted me to figure out technical solutions for these monstrous beasts. Valathil's upcoming shadowing implementation has me a tad worried about the potential impacts on performance as our assets are already demanding enough. But we'll see what happens once he's finished with it.
I've been playing with occlusion culling by trying to cull out non-visible subobjects using hardware supported occlusion queries. Not much luck there. My next move may be to implement a z-prepass on scene renders in order to reduce the number of overlapped pixels being worked on by the pixel shader. Another performance optimization being discussed lately is finding out ways to reduce the number of expensive texture switches done by the video card. Texture atlasing has been discussed along with merging common textures into one big 3D texture. So far, the method with the quickest implementation time would be sorting render calls by their texture ID so the texture switches are shared by multiple render calls.
Non-Photorealistic Rendering: This is probably my most anticipated thing I have planned. I've been reading a lot of interesting material on non-photorealistic rendering. Also known as toon shading or cel shading. With the glut of anime mods in the pipeline for Freespace and being probably the only coder for these anime mods ('Sup, Wings of Dawn?), I thought it would be nice to offer cartoon-ish visuals to complete the aesthetic these projects are trying to reproduce. Not only does this mean producing a different lighting model for objects (Likely just different SDR files that modders can drop into the effect folder) but also creating a good and coherent method for Freespace to create seamless outlines around depth and normal discontinuities so we can get a nice hand-drawn look. Valathil's shadows will excellently complement the cel lighting and will probably be a major key to convincingly pull this off.
-
I unfortunately don't have an ETA on all this stuff. It's a lot of work to do but I at least want to be held accountable for these features such that I don't get lazy and forget about them. There's so much I want to do for the engine but I figure I should get these out of the way first instead of flip flopping around the codebase and spreading myself thin.
-
So the dradis video you guys uploaded a while back is made using the scripting system right?
I've been playing around with the hud table and I must say it was a good idea to code that, the hud looks so much better now that's hi-rez compatible.
Me be quite happy, thanks :D
-
Oh my god Cell-Shading's coming back?
And double-thumbs up to the optimization changes, and Render to Texture.
Hell, thumbs up to the whole damn thread. :D
-
The days of MV-Cel shall come once more, only gooder this next time around. :D
-
Wow. Can't wait for it, especially simpler RTT and optimizations.
-
a thought on the rendering things, it might be a good idea to separate out all of the code involved into modular components, this will make future endeavors of this nature easier, and eventually a materials system could be plugged in as a new rendering module.
-
Show this man more appreciation. I'm doing the flashy eyecandy stuff everybody notices. He does the invisible grunt work that nonetheless is needed and is as awesome as my work!
-
Soft particles do count as awesome eyecandy. But heh, it's your problem here. Stop stealing him all the glory !
-
(http://images.cheezburger.com/completestore/2010/9/10/141fa576-62dc-477c-b977-709fe73716d2.jpg)
-
I approve of this post a lot!
This gives a bit of insight on the less appreciated things being done behind the scenes like optimizations. Of course I'm also really interested in what kind of result the cell shading will produce :nod:
I also like this line: "I at least want to be held accountable for these features such that I don't get lazy and forget about them"
It helps when you know which coder you need to ask when something is bugged somehow! :yes:
-
hey swifty a question:
The new HUD will allow us to animate it?
i was thinkin at this :
http://www.icosaedro.it/acm/download-hud.png
as you know the pitch ladder moves...it should be a good improvement :)
-
So the dradis video you guys uploaded a while back is made using the scripting system right?
No, that is all done by the HUD code. DRADIS is just a different radar type along with the standard and orb radars.
Show this man more appreciation. I'm doing the flashy eyecandy stuff everybody notices. He does the invisible grunt work that nonetheless is needed and is as awesome as my work!
Thanks, Vala. I've always wanted to work on graphics improvements but I never had the time because I would always fixate myself on optimizations, save for soft particle rendering. It's great having you around so I can focus more on performance stuff and frivolous stuff such as cel shading. :P
hey swifty a question:
The new HUD will allow us to animate it?
i was thinkin at this :
http://www.icosaedro.it/acm/download-hud.png
as you know the pitch ladder moves...it should be a good improvement :)
Why do you need a pitch ladder if you don't even have a horizon in space? :wtf:
In any case, the new HUD code allows us to create any gauge in the source code and allows us to use it using hud_gauges.tbl. So yes, we can theoretically make available a pitch ladder HUD gauge. There are some gauges I've created for Diaspora already using this framework but are still work in progress.
-
Why do you need a pitch ladder if you don't even have a horizon in space? :wtf:
FS mods are not necessarily about space, noob :p You most not forget atmospheric mods !
-
Why do you need a pitch ladder if you don't even have a horizon in space? :wtf:
FS mods are not necessarily about space, noob :p You most not forget atmospheric mods !
And simply because is... COOL!
Seriously,the pitch ladder not needs only for horizon, but gives you the feel of your roll and pitch speed,and,in space theorically,where many places are completely dark,this feature could help a lot.
plus,if the pitch ladder should be sincronized with a ship,this could help to bearing your fighter with the ship you targeting (for example,very useful in landing procedures with a capship)
-
A well "pitch ladder" needs some frame of reference from which to orientate. I suppose you could have an orbiter style hud where its orientated to your forward movement, but that would only be important if you were orbiting something which isn't exactly useful in this engine. Especially where nothing operates on pure Newtonian physics.
-
Plus you can always have it be an arbitrary celestial grid based on a planet, or galactic plane, etc. (which FS wise would be based on the mission grid)
-
However much of a good idea or bad idea a pitch ladder gauge will be, I'd rather we not derail this topic any further.
-
I'm greatly interested for the more "modder" friendly rtt code :D
-
massive :yes: to the optimisations you are planning for the collision detection Swifty
-
Render HUD to Texture: Render to texture is currently a feature that's available using the scripting system. You can easily render pretty much anything to cockpit models and ship models using the Lua subsystem. However, a common request despite the availability of script-based render to texture is the capability to render-to-texture existing HUD gauges that have already been built into the code.
The HUD code has been rewritten to be flexible enough to feature this capability. And as a result, Diaspora is currently testing this feature using the DRADIS radar as shown in various video previews. The plan is to open this feature up to all HUD gauges and not just the DRADIS radar once it's definitively stable and ready.
script level rtt is buggy as hell right now. granted it was pretty rock solid in 3.6.12, it had its quirks but for the most part it worked well. i managed to do several from-scratch hud and panel elements, entirely in scripting, and managed to apply them to ship geometry (old-skool cockpit submodel using show ship flag, as scripting access to cockpit modes was non-existant at the time). it worked well, had working radars and whatnot, and a system for animating subobjects within the cockpit model and elsewhere so you could have animated cockput controls and potentially others, such as control surfaces. i also had intended to make its features modder friendly so they could edit familiar tables to configure the script for their mod. of course at some point the rtt features of script just did not work with 3.6.13.
right now i think ive identified 2 distinct problems. one i believe is a geometry issue in my testbed models. when i converted models for use in my rtt heavy cockpit script, i didnt make models from scratch, i just used some of the cockpits already found in various nukemod ships. i essentially used pcs2 to insert a few polygons which were textured for the mfd panels i was using at the time. the mfd textures would be replaced with textures generated by the script. now this worked before 'go faster' builds came along and after that i had a whole bunch of issues with uv space banding. i found out that this had nothing to do with render to texture calls and 2d stuff worked fine. i think the problem had something to do with ibos (the effect is similar to the uv space corruption that happened recently in the nightly builds). to fix this id just have to work on the models abit more.
the second issue is probibly not relevant to to your hud system, but getting the renderFrame() call to work with a render target is really hard to make work. it kinda works right now, sometimes, but at what appears to be 1/4 the resolution (it kinda renders to the bottom left corner of the texture). some times it renders to the screen in an odd way, instead of into a texture. this is only useful if you want things in your cockpit like a simulated monitors, mirrors, etc.
i just want to bring this up, kind of a heads up on whats going on with the scripting side.
hey swifty a question:
The new HUD will allow us to animate it?
i was thinkin at this :
http://www.icosaedro.it/acm/download-hud.png
as you know the pitch ladder moves...it should be a good improvement :)
scripting. learn it, know it, love it, and then use it for evil.
it does however bring up a good point. id like to some how make it so scripting and the hud system have some degree of interaction. i want to use scripting to create gauges. scripting gives you drawing primitives, capacity for bitmap rendering, some 3d rendering features, in addition to maths and access to game data. everything you need to come up with gauges just like the one in the picture there. problem with these scripted gauges, is that you pretty much treat it as a function to be called on the draw hud hook. it just draws on top of whatever was on the hud without regard to its layout. you could give the scripting access to some information about the hud layout, but it still requires scripting talent to get it to work with your mod.
instead what if i define the gauge with scripting, and place it with the hud layout system. so when it comes time to render that gauge, it runs a hook ($on hud gauge render: name of gauge). and when it does the script is passed layout data such as: resolution, size, color, Slew, etc. as an example, some time ago a modder wanted to use my attitude gauge from my atmospheric flight script (http://www.youtube.com/watch?v=MMmhsxv69uI). it shoulda been easy to hand it over, a table and some graphics. but i had to do a lot of cut and paste to make it standalone and then had to tweak it to look right on their hud at different resolutions. it would be nice if i can just say, "stick this in your mod folder and configure it in hud-gauges.tbl". would also make it much much easier to render custom gauges to texture without having to have the script manage the render targets and texture replacement.
-
Yeah, thanks for the comprehensive sitrep. I should definitely fix render-to-texture scripting access and devise a good way to for scripts to integrate with the engine's HUD gauge system.
-
other question:
Will the hud be affect from post processing?
I think is good having an hud that glows a bit :)
-
I think that's a bad idea. If you want a glow effect on the hud, it's better and less expensive rendering-wise to incorporate that effect into the HUD bitmaps.
-
i think he means the rtt hud and this would be a yes its affected
-
at some point rtt would need to mesh with the currently theoretical materials system. say your doing a monitor you may want to draw to the glow map and have a static or animated bitmap as the diffuse texture. if your doing a mirror would use the dynamic texture as diffuse and want to overlay specular to make the mirror look dirty when the sun hits it (much like my monitor). another idea, scorch maps. when damage happens you could figure out on which polygon the imact happened, and get the uv position, then draw impact bitmaps to the scortch map, and blend it multiplicatively into the diffuse texture, lts of cool things you can do with this. if your rendering hud gauges to the panel in the cockpit model, such feetures would be needed to improve the appearance of rtt textures.
-
Food for thought here: What about making the collision detection a seperate Thread cause its kinda asynchronous anyway with the time delay on the checks and everything. Would help on multicores.
-
I kinda don't want to think about designing a multithreaded collision detection system until my current revisions to the collision detection system are done.
-
Aside from that, wouldn't that take rewriting the whole engine, seeing as the engine is not multi-threaded at all?
-
No, it would take rewriting those subsystems of the engine, which is a big enough task already.
-
My mistake. I've seen a lot of "we should make FSO multithreaded" suggestions over the years since I discovered FSO, and most of them seemed to get shot down based on the need to rewrite basically the whole engine to even multithread part of it. Others were shot down with, "If you think it's such a great idea to do that, you do it."
In any case, there are many features that need to be worked out before there's a feature freeze and the time taken to multithread even part of the engine.
-
There's a huge difference between programmers familiar with the codebase talking about it and random forum members.
-
Agreed. In any case, I hope I'm wrong about how long I think it might take to get to the point where a feature freeze can be put in place and work on multi-threading the engine can begin.
-
The main argument against doing something like that is that there are plenty of other ways to optimize the code without multi-threading, that we haven't done yet. Supposedly. But seriously, if multi-threading is ever the answer, we'll do what is necessary in order to accomplish it.
-
Sounds like a plan to me. I look forward to all the optimizations you coders can manage. Me, I'm no coder. Closest I get to it is writing PHP. Oh and correcting some constant defines in a single file for another app I compile from source. Someone forgot to make one of the source files define _STDINT_H if _STDINT was already defined and _STDINT_H wasn't if the project was being built for windows. Of course, that has to do with none of the sdk includes, either from MS or the Quicktime SDK having that constant defined anymore. Nonetheless, it's a sanity check that should already have been in place in the particular source code file to which I had to add the necessary ifdef and ifndef lines. But still, that's the most I've ever done with actual c++, and I had to get help to figure that much out.
-
Show this man more appreciation. I'm doing the flashy eyecandy stuff everybody notices. He does the invisible grunt work that nonetheless is needed and is as awesome as my work!
Oh hey now, heat distortion and shadows are very cool and look awesome, but hardly the only things I look for in the nightly changelog. I'm constantly hoping to see more optimizations. Hosting Delenda Est Co-op takes a lot out of ones computer after all, and every little bit helps.
-
Hey Swifty,
A few months back (maybe a year ago? I don't remember), I asked you about rendering shield/weapon/speed gauges as a diagonal (or even arbitrary angle) instead of vertical or horizontal. Did you ever get around to looking at that? Is that in your current To-Do list? Because as things stand, my current hud doesn't exactly work... ;_;
(http://img23.imageshack.us/img23/7596/fs2open3613rinfsse22011.png)
-
you can render bars like that with 2 polygons, and 2 images of full and empty bars. by changing the size and uv coords of the polygons and texturing each with one bitmap or the other you can approximate a progress bars. also polygons can be rotated so you should be able to pull it off. i think you can in scripting (another case for scripted gauges). could also support ani/eff based gauges, but i dont think they are as good.
*edit*
after looking up some functions i doubt that this can be done with scripting now. currently gr.drawPolygon() doesnt let you change the uv space for its vertices, of course i cant imagine this being hard to add in.
-
I'd rather avoid using lua if at all possible
-
I'd rather avoid using lua if at all possible
You got a problem with Lua? Well get over it, because you're not going to get anywhere with that attitude.
-
That's a potentially sexy HUD you got going there, Quanto. :cool:
-
I'd rather avoid using lua if at all possible
You got a problem with Lua? Well get over it, because you're not going to get anywhere with that attitude.
What the hell, bro? :wtf:
Chill out. He's probably just like me - completely unable to use Lua, and looking for a way to do things without having to invest weeks in learning an entire coding language.
-
Frankly I'd like to know about horizontal gauges as well... I've got posts going back since the new HUD code was released that I've been
asking about doing it...
..and that's a nice start to a HUD quanto... I like it.
-
On top on being unwilling to invest weeks into a whole new scripting language, I also don't like how it tends took "tacked on" over the existing UI in many of the examples I've seen, and I'd like to avoid doing that in my TC.
I have seen great examples of LUA in other games, but the LUA implementation in FSO isn't robust enough for me to take it seriously here on this engine.
Below is an example of a beautiful UI done entirely in LUA on the SpringRTS Engine
(http://img502.imageshack.us/img502/7465/screen00000.jpg)
Unless someone can say I can achieve a similar result ENTIRELY with LUA and not use the standard HUD at all, then I'd take the time, but I'm not going to use both at the same time, its all or nothing on one or the other.
-
That's not intrinsic to LUA but rather a result of a bad implementation. LUA is a very simple programming language that can be used and abused at will. If FS2 exposes rendering functions to you, you can make remake the whole FS2 interface art with scripting. Using that "example" of an interface used by Spring is a very ignorant ploy because, honestly, the only thing that separates the Spring interface from something that looks good is the presence of actual art to use on and around the buttons and various widgets. If you have the art, there's nothing that stops you from using LUA except your own stubbornness.
-
That's not intrinsic to LUA but rather a result of a bad implementation. LUA is a very simple programming language that can be used and abused at will. If FS2 exposes rendering functions to you, you can make remake the whole FS2 interface art with scripting.
That's very, very likely not true. While the scripting system can do all sorts of cool things, it comes with a lot of bugs and limitations. Sometimes some information simply isn't exposed to the scripting API, sometimes there's no function to do what you need and sometimes something just plain don't work right.
That said, it's an irreplaceable tool when you need to do complicated things, and I think it'd be utter folly to try to do for example a TC without it. Making a TC is already a massive undertaking and I don't think that having to do some reasonably light programming is really unreasonable at all. However, you must prepare to either 1) compromise or 2) try to get a coder to add new things if and when the need arises. If you need special features in your mod for which you need scripting, then you will almost inevitably run into the problem of not being able to make it look or work exactly the way you'd want using the current API.
-
If it's minor or "general purpose" enough, you can try to convince a scripter to do it for you (though keep in mind that in the latter case, the script would most likely end up released to general public).
-
-snip-
that kind of interface is quite doable, provided someone wants to invest the time and effort into it (as someone did there). of course were talking a lot of scripting, every type of interface widget seen there would need to be scripted (my svn has the start of such a system of widgets, which is skinable). its not like you dont have all of the graphics features, you have a full graphics library to work with, you have access to game events and game controls. there is room for improvement, but almost every major scripter, myself included, has made contributions to the c code to add features to scripting.
the tacked on look is kind of an ongoing issue. you can override the hud and remake it from scratch, or you can float new gauges on top of it. this is why i asked for better integration of scripted hud gauges so that modders can use, place, and configure scripted hud gauges in hud_gauges.tbl without ever having to touch any lua. you just drop the *-sct.tbm in your tables folder and make a gauge entry to represent that script. eventually you would have a library of hud gauges that you can choose from and can mix and match with stock gauges to create a custom hud. also since many of these gauge scripts would likely include graphics, they could be made skinable as well by redrawing the bitmaps.
that covers the hud but you still got the interface. for that you need widgets and a command interface. and while the former can be scripted from scratch (as mentioned above), the latter is needed to be able to issue commands to the game which would have been able to do with the hard coded interface. you can already hook into pretty much any screen in the game and draw graphics there, you could also override the interface screens entirely giving you a blank screen to work with. with a system of widgets you can turn these blank screens into actual interfaces. however this is not useful because there is no way to change the game settings with these interfaces. so a command system is still required for this kinda thing. but then again what good is implementing such a system if no one is willing to learn how to script to make use of it. i think a table based interface configuration would be easier to use, but would be more difficult to implement than a command interface, and im sure most coders would just tell you to skin the hard coded interface instead. of course scripting new interface screens are not that important to me right now.
-
Nuke, that actually sounds pretty exciting, I would love if someone could actually include all of the game settings commands into the lua system so a full LUA UI (game briefing, menus, HUD, etc, all) may be possible. I do like LUA as a scripting language and I've always been lua curious, its just that programming has never been fun for me (I took C++ and Pascal in Highschool back in 2000-2001), and I find scripting only moderately more tolerable.
Art and content creation has always been my strength, its just unfortunate that I haven't been able to attract any motivated contributors to my project. Some simply have other projects themselves, and still others have only been slightly interested in SAFSO enough add one thing here or there, I've shouldered 80% of the work pretty much (with Andy being the other major contributor who has created the tables for the game, but given up on mission design.) It's mentally exhausting and I just don't know how I can fit learning a robust language like LUA into my workflow at the moment.
-
What the hell, bro? :wtf:
Chill out. He's probably just like me - completely unable to use Lua, and looking for a way to do things without having to invest weeks in learning an entire coding language.
Eh... I've just seen a lot of "I don't want to use scripting for <problem which could most easily be solved using scripting>" comments... Quanto just had the luck of being the one I blew up at.
-
For a while, there was someone that was actually working on a scripted hud, but it was dropped. Why? Because autoaim doesn't work with a scripted hud. So, unless there's a way to force autoaim to work with scripted huds, I think making a hud through scripting is not an option for SAFSO.
edit: Oh gee I even have a very, very old video showing it (http://www.xfire.com/video/2088b3/)
-
Um, I don't think you mean auto-aim. I think you mean the target lead indicator doesn't work. I also didn't see any missile lock-on indicator, but the missiles used in that vid may have been FaF types.
-
The lead indicator obviously worked, look more carefully.
-
All I saw were target brackets. Not a lead indicator. The video is quite low resolution though.
-
It's not that difficult to spot even with the low resolution, the ships move extremely fast so the indicator has wide spacing.
(http://img683.imageshack.us/img683/1803/fertx.png)
Discussion over lead indicator done now.
-
Someone's a questionable content fan XD (I am too)
-
So what about getting autoaim to work in a LUA based HUD?
-
Wtf, Really guys? Take this crap out of this thread.
-
ive done a few from scratch hud gauges as part of the cockpit script. ive got a weapon gauge, lead indicators, target information floaters, radars, etc, and they dont affect auto-aim at all. granted i didnt +override: the hud, i just disabled rendering with hu.HUDDrawn = false.
-
Wtf, Really guys? Take this crap out of this thread.
So Swifty can u maek soft shados? U make soft particle right its not that different?
-
It's not that difficult to spot even with the low resolution, the ships move extremely fast so the indicator has wide spacing.
It was actually impossible to spot until I put the video in full screen mode. I don't usually watch flash video in fullscreen. The artifacting from the extreme compressions usually used is impossible to stand at my screen resolution. In any case, I'm curious as to why an all scripted HUD would affect auto-aim.
-
Wtf, Really guys? Take this crap out of this thread.
lawl n00b, who u tink u ar3?
-
It's not that difficult to spot even with the low resolution, the ships move extremely fast so the indicator has wide spacing.
It was actually impossible to spot until I put the video in full screen mode. I don't usually watch flash video in fullscreen. The artifacting from the extreme compressions usually used is impossible to stand at my screen resolution. In any case, I'm curious as to why an all scripted HUD would affect auto-aim.
it does effect things like aspect missile lock. code to control this kinda thing runs when the hud is being drawn. so if your scripting hook overrides that code, then you wont be able to attain lock. i dont know why autoaim solutions would be handled in the hud code (it kinda makes sense for the missile lock) and theres no indication of the autoaim on the hud last i looked. a good feature would be to set up an indexer in lua so your script can iterate through the current set of gauges currently being used to get a gauge handle. then through that handle let you toggle certain gauges on or off or change other settings for those gauges. this would also provide a means of access to information about any custom gauge whos behavior you would implement through scripting. throw on hooks for "on gauge init", "on gauge frame", and "on gauge uninit" and i think we would be set.
-
Interesting. So an all scripted HUD disables aspect lock on missiles because the scripting disables the HUD portion that the missile lock works with. I hope that's already in Mantis. Seems like a serious bug.
-
Interesting. So an all scripted HUD disables aspect lock on missiles because the scripting disables the HUD portion that the missile lock works with. I hope that's already in Mantis. Seems like a serious bug.
id rather fix it with a feature than try to separate it out of the hud code. make it so you can disable parts of the hud as needed instead of a complete override. then you can keep the aspect lock gauge and any other gauges you want to keep, and disable gauges you plan to replace. you can still script in a few targeting schemes in its place if you want an entirely different lock behavior.
-
Well, yes, we need that as well. Still, there ought to be a way for everything to work right for someone who wants to replace the entire HUD because none of it properly matches the desired behavior.
-
Well, yes, we need that as well. Still, there ought to be a way for everything to work right for someone who wants to replace the entire HUD because none of it properly matches the desired behavior.
+1
-
just the way aspect lock works is a very 2d operation in screen space which is why its coded into the hud instead of somewhere else. so instead of flipping the override switch and rewriting the whole hud from scratch, make it possible to turn off the things youre replacing and keep the things youre not. way i figure it, instead of not using the aspect gauge, it should be fairly simple to re-skin the aspect lock gauge to match your custom hud gauges configuration and use that. re-writing the gauge in script would likely offer very little. still better script control over missile lock would be a good thing to have.
-
I believe it has recently become possible to disable certain HUD gauges... so using that and leaving +override: false, it ought to be possible to have both scripted HUD and the missile lock feature...
-
im still deving in 3.6.12 builds because they still have stable rtt. but should look at some of those new features and see what they can do. i had considered setting up a base hud in the hud_gauges.tbl and overlaying my gauges on top of it.