The Dynamic Cockpit Project

Want to edit the game, build your own craft and missions? Here you'll find help, tools, guides and people to discuss with.
Post Reply

Re: The Dynamic Cockpit Project

User avatar
Driftwood
Admiral (Moderator)
Posts: 2174
Joined: Wed Oct 22, 2003 11:01 pm
Contact:

Post by Driftwood » Sat Aug 03, 2019 12:23 am

Yes, obviously having everything based on the opt.ini file would make things forward/backward compatible, result in less additional files, and everything relevant is located in one location for ease of editing.

User avatar
blue_max
XWAU Member
Posts: 2295
Joined: Wed Mar 20, 2019 5:12 am

Post by blue_max » Sat Aug 03, 2019 6:35 am

Thanks for your opinions guys. I appreciate the effort to propose a format too. In fact, you've forced me to consider how this project should evolve. A few notes though:

The screen resolution is probably not optional. Computing the HUD regions at run-time is possible; but there are many technical details and the end result never fits properly. In fact, that's what I was doing first; but abandoned it because things were always misaligned... On the other hand, I need this bit of information because the coordinates are different depending on the resolution. So, for the same cockpit, there's going to be multiple sets of coordinates, one set per resolution and I need to load the right set depending on the current resolution -- which is why I need this bit of information.

I can remove the dimensions for the target texture, though.

I don't think it's a great idea to provide normalized (in the range [0..1]) coordinates because they are more difficult to update. In its current implementation, you can run XWA and then do fine adjustments at run-time without exiting the game or reloading the mission. So, I'm currently checking how the cockpit looks, then I go back to the text file, add a few pixels to the coordinates and press Ctrl+Alt+L to apply the changes right away. That seems to work fine. If it helps, coordinates can be specified at sub-pixel precision.

At some point I'd like to split the CFG file to the INI files. Yes, that makes sense and makes things more manageable.

BTW, I was working on the Assault Gunboat and noticed that it's not illuminated properly. I just fixed the cockpit (thanks for the explanation, Darksaber!) and you'll probably need this OPT:

EDIT: https://www.dropbox.com/s/rvbkkhmgkkf9k ... C.zip?dl=0

BTW, I couldn't contact the author of this OPT (Matt), so if anyone has issues with me touching that file, let me know. This is how it looks with DC enabled:
Assault-Gunboat-DC.jpg
I'll release a new version soon. It still doesn't support 32-bit mode, because I need to merge Jeremy's latest changes; but I'll get there, I promise.
You do not have the required permissions to view the files attached to this post.
Last edited by blue_max on Sun Aug 04, 2019 5:50 pm, edited 2 times in total.

Bman
Lieutenant Commander
Posts: 1167
Joined: Mon Apr 05, 2004 11:01 pm

Post by Bman » Sat Aug 03, 2019 5:12 pm

DTM made a new AGB few months ago. I'm not sure if the cockpit was redone as part of it. Haven't flown it yet. This is looking really great! Actually this might make texturing a little easier to do going forward with less "stuff" for the authors since you're moving the "field-of-view" objects onto dashboard and sides. Everything is far more realistic now.
W-I-P: TFTC, MC Viscount Cr., ISD-II Avenger, NL-1 Platform, Ton-Falk Esc. Cr., & Misc.

User avatar
Trevor
Lieutenant JG
Posts: 541
Joined: Thu Dec 04, 2014 7:11 pm

Post by Trevor » Sat Aug 03, 2019 6:27 pm

blue_max wrote:
Sat Aug 03, 2019 6:35 am

The screen resolution is probably not optional. Computing the HUD regions at run-time is possible; but there are many technical details and the end result never fits properly. In fact, that's what I was doing first; but abandoned it because things were always misaligned... On the other hand, I need this bit of information because the coordinates are different depending on the resolution. So, for the same cockpit, there's going to be multiple sets of coordinates, one set per resolution and I need to load the right set depending on the current resolution -- which is why I need this bit of information.
Can you provide more info on this limitation?
As it stands it sounds like people are going to have to make their own configurations which might be beyond the scope of some.

I cannot see how the HUD cannot be preset with code... am I missing something?

Maybe its the HUD_Scale value? is that not readable by ddraw?

I would have thought something along the lines of

Code: Select all


struct HudElement
	width
	height
	x
	y
	anchorx
	anchory
	scaledwidth
	scaledheight
	scaledy
	scaledx


SLRecharge_FRadar
	.scaledwidth = (SLRecharge_FRadar.width * HUD_Scale) * vrHUDScale //width taken from texture 10000-300 (109x92)
	.scaledheight = (SLRecharge_FRadar.height * HUD_Scale) * vrHUDScale 
	.scaledx = 0
	.scaledy = 0

Reticle
	.width = 64
	.height = 64
	.scaledwidth = (Reticle.width * HUD_Scale) * vrHUDScale 
	.scaledheight = (Reticle.height * HUD_Scale) * vrHUDScale 
	.anchorx = (0.5 * screen.width)
	.scaledx = Reticle.anchorx - (Reticle.scaledwidth /2)
	.anchory = ((0.5 * screen.height) - (77 * HUD_Scale))
	.scaledy = Reticle.anchory  - (Reticle.scaledheight /2)

if xwing
	cannon1light
		.width = 8
		.height = 8
		.scaledwidth = (cannon1light.width * HUD_Scale) * vrHUDScale 
		.scaledheight = (cannon1light.height * HUD_Scale) * vrHUDScale 
		.anchorx = 
		.scaledx = Reticle.scaledx - cannon1light.scaledwidth - (4*HUD_Scale)
		.anchory = ((0.5 * screen.height)- 77)
		.scaledy = cannon1light.anchory  - (cannon1light.scaledheight)
	cannon2light
		.width ...
		

===================


Working table for radar/SLrecharge element
size		res		scale	scaled size
108x92	640x480 	1		108x92
245x208	(1920x1080)	1		108x92

109x92	800x600 	1		109x92
196x166	(1920x1080)	1		108x92

196x166	1280x1024	1.8		109x92
206x174	(1920x1080)	1.8		109x92

196x164 1920x1080	1.8		109x92

conclusion, each element is the same size no mater the screen res (before scaling)
size can be determined from texture


working table for position of central elements
pos		res			scale	scaled pos
960,0	1920x1080	1.8		
320,0	640x480		1	

ok, so the anchorages are 
0,0
0.5,0
1,0
0.5,0.5-(77*HudScale)
0,1
1,0.5
1,1



78 1920
77 720

Last edited by Trevor on Sun Aug 04, 2019 8:05 pm, edited 1 time in total.

User avatar
rogue518
XWAU Member
Posts: 2856
Joined: Wed Jul 12, 2000 11:01 pm
Contact:

Post by rogue518 » Sat Aug 03, 2019 7:40 pm

Yeah blue_max I thought you said you were going to do a tutorial regarding this like Trevor said:
As it stands it sounds like people are going to have to make their own configurations which might be beyond the scope of some.
I know you're really busy trying to figure this out... and I remember you saying you were going to do a tutorial?


Sincerely, Rogue518
'Stay in Attack formation!' Darth Vader aka: Anakin Skywalker During the 'Battle Of Yavin'

User avatar
keiranhalcyon7
Lieutenant JG
Posts: 599
Joined: Tue Jan 02, 2018 6:41 am

Post by keiranhalcyon7 » Sat Aug 03, 2019 7:51 pm

If nothing else, the formulas the game engine uses for the HUD element placement and scaling can be reverse engineered.

User avatar
blue_max
XWAU Member
Posts: 2295
Joined: Wed Mar 20, 2019 5:12 am

Post by blue_max » Sun Aug 04, 2019 5:25 am

This is why it's great to listen to other people's ideas. Thanks for your input, Trev. Yes, it's going to suck for some people right now because they'll have to write down a bunch of coordinates on their own; but we're still in the beta stage. Hard-coding coordinates (I see a "77" in there, for instance) may not work because there are many possible configurations out there (there's people with extra-wide FOVs that span 3 screens, for instance). However, you guys have forced me to reconsider how I'm doing this right now.

In the first implementation, whenever I saw a HUD texture, I would walk the IndexBuffer and use it to compute the min/max coordinates of the texture. These coordinates are in XWA's internal resolution, though. So they had to be transformed to screen coordinates. That avoids hard-coding coordinates in the code; but then the problem is that the dimensions of these textures are all powers of two, so they overlap each other. For instance the laser charge overlaps the targeting computer, and then I had to hard-code stuff to avoid this, which doesn't work very well for all resolutions, and I was defeating the original purpose of the algorithm anwyay -- which was to avoid hard-coding stuff in the code. So I dropped that and switched the responsibility to the user: no more hard-coding things; but now there are a bunch of coordinates to write down for each resolution.

So, I think what I can do is specify coordinates in a way that is scale-invariant: instead of specifying pixels, I can specify coordinates relative to the texture's size in the range [0..1] -- just as if they were uv coordinates. Maybe that'll work for all resolutions and we can move on... It might just work... I'll try that later. I think it's time to write down the instructions and release a new version, though.

User avatar
blue_max
XWAU Member
Posts: 2295
Joined: Wed Mar 20, 2019 5:12 am

Post by blue_max » Sun Aug 04, 2019 5:36 am

Alright, this all begins with a screenshot. I'm going to use my setup which is 3240x2160 screen res, 1280x1024 in-game res and PreserveAspectRatio = 1. Here's how my screen looks like normally:

https://www.dropbox.com/s/1tr44z3jbvso4 ... 0.jpg?dl=0

The only thing that matters about the screenshot above is the HUD. We'll be using coordinates that make sense with respect to the previous image.

The next thing is to identify the texture that you want to work on. For this example we'll be mapping the left radar to the X-Wing cockpit. I'm using XwaOptEditor to open FlightModels\XWingCockpit.opt. Browse the textures until you find the one you want to modify and write down the texture's name and dimensions. For this example, we'll be modifying TEX00096:
TEX00096.png
You do not have the required permissions to view the files attached to this post.

User avatar
blue_max
XWAU Member
Posts: 2295
Joined: Wed Mar 20, 2019 5:12 am

Post by blue_max » Sun Aug 04, 2019 5:39 am

Use your favorite image editor and convert the image to 32-bit RGB. Then punch a few transparency holes in it. These holes will show the HUD elements later on:
x-wing-left-radar-cover.png
Here I've made holes for the left radar and the ELS recharge rate. Export this file to PNG and use a sensible name. We'll use this name later.
You do not have the required permissions to view the files attached to this post.

User avatar
blue_max
XWAU Member
Posts: 2295
Joined: Wed Mar 20, 2019 5:12 am

Post by blue_max » Sun Aug 04, 2019 5:59 am

Now go back to the screenshot with the HUD and write down the coordinates for the radar, in pixels. Here I'm using Photoshop's ruler and guides to find the coordinates I'm interested in:

DC-coordinates-sample.jpg

These are the source coordinates. Now do the same for the cover texture:

coords_in_cover_texture.png

and write down the destination coordinates. We put all this together in the dynamic_cockpit.cfg file in a section that looks like this:

Code: Select all

; Left Radar and Energy Recharge Levels
[XwingCockpit.opt,TEX00096]
cover_texture = DynamicCockpit\x-wing-left-radar-cover.png
uv_coords  = 3240,2160, 327,0, 675,347;      256,256, 40,28, 98,111; 0x0 ; Left radar
uv_coords has the form:

Code: Select all

source-width,height, source-(x0,y0,x1,y1); dest-width,height, dest-(x0,y0,x1,y1); BackgroundColor 
Background color is specified in hex in RRGGBB and it's optional.
You do not have the required permissions to view the files attached to this post.

User avatar
blue_max
XWAU Member
Posts: 2295
Joined: Wed Mar 20, 2019 5:12 am

Post by blue_max » Sun Aug 04, 2019 6:12 am

Repeat the process above to put whatever you want in the transparency holes. You can put a maximum of 8 uv_coords per texture, though.

To erase pieces of the HUD, you can add an "erase_coords" tag which as the same format except it only has source coordinates:

Code: Select all

erase_coords = 3240,2160, 260,0, 700,360
You can erase whatever you want; but it usually makes sense to erase the stuff you just copied. Again, a maximum of 8 erase_coords is allowed right now.

The source coordinates must be top-left, bottom right. In other words, for source coordinates, x0 < x1 and y0 < y1. Always.

For destination coordinates, you can flip the order to mirror the element. Sometimes you'll *have* to mirror it because the textures are mapped upside down in some cockpits. You can also stretch each axis independently too. Sometimes you'll have to do that to compensate for the different aspect ratio between the HUD and the cover texture. There's a little trial-and-error here, so I've added the option to press Ctrl+Alt+L to reload the settings at run-time so you can see your changes without exiting XWA. However, if you add a new cover texture or a new section, you'll have to quit the current mission and reload it (because that's when XWA loads textures). However, you *don't* have to restart XWA at all

The cover_texture is a relative path with respect to the installation path of XWA; but I guess you can also write an absolute path in there if it makes sense to you.
The cover_texture is optional: if it's not specified, then the whole source texture is replaced by the HUD element. Sometimes this works very well for the targeting computer.

Anyway, here's the whole section for this cover texture:

Code: Select all

; Left Radar and Energy Recharge Levels
[XwingCockpit.opt,TEX00096]
cover_texture = DynamicCockpit\x-wing-left-radar-cover.png
uv_coords  = 3240,2160, 327,0, 675,347;      256,256, 40,28, 98,111; 0x0 ; Left radar
uv_coords  = 3240,2160, 271,0, 289,171;      256,256, 220,11, 228,78 ; Laser recharge rate
uv_coords  = 3240,2160, 271,174, 289,341;    256,256, 229,11, 236,78 ; Shield recharge rate
uv_coords  = 3240,2160, 2948,0, 2971,171;    256,256, 237,11, 245,78 ; Engine recharge rate
erase_coords = 3240,2160, 260,0, 700,360
And that's how it works right now. If you change your screen resolution, your in-game resolution or the PreserveAspectRatio, chances are you'll need to repeat the process since the HUD will change.

I know there's a lot of tweaking at the moment; but maybe we'll be able to get rid of a bunch of things in the near future.

User avatar
blue_max
XWAU Member
Posts: 2295
Joined: Wed Mar 20, 2019 5:12 am

Post by blue_max » Sun Aug 04, 2019 6:33 am

And here's release 1.0.2 so that you guys can try this out by yourselves:

https://www.dropbox.com/s/ruht23311evt1 ... 2.zip?dl=0

I'm asking for permission to release the fixed version of the Assault Gunboat. I'll post those files later.

EDIT: Here's the updated Assault Gunboat cockpit: https://www.dropbox.com/s/rvbkkhmgkkf9k ... C.zip?dl=0

User avatar
Trevor
Lieutenant JG
Posts: 541
Joined: Thu Dec 04, 2014 7:11 pm

Post by Trevor » Sun Aug 04, 2019 8:25 pm

So, you mention the 77.
this is an "original" offset in px from dead-center for the reticle - and under normal conditions (looking straight ahead) its always 77 before scaling.
HOWEVER... the reticle is a bad example since it is NOT fixed to screen, but to forward, but that's another problem for later.

All the calculations (can be modified to be outside the struct I think) are Resolution Agnostic - they don't move relative to their anchorages.

All HUD elements are based on a 640x480 screen.
All HUD elements are anchored to the 4 corners of the screen and center top and center bottom
ALL HUD elements are texture size * HUD Scale.

finally the screen resolution can determine a final scale to cut from by scale = screenheight /480
so the radar is always 109x92 * hudscale * screenscale no matter what resolution you use
and is always anchored top left again, no matter what res you use - although you bring up "preserveaspectratio", so its another calculation, anchor1.top = 0,
anchor1.left = (screen.width-game.width)/2 (presumabley for preserve to work game res must be known)

hope all this helps, I really would love to see a simplified config come out of this for selecting HUD elements.

Trev

User avatar
keiranhalcyon7
Lieutenant JG
Posts: 599
Joined: Tue Jan 02, 2018 6:41 am

Post by keiranhalcyon7 » Sun Aug 04, 2019 9:20 pm

Another observation is that source coordinates are independent of the craft. So while destination coordinates need to eventually go into ship ini files, the source coordinates can go into a global file.

It's a good tutorial, though, for the current version.

User avatar
Trevor
Lieutenant JG
Posts: 541
Joined: Thu Dec 04, 2014 7:11 pm

Post by Trevor » Sun Aug 04, 2019 10:31 pm

Exactly, which would make proposal 3 the most logical end goal with a common list of Elements to choose from.
That leaves only the destination up to craft designers (who would presumably be more used to uv co-ords* - allowing future hi-res textures to replace current ones) and allows anyone to download any craft without further altering.

* Just thought of something, since the destination is currently a rectangle, how would you map to a 3d instrument of circular shape?
does your code modify the texture in memory before the 3d elements read it?

Trev

User avatar
keiranhalcyon7
Lieutenant JG
Posts: 599
Joined: Tue Jan 02, 2018 6:41 am

Post by keiranhalcyon7 » Sun Aug 04, 2019 10:41 pm

Trev, that's part of why there's a cover texture. The round transparent region of the cover texture allows the round instrument to be seen while masking away the corners of the rectangular HUD capture.

Question for blue_max: I noticed your erase coords there have three coordinate pairs. Doesn't it need to be an even number of coordinate pairs, to create an integer number of erase rectangles?

User avatar
blue_max
XWAU Member
Posts: 2295
Joined: Wed Mar 20, 2019 5:12 am

Post by blue_max » Mon Aug 05, 2019 6:47 pm

Well, I'm not sure that XWA always renders the HUD at 640x480. Maybe; but in any case I don't know where to read the HUD scale. But I see your point guys: we can predict where the HUD will land using formulas. If we can do that for in-game coordinates, I can translate that to actual screen coords. So if you figure that out, let me know. BTW, all textures are powers-of-two, so even if a texture is 109x92 in the DAT file that doesn't mean XWA will use that resolution, it will jump to 128x128 which is what I actually see in ddraw.

Round geometry is not a problem. In fact, if the element is surrounded by round geometry we sometimes don't even need a cover texture. The A-Wing cockpit has three examples of that.

There's 3 pairs of coords in erase_coords because the first pair is the screen resolution. I know, lots of repetition everywhere :P

Anyway, yesterday I was looking at this problem again and it looks like I found a way to solve it without formulas and it's resolution-independent. There's one more invariant that I hadn't noticed: the HUD textures are always loaded at the same power-of-two size (although this size is usually different from the texture size as stored in the DAT). Coordinates can be specified in that space and then they can be translated to screen coordinates. Yes, I got this idea from reading and thinking about your comment, so thanks for that. I need to do more testing; but it looks like we may be able to remove a bunch of stuff soon. Yes, having one global CFG for the sources and one per-craft file for the destination makes sense. I'll try to steer the project in that direction.

User avatar
keiranhalcyon7
Lieutenant JG
Posts: 599
Joined: Tue Jan 02, 2018 6:41 am

Post by keiranhalcyon7 » Mon Aug 05, 2019 7:32 pm

blue_max wrote:
Mon Aug 05, 2019 6:47 pm
There's 3 pairs of coords in erase_coords because the first pair is the screen resolution. I know, lots of repetition everywhere :P
I see. Screen resolution is also common among all the elements where it's being specified, so it could be separated out into its own value, which could then be deprecated once the auto-detection is working.

User avatar
Trevor
Lieutenant JG
Posts: 541
Joined: Thu Dec 04, 2014 7:11 pm

Post by Trevor » Mon Aug 05, 2019 7:38 pm

Reading hudscale is done in hook_resolution
Jeremy returns an int of a string (why?) of format [Index + width + "x" + height + "HUD:" + hudscale]

Code: Select all

stream << screenIndex << ": ";
	stream << width << " x " << height;
	stream << " HUD: ";
	stream << std::fixed << std::setprecision(2) << hudScale;
	g_screenResolution = stream.str();
	return (int)g_screenResolution.c_str();
I also noticed in the d3d source that "if (g_config.AspectRatioPreserved" uses a backbufferwidth and width, so I assume width is "game width" and backbuffer is screenwidth
failing that, the string above has the game width to calculate the anchorages'.

Also, my statement about 640x480 is slightly misleading.
it was in support of fixed offsets from floating anchors.
what I should have done was
78/480 = 0.1625
so "dead center" is actually 0.5, 0.3375 (assuming origin is top left else y = 0.6625)

Trev

User avatar
JeremyaFr
XWAU Member
Posts: 3921
Joined: Mon Jan 18, 2010 5:52 pm
Contact:

Post by JeremyaFr » Mon Aug 05, 2019 8:23 pm

The HUD scale is stored in a variable at address 0x006002B8 as a float.

User avatar
blue_max
XWAU Member
Posts: 2295
Joined: Wed Mar 20, 2019 5:12 am

Post by blue_max » Mon Aug 05, 2019 8:52 pm

Thanks for the exact offset Jeremy. OK, so I think I can read HUD_scale now.

"width" has a number of meanings. It can refer to the in-game resolution width, or the backbuffer width (which I think it's the actual screen resolution) or it can refer to a value that is computed at run-time by ddraw to properly scale betwee in-game resolution and screen resolution. This latter also depends on PreserveAspectRatio as you pointed out, Trevor. I think this is the "width" you're talking about here.

So, anyway, I'm a bit mystified about all those numbers you're providing, Trevor. Can you elaborate a little bit? What formulas are you using?

User avatar
Trevor
Lieutenant JG
Posts: 541
Joined: Thu Dec 04, 2014 7:11 pm

Post by Trevor » Tue Aug 06, 2019 12:04 am

So, anyway, I'm a bit mystified about all those numbers you're providing, Trevor. Can you elaborate a little bit? What formulas are you using?
ok, so just quickly, if we wanted to find the targeting reticle position and size we could have an object/struct with

Code: Select all

width = 64
height = 64 //I know you said your presented with a square texture, but perhaps this can be worked out later, at the moment I'll use the DAT value
anchor-x = 0.5
anchor-y = 0.3375 
x = 0 - width/2
y = 0 - height/2
then to use it, read the hudscale, the ingame resolution and the screen resolution

Code: Select all

 blackbarw =0
 blackbarh =0
ScreenResGameResMultiplier = (screenheight / gameheight) //assuming aspect = or wider but not taller (i.e. no black bars top+bottom) need additional test fpor this
if wider
    blackbarw = ((screenwidth-gamewidth)/2) 
elseif taller
    blackbarh = ((screenheight-gameheight)/2) 


readwidth = reticle.width * hudscale * ScreenResGameResMultiplier 
readheight = reticle.height * hudscale * ScreenResGameResMultiplier 
if preserve then
readx = (reticle.anchor-x * gamewidth) * ScreenResGameResMultiplier + blackbarw + (reticle.x * hudscale)*ScreenResGameResMultiplier 
ready = (reticle.anchor-y * gameheight) *ScreenResGameResMultiplier  + blackbarh + (reticle.y * hudscale)*ScreenResGameResMultiplier 
this should result in reading a square in the center of the screen
if game res was 640x480 and screenres was 1280x960 this should read a 128x128 {64*(960/480)} square starting at 576 {640-(128/2)} and 260 {324-(128/2)}

hope this helps, Im off to bed, I hope the formula makes snese, might have to re-work it but hopefully you get the idea

Trev

User avatar
keiranhalcyon7
Lieutenant JG
Posts: 599
Joined: Tue Jan 02, 2018 6:41 am

Post by keiranhalcyon7 » Tue Aug 06, 2019 12:58 am

... I don't think that helped.

Look, at some point the game should be providing ddraw with a HUD overlay at game resolution for ddraw to scale up to screen resolution, taking preserveAspectRatio into account. The math is quite a bit easier if you read from the pre-scaled version, since then you don't even need to care about screen res or preserveAspectRatio; only the game resolution and hud scale matter.

User avatar
blue_max
XWAU Member
Posts: 2295
Joined: Wed Mar 20, 2019 5:12 am

Post by blue_max » Tue Aug 06, 2019 9:48 pm

Alright, I think I understand what you're proposing now, Trevor. I think it probably would work. In fact, I think we're more-or-less doing the same thing; but you're using the screen as a reference frame + formulas to compute the locations, whereas I'm using individual textures and pixel coordinates. I think each approach has its own merits.

Good news is that I've got something that seems to work now. I was able to map the radars and ELS on the X-Wing cockpit across multiple resolutions. This also reduces the number of coordinates that we have to use and yes, at some point, we could split this into "global source coordinates" and per-craft data. Thanks for your ideas guys.

I've got a bit of trouble mapping the laser energy levels though. AFAIK, there's 3 types of laser displays:

* Quad lasers, like in the X-Wing, Y-Wing and TIE-Interceptor
* Dual lasers, like A-Wing, TIE-Fighter, etc
* Six lasers, like the B-Wing

Does anyone know if there's another laser energy layout that I would have to map?

Bman
Lieutenant Commander
Posts: 1167
Joined: Mon Apr 05, 2004 11:01 pm

Post by Bman » Tue Aug 06, 2019 11:03 pm

Ion cannons. Well it also depends on how many laser hardpoints are on the model and how they are utilized / mapped in .exe. The table in .exe will usually trump how the laser hardpoints behave in-game. In the example of the Shuttle.opt I posted the previous week, if you have 5, 6, 7, 8 or more front "EmpireLaser" hardpoints for example, it can break the engine. Meaning the laser energy bars won't display, or not display properly. Or if you assign more powerful laser hardpoint like type 288 and higher. The E-Wing for example or the Moldly Crow--an even better example with it's multiple front lasers. If someone can figure out how to get the engine to allow for more laser energy bars to represent what's present on the model or maybe bind multiples of 2 or 4 pairs of lasers to at least one energy bar display (left and right side), that would allow for some really creative setups. Does that make sense?
W-I-P: TFTC, MC Viscount Cr., ISD-II Avenger, NL-1 Platform, Ton-Falk Esc. Cr., & Misc.

Post Reply