Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Familiar on January 20, 2014, 02:43:24 am
-
Hi to all.
This is my very first post on Hard Light, so ... may be it should go to other section or ...
Anyway, I'll start with offtopic as any newbie should:
[off]
First of all, I would like to say "Thank you guys and keep up doing this great stuff to Freespace"
Thanks to all coders modders actors. Somehow I missed whole Freespace universe and FCP based games.
This is actualy very strange, because I'm long time fan of X3, Tarr: Cronicles, Homeworld 1|2, Nexus Jupiter Accident, ot of 4X games
Started with Elite on ZX Spectum, I'm addicted to space games.
Honestly I came here with a little help of WCS (missed that whole WC universe too... :banghead:)
May be it because I never had a joystick and never look closely into spacesim with intense dogfighting.
But now I'm a happy owner of HOTAS kit (Cobra M5 + Gametrix Engine Control System) and it's time to fly space.
Now finished Wing Commander Saga (Great stuff except mission design flaw 25-45 minutes without checkpoints is really awful because I have real life as well. With all respect to hardcore gaming I cannnot invest so lot of time in gaming, so I played at easy, on some missions very easy - not satisfying my ego ;) )
Just finished FSport with MediaVPS 2014, and aiming for Silent Treat : Reborn
In general it's amazing how much love and tenderness was put into this game by community. I thought X Universe community is most dedicated but, now I see... ;)
So again, thank you thank you. So long Freespace Source Project is best space dogfighting game. And looks like it will be further, despite the fact Star Citizen (I'm pretty sceptical about it honestly - too much bla bla and fan hype around it; yet to respect their ability to sell pixels) is coming and Elite: Dangerous (Alpha dogfight looks very intersteng, and I want to beleive that legendary Elite will be cool).
[/off]
I have not found any suggestions topic to engine features, so :
Would be great to have all this animated hangars, briefings unstreched on 16:9 monitors.
Widescreen became a standart in monitor long time ago, so this feature will be apreciated by a lot people.
All this wonderful art (menus, briefing) doesn't looks so cool streched.
I'm not sure about how hard to implement, but I suggest option in launcher:
- preserve 4:3 aspect ratio in menus, techroom, campaign
as result, istead of ugly streched
(https://dl.dropboxusercontent.com/u/18265894/Freespace/aspect/stretched.png)
will be nice pic with aspect ratio maintened
(https://dl.dropboxusercontent.com/u/18265894/Freespace/aspect/fixed.png)
And different mod could use different wallpapers for behind (took some random stars just for example)
Again, I have only WCS on my laptop, so post just it for example.
As result Freespace game will get nice and modern look.
Apreciate your opinion on that.
-
Yeah, it would be awesome to change the mainhalls so that 4:3 is not stretched, and to also support 16:9 (and other aspect ratios) in the mainhall. All we need is a coder with some spare time and the drive to implement it :)
-
For what it's worth, I've tried to look into it a couple of times and the problem as far as I've been able to tell is that the stretching happens at a really low level in the graphics pipeline. I didn't figure out any convenient way to make the interfaces draw themselves to only part of the screen, so I'm afraid it'll need some serious work in order to fix.
I've actually written a de-stretching script which works... except for model renderings (tech room, loadout, etc) which get completely screwed up. :sigh:
-
I completely agree with this. While I must say "Hats off" to the moders that fixed the HUD stretching issue for those of us on triple monitors, trying to navigate the in the lobby and tech rooms on nvidia surround 5760x1080 is down right terrifying and almost impossible. Instead of fixing the stretching at a low coding level, might it be possible to simply have two resolutions (loby and in-ship) and have the game trigger between the two when needed?
-
No sugestion...
just a prairie
please,please a mod with hangars and rooms adapted to triple screens res (example 3840 x 1028)
-
I'm still experiencing this lately. We should probably have to revamp the interface code which we are looking to it right now. This includes making the interface adaptable to every resolution, the Interface.tbl table, the use of SWF menus and other eye-candy found in modern computer and video games, and extensive keyboard/gamepad support.
-
I'm still experiencing this lately. We should probably have to revamp the interface code which we are looking to it right now. This includes making the interface adaptable to every resolution, the Interface.tbl table, the use of SWF menus and other eye-candy found in modern computer and video games, and extensive keyboard/gamepad support.
Who's "we"? Are you a coder now?
-
... the use of SWF menus ....
nooooooooooooooooooooooo! We're constantly patching that damn software at work to fix its multitude of security flaws, and its Linux support is subpar :(
-
This behavior should be easily chosen from your graphics control panel. Attached is a screenshot of how to do it with NVIDIA. Notice the black bars to the left and right of the thumbnail.
[attachment deleted by an evil time traveler]
-
This behavior should be easily chosen from your graphics control panel. Attached is a screenshot of how to do it with NVIDIA. Notice the black bars to the left and right of the thumbnail.
...which does not work in this case because the game is stretching the interface to a widescreen resolution. The black bars need to be added by FSO, not the graphics driver.
-
Well, I left out a step: when launching FSO, set the resolution to the largest 4:3 ratio that will fit within the widescreen resolution.
It does work; I've used the same technique myself.
-
Well, I left out a step: when launching FSO, set the resolution to the largest 4:3 ratio that will fit within the widescreen resolution.
It does work; I've used the same technique myself.
True, it does work if you play in a 4:3 ratio. I thought you were referring to playing in a widescreen resolution; that's what this thread is about, after all.
-
...Ok. I misinterpreted it as wanting to play with a 4:3 ratio while on a widescreen monitor. Yes, if you want to use 4:3 in the menus and widescreen in the mission, there is currently no solution.
-
Would that be possible to at least allow different variants of the interface art to be loaded depending on resolution? You could have dedicated 4:3, 16:9 and 16:10 graphics and ship them with the mod. That would probably bloat the VPs quite a bit, and require quite a bit of work on the mod's side, but it's a better solution than what we have now. Extreme and unusual aspects would still have a problem, but that would fix it for the majority. The code could probably be based on current mission-based mainhall switching.
-
The code could probably be based on current mission-based mainhall switching.
Err... not really. The mainhall switching code is separate to the code that manages the two supported interface resolutions (640x480 & 1024x768).
-
I am a coder, and "we" refers to the SCP team. I think the interface code should be rewritten to allow support for non-4:3 resolutions and interface.tbl.
-
I am a coder, and "we" refers to the SCP team. I think the interface code should be rewritten to allow support for non-4:3 resolutions and interface.tbl.
Great! Looking forward to your patches then. (Friendly tip though: You should only use "we" when talking about a group you actually are a member of. You're not a member of the SCP, and posting as you did may confuse people regarding what they can expect)
-
I am a coder, and "we" refers to the SCP team. I think the interface code should be rewritten to allow support for non-4:3 resolutions and interface.tbl.
Heh, looks like Bryan See is the boss of SCP team :D
At least his posts all look like.... :lol:
-
Actually, I am looking into the problem. I'd like a solution. Others may think of others if you wish.
-
May I ask, what is your experience with C/C++?
-
The code could probably be based on current mission-based mainhall switching.
Err... not really. The mainhall switching code is separate to the code that manages the two supported interface resolutions (640x480 & 1024x768).
Ah, so in that case, why not expand the code that supports those two? TBH, I totally forgot it was there besides the mainhall, but FSO already has (and had since retail) a way of supporting two different resolutions, for all interface bitmaps. While three aspect ratios would be needed to cover everything, there is some sort of code in there that perhaps could handle it.
Though on the other hand, we did have it since retail, and I don't think it was touched since then. This tends to mark Codethluthu lairs, from what I've gathered. :) Still, I suppose some of that code might be of use. Eh, I wish I knew more about "proper" languages, not only Mathematica and LaTeX. If I make it through those exams somehow, it's possible that I'll have some sort of course in C during my second year. Maybe then I'll be able to help more with it.
-
There are two layers to the interface issue. You are talking about the frontend one, the one that decides what to show the player.
The issue with interface scaling however lies on the backend layer, the one that decides how something will be shown. Something that controls behaviour in one layer should not interact with anything on the other; the two should be as separated as possible.
-
To be honest, I'd rather see us move to a system where we simply use a table to decide where the hotspot areas are, rather than the archaic method we use now. I've been looking at rewriting the loadout code but I find my work heavily constrained by the fact that I have to support the old system.
What we'd need would be
1) A default table (based on FS2's default layout)
2) A way to parse other layouts from the image they use to the newer table format (to support older mods and TCs)
the advantage of a table system is that you'd only need a few layouts (4:3, 16:9, etc) to support everyone. It would also be analogous to current way we handle HUD layout so it would make an easier learning curve for new modders.
I've been seriously tempted to write such a system (cause of the loadout issues) but it would probably be better coming from someone more familiar with the graphics code.
-
May I ask, what is your experience with C/C++?
My experience with C++ is from several institutions e.g. Tunku Abdul Brahman College and Universiti Putra Malaysia, and more than a decade ago. I agree with karajoma that the load out system should be reworked.
-
There are very few parts of the engine that shouldn't be rewritten. The issue is what is a priority and what can we live with for now.
My issue with the loadout screen is that it's been the source of a large number of bugs over the years and that it's very restrictive in what it allows. The only reason I haven't completely rewritten it already is that it would require the changes I mentioned to snazzyUI.
-
Then you strongly propose rewritting the loadout screen, as well as the fix of wide screen aspect ratio in briefings, tech room and so on.
-
Well, after having personally handled the new HUD code pre Yarn's patches and then also working with the new HUD code post Yarn's patches... I would prefer not to have to write tables for every resolution ever. I did that with the HUDs and it was a PITA anytime I wanted to make a change that affected the HUD.
I fully realize it's more of a complaint than a logical argument. I'm mostly saying that I'd like to make conversation to see if we would be able to find a better way that to have to table Interfaces for every (or most) resolutions.
-
Theoretically couldn't one develop a system that used relative coordinates, so that you'd only have to make separate tables for each aspect ratio instead of resolution? From what I can tell that's how Yarn's updated HUD code handles things. (I say this realizing it'd probably be a massive pain in the ass to do so for the interface, though.)
-
Yarn's HUD code doesn't even require Widescreen vs Fullscreen designation for all but the most fringe cases, as I recall from when I setup MediaVPs 2014 and BtA.
-
Yeah, I think that if this is going to happen, we're going to implement it in such a way that the amount of duplicate definitions needed is drastically reduced. Like this, for example:
$Button
$Coords: (x, y) ;;default coordinates if no matching ones for the current aspect ratio can be found
+Aspect Ratio: 16:9
+Coords: (x, y)
+Aspect Ratio: 4:3
+Coords: (x, y)
$Action: some_action
$Default Image: awsmbutton.png
$MouseOver Image: awsmbutton_hi.eff
$MouseClick Image: awsmbutton_cl.png
I know that Yarn's hud rewrite doesn't require this dance, but there may be points where it would be benefitial to have the ability to define something like this for the interface. Alternatively, we could just let the tabler set an aspect ratio globally for his interface, and then just apply scale-to-fit.
Point is, there's a bunch of options we could pursue, but I think the overriding concern will always be to hide as much complexity as possible.
-
I think doing it by aspect ratio would be the most sensible way to solve the problem. I was under the impression the HUD fix did that. If not, why not?
-
The first HUD fix did need aspect ratios to be defined. After Yarns patches, you define positions by screen percent rather than pixel location and the code does its best to place them on all aspect ratios based on the percentage. You can certainly be more accurate by creating HUDs for each aspect, but its not required anymore.
-
Do you think something like that would work for the rest of the interface?
-
Honestly, I can't really answer that question. I have no idea what kind of crazy math goes on in the background with Yarn's HUD patches. As a modder, I would hope so.. because I've experienced first hand what it's like to keep up with lots of duplicate table entries for different resolutions. I don't necessarily look forward to that for something even more complicated, like the Interface.
However, I will say if it were between having to deal with duplicate entries or no upgrades at all.. I'd root for the former.
-
I've been experimenting a bit and finished a (simple) implementation of an unstretched interface.
For every element you can specify the distance to the top, right, bottom and left edge (in relation to its parent). If you want to have a button appear at the lower right, you can set bottom and right to 0. If you want an element to appear at (10, 20) you have to set left to 10 and top to 20. You can set pixel values or percentages (which are relative to the parent element's size).
Right now I've implemented four kinds of elements: Box, Text, Image and Button.
A box can have a background color, border and a fixed size.
A text element displays text. You can set a fixed width which will make the text wrap or let the engine calculate the width (and height) of the text content. You can also change the text font and color.
An image element displays an image (duh!) and can be stretched.
A button has three images: normal, hover and clicked (it can also be stretched).
All settings are optional but every element has to have at least two coordinates.
A simple screen with a background, a logo, a button and some text would look like this:
#Interface Start
$Name: Example_Screen
[
$Image: background_image
+Stretch
+Top: 0
+Right: 0
+Bottom: 0
+Left: 0
[
$Image: logo
+Top: 10
+CenterX
$Text: I'm an example text to demonstrate this...
+Top: 10%
+Left: 20
+Right: 20
$Box
+Autosize
+Bottom: 0
+Right: 0
[
$Text: Commit
+Top: 0
+Left: 0
$Button
+Top: 10
+Left: 0
+Image: accept-normal
+HoverImage: accept-hover
+ClickImage: accept-click
]
]
]
#Interface End
(http://i.imgur.com/IJEWHXU.png)
NOTE: I used the multiplayer symbol as the logo, the fictionviewer as background (that's why there seem to be two buttons).
"+Autosize" means the engine calculates the box's size itself (I guess I should make that the default when only two coordinates and no fixed size are given.).
"+CenterX" and "+CenterY" center an element along the X or Y axis.
The hover and click effects for the button already work. What do you think so far? Is the table format too complex?
-
This is pretty cool.
And also slightly distressing! I was making my own LUA UI stuff for interfaces and stuff and then you come in with this. :P
(Still this is very awesome and I wish to see more! MORE!)
-
This sort of thing should definitely be handled by the engine rather than lua though. It's one thing for something like the mainhall, but something like loadout would be incredibly complicated to handle via scripting.
-
Oh I totally agree. Native code is always better than hackish scripting trying to emulate native code.
-
Well in the case of the loadout, I don't think it would even be possible. So much is hardcoded there.
Which is why I'm very interested in ngld's changes.
-
I added text boxes, transparent colors (alphacolor) and animations.
(http://i.imgur.com/uGmvkpf.png)
The code is now on github (https://github.com/ngld/fs2open.github.com). The important parts are in code/menuui/tblui.cpp (https://github.com/ngld/fs2open.github.com/blob/tblui/code/menuui/tblui.cpp).
If you want to create your own ui tables, just drop them in the data/tables folder and put something like the following in scripting.tbl:
#Conditional Hooks
$State: GS_STATE_TECH_MENU
$On State Start: [
ba.readTblui("ui-test.tbl")
ba.openTblui("Example")
]
#End
EDIT: Added tags to the text renderer. Now you can write i.e. "This is {blue}some blue text{/blue}." or "This is {color #00000}black text{/color}.". I also added a a {font ...} tag.
-
Back to the original topic: I managed to implement this feature for the preload screen, the pilot selection, and the main halls, and it seems to work beautifully! I also added a new command-line parameter, -stretch_menu, for players who prefer the stretched interface. The patch is below. If it looks good to you guys, I'll go ahead and implement this for the rest of the interface.
(Yes, I'm aware that most of the screens don't display properly without -stretch_menu. This is just meant to test the three screens mentioned above.)
(Old code removed; see below (http://www.hard-light.net/forums/index.php?topic=86617.msg1740803#msg1740803) for the most recent patch.)
-
I'm so glad to see you guys actually are working on it!
Any hope for test build to test?
-
Awesome. :yes:
-
ngld: While I appreciate your work, at this time, I can not accept it into the engine. There are two issues with it that I would like to see addressed in subsequent versions:
1. It does not adhere to the design patterns established by other table parsers. Take the HUD gauge parser as an example for how to write one that does conform to the patterns used elsewhere while still incorporating OOP design principles.
2. The issue of how to hook up the UI code with the "business" code needs to be addressed.
Also, be aware that m!m is currently working on incorporating Chromium/Awesomium as an interface renderer, and already a good way into it. Maybe it would be a good idea for you two to work together on this, before we get too far into duplicated efforts.
-
Oooh yeah, loving it :) :yes:
(taken from a 1600x900 window)
(http://i.imgur.com/7l9VnF6.jpg)
(I'll have to look through the code next)
Any hope for test build to test?
As Yarn mentioned this only covers three of the menus, the rest are... kinda wonky. i.e. the mouse action masks don't match the images making navigating around a bit tricky. I think a build would be more appropriate once all the menus are done.
-
I made more progress on my patch. All the single-player stuff
(save for the fish tank) should be stretch-free now. As a bonus, the in-game debug info doesn't stretch anymore. Here's the patch and a Windows build:
Patch (https://dl.dropboxusercontent.com/u/89353583/FreeSpace/Patches/Interface_stretch_fix.patch) (It's too big to fit in this post.)
Windows build (https://dl.dropboxusercontent.com/u/89353583/FreeSpace/Patches/Interface_stretch_fix_build.zip) (based on revision 10531)
(In case you don't know what I mean by "fish tank," I'm talking about the fish that appear when you enter vasudanswuvfishes at the Vasudan main hall.)
EDIT: The patch and builds have been updated; see this post (http://www.hard-light.net/forums/index.php?topic=86617.msg1740943#msg1740943) for notes.
-
Could there also be some sort of knowing which mode we're in through lua? Because I made this interface (http://www.hard-light.net/forums/index.php?topic=86881.msg1736241#msg1736241) screen and its meant to take up the full screen no matter what. So some sort of true/false thing would help me account for that. Or some kind of scaled coordinates function (which actually might be better).
-
Could there also be some sort of knowing which mode we're in through lua? Because I made this interface (http://www.hard-light.net/forums/index.php?topic=86881.msg1736241#msg1736241) screen and its meant to take up the full screen no matter what. So some sort of true/false thing would help me account for that. Or some kind of scaled coordinates function (which actually might be better).
If you can provide me with your code, I'll take a look at it and see what I can do.
-
Well, there is no "code", its a lua script.
When I need to account for coordinates being scaled, I have my own lua function that does that.
function AXUI:ScaleCoord(c, xy, base_x, base_y)
--A dumb function that will scale coordinates from a base resolution. Usually base_x and _y are 1024 and 786.
--c is the coordinate we want to scale
--xy = 0 returns the scaled x coord
--xy = 1 returns the scaled y coord
if c ~= nil then
local x_factor = self.Screen.w / base_x
local y_factor = self.Screen.h / base_y
local result = c
if xy == 0 then
result = result * x_factor
elseif xy == 1 then
result = result * y_factor
end
return result
end
end
(Man, I should really rewrite that function, but you get the picture)
To me (though I haven't tried it yet), the interface images aren't starting at 0,0 now, which parts of my script are assuming.
-
Actually, I was hoping that you would also provide an interface screen that uses that function. I have never used or done anything with Lua before, and I really don't feel like learning Lua just to make a new interface screen for testing, so I need you or someone else to give me a functional screen, even if it's simple. I should be able to figure things out from there.
-
Oh sure.
This is the Script, still in a sort of beta state (No one else use it yet please!)
http://lazymodders.fsmods.net/files/Journal.rar
Its in its own mod folder, go to the barracks to activate the journal. Note that the journal screen ISN'T the barracks screen, it immediately skips to GS_STATE_SCRIPTING when you go to the Barracks screen from the mainhall.
-
Tried out Yarn's patch and works fine with me. Outstanding work! I can only hope that this fix should be committed to trunk, and the loadout screen should be cleaned from the source of bugs in FSO... :)
-
It is highly likely that this will be committed when it is completed and reviewed.
Fixing bugs in FSO is something we like to see, it would be great to see you submit some patches for bugs either in the loadout screen, or for any of the bugs in mantis (http://scp.indiegames.us/mantis/my_view_page.php).
-
Windows build (https://dl.dropboxusercontent.com/u/89353583/FreeSpace/Patches/Interface_stretch_fix_build.zip) (based on revision 10496)
You are the God amongst men!!!
-
First the adaptable HUD and now the menus?! Yarn, you are now officially my FSO hero :)
Patch is working mighty fine for me, good job :yes: :yes:
-
me gusta. so much gusta.
-
This needs to be behind an option or flag somewhere. I much prefer stretched menus to black border bars. Not only that, but this build kills any sort of animorphic stuff I've been toying and trying with for mainhalls.
-
... I also added a new command-line parameter, -stretch_menu, for players who prefer the stretched interface.
:D
-
Well I should read, then shouldn't I?
-
I updated the patch and build. All of the regular menus and HUD elements not definable in hud_gauges.tbl should now be completely free of stretching. Here are the notes for this version:
- I haven't been able to fully test all of the multiplayer screens, and I could not test the ones that require joining a game (as opposed to creating one) or are seemingly inaccessible. However, I did my best to get these screens to work properly without being stretched.
Much of the stuff in the ui folder is untouched. The things that I left alone are either unused or used only by the Load Mission screen, which is normally inaccessible; menus using such code will stretch right now. Anything there that is used by the regular menus (to the extent that I can test them, at least) has been fixed. Update: All of this should be fixed now!- I haven't taken a good look at Lua yet, but I'm happy to say that Axem's script still appears to work as intended, complete with the background stretching.
I don't know if it's possible to stretch a Lua menu based on the -stretch_menu flag, though. Update: You can now use isMenuStretched() to determine whether the -stretch_menu flag is enabled. - Since I can't compile FRED, I have no idea if I broke anything there. I would appreciate it if someone can test it for me.
-
- I haven't taken a good look at Lua yet, but I'm happy to say that Axem's script still appears to work as intended, complete with the background stretching. I don't know if it's possible to stretch a Lua menu based on the -stretch_menu flag, though.
Wait, no! I think I didn't make it clear. Since I'm trying to emulate FreeSpace's interface system, I would want it to match how your system scales the background. If there's a non-stretched interface, I wouldn't want my interface to be stretched. The best way I could think of to do this is to get some sort of function that returns scaled interface coordinates?
-
I updated the patch and build to add a new Lua function, isMenuStretched(), which returns true if the main interface is stretched to fill the screen, and false otherwise. (Yes, I tested it; it appears to return the correct values.) If you want your script to match FS2's scaling behavior, you still need to write it in a way that does that; the game won't add the black bars for you if you don't.
-
The patch and build have been updated again. This should be ready for code review once Axem confirms that everything is good on the Lua side.
-
Yeah, the function seems to work as expected. :)
-
I was doing some testing and noticed this issue:
(http://i.imgur.com/7OdgEoa.jpg) (http://imgur.com/7OdgEoa)
It looks like it's related to this chunk of the patch.
diff --git a/code/sound/sound.cpp b/code/sound/sound.cpp
index ddb2cbf..b513401 100644
--- a/code/sound/sound.cpp
+++ b/code/sound/sound.cpp
@@ -216,7 +216,7 @@ void snd_spew_debug_info()
int interface_sounds = 0;
int done = 0;
- if(!Sound_spew){
+ if(Sound_spew){
return;
}
@@ -252,10 +252,10 @@ void snd_spew_debug_info()
// spew info
gr_set_color_fast(&Color_normal);
- gr_printf(30, 100, "Game sounds : %d\n", game_sounds);
- gr_printf(30, 110, "Interface sounds : %d\n", interface_sounds);
- gr_printf(30, 120, "Message sounds : %d\n", message_sounds);
- gr_printf(30, 130, "Total sounds : %d\n", game_sounds + interface_sounds + message_sounds);
+ gr_printf_no_resize(30, 100, "Game sounds : %d\n", game_sounds);
+ gr_printf_no_resize(30, 110, "Interface sounds : %d\n", interface_sounds);
+ gr_printf_no_resize(30, 120, "Message sounds : %d\n", message_sounds);
+ gr_printf_no_resize(30, 130, "Total sounds : %d\n", game_sounds + interface_sounds + message_sounds);
}
// ---------------------------------------------------------------------------------------
I think it can be "removed again" by reverting the 1st section, but I'm kinda confused as to why the 2nd section is outputting text inti 3D space, rather than 2D like the (e.g.) FPS counter.
-
I must have changed that if statement to test that part of the code (I couldn't, and still can't, figure out how to test it otherwise). The inclusion of that change in the patch is completely unintentional. I'll get a new patch and build up soon. (EDIT: It's uploaded now.)
As for what you experienced, I was able to reproduce it by changing only that if statement, so it appears to be unrelated to my patch (aside from that one little change). If you know how to properly enable the sound info display, perhaps try that with an unmodified build and see if the bug still occurs.
-
I finally figured out how you're supposed to make the sound info appear: Press shift+enter to enter the debug console, then enter show_sounds. I tried this with an unpatched build, and the info was still rendered in 3D space! So, my patch definitely isn't causing it.
I also noticed that the debug console was still stretched; I updated the patch and builds again to fix that. Hopefully, no more changes are needed.
-
Tried your patch, Yarn. Works best. I'd like to see this commit added to SVN as urgent, given the circumstances.
-
Okay, just to be clear here: "Urgent" are issues like "game crashes while starting FS2 retail". Or "FSO will sometimes corrupt VP files". This? This is not urgent. It's nice and good to have, but it is very emphatically not "urgent".
Nevertheless, it should be appearing in the next nightly.