Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Nightly Builds => Topic started by: SirKnightly on January 19, 2010, 01:46:40 am
-
Here is the nightly for Windows on 19 Jan 2010 - Revision 5828
Group: SSE2
fso-WIN-SSE2-20100119_r5828.7z (http://swc.fs2downloads.com/builds/WIN/fso-WIN-SSE2-20100119_r5828.7z)
MD5Sum (http://swc.fs2downloads.com/builds/WIN/fso-WIN-SSE2-20100119_r5828.md5)
Group: Standard
fso-WIN-Standard-20100119_r5828.7z (http://swc.fs2downloads.com/builds/WIN/fso-WIN-Standard-20100119_r5828.7z)
MD5Sum (http://swc.fs2downloads.com/builds/WIN/fso-WIN-Standard-20100119_r5828.md5)
Group: Inferno_SSE
fso-WIN-Inferno_SSE-20100119_r5828.7z (http://swc.fs2downloads.com/builds/WIN/fso-WIN-Inferno_SSE-20100119_r5828.7z)
MD5Sum (http://swc.fs2downloads.com/builds/WIN/fso-WIN-Inferno_SSE-20100119_r5828.md5)
Group: Inferno_SSE2
fso-WIN-Inferno_SSE2-20100119_r5828.7z (http://swc.fs2downloads.com/builds/WIN/fso-WIN-Inferno_SSE2-20100119_r5828.7z)
MD5Sum (http://swc.fs2downloads.com/builds/WIN/fso-WIN-Inferno_SSE2-20100119_r5828.md5)
------------------------------------------------------------------------
r5827 | Wanderer | 2010-01-18 08:58:45 -0600 (Mon, 18 Jan 2010) | 1 line
Changed paths:
M /trunk/fs2_open/code/freespace2/freespace.cpp
potential fix for mantis 2041
------------------------------------------------------------------------
r5828 | chief1983 | 2010-01-18 10:06:35 -0600 (Mon, 18 Jan 2010) | 1 line
Changed paths:
M /trunk/fs2_open/code/freespace2/freespace.cpp
M /trunk/fs2_open/code/hud/hud.cpp
M /trunk/fs2_open/code/hud/hudescort.cpp
M /trunk/fs2_open/code/hud/hudparse.cpp
M /trunk/fs2_open/code/hud/hudshield.cpp
M /trunk/fs2_open/code/hud/hudtarget.cpp
Fix for Mantis #1936: Per ship gauges should now work properly. From KK.
------------------------------------------------------------------------
-
Fix for Mantis #1936: Per ship gauges should now work properly. From KK.
Hooray! :D
-
If you're excited about that, _please_ test it and let me know how it goes. Test every aspect of that table you can. Let me know if you have any issues with it.
-
I won't be able to do any significant work until later this week but I will let you know how it works. I should be good at testing it - I can screw up just about everything. :p
-
Adding custom gauges VIA xxx-hdg.tbm does not work. It only works properly if you modify hud_gauges.tbl
-
I know the misc vars in xxx-hdg.tbm worked for me, can you use a previous build and tell me if the situation was any better? Not too late to revert this if so.
-
For some reason it doesn't work for me...
-
It's your patch :P
Double check the commit to make sure I didn't goof it up.
-
I'll compile my own version and do a debug. All I know is that the build I created the diff from worked, this one doesn't. Maybe something else in the code changed in the meantime I don't know. I'll have to check.
Edit: Gah.. forget it.. works fine. I had a bug in my table, that's all. Instead of removing the commenting of the necessary lines I removed ALL semicolons from the table, which of course resulted in buggy parsing (which the game never reported btw :P )
It works.
-
Yup, as I pointed out there is no parse error reporting for that table, I would love to see that addressed in the future as well. Might be something I could look into but I wouldn't hold your breath.
-
There's other stuff to be done first anyway ^^ The custom gauges need the ability to inherit a color of a standard gauge and one must be able to set whether a gauge moves in pan view or remains static.
I have that code pretty much ready, I'll adjust it to recent code changes and post a patch in the Mantis tickets later this week.
-
I know the misc vars in xxx-hdg.tbm worked for me, can you use a previous build and tell me if the situation was any better? Not too late to revert this if so.
The misc vars in xxx-hdg.tbm worked...
I've tested the xxx-hdg.tbm stuff on the Jan 1 2010 SSE2 Nightly (r5758). It seemed to work fine on that build. However, the tbm stuff doesn't work on this build (r5828.)
-
@chief: Can you check this one out next?
http://scp.indiegames.us/mantis/view.php?id=2076
-
We seem to have a problem with the previous patch, or with this guy's modular table. But since it worked before it seems to be a patch issue, shouldn't we get that sorted out?
-
We seem to have a problem with the previous patch, or with this guy's modular table. But since it worked before it seems to be a patch issue, shouldn't we get that sorted out?
Before we jump to conclusions, I'll just give r5824 a test... There's quite a difference between 5758 and 5828.
EDIT: Yep, the tbm worked properly on 5824, but not on 5828.
-
What exactly is the tbm supposed to do and what doesn't work / what happens? Can you post the tbm?
I find the concept of tbms not working when then standard file is working a bit strange. Shouldn't the tbm just replace or extend contents of the main table? Is the tbm parsing handled somewhere else?
-
Like I said, it's hard to know without any sort of parsing error reporting in this code. That would be really handy to help with this stuff. I have a feeling the tbl and tbm parsing are probably not tightly integrated though.
-
I just looked at the sourcecode. All the tbm parsing does is checking what the tbm is overriding and then passing it to the same parsing function that parsed the main table.
So this can't be a normal parsing error. Otherwise the normal table wouldn't work either.
I somehow suspect an error in the tbm that the earlier build simply let through without reporting an error and now causes a different result.
But without seeing such a tbm and know WHAT exactly doesn't work, I can't say anything.
-
Talon sent me a tbm and I sent him a test build back.
To be honest I think this entire hud_gauges parding was totally broken from the start. It does everything wrong.
I hope I fixed that stuff now.
Several important things when using this tbl:
if you specify gauge data fro a Default: resolution, then you must be careful when using a tbm. If the tbm tries to override stuff with a different resolution that will work, however all non-overriden stuff from the original table will be set back to default values since the engine cannot scale them correctly anymore since you reset the default resolution.
The same is true if you use a different resolution for ship gauges. That doesn't reset the default gauge, but the ship gauge won't be able to use any default data you declared earlier since you defined a different default resolution for that ship so it wouldn't know how to scale the default ones anymore. It can only handle one scale-resolution.
if you specifdy $Resolution: gauge data, that data will be used if the game res matches that resolution. Be aware that NONE of the Default resolution stuff will be used in this case. The engine cannot scale half of the data and use the other data unchanged. So if you defined stuff in the $Default: section and want to specify stuff for a specific resolution you need to define it ALL again. Stuff you won't define here again will use the standard values.
Same goes for tbms or ship data. You cannot mix $Default: and $Resolution: stuff. if $Resolution: matches, it and only it will be used. If you specify stuff in the tbm or for a ship using $Resoltution, nothing of the earlier defined $Default: stuff will be used anymore.
I hope this was clear somehow.
Before these changes the code was totally broken. Parent lookup didn't work under certain circumstances and $Resolution: worked totally wrong, in parts it tried to copy some memory onto itself even. As I said.. totally broken.
If Talon reports back that the new build works I'll post the patch on the Mantis ticket. Hopefull this will make the hud_gauges.tbl fully functional. From what I could see it didn't work at all as intended before...
Edit: One more thing I must mention since Talon used it wrong and it obviously isn't documented well in the Wiki:
If you declare a parent for a custom gauge, then you need to declare that gauge in the #Gauges section, not the #Main Gauges section.
Also you can only use gauges as parent that can be manipulated in hud_gauges.tbl. "center of reticle" is not one of those.
Any coordinates you define for a gauge that has a parent will be interpreted as coordinates RELATIVE TO THE PARENT. That means the parent's coordinates will be ADDED to the coordinates you specify. Be aware of this.
-
To make this even more clear: The corect layout is like this:
#Custom Gauges
$Name: MyParentGauge
+Default1024x: 100
+Default1024y: 100
+Parent:
$Name: MyChildGauge
+Default1024x: 10
+Default1024y: 5
+Parent: MyParentGauge
#End
#Main Gauges
$Default: (1024 768)
$Player Shield: (694 670)
$Target Shield: (232 670)
$MyParentGauge: (100 100)
#End
#Gauges
$Default: (1024 768)
$Gauge: MyParentGauge
$MyChildGauge: (347 219)
+Image: child_image
+Color: 175 230 175
#End
#Ship Main Gauges
$Ship: WhateverShip 107A
$Default: (1024 768)
$Player Shield: (694 670)
$Target Shield: (232 670)
$MyParentGauge: (100 100)
$Ship: WhateverShip 105B
$Default: (1024 768)
$Player Shield: (694 623)
$Target Shield: (211 670)
$MyParentGauge: (100 150)
#End
#Ship Gauges
$Ship: WhateverShip 107A
$Default: (1024 768)
$Gauge: MyParentGauge
$MyChildGauge: (347 219)
+Image: child_image
+Color: 175 230 175
$Ship: WhateverShip 105B
$Default: (1024 768)
$Gauge: MyParentGauge
$MyChildGauge: (347 219)
+Image: child_image
+Color: 175 230 175
#End
-
Keldor's new build worked. I've tested by parenting the text gauges in my tbm to their appropriate image gauges, and also by testing out the table/ANI in the mantis ticket.
-
Alright, I'll post the patch file for this in Mantis.
-
I just provided a final patch for this. Now percentage and size should work fine also. Also custom child gauge positioning might have been buggy before. That should be fixed now also. Talon confirmed the correct functionality.
Edit: Oh yeah btw... I know I'm somehow considered to be the big asshole in this forum, but MAYBE someone might think about saying something like "thanks, appreciated" to people who provide code and bugfixes without being on the team and without really having the time for it instead of telling that person how much '****' he's providing.
-
I made a comment about how I think the $Default res stuff has worked before in the ticket, please check that out.
-
I didn't change any $Default: behavior.