[swashmebuckle]

Would it be possible to have table control over the size of the radar window?  Right now it seems to be hard coded to switch between windows that fit the stock low and high res anis based on which set of interface graphics is being used. The problem is that I am finding situations with intermediate resolutions where, due to legibility issues, I'd rather scale up the low res graphics than squeeze the high res set. 

For instance, I have a low res widescreen table based on 800x500 that scales beautifully up to 1024x576, but when I try to use it at 1024x600 or 1024x640 (resolutions where the high res interface art is used), the engine assumes I am using the high res radar gauge, so the positions of the radar blips no longer correspond to the chosen graphics.  This wouldn't be a problem if I could just cover those resolutions with a separate high res table (I do have one that's based on 1440x900), but that much compression makes things look pretty scrunched when you're using the high-res anis.

The same thing seems to happen somehow for the throttle gauge--I works fine at 800x500, but on 1024x600 the arc that the current speed indicator travels along seems to have been moved as if the larger resolution artwork was being used.  Apologies if I've screwed something up or am just ignorant of obvious fixes for these problems.

[Swifty]

I didn't open up those fields yet because I've yet to find out how the width and height variables of the radar will affect other rendering variables. I'll get to that eventually.

[swashmebuckle]

Ah, I see--thanks for the info

[Reprobator]

1: I'm really sorry for repeating my question, but as it was the last post of the previous page, i repeat it here in case it has been missed.
2: In order to fake rtt without modders having to deal with lua, would it be possible to add an option like slew but that would fix for example the radar at its desired place and that would not follow your view with the track Ir like the actual reticule does for example?

as I'm remodeling a cockpit , i was thinking about it, because if it is possible then it worth trying to Allign mfd's screen and hud etc... with the HUD.



 

[Dragon]

$Slew option, IIRC, does just that.

Also, I think I've found a bug in the new code.
Some mods make use of toparc.ani , which is included in retail code, but the ani itself is left blank.
With the new code, toparc.ani stops showing up in these mods (like ASW).

[The E]

That is not a bug. That just means that the teams responsible have to write hud_gauges.tbls to include that graphic.

[Dragon]

I don't think it should work like that. It means Antipodes 7 breaking backwards compatiblity with a retail (though originally unused) feature.

[The E]

No. If a feature was unused in retail, we can break it. It's a direct consequence of SCP rule #1 (Thou shalt not break retail). There never was a rule that we have to support every little quirk retail had that retail data didn't use. Mods can, and will, be broken occasionally.

[chief1983]

Even if you can't tell retail behaved that way, it did.  This sounds like a valid issue to me.  Is putting top arc in the default 4:3 layout a difficult task?

[The E]

Probably not, to be honest.

But to be brutally honest, it doesn't make much sense to me. It's just a weird workaround that we do not need to do, exactly, when the solution is as simple as writing a tbl. That's what the tbls are for, isn't it?

[Dragon]

If it's not difficult to include it into the default configuration, then IMO it should done.
Afterall, it originally was in default HUD, so using the new code, it should still be there.

[chief1983]

I just feel like expecting a mod that might have worked perfectly since retail, if done properly, could suddenly break because of a change to the default behavior.

[Dragon]

Indeed.
And people will complain a ton about it being broken, not all teams will make a nessesary table, and even if they do, a lot of people will miss the download, and in the end, come here (or to the project board) complaining. If we can afford not to break it, I'd recommend we don't.

[Everglide]

I've placed the Mac build FS2_Open-Inferno r6780 ANTIPODES into the mediavps_3612-6  folder

Created a two directories data/tables inside mediavps_3612-6

Copied the Table hud-hdg.tbm inside the tables directory but no luck

What am I missing? Can someone help... please 

[chief1983]

You should not be using Antipodes 7 anymore.  The HUD code is already in 3.6.14 RC5.  Use that instead.

[hurleybird]

Now if only we could get menus to scale properly, FS2 would be amazing in triple head!

[Reprobator]

agreed.
If menu stayed in its original 4/3 or 16/9 format but just centered it would be awesome.