Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Test Builds => Topic started by: Zacam on October 22, 2010, 05:08:44 pm
-
Test Builds - Antipodes 7
HUD Code by Swifty
Supercedes any HUD Overhaul test builds.
Reported Issues
'Killed by' messages no longer display
External Camera view no longer shows Messages (such as when pressing enter to rotate the ship vs camera)
Same with 'Current Target' view
hud-set-message and variables not working properly - Fixed in r6691
word wrap for messages instead of running off the screen (either by resolution or by fixed entry)
When using a ballistic primary, both the weapon energy gauge and the ballistic ammo gauge are moved to the far right side of the screen
Target View monitor shows invalid position for targeted subsystem when no hud_gauges.tbl in use
Not a Bug but would be nice:
Displaying Comms removes already on-screen messages and head.ani
Windows Builds
NEW! 11/24/2010 - r6775
fso-WIN-Inferno_Ant7-r6775.7z (http://swc.fs2downloads.com/builds/WIN/fso-WIN-Inferno_Ant7-r6775.7z)
MD5: C8A5B6D3959789A30C56C38EA55279F2
fso-WIN-Inferno_Ant7_SSE-r6775.7z (http://swc.fs2downloads.com/builds/WIN/fso-WIN-Inferno_Ant7_SSE-r6775.7z)
MD5: 922604E6E7DA8E8F01E6B677A8886F6F
fso-WIN-Inferno_Ant7_SSE2-r6775.7z (http://swc.fs2downloads.com/builds/WIN/fso-WIN-Inferno_Ant7_SSE2-r6775.7z)
MD5: 1EA6FFF5E2862E804140F085AFB6E233
*** Older Builds Here***
11/09/2010 - r6721
Group: Inferno
fso-WIN-Inferno_Ant7-r6721.7z (http://swc.fs2downloads.com/builds/WIN/fso-WIN-Inferno_Ant7-r6721.7z)
MD5: 79312DE9EAD30A53700888AB9B80B96A
Group: Inferno SSE
fso-WIN-Inferno_Ant7_SSE-r6721.7z (http://swc.fs2downloads.com/builds/WIN/fso-WIN-Inferno_Ant7_SSE-r6721.7z)
MD5: E35A873F761AB7E0C2B6A693697EE1BD
Group: Inferno SSE2
fso-WIN-Inferno_Ant7_SSE2-r6721.7z (http://swc.fs2downloads.com/builds/WIN/fso-WIN-Inferno_Ant7_SSE2-r6721.7z)
MD5: 50655603ADBBC7F061E6BB6EA58BC950
10/24/2010 - r6685
Group: Inferno
fso-WIN-Inferno_Ant7-r6685.7z (http://swc.fs2downloads.com/builds/WIN/fso-WIN-Inferno_Ant7-r6685.7z)
MD5: 03498CAC487F305F93BC06E7FF1FD91C
Group: Inferno SSE
fso-WIN-Inferno_Ant7_SSE-r6685.7z (http://swc.fs2downloads.com/builds/WIN/fso-WIN-Inferno_Ant7_SSE-r6685.7z)
MD5: B74901CAE3F415AD3F9054D22D8AF3A4
Group: Inferno SSE2
fso-WIN-Inferno_Ant7_SSE2-r6685.7z (http://swc.fs2downloads.com/builds/WIN/fso-WIN-Inferno_Ant7_SSE2-r6685.7z)
MD5: BAC566BB5A37E7A16E1682B1D948B6EA
10/22/2010 - r6670
Group: Inferno
fso-WIN-Inferno_Ant7-r6670.7z (http://swc.fs2downloads.com/builds/WIN/fso-WIN-Inferno_Ant7-r6670.7z)
MD5: 18A9B8EC836539E9F2AD03EB5A60214B
Group: Inferno SSE
fso-WIN-Inferno_Ant7_SSE-r6670.7z (http://swc.fs2downloads.com/builds/WIN/fso-WIN-Inferno_Ant7_SSE-r6670.7z)
MD5: F0B449DF5624E9277B311525DF182C64
Group: Inferno SSE2
fso-WIN-Inferno_Ant7_SSE2-r6670.7z (http://swc.fs2downloads.com/builds/WIN/fso-WIN-Inferno_Ant7_SSE2-r6670.7z)
MD5: 894C90ADF1725207D3368373EF9AB57D
OS X Builds
NEW! 11/24/2010 - r6775
FS2_Open-Inferno_Ant7_r6775.zip (http://swc.fs2downloads.com/builds/OSX/FS2_Open-Inferno_Ant7_r6775.zip)
MD5: 45EDE4F12B0E9528F89EA9FC0304FC6A
*** Older Builds Here***
11/09/2010 - r6721
FS2_Open-Inferno_Ant7_r6721.zip (http://swc.fs2downloads.com/builds/OSX/FS2_Open-Inferno_Ant7_r6721.zip)
MD5: 5548757e9d4aebedee810d44e05db03b
10/22/2010 - r6670
FS2_Open-Inferno_Ant7_r6670.zip (http://swc.fs2downloads.com/builds/OSX/FS2_Open-Inferno_Ant7_r6670.zip)
MD5: 4294961EBB09E1283C526D85AD8AAC8A
Linux Builds
fs2_antipodes_7_LINUX_r6670.tgz (http://swc.fs2downloads.com/builds/LINUX/fs2_antipodes_7_LINUX_r6670.tgz)
MD5: 77B97E55A171EC25D40DEE957DF31E3F
Quoted from initial HUD Overhaul Testing Thread:
Make sure you guys turn on all the HUD gauges in the HUD Options Menu. I know that FSO by default sets Squad Messages and Text Warnings off; originally FSO would just display them regardless of they were off or not but my code, for better or worse, does not make any such discrimination.
Sample HUD Layouts
Standard HUD layout 4:3 resolutions (http://www.hard-light.net/forums/index.php?topic=69858.msg1382506#msg1382506)
Standard HUD layout for 16:9/10 resolutions (http://www.hard-light.net/forums/index.php?topic=69858.msg1380458#msg1380458)
The_E's custom layout for 16:9/10 resolutions (http://www.hard-light.net/forums/index.php?topic=69858.msg1380229#msg1380229)
Layout for triple head monitors (http://www.hard-light.net/forums/index.php?topic=69858.msg1382534#msg1382534)
Some basic documentation:
All HUD configurations are encapsulated with "#Gauge Config" and "#End". You can define as many different configurations as you need.
Example:
#Gauge Config
(HUD layout information goes here)
#End
You can define a HUD layout configuration for a specific ship or for the default configuration. The default configuration is the HUD layout which will be used for any ships that do not have its own layout. Ship specific gauge layouts will have "$Ship:" defined while non-specific layouts do not.
Each #Gauge Config will have a Base resolution. This resolution is the scale in which the corresponding HUD layout will be drawn regardless of the actual resolution. This is similar to how Freespace Open draws the HUD at a 640x480 or 1024x768 scale regardless of the resolution and aspect ratio. This scale is defined using the "$Base:" field.
Example:
#Gauge Config
$Base: (1440, 900)
$Gauges
(List desired gauges here)
$End Gauges
#End
You can restrict a given HUD layout to be used for specific resolutions and/or aspect ratios. The "$Required Aspect:" field will limit a HUD configuration for use for a specified aspect ratio. The "$Min:" field will set a minimum resolution. "$Max:" will set a maximum.
The following example will restrict this particular HUD gauge layout, that will be drawn in 1440x900 resolution, for use for in wide screen resolutions that are greater than 1280x719 and less than 1680x1051. Since this example does not have the "$Ship" field, it will be used for the default configuration.
Example:
#Gauge Config
$Base: (1440, 900)
$Required Aspect: Wide Screen ;Can be "Wide Screen" or "Full Screen" ATM
$Min: (1280, 719)
$Max: (1680, 1051)
$Gauges
(List desired gauges here)
$End Gauges
#End
Any desired gauges are encapsulated within $Gauges and $End Gauges. Each gauge is followed by a set of coordinates representing the desired screen position. Setting "default" instead of an ordered pair will set the HUD gauge to draw with it's original retail coordinates and scale (640x480 or 1024x768)
Example:
#Gauge Config
$Base: (1440, 900)
$Required Aspect: Wide Screen ;Can be "Wide Screen" or "Full Screen" ATM
$Min: (1280, 720)
$Max: (1680, 1050)
$Gauges
+Wingman Status:
Position: (600, 400)
+Radar:
Position: (900, 50)
+Target Monitor:
Position: (50, 850)
+Center Reticle: default
+Player Shields: default
$End Gauges
#End
Add "$Ship:" to define this gauge layout for a particular flyable ship.
Example:
#Gauge Config
$Ship: GTF Ulysses
$Base: (1440, 900)
$Required Aspect: Wide Screen ;Can be "Wide Screen" or "Full Screen" ATM
$Min: (1280, 720)
$Max: (1680, 1050)
$Gauges
+Wingman Status:
Position: (600, 400)
+Radar:
Position: (900, 50)
+Target Monitor:
Position: (50, 850)
+Center Reticle: default
$End Gauges
#End
EDIT:
To add a custom gauge, use +Custom and it's parameters
Example:
#Gauge Config
$Ship: GTF Ulysses
$Base: (1440, 900)
$Required Aspect: Wide Screen ;Can be "Wide Screen" or "Full Screen" ATM
$Min: (1280, 720)
$Max: (1680, 1050)
$Gauges
+Custom:
Position: (1300, 20)
Name: Sup
Text: This is a custom gauge
Gauge Type: ETS_GAUGE ; strings for gauges defined in sexp.cpp. Will adopt the color and activation settings of its corresponding control in HUD config.
Slew: No
Filename: netlag1
+Wingman Status:
Position: (600, 400)
+Radar:
Position: (900, 50)
+Target Monitor:
Position: (50, 850)
+Center Reticle: default
$End Gauges
#End
From sexp.cpp:
char *HUD_gauge_text[NUM_HUD_GAUGES] =
{
"LEAD_INDICATOR",
"ORIENTATION_TEE",
"HOSTILE_TRIANGLE",
"TARGET_TRIANGLE",
"MISSION_TIME",
"RETICLE_CIRCLE",
"THROTTLE_GAUGE",
"RADAR",
"TARGET_MONITOR",
"CENTER_RETICLE",
"TARGET_MONITOR_EXTRA_DATA",
"TARGET_SHIELD_ICON",
"PLAYER_SHIELD_ICON",
"ETS_GAUGE",
"AUTO_TARGET",
"AUTO_SPEED",
"WEAPONS_GAUGE",
"ESCORT_VIEW",
"DIRECTIVES_VIEW",
"THREAT_GAUGE",
"AFTERBURNER_ENERGY",
"WEAPONS_ENERGY",
"WEAPON_LINKING_GAUGE",
"TARGER_MINI_ICON",
"OFFSCREEN_INDICATOR",
"TALKING_HEAD",
"DAMAGE_GAUGE",
"MESSAGE_LINES",
"MISSILE_WARNING_ARROW",
"CMEASURE_GAUGE",
"OBJECTIVES_NOTIFY_GAUGE",
"WINGMEN_STATUS",
"OFFSCREEN RANGE",
"KILLS GAUGE",
"ATTACKING TARGET COUNT",
"TEXT FLASH",
"MESSAGE BOX",
"SUPPORT GUAGE",
"LAG GUAGE"
};
-
At last! Time to get back to word on custom HUD gauges.
Already got a few cool ones cooking. Per-ship HUDs are also on the table now to my understanding.
-
I may/may not have found a bug, since I can only use a corrupted pilot to test this:
With mediavps_3612 as the active mod, and with your pilot on the Psamtik (vasudan main hall), starting up the game will show you the Aquitaine main hall. Going to the Campaign menu and exiting will return you to the Vasudan main hall.
Again, the only pilot I had that was far enough along in the retail FS2 campaign for this to be testable is also slightly corrupted (very broken weapon loadouts), so I can't say for sure.
-
Yeah, sorry. Bug reports like that are things we kinda have to ignore.
And honestly, if you know the pilot is broken, why do you keep using it?
-
That'd be my bad. I haven't really had the time to play retail at all, so I never bothered to make a new retail campaign pilot. I have 4-5 others I made for user campaigns, but those have 0% progress on any campaign except their own. I merely point it out so that some other user with working pilots can see if there actually is an issue. I could care less that my broken pilot causes broken game behavior.
16:9 HUD table is up, and can be found here: http://www.hard-light.net/forums/index.php?topic=69858.msg1426872#msg1426872 (http://www.hard-light.net/forums/index.php?topic=69858.msg1426872#msg1426872)
-
Is this built on the back of 6?
Hud code is soooooooooooooooo welcome btw.
(^_^)b
thankoo.
-
6 is done, and in trunk, hence 7. So yes, this is based off of the latest trunk, including go_faster (Ant 6), and its only difference is the HUD code going through official stability testing.
-
can someone whip up a 5:4 (aka 1280x1024) HUD?
-
You could use the given 4:3 table and set the base as (1024, 819). Then, multiply all Y values for gauges by 1.066666, rounding to the nearest integer. That will give you a non-stretched HUD with elements that won't be much smaller than retail. It'll look low-res, albeit a bit better than retail, but it if you want, it can be a tie-over until someone makes a proper 5:4 layout with smaller HUD elements.
-
Problem encountered. In the Retail Campaign 'Romans Blunder' with the layout I have the line from the Iceni is getting chopped or running off screen.
"of your leaders." is the portion not displaying, though the "Helm, engage subspace drive" displays on a newline under it.
+Messages:
Position: (175, 10)
+Talking Head:
Position: (5, 5)
Resolution: 1024x768. Needing: Either a length wrap value to put in to customize the message length for display or a parse to auto-wrap.
-
Here's the resolution calculator, relocated from Swifty's HUD thread (and fixed a typo).
Instructions to use:
1. Do not touch the default values or the formulae unless you want to make personal adjustments/know what you're doing.
2. Look at the red stuff, plug in a custom resolution. (Don't put a super high native resolution like 1920x1200 unless you want barely readable tiny text)
3. Copy the bolded values into HUD_gauges.tbl. Since it's an Excel 2007 calculator, it doesn't spit out a ready-to-use tbl for you.
4. Test it! I didn't do much testing myself, so consider this a beta release. I'll try to fix anything that crops up.
Updated to attach fixed calculator.
[attachment deleted by admin]
-
I got a weird bug happening with the hud-set-message and variables. If I use hud-set-message at all, variables in messages won't update past their initial value, either through hud-set-message or through normal send-message. But as soon as I take out hud-set-message, everything works fine.
Here's a quick mod that shows the problem. Comes with a hud gauge and two missions. One has a timer that tries to use hud-set-message in a number of ways, and the only one that works is using hud-set-text-num taking the variable as a parameter directly. The other is a mission has the same timer set up, just using only send-message and no hud sexps.
http://www.sectorgame.com/axem/files/otherstuff/hudbug.rar
-
Got a problem with sound. In the second FS2 mission (on a new, uncorrupted pilot :P), music cuts out after the Victory track finishes playing right before you find the installation. I think this was a confirmed sound issue with Ant 6 where ambient music does not play if it's supposed to after non-ambient music finishes.
On a side note, the head.ani seems to be causing stuttering for me as well, as was mentioned by Psychonaut and Macfie. My stuttering is so bad that I can't aim properly if a head ani is visible. I'm also running Zacam's shaders, which tend to be extremely intensive in certain scenes, so I can't be totally sure what the stuttering is from. I'll take the shaders out later and test again to eliminate other causes.
-
Windows Builds updated to r6685. Matches against Nightly Build of the same revision.
-
Would it be possible to make the messages remain visible when bringing up the communications menu? There seems to be plenty of room for both.
Also, not sure if this is intentional with this test build since I'm new to this Antipodes thing, I noticed that the killed-by messages no longer show up.
And it seems that this isn't important as implied by previous posts but yeah, I'm getting that bug too where I'm supposed to be in the GVD Psamtik but the main menu shows I'm in the GTD Aquitane and I have to go to the campaign menu and select the FS2 campaign to get the proper menu.
-
Would it be possible to make the messages remain visible when bringing up the communications menu? There seems to be plenty of room for both.
Also, not sure if this is intentional with this test build since I'm new to this Antipodes thing, I noticed that the killed-by messages no longer show up.
And it seems that this isn't important as implied by previous posts but yeah, I'm getting that bug too where I'm supposed to be in the GVD Psamtik but the main menu shows I'm in the GTD Aquitane and I have to go to the campaign menu and select the FS2 campaign to get the proper menu.
No, these are excellent bug finds. The main menu bug isn't unimportant at all. It was just thought to be an isolated special case until you noticed it as well.
-
I updated the main post with a quote section of reported issues so far.
And pre-HUD overhaul, messages would disappear when you bring up the comms menu, hence why it is listed as not a bug, but nice to have.
-
I think "main hall defaults incorrectly to Aquitaine" should be added.
-
That's a bug that is considerably older, and pilot file related. As such, it's an issue for Antipodes 8.
-
It's a bug that's probably already fixed in the code for Antipodes 8, specifically.
Also, I finally added an 'Antipodes 7' version to Mantis, so you can report issues from these builds specifically under the version they were encountered under.
-
Current Target view is bugged.
It doesn't show messages like with the bug with the external camera view and in addition to that, most of the HUD elements remain on screen, when normally, only some of them, like the target monitor, extra target data, messages, talking head, center reticle and the "viewing from xxx" message are the ones that remain.
-
When using a ballistic primary, both the weapon energy gauge and the ballistic ammo gauge are moved to the far right side of the screen, and in fact most of said gauges are just dangling off the edge of the screen.
I'm at 1680x1050. Will try for screen.
-
Have the alternate header name lines been added to the other gauges, and would it be possible to get an up-to-date table that shows all of the available configuration options (any resolution would be fine)?
The only other things I had left over from the other thread were a vertical spacing adjuster for the wing names in the wingmen gauge and I think a horizontal (and maybe vertical?) clip distance for the normal messages readout. Hooray for the HUD!
-
The Lead Sight seems inaccurate when flying backwards vs a stationary target, at least in Diaspora. I'm not sure how the sight is calculated, but we might want to double-check the math on it.
-
Out of curiosity, what distro are the Linux builds compiled under? While installing under Fedora (13) yesterday it kept telling me it couldn't find "liblua5.1.so.0" even though I was positive I had it installed (even after symlinking a .so.0 to the .so). After a few minutes of head scratching, I discovered Fedora was calling it "liblua-5.1.so" (note the dash). Creating a symlink for that solved the problem (and a second one I wasn't even thinking about at that point).
-
Ubuntu 10.04 LTS 32bit. I'm not surprised there's some differences between a Redhat distro and a Debian distro. There was some talk about possible ways to fix the problem, but I don't know nearly enough to tackle it myself.
-
It's the kind of **** anyone who uses Linux is more than used to (that doesn't mean it's acceptable, but that's another topic entirely...), I was just curious as to where the issue was creeping in from.
-
I upgraded the FSPort files on my MacBook to 3.2 last night and I noticed a couple of the HUD elements, namely the speed gauge and the threat indicators are being drawn in the wrong spot. Switching back to the retail campaign and they get put in the right spot, which indicates it's a problem specific to the Port, but I don't recall seeing it on Windows, so I have no idea. I'd post a screenshot, but I lack a PrtScr key to take one with :/ Any ideas what might be up?
-
Cmd-Shift-3 can take that screenshot for you.
-
That works in 3D? Neat. Will post back in a bit :D
-
(http://www.hexellent.com/files/26/brokenhud.jpg) (http://www.hexellent.com/files/26/brokenhud.jpg)
There we are. I just realised, going in and taking that, that I was referring to the wrong gauge when trying to describe it on IRC :P That said, both the two I was confusing seem to be in the wrong spot, so it's not all bad :D
-
I don't think there's a HUD_gauges.tbl for FSPort yet. If I'm wrong, then I'd really like a copy.
-
Shouldn't matter. The default layout probably shouldn't be breaking.
-
There's a HUD table included with FSPort.
And it screws things up.
-
I just checked with the Port on the Windows computer, same issue. Which is odd, since I could have sworn it looked fine when I first started using these builds...
edit: I should add here that I did see the post above this one, just mentioning that my initial belief that it was specific to the Mac was wrong, which jives with the above explanation.
-
Problems with the target information monitor, the system/turret targeting is off, screens to follow
(http://i223.photobucket.com/albums/dd250/maverickx329/targeting1.jpg)
(http://i223.photobucket.com/albums/dd250/maverickx329/targeting2.jpg)
-
I've noticed that as well but even before the new HUD code. Can you check with trunk and see if it's the same. I haven't tested it myself with retail.
-
Just wanted to say thanks this is really a good thing something that I personally was hoping for. :) :yes:
-
Might be a widescreen thing? I've noticed the same problem, half the time the bracket in the target window won't even be on the ship (it looks like you're targeting empty space near it). I think it's been happening since before Ant7, but I'm not entirely sure about that.
-
There's a HUD table included with FSPort.
And it screws things up.
The FSPort hudgauges.tbl does nothing but specify Hud Style: FS1. I've been asking ever since this HUD code was made public for someone with knowledge of it to make a FS1-style compatible HUD. This way we can put the code to immediate use by assigning FS1-style HUDs to the Hercules, Ulysses, Loki, Zeus, Medusa, and Ursa in the FS2 Media VPs.
I've taken a few cracks at it but there's a conflict with the TopArc and the Laser/Missile Warning Indicators that's stumped me. I would really like someone with access to the code itself to try it.
-
Might be a widescreen thing? I've noticed the same problem, half the time the bracket in the target window won't even be on the ship (it looks like you're targeting empty space near it). I think it's been happening since before Ant7, but I'm not entirely sure about that.
Might be. I remember that there was a widescreen targeting box hack/fix a long long time ago, but I don't remember the details of what it did. Maybe the new HUD code is messing with that hack.
-
The FSPort hudgauges.tbl does nothing but specify Hud Style: FS1. I've been asking ever since this HUD code was made public for someone with knowledge of it to make a FS1-style compatible HUD. This way we can put the code to immediate use by assigning FS1-style HUDs to the Hercules, Ulysses, Loki, Zeus, Medusa, and Ursa in the FS2 Media VPs.
I've taken a few cracks at it but there's a conflict with the TopArc and the Laser/Missile Warning Indicators that's stumped me. I would really like someone with access to the code itself to try it.
Check out HudGauges.tbl in the latest FSPort mediavps release.
There's a full HUD entry and it's borked.
-
Yup, he's right, there's a full entry in the FSPort MediaVPs. Looks like it's not a bug in the code then (probably).
-
Huh, I know I did that for a reason...
-
Just wanted to mention that I'm also getting the stuttering issue with head ANIs. Just using the standard layout, so no idea what it could be. Other than that, everything works fine.
-
Why would I be able to use cockpits in 3.6.12 final but not in Antipodes 7? I'm trying to use the GenericCP.pof cockpit and it works fine in other versions, just not this? (though rscaper1070 swears it does work?)
Am I missing something? Do cockpits need to be put elsewhere? Also, Antipodes build doesn't use my older savegames?
-
Externe Cockpitpof works for me with this build.
-
Update release for 6720 is now out, see first post.
Updated to Trunk 6715.
Fixes since 6685 Release: (not listing Trunk Sync's):
------------------------------------------------------------------------
r6691 | The_E | 2010-10-26 03:20:48 -0800 (Tue, 26 Oct 2010) | 2 lines
Changed paths:
M /trunk/fs2_open/code/parse/sexp.cpp
Fix for Mantis 2331 (hud-set-message not working properly)
------------------------------------------------------------------------
r6696 | The_E | 2010-10-28 12:03:07 -0800 (Thu, 28 Oct 2010) | 2 lines
Changed paths:
M /trunk/fs2_open/code/hud/hudmessage.cpp
Fixes issue with the head ani not being unloaded correctly
------------------------------------------------------------------------
r6716 | The_E | 2010-11-08 17:30:22 -0800 (Mon, 08 Nov 2010) | 2 lines
Changed paths:
M /trunk/fs2_open/code/hud/hudmessage.cpp
M /trunk/fs2_open/code/hud/hudtargetbox.cpp
Changes render permissions for the messages, head ani, and target view gauges.
------------------------------------------------------------------------
r6717 | The_E | 2010-11-08 20:05:18 -0800 (Mon, 08 Nov 2010) | 2 lines
Changed paths:
M /trunk/fs2_open/code/hud/hudtarget.cpp
Fix issue with alternate weapon energy/ballistic ammo gauges not drawn correctly
------------------------------------------------------------------------
r6719 | The_E | 2010-11-09 01:48:26 -0800 (Tue, 09 Nov 2010) | 2 lines
Changed paths:
M /trunk/fs2_open/code/sexp/sexp.cpp
M /trunk/fs2_open/code/sexp/sexp.h
Adding the hud-set-directive sexp, to complete the set.
------------------------------------------------------------------------
r6720 | Zacam | 2010-11-09 04:38:17 -0800 (Tue, 09 Nov 2010) | 1 line
Changed paths:
M /trunk/fs2_open/code/sexp/sexp.cpp
Hmm. There's a game-breaker, hopefully now fixed appropriately. (At least now it compiles)
------------------------------------------------------------------------
**EDIT: Updated to 6721, my 'fix' on commit 6720 wasn't actually a fix. Plus, the download links were wrong.
-
Just wanted to mention that I'm also getting the stuttering issue with head ANIs. Just using the standard layout, so no idea what it could be. Other than that, everything works fine.
Same here, stuttering with video playback in mission.
-
Problems with the target information monitor, the system/turret targeting is off, screens to follow
(http://i223.photobucket.com/albums/dd250/maverickx329/targeting1.jpg)
(http://i223.photobucket.com/albums/dd250/maverickx329/targeting2.jpg)
Fixed.
-
I rewrote the HUD messages gauge to be configurable. Code has been committed to SVN but no new build is available yet. The specification to configure HUD messages is as follows:
+Messages:
Position: (5, 5)
Font: 3
Slew: No
Max Lines: 3
Max Width: 1004
Line Height: 12
Total Lifetime: 14000 ; in milliseconds
Scroll Time: 30 ; in milliseconds
Step Size: 3 ; number of pixels a line moves up per Scroll Time
-
Awesome! So close to having everything we need for the SWC HUD to be finished :yes:
-
Will try to get you a Mac build soon swash :)
-
#Gauge Config
$Base: (1280, 1024)
$Required Aspect: Full Screen ; Can be "Wide Screen" or "Full Screen" ATM
$Gauges:
;Messages
+Messages:
Position: (7, 5)
+Training Messages:
Position: (507, 238)
+Multiplayer Messages:
Position: (-69, 360)
+Talking Head:
Position: (7, 59)
;Comm Menu
+Squad Message:
Position: (1081, 5)
;Objectives
+Escort View:
Position: (1119, 507)
+Directives:
Position: (7, 400)
+Objective Notify:
Position: (564, 408)
;Reticle
+Afterburner Energy:
Position: (342, 537)
+Throttle:
Position: (410, 392)
+Center Reticle:
Position: (620, 501)
+Threat Indicator:
Position: (767, 392)
+Weapon Energy:
Position: (850, 537)
+Target Brackets: ; Target Brackets, Lock Indicator, Lead Indicator, and Offscreen Indicator don't need a "Position:" field.
+Lock Indicator:
+Lead Indicator:
+Offscreen Indicator:
+Hostile Triangle:
Position: (640, 512)
+Target Triangle:
Position: (640, 512)
+Missile Triangles:
Position: (640, 512)
+Orientation Tee:
Position: (640, 512)
;Target
+Target Monitor:
Position: (7, 836)
+Extra Target Data:
Position: (7, 796)
+Target Shields:
Position: (393, 916)
+Mini Target Shields:
Position: (625, 604)
;Player Status
+Damage:
Position: (568, 171)
+Player Shields:
Position: (777, 916)
+Kills:
Position: (1134, 872)
;ETS
+ETS Weapons:
Position: (1134, 897)
+ETS Shields:
Position: (1152, 897)
+ETS Engines:
Position: (1170, 897)
;Wingmen & Support
+Wingman Status:
Position: (1186, 259)
+Support:
Position: (587, 670)
;Radar & Targeting
+Radar:
Position: (537, 836)
;+Radar Orb:
; Position: (535, 836)
+Auto Target:
Position: (1214, 897)
+Auto Speed:
Position: (1214, 923)
;Weapons
+Countermeasures:
Position: (1134, 849)
+Weapons:
Position: (1134, 768)
;Warnings
+Text Warnings:
Position: (640, 397)
+Supernova:
Position: (239, 179)
;Mission Info
+Mission Time:
Position: (1223, 969)
;Multiplayer
+Voice Status:
Position: (7, 281)
+Ping:
Position: (1180, 5)
+Lag:
Position: (801, 665)
$End Gauges
#End(http://img709.imageshack.us/img709/7362/screen0114.jpg)
Made with Kolgena's excel calc, and fixed up the minor mistake of his in it with designating the position of the engine part of the ETS thingy. the position of it in the default layout should be 1330, not 916, since that puts it just next to the radar.
-
Oops. Updated my post for the 'fixed' calc. Thx for finding the error.
-
np :p
guess noone used it till now, otherwise they'd have complained about it already.
-
Another bug:
When using "view from target (/ key on numpad), a bunch of the player HUD is rendered if you are facing the same direction as the target.
Used to be that only the crosshair showed up (which was silly enough) but now it's rendering a lot more (which is even sillier).
-
I think that's already been reported, at least in IRC. Thought it was already addressed too, guess not.
-
Another bug:
When using "view from target (/ key on numpad), a bunch of the player HUD is rendered if you are facing the same direction as the target.
Used to be that only the crosshair showed up (which was silly enough) but now it's rendering a lot more (which is even sillier).
Currently being fixed. I accidentally assigned VM_OTHER_SHIP to disabled_views for the inverse of hud gauges that normally displayed in view from target mode. So everything but the gauges that needed to display in that view are being displayed. :P
Yeah pretty stupid. Apologies.
-
ah, as a side note, with my 5:4 layout, killed by messages still dont display. (i assume its the infamous "Killed by <ship name>")
11/09/2010 build, BP2 mod.
all in all, not much of a problem for me honestly, as i just quickly click restart, and dont really care much about who i was killed by, since i usually see it.
god i hate slasher beams...
-
Just recently, support for Fixed Messages as a separate HUD gauge was added by The_E.
+Fixed Messages:
Position: ( , )
-
Is it possible to move the FPS display? Right now it's on top of the talking head and I can't find it in the table. Also I was wondering about the missile "LAUNCHED" and "EVADED" displays, they don't show up.
-
Quoted from initial HUD Overhaul Testing Thread:
Make sure you guys turn on all the HUD gauges in the HUD Options Menu. I know that FSO by default sets Squad Messages and Text Warnings off; originally FSO would just display them regardless of they were off or not but my code, for better or worse, does not make any such discrimination.
It's because of this.
-
Quoted from initial HUD Overhaul Testing Thread:
Make sure you guys turn on all the HUD gauges in the HUD Options Menu. I know that FSO by default sets Squad Messages and Text Warnings off; originally FSO would just display them regardless of they were off or not but my code, for better or worse, does not make any such discrimination.
It's because of this.
Yeah I really got to find out why and where those defaults are being set to off.
-
Ugh, I thought that meant the tab in the launcher. Thanks for the tip.
-
Ok, here's a triple 16:10 monitor setup I made just now. It works in the retail campaign at least, so it should be good to go:
#Gauge Config
$Base: (3840, 800)
$Required Aspect: Wide Screen
$Min: (640, 480)
$Max: (5760, 1200)
$Gauges:
+Messages:
Position: (1287, 5)
+Training Messages:
Position: (1787, 126)
+Multiplayer Messages:
Position: (1211, 248)
+Support:
Position: (1867, 558)
+Damage:
Position: (1848, 59)
+Wingman Status:
Position: (2466, 147)
+Auto Speed:
Position: (2494, 699)
+Auto Target:
Position: (2494, 673)
+Countermeasures:
Position: (2414, 625)
+Talking Head:
Position: (1287, 59)
+Directives:
Position: (1287, 288)
+Weapons:
Position: (2414, 544)
+Objective Notify:
Position: (1844, 184)
+Squad Message:
Position: (2361, 5)
+Player Shields:
Position: (2057, 692)
+Target Shields:
Position: (1673, 692)
+Escort View:
Position: (2399, 283)
+ETS Weapons:
Position: (2414, 673)
+ETS Shields:
Position: (2432, 673)
+ETS Engines:
Position: (2450, 673)
+Target Monitor:
Position: (1287, 612)
+Extra Target Data:
Position: (1287, 572)
+Radar:
Position: (1817, 612)
; If you want different types of radar running, be my guest
;+Radar Orb:
; Position: (1815, 612)
+Afterburner Energy:
Position: (1622, 425)
+Text Warnings:
Position: (1920, 285)
+Center Reticle:
Position: (1900, 389)
+Mini Target Shields:
Position: (1905, 492)
+Throttle:
Position: (1690, 280)
+Threat Indicator:
Position: (2047, 280)
+Voice Status:
position: (1287, 169)
+Ping:
Position: (2460, 5)
+Lag:
Position: (2081, 553)
+Supernova:
Position: (1519, 179)
+Target Brackets: ; Target Brackets, Lock Indicator, Lead Indicator, and Offscreen Indicator don't need a "Position:" field.
+Lead Indicator:
+Lock Indicator:
+Offscreen Indicator:
+Hostile Triangle:
Position: (1920, 400)
+Target Triangle:
Position: (1920, 400)
+Missile Triangles:
Position: (1920, 400)
+Orientation Tee:
Position: (1920, 400)
+Weapon Energy:
Position: (2130, 425)
+Mission Time:
Position: (2503, 745)
+Kills:
Position: (2414, 648)
; FS1 specific gauge
;+Weapon Linking:
; Position: (598, 387)
; Komet's lead sight. Looks for "leadsight.ani"
;+Lead Sight: default
$End Gauges
#End
-
The Lead Sight seems inaccurate when flying backwards vs a stationary target, at least in Diaspora. I'm not sure how the sight is calculated, but we might want to double-check the math on it.
Good news: this isn't the case. The lead sight works fine.
Bad news: it's a collision detection bug. I can repro it in Diaspora by flying backwards, aiming directly at a stationary fighter, and watching my shots go right through it. I'm guessing it has to do with the way that collision detection optimizes out "impossible" collision pairs, and I'm guessing it isn't correctly handling additive weapon velocity.
-
Damn, I hate that optimization.
-
Damn, I hate that optimization.
Yeah, me too. :hopping: I'll look into it in more depth when I get the chance to see if I can figure out exactly where/why it's breaking. I thought I already fixed the "additive weapon velocity screws up collision detection" bug once...
-
I found a problem with the new HUD code. :p
In FSU svn testing directory there exists mvp-hdg.tbm and in BP2 svn there also exists hdg.tbm of different name. What happens when both files are about identical and have full HUD layout? Your HUD is now rendered twice on top of each other, that's what. :D
What happens if you edit either one of the files to position HUD gauges elsewhere, like for example Directives gauge? You now have two Directives gauges. :D
-
That's pretty much expected behavior right now. If there are two layouts with the same conditions present, they're both gonna be parsed. If you guys can suggest a good fallback flow for these cases, I'd like to hear it.
-
Seems like with a little bit of tweaking, with a set of red gauges and a set of blue gauges, we'll have STEREOSCOPIC HUD LAYOUTS!!!!!
ahem.
-
Standard behaviour: Parse only the "topmost" set (in order of loading)
Modifier would be +nocreate, to add stuff to an existing layout.
-
Check out HudGauges.tbl in the latest FSPort mediavps release.
There's a full HUD entry and it's borked.
So... any timetable on when this will be fixed? :/
-
Already fixed.
edit: or not lolololol
-
Update release for 6775 is now out, see first post.
Updated to Trunk 6774.
Fixes since 6721 Release: (not listing Trunk Sync's):
------------------------------------------------------------------------
r6722 | The_E | 2010-11-10 19:17:37 -0800 (, 10 Nov 2010) | 2 lines
Changed paths:
M /branches/antipodes/code/hud/hudtarget.cpp
Fix for faulty check
------------------------------------------------------------------------
r6723 | The_E | 2010-11-10 19:33:06 -0800 (Wen, 10 Nov 2010) | 3 lines
Changed paths:
M /branches/antipodes/code/hud/hud.cpp
M /branches/antipodes/code/hud/hud.h
M /branches/antipodes/code/hud/hudparse.cpp
M /branches/antipodes/code/hud/hudreticle.cpp
M /branches/antipodes/code/hud/hudreticle.h
Adds an XWA-style firepoint display to the standard reticle. To use it, add "Firepoint display: YES" to the center reticle gauge (after "Filename:"). Additional options are "Firepoint size:" (size in pixels, default value is 5), "Firepoint X coordinate multiplier:" (Default is 15) and "Firepoint Y coordinate multiplier:" (Default value 10)
Also adds HudGauge::renderCircle().
------------------------------------------------------------------------
r6727 | The_E | 2010-11-11 08:38:34 -0800 (Thu, 11 Nov 2010) | 2 lines
Changed paths:
M /branches/antipodes/code/hud/hudtarget.cpp
Ooops, forgot to change this to a renderString()
------------------------------------------------------------------------
r6728 | The_E | 2010-11-11 19:01:30 -0800 (Thu, 11 Nov 2010) | 2 lines
Changed paths:
M /branches/antipodes/code/parse/sexp.cpp
The real fix for hud-set-directive
------------------------------------------------------------------------
r6730 | The_E | 2010-11-12 18:09:01 -0800 (Fri, 12 Nov 2010) | 2 lines
Changed paths:
M /branches/antipodes/code/hud/hudtargetbox.cpp
Fixing bug where the coordinates for the subsystem reticle in the targetview window got manipulated wrongly if no hud_gauges.tbl was present.
------------------------------------------------------------------------
r6732 | The_E | 2010-11-13 03:16:29 -0800 (Sat, 13 Nov 2010) | 2 lines
Changed paths:
M /branches/antipodes/code/hud/hudmessage.cpp
M /branches/antipodes/code/hud/hudmessage.h
M /branches/antipodes/code/hud/hudparse.cpp
M /branches/antipodes/code/hud/hudparse.h
Adding the "Fixed Message" gauge. This is used to display status messages, like the "Killed by..." and "Viewing from:..." messages. Usage is the same as the standard message gauge.
------------------------------------------------------------------------
r6733 | The_E | 2010-11-13 07:55:29 -0800 (Sat, 13 Nov 2010) | 2 lines
Changed paths:
M /branches/antipodes/code/hud/hudmessage.cpp
M /branches/antipodes/code/missionui/missionshipchoice.cpp
Ooops, small oversight
------------------------------------------------------------------------
r6734 | The_E | 2010-11-13 08:01:21 -0800 (Sat, 13 Nov 2010) | 2 lines
Changed paths:
M /branches/antipodes/code/missionui/missionshipchoice.cpp
This wasn't supposed to be committed as well, sorry
------------------------------------------------------------------------
r6742 | The_E | 2010-11-14 11:28:11 -0800 (Sun, 14 Nov 2010) | 2 lines
Changed paths:
M /branches/antipodes/code/hud/hud.cpp
M /branches/antipodes/code/hud/hudmessage.cpp
M /branches/antipodes/code/hud/hudmessage.h
M /branches/antipodes/code/hud/hudparse.cpp
Rewrite of the HUD messages rewrite.
------------------------------------------------------------------------
r6744 | The_E | 2010-11-15 07:36:27 -0800 (Mon, 15 Nov 2010) | 2 lines
Changed paths:
M /branches/antipodes/code/hud/hudparse.cpp
M /branches/antipodes/code/parse/sexp.cpp
M /branches/antipodes/code/parse/sexp.h
Adding option to designate a custom HUD gauge as off by default, as well as a sexp to activate/deactivate custom gauges
------------------------------------------------------------------------
r6747 | The_E | 2010-11-16 04:29:13 -0800 (Tue, 16 Nov 2010) | 2 lines
Changed paths:
M /branches/antipodes/code/hud/hudmessage.cpp
Fix for code analysis warning
------------------------------------------------------------------------
r6748 | The_E | 2010-11-16 05:57:26 -0800 (Tue, 16 Nov 2010) | 2 lines
Changed paths:
M /branches/antipodes/code/hud/hudreticle.cpp
Changes the firepoiunt display to be a tiny bit more efficient. Also, working as planned now.
------------------------------------------------------------------------
r6749 | Swifty | 2010-11-17 13:52:08 -0800 (Wen, 17 Nov 2010) | 2 lines
Changed paths:
M /branches/antipodes/code/hud/hud.cpp
M /branches/antipodes/code/hud/hudescort.cpp
M /branches/antipodes/code/hud/hudets.cpp
M /branches/antipodes/code/hud/hudmessage.cpp
M /branches/antipodes/code/hud/hudreticle.cpp
M /branches/antipodes/code/hud/hudshield.cpp
M /branches/antipodes/code/hud/hudsquadmsg.cpp
M /branches/antipodes/code/hud/hudtarget.cpp
M /branches/antipodes/code/hud/hudtargetbox.cpp
M /branches/antipodes/code/hud/hudwingmanstatus.cpp
M /branches/antipodes/code/mission/missiontraining.cpp
M /branches/antipodes/code/radar/radarsetup.cpp
Rectified the behavior of View From Target from rendering the inverse of HUD elements it originally displayed. Targetbox returned to its original behavior of not displaying in external cam.
------------------------------------------------------------------------
r6750 | The_E | 2010-11-19 09:18:56 -0800 (Fri, 19 Nov 2010) | 2 lines
Changed paths:
M /branches/antipodes/code/hud/hudmessage.cpp
M /branches/antipodes/code/mission/missionmessage.cpp
Fixes issue noticed by Axem, where messages without head anis would reuse the last head ani in use.
------------------------------------------------------------------------
r6751 | The_E | 2010-11-19 13:21:47 -0800 (Fri, 19 Nov 2010) | 2 lines
Changed paths:8
M /branches/antipodes/code/hud/hud.cpp
M /branches/antipodes/code/hud/hud.h
M /branches/antipodes/code/hud/hudparse.cpp
Fixes issue noticed by Axem, where messages without head anis would reuse the last head ani in use.
------------------------------------------------------------------------
r6752 | The_E | 2010-11-19 13:22:12 -0800 (Fri, 19 Nov 2010) | 2 lines
Changed paths:
M /branches/antipodes/code/hud/hudreticle.cpp
Logic is a good thing. If you don't reverse it.
------------------------------------------------------------------------
r6759 | The_E | 2010-11-20 15:38:53 -0800 (Sat, 20 Nov 2010) | 2 lines
Changed paths:
M /branches/antipodes/code/hud/hud.cpp
M /branches/antipodes/code/hud/hud.h
M /branches/antipodes/code/hud/hudparse.cpp
M /branches/antipodes/code/hud/hudparse.h
M /branches/antipodes/code/mission/missionload.cpp
More fixes for the "initial off" thing.
------------------------------------------------------------------------
r6759 | The_E | 2010-11-23 00:06:10 -0800 (Tue, 23 Nov 2010) | 2 lines
Changed paths:
M /branches/antipodes/code/sexp/sexp.cpp
eval_sexp -> is_sexp_true
------------------------------------------------------------------------
Mac Builds updated on first post, courtesy Echelon9.
-
------------------------------------------------------------------------
r6723 | The_E | 2010-11-10 19:33:06 -0800 (Wen, 10 Nov 2010) | 3 lines
Changed paths:
M /branches/antipodes/code/hud/hud.cpp
M /branches/antipodes/code/hud/hud.h
M /branches/antipodes/code/hud/hudparse.cpp
M /branches/antipodes/code/hud/hudreticle.cpp
M /branches/antipodes/code/hud/hudreticle.h
Adds an XWA-style firepoint display to the standard reticle. To use it, add "Firepoint display: YES" to the center reticle gauge (after "Filename:"). Additional options are "Firepoint size:" (size in pixels, default value is 5), "Firepoint X coordinate multiplier:" (Default is 15) and "Firepoint Y coordinate multiplier:" (Default value 10)
Also adds HudGauge::renderCircle().
I've been messing with this and it pretty much rocks my socks. Will there eventually be a way to make custom ship HUDs in some sort of tbm-type-style manner so that the redundant data doesn't have to be copied over and over again?
-
OK, so the new build seems to have corrected the crazy HUD element placement I was noticing in the Port, except now the custom part is green while everything else seems to be inheriting the default colours from FS2. Any idea what's up with that? Is that the Port's HUD tbl getting in the way of things?
-
Whatever the circumstances, if you override the Port's HUD tbl with a copy of the default and THEN make your own TBM, it ought to work. Has anyone accomplished this yet?
-
I attempted to make a new table for a normal wide screen FSPort. I changed the position of the throttle, the threat indicator, and the weapon linking gauges. I made these changes in an extracted hudgauges.tbl from the FSPort vps and tested the changes in the extracted table in my fsport-mediavps folder.
These are the new positions.
+Throttle:
Position: (500, 417)
+Threat Indicator:
Position: (594, 287)
+Weapon Linking:
Position: (861, 413)
The original settings for these are
+Throttle:
Position: (490, 317)
+Threat Indicator:
Position: (847, 317)
+Weapon Linking:
Position: (841, 453)
(http://farm5.static.flickr.com/4112/5212756163_d3d86bef6c.jpg) (http://www.flickr.com/photos/56368596@N07/5212756163/)
fs2_open_ant_7r_INF_SSE2 2010-11-27 21-24-31-47 (http://www.flickr.com/photos/56368596@N07/5212756163/) by BlueKobold (http://www.flickr.com/people/56368596@N07/)
(http://farm6.static.flickr.com/5004/5211213894_1f05a5b979.jpg) (http://www.flickr.com/photos/56368596@N07/5211213894/)
fs2_open_ant_7r_INF_SSE2 2010-11-27 01-33-09-85 (http://www.flickr.com/photos/56368596@N07/5211213894/) by BlueKobold (http://www.flickr.com/people/56368596@N07/)
I'm not happy with the threat indicator at all. All I can think of when I look at this is a potato. The weapon linking gauge is also not perfect, the horizontal alignment just doesn't fit because I think the arc's of the throttle and the weapon linking gauges are different.
These are my modifications based on my limited ability.
-
I must say that looks kind of strange. For FSPort, I think it's imperative to keep the round central HUD stuff round. It's a little easier to fudge in FS2, and since most of us have played on stretched HUDs for years, we don't like the normal squarish looking central stuff and at least The_E has opted to keep the rectangular center stuff.
-
That's pretty good. Just raise the threat indicator height to almost the same as the wingmen gauge and that would be pretty close.
-
I decided to open a picture of the hud from Freespace 1 to try and guide my next iteration. I was very surprised to see how nice the original hud looked. The central gauges may not make a perfect circle, but they do not make some kind of weird potato. The new code is below.
+Afterburner Energy:
Position: (498, 439)
+Weapon Energy:
Position: (854, 439)
+Throttle:
Position: (570, 417)
+Weapon Linking:
Position: (791, 413)Of course a picture is worth a thousand words.
(http://farm6.static.flickr.com/5248/5212953693_2e7d4a037e.jpg) (http://www.flickr.com/photos/56368596@N07/5212953693/)
The obvious problem with this compared to FS1 is the threat indicator gauge is still too low. Now the oval FS1 created is bigger horizontal than vertical.
I don't want to move the threat indicator upwards since the hostile, missile, and target triangles are directly above that. Above those we have the objective complete gauge and above that is the players hull and subsystem status.
Most of the gauges seem off center, just look at this shot.
(http://farm6.static.flickr.com/5168/5213593134_654a4c03a1.jpg) (http://www.flickr.com/photos/56368596@N07/5213593134/)
-
Does anyone have the original coordinates built for 640x480? I could modify my calculator and spit out something as close to the original as possible.
As a side note, it's bugging me that the ETS gauges will look screwed up without the shield gauge. Without new HUD builds, FSPort used to have the two gauges lined up nicely without the gap in the middle (similar to how things look when you're in subspace). I'm wondering if it's a code problem that's preventing us from doing the same with the new HUD code.
-
I'm getting this problem where any sound played, except music, gets doubled. I've tested this with and without the build and on different mods. It's definitely Antipodes that is doing it. Also, the speed and warning gauges are now coloured differently. I'd like it set back the way it was:
Before - (http://img818.imageshack.us/img818/5066/screen0020.th.png) (http://img818.imageshack.us/i/screen0020.png/)
After - (http://img823.imageshack.us/img823/5126/screen0069.th.png) (http://img823.imageshack.us/i/screen0069.png/)
-
What do you mean by doubled? Could you describe what you're getting a bit more? If EAX is turned on in your launcher, then you will get reverb sound effects. I'm not sure if that's what you're experiencing or something else.
I notice that you're not using a HUD_gauges.tbl with your setup. It probably won't make a difference to the coloring problems (which as far as I can tell are only affecting your left/right center brackets), but do you want to give that a try just in case?
-
How do I setup a HUD_gauges.tbl? Oh and turning off EFX solved the sound problem.
I really liked having the left and right parts of my HUD the same colour as the reticle so I'd really like to remedy this if at all possible.
EDIT: HUD_gauges is in there, I can tell it's working as the HUD has been bandied around on my current resolution. The colour problem still presists though. I'd really like it back the way it was.
-
go to options, hud section and check the colors there.
[edit] actually, yeah, there seems to be a subtle thing there, possibly a bug, but still try and do what i said above :)
-
Yeah I checked again Peceni the colours for the warning indicator and throttle only apply to the whole sort of HUD element thing they're in, but they used to have the colour of the reticle. Ack, I'll just play as is. I can't play FS without Fury's lighting settings now!
-
You know that older builds should still work with Fury's lighting tags (if that's what you're talking about). Edit: Nm, realized you meant Fury's post-processing stuff.
They'll have stretched HUDs though.
-
If there are no technical build issues involved with the HUD Code (aside from the aesthetics of getting a working config), then this is absolute Last Call for any problems related to the HUD Overhaul code before it goes Trunk.
Repeat: Last Call for any HUD Overhaul build problems
-
What Zacam said
-
Zacam, what about this (http://www.hard-light.net/forums/index.php?topic=72205.msg1439497#msg1439497)?
-
Yeah. That bug is easily reproducible. Although the new HUD build does what the HUD config shows it's supposed to do, it doesn't follow what the other builds do.
-
I'm really not going to take the time to "fix" that. For the greater good of code sanity and modularity, those two arcs are not considered as an extension of the center reticle. The two arcs need to be considered separate from the reticle and from each other in order to make them easily modable.
I've thought about this for the one year I took working on this rewrite. But then I saw that this new behavior is consistent with the highlights for the Throttle and Threat Indicator in the HUD Config anyway. The HUD Config screen makes the impression that both elements in their entirety will be affected by the customizations when selected. This old inconsistency was actually a bug depending on how you look at this.
-
Well, the go-faster code is not at all related to the HUD code, but I think it causes heavy stuttering when head anis are played. Head anis are HUD elements so it might be relevant :nervous:
-
If it happens in trunk and Antipodes 7 though, it's not related to this code thus far.
-
I'm really not going to take the time to "fix" that. For the greater good of code sanity and modularity, those two arcs are not considered as an extension of the center reticle. The two arcs need to be considered separate from the reticle and from each other in order to make them easily modable.
I've thought about this for the one year I took working on this rewrite. But then I saw that this new behavior is consistent with the highlights for the Throttle and Threat Indicator in the HUD Config anyway. The HUD Config screen makes the impression that both elements in their entirety will be affected by the customizations when selected. This old inconsistency was actually a bug depending on how you look at this.
could you maybe add it to the hud coloring screen then?
-
could you maybe add it to the hud coloring screen then?
That's not a possible solution. Each gauge has a single reference which ties it to the HUD config. The Threat Indicator is it's own monolithic gauge. A gauge having multiple HUD config references just will not work.
-
ah. very well then :)
i see that this was merged to trunk three hours ago, will compile and test it just in case :D
-
I've noticed that when in the external view where you can freely move the camera around your ship, the communications dialog box does not appear.
Also, when jumping out, "subspace drive engaged" does not appear in the left corner, and when I was playing about with supernovae earlier today, the countdown didn't appear at all.
I've just checked the 3.6.12 release executables, and all of these things appear with them.
-
Comms Menu: Shows in "Chase" view and "Target Padlock", but not external "Free Look" or when panning view or while "Viewing from Target"
(This is indeed different than from 3.6.12, where these elements do show there, though as a benefit, hud-set-messages are now visible when view panning where as in .12 you had to hit the comms menu to see them if you were looking anywhere other than straight ahead)
Comm talk (including head.ani) does appear while in Free Look and Chase view, but not while panning cockpit view (including "Target Padlock")
"Subspace Drive Engaged" does appear, check your hud file configuration and make sure that you have all HUD elements ON in your Options screen
Still testing Supernova.
-
In the first training mission of FS2 the secondary weapon counter has a glitch, in that there is a gap in the gauge where there is only the regular game display and no hud gauge. The gauge is split below the <None> in the secondary weapon bank and continues further down the screen.
I am using FS2 without the mediavps and at the lowest resolution with all the hud options enabled in the launcher.
On my computer, this happens when I am using the current Nightly (6847) with Antipodes 7 and Antipodes 8 but not when using 3.6.12 Release.
Attached is a debug log from 6847.
[attachment deleted by admin]
-
Reported in the AP8 Thread:
Head .ani's are now permanently bright, whereas before hitting L was able to toggle them between bright and dim.
(As a side note, whenever they're shown, they still lag up the game. I'm going to guess that this is being worked on already)
My finding is that the border of the head.ani is adjusted, but not the full over-lay itself. No idea what is causing it to be reported as "bright" in Kolgena's post though.
-
In the first training mission of FS2 the secondary weapon counter has a glitch, in that there is a gap in the gauge where there is only the regular game display and no hud gauge. The gauge is split below the <None> in the secondary weapon bank and continues further down the screen.
I am using FS2 without the mediavps and at the lowest resolution with all the hud options enabled in the launcher.
On my computer, this happens when I am using the current Nightly (6847) with Antipodes 7 and Antipodes 8 but not when using 3.6.12 Release.
Attached is a debug log from 6847.
Found root pack 'C:\Games\Freespace 2\data\tango1_fs2.vp' with a checksum of 0x4c25221e
Found root pack 'C:\Games\Freespace 2\data\tango2_fs2.vp' with a checksum of 0x86920b82
Found root pack 'C:\Games\Freespace 2\data\tango3_fs2.vp' with a checksum of 0x705e8d71
Found root pack 'C:\Games\Freespace 2\data\tangoA_fs2.vp' with a checksum of 0x2e10c984
Found root pack 'C:\Games\Freespace 2\data\tangoB_fs2.vp' with a checksum of 0x0a5f4659
Found root pack 'C:\Games\Freespace 2\data\warble_fs2.vp' with a checksum of 0xd85c305d
No idea what these are, but PLEASE put them some where else OUTSIDE of your FreeSpace2 directory.
Searching root 'C:\Games\Freespace 2\' ... 32 files
This indicates that there are some loose files being loaded from semowhere in the FreeSpace2 data dir that is not in a VP.
Requested WGL Video values = R: 5, G: 6, B: 5, depth: 16, double-buffer: 1
Actual WGL Video values = R: 8, G: 8, B: 8, depth: 32, double-buffer: 1
This suggests that your desktop is in 32bit Color mode, but you are launching the game in 16. Please set the game to launch in 32bit Color.
Compiling shader: null-v.sdr (null-v.sdr), null-f.sdr (null-f.sdr)
Shader in_error! Disabling GLSL!
Wokka! Error opening file (post_processing.tbl)!
Unable to parse 'post_processing.tbl'! Error code = 5.
Unable to read post-processing table! Disabling post-processing...
I don't see that you have -normal or -post_process in your command line options. But if you don't have and Shader (*.sdr) files in your FreeSpace2\data\effects folder, then "Disable Shader Support (GLSL)" in the launcher or manually enter -no_glsl in your command line options.
Additionally, while It should use default code to handle 640x480, I would recommend (if at all possible) playing in 1024x768.
-
Reported in the AP8 Thread:
Head .ani's are now permanently bright, whereas before hitting L was able to toggle them between bright and dim.
(As a side note, whenever they're shown, they still lag up the game. I'm going to guess that this is being worked on already)
My finding is that the border of the head.ani is adjusted, but not the full over-lay itself. No idea what is causing it to be reported as "bright" in Kolgena's post though.
L toggles between bright and dim, and the full overlay is stuck in bright mode.
-
I got back onto a different computer of mine and ran Training Mission 1 again on Ant 7 6775. The same issue arose.
The tangoN.vps were moved from the data 2 and 3 folders into the root data folder when they should not have been on that installation.
I am running a GOG install, mediavps_3612, and 6775.
Perhaps a picture?
(http://farm6.static.flickr.com/5170/5262577364_9ed72b3285.jpg) (http://www.flickr.com/photos/56368596@N07/5262577364/)
[attachment deleted by admin]
-
How do I fix the3 FS1 style hud? It gets all jumbled up in fsport.
-
Put this file in your FSPort_MediaVPS/data/tables file
[attachment deleted by admin]
-
Absolute saviour, thankyou. :)
-
Sorry to have caught this so late, but we don't tend to test ant builds for multi...
Asof the latest nightly (first one with ant7 included) we noticed that there are several problems with certain elements of the hud displaying, as a host you only really notice messages, so I'll poke mura to list everything he's noticed.
The Ping indicator is definitely one of them though.
-
Yup, i can testify for that. Using latest nightly and using ant 7 we got a few issues.
First, when you press 1-4 to send a message in game, it doesn't appear on the screen, so you can't really see what you are typing, also, when you die, you can't see the messages being displayed, and you still can't see what you are typing, I think it isn't working all together, since you can't see messages displayed, you can't see for yourself if you sent a message or not.
Second, the ping element that you normally see during gameplay as a client is nowhere to be found. It isn't entirely vital, but it certainly helps you to adjust how far ahead you should shoot.
That's all for all, there is a last thing, I think the LAG logo that flashes when over 400ms isn't flashing at all, but can't confirm as it seems this is intended behavior for over 1s lag and haven't tested further yet.
-
Ok. I'm about ready to start weeping. I can't get this to work. Could someone PLEASE tell me where the f*** I am supposed to put this code to make my f'ing HUD NOT looked all jacked up in 1680x1050? Or any other resolution?
I have tried running several different executables, and I tried extracting the RAR or whatever that had fonts.tbl and hud_gauges.tbl into my FS2/data/tables directory. WTF am I doing wrong?
P.S. And by all jacked up, I mean gauges being out of place and oriented incorrectly. Everything I do results in NO change whatsoever.
-
Ok. I'm about ready to start weeping. I can't get this to work. Could someone PLEASE tell me where the f*** I am supposed to put this code to make my f'ing HUD NOT looked all jacked up in 1680x1050? Or any other resolution?
I have tried running several different executables, and I tried extracting the RAR or whatever that had fonts.tbl and hud_gauges.tbl into my FS2/data/tables directory. WTF am I doing wrong?
You need to learn how to READ. Read this over and over again until you understand where you messed up and fix it yourself. (http://www.hard-light.net/forums/index.php?topic=72205.msg1426832#msg1426832)
-
You need to learn how to READ.
Hey. Asshole. Instead of being an antagonistic ****wad, you could a) simply answer my question, or b) point out WHERE in the post it tells me where to add the code. I've obviously already ****ing read it if I'm asking about it, you piece of ****.
I mean, wow. And here I thought I'd actually find some decent, friendly people here. My mistake.
P.S. To whom it may concern, I apologize for my language, but I was already frustrated by trying to figure it out myself and failing, but then to have some douchebag (not) answer my simple question in such a way... set me off.
P.P.S. And to clarify, I HAVE read it over and over. There are no instructions of the sort I am asking for, or at least, they are not readily apparent. The post DOES NOT state WHERE to add this code, and did not in the original post (the one linked to off the main SCP page).
---------------------------------
Apparently it doesn't work with FSPort, which was my problem, so I guess I'll just have to deal with it while playing that campaign?
I should have read further to learn this fact. However, the instructions I was originally looking for still don't exist. My familiarity with things like this enabled me to find the correct location, but... well, at least I learned not to ask questions or expect amiable or helpful responses from the people here.
----------------------------------------------
For those who don't know (as, like me, not everyone is proficient with coding and/or modding), rearranging the HUD elements will work in FSPort if you create the directory \*YourFS2Dir*\fsport-mediavps\data\tables (assuming you're using the MediaVPs) and add the appropriate .tbl files to it.
To percenipicek: thanks for nothing. DIAF please.
-
Asshole... ****wad... you piece of ****
... douchebag
... DIAF
<3
Always happy to have people like this on board.
-
Read this:
http://www.hard-light.net/forums/index.php?topic=72205.msg1439305#msg1439305
-
I mean, wow. And here I thought I'd actually find some decent, friendly people here. My mistake.
While I agree that pecenipicek's reply wasn't one of the most friendly or useful ones, your original post already had hostile tone in it. Which is understandable when you're frustrated, but it does tend to provoke hostile replies too.
For those who don't know (as, like me, not everyone is proficient with coding and/or modding)
There is a reason why this topic is located under "Test Builds" board. It is meant for testing, by those who are proficient enough. Average players shouldn't attempt to deal with testing assets, unless they want to learn at least basics of modding.
To percenipicek: thanks for nothing. DIAF please.
Now, you really aren't making things easier for yourself. Even if you feel offended, frustrated, angry, there is no need to return the favor and further escalate things.
You need to learn how to READ. Read this over and over again until you understand where you messed up and fix it yourself. (http://www.hard-light.net/forums/index.php?topic=72205.msg1426832#msg1426832)
As for you, you really could have handled your reply much better than that. Or not post it at all.
-
Getting really worked up about problems with test builds is counterproductive. If you don't want to start weeping because it's not working right, wait for the final release!
Though in this case, it's FSPort's fault.
-
In all honesty, it doesn't specify ins the instructions any where (such as they are) that the code for the hud gauges goes into a file named "whatever"-hdg.tbm (where "whatever is replaced with what ever you want to call it) or that the file in question goes into a data\tables directory (such as: "MediaVPs_3612\data\tables) in order to be used.
But then, that's why it is in test builds. While we want a lot of feedback, it's not a case of general user usage where said general user may not already be familiar with this (what developers have as basic) understanding.
-
However five posts up from louthelou's first post is a hud table for FSport and directions on where to put the table. He also didn't specify that he was having problems with FSPort.
-
Though in this case, it's FSPort's fault.
Yes and no; in general one shouldn't expect a feature still very much in testing to work with mods other than the one it was designed for. I doubt you would put experimental racing slicks on your car and then complain when it can't drive on gravel roads.
Even though FSPort has no responsibility to address compatibility until this feature has been finalized, community members have been kind enough to provide fixed data for us if you're willing to read the thread.
-
I apologize for losing my temper. I had spent not a small amount of time trying to make it work without asking for assistance, as I realized this, and things like it, don't necessarily work like a charm all the time and the vets here probably feel they have better things to do with their time than help every schmo who comes along saying, "It doesn't work! Halp me plz!", and not being able to figure these kinds of things out evidently really gets to me. My last resort was asking for help, and the response I got simply sent me in another circle, which really set me off.
Even given that, I should not have responded as I did, and I apologize for it. I'd also like to thank you guys for this whole thing, and for your time.
P.S. An extra apology to the moderators here. I will not conduct myself in such a way again, you have my word.
-
It's okay. But did it end up working?
-
apology accepted. HLP is a bit rough, but when you figure out how the community breathes, you'll fit right in :D
-
Indeed, I did get it to work. Getting the HUD elements to realign in FSPort (using the mediavps) required creating a \data\tables directory in the fsport-mediavps directory and adding the .tbl file there.
Probably something very simple... but for someone new to this, that was hell to figure out. ;)
-
Probably something very simple... but for someone new to this, that was hell to figure out. ;)
If you're new at this, you're not expected to. See "Test Builds" etc. But at least you've taken your first steps into a larger world. :)
-
so uhh, any news with the multi bugness?
-
Happy new year everyone!
Could someone please repost the hud-gauges.tbm for FSPort . There are no longer any working links in the associated threads.
TIA an greettings, Psychonaut
-
so uhh, any news with the multi bugness?
Which issue?
-
so uhh, any news with the multi bugness?
Which issue?
Reported here (http://www.hard-light.net/forums/index.php?topic=72205.msg1448112#msg1448112)
and here (http://www.hard-light.net/forums/index.php?topic=72205.msg1448115#msg1448115)
-
Not that I mean to sound impatient or anything, but Swifty; the multi crowd are the only people who give the nightlies a decent pacing on a semi-regular basis, we picked up a huge huge number of .11's bugs before they were set in stone, and your bugs are really preventing us from going beyond 6832, as the revisions trundle on, the less likely we are to spot bugs between the inclusion of ant7 and where-ever we end up by the time you fix this mate :<
Kind of a priority?
-
I've actually been working on this bug for about two weeks now. Assuming that this isn't a priority to me and saying I'm working too slow won't make the lines of code with the bugs in it reveal themselves any faster.
Regardless, I managed to find the culprit over the weekend and just pushed up a commit. Enjoy.
-
Thank you, to be honest if you had said you were working on it, it would've been enough, and I would have been happy to help out if you needed a guinea pig.
Based on how it's been so far this week this will probably be tested tonight ;o
-
There should be a nightly build for all platforms up within the next couple of hours.
-
Currently you can override directives and escort list with $Max Directives and $Max Escort Ships, but they are global settings and don't work flawlessly with all these new per-resolution and per-ship HUD configs. Hence could I please request that they would be configurable under #Gauge Config? That way you can set a good number for each specific HUD config, since one global value doesn't necessarily fit all configs used.
Thanks!
-
http://www.hard-light.net/wiki/index.php/Hud_gauges.tbl#.24Load_Retail_Configuration:_2
Says you can use $Load Retail Configuration under $Gauge Config, but only if you also specify $Ship.
Can we remove this requirement, please?
-
Hello chaps, on page 7 of the hud overhaul test build thread here:
http://www.hard-light.net/forums/index.php?topic=69858.120
hurleybird posted some code to fix the hud at 5760x1200, the problem is ive no idea what to do with the code
could someone give me some pointers
tnx.....
-
Sort of a necro, but did the issue where the Gun and Engine gauges don't get moved closer together when the ship doesn't have shields get fixed?
-
Sort of a Necro too, i was wondering if it was possible to add option via the hudgauge.tbl to set whatever in the hud has its position fixed to the ship and what move with your view when you use the track Ir?
it would help for creating cockpit with screen that hud's thing take place in.
edit: fixed a typo that could have caused a bit of a stir. --Chief
-
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.
-
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.
-
Ah, I see--thanks for the info :yes:
-
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.
-
$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).
-
That is not a bug. That just means that the teams responsible have to write hud_gauges.tbls to include that graphic.
-
I don't think it should work like that. It means Antipodes 7 breaking backwards compatiblity with a retail (though originally unused) feature.
-
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.
-
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?
-
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?
-
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.
-
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.
-
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.
-
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 :)
-
You should not be using Antipodes 7 anymore. The HUD code is already in 3.6.14 RC5. Use that instead.
-
Now if only we could get menus to scale properly, FS2 would be amazing in triple head!
-
agreed.
If menu stayed in its original 4/3 or 16/9 format but just centered it would be awesome.