Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Test Builds => Topic started by: taylor on June 30, 2005, 05:07:01 am
-
Even FRED2 needs to be tested so here is a new build. I'm not really sure how much has been fixed (or broken) since the last build but this is the most recent stuff:
- fixed the sound index error (the "between 0 and 0" thing)
- fix crash on exit editing missions with jumpnodes in them
- make sure departure target dropdown gets populated properly in wing and ship editor and correctly saves the setting
- fix problem where only the first 30-40 or so sexps would have help listed for them
- finally get set-skybox-model sexp listed in FRED2, and it actually has help now too ;)
I think that both phreak and Goober5000 have made fixes as well but I didn't keep up with what they were since the last public test build. As usual, check for continued presence of old bugs or verify that they have been fixed, and report anything new.
http://icculus.org/~taylor/fso/willrobinson/20050630-FRED2-win32.rar
-
ships still may be rendering out of position. i could have sworn i fixed it, but its not working now. i think i changed my resolution from 1152x864 to 1280x1024 between those times, so the screwy aspect ratio may be screwing with some stuff.
-
Originally posted by taylor
Finally get set-skybox-model sexp listed in FRED2, and it actually has help now too ;)
That was listed before though :confused:
EDIT : Hmmm it appears it wasn't. Odd it worked for me.
EDIT 2 : Aha. I remember now. I entered the details in notepad cause there wasn't a version of FRED available when you first added this and because the SEXP shows up correctly after you do that I never realised that there was anything wrong with it :D
-
Originally posted by taylor
- make sure departure target dropdown gets populated properly in wing and ship editor and correctly saves the setting
WOW, it really seems to be fixed now. After all these years this incredible minor, but deadly annoying bug has been smashed *whipes a tear away*
Thanks four effort (again) Taylor :yes:
-
How'bout adding "open" button to the background editor, that let's you choose your skybox the same way you save/open missions. Could be a little more convienient than typing filenames ?
-
Actually, what I think would be best is (Eventually) for it to be possible to have a "starsystems.tbl" or somesuch that lets you define background elements of a mission (Maybe some other appropriate things as well). That way you just need to specify "Capella" in all missions set in Capella, and if you decide you want to tweak the background a little, changes take effect in all missions in that system.
-
wmc i don't care fopr that idea. while i do like the star systems table....missions will be taking place in more than one area of a given star system. maybe as part of the star system table, have capella 1, capella 2, capella 3...etc etc etc......so that each local of a given system can be seprate from the rest, though very much like it, just a bit different. ie...casualties of war took place in the upuaat system, but there were 6 locations in that system. know what i mean? god i hope my tired brain is conveying my thoughts properly. :)
-
I tried this out with my PI tables (which I use for all of my missions) and it doesn't really work at all. The area where things are rendered just shows a copy of what that part of the screen was displaying before along with a single grayed out title bar type box (hard to explain, can post a screenshot if needed). It also hides the mouse cursor. Might just be my tables, but they work fine on the old 3.65 version. There are some other bugs as well, but they have been around for a while so you probably know about them already.
Originally posted by Starman01
WOW, it really seems to be fixed now. After all these years this incredible minor, but deadly annoying bug has been smashed *whipes a tear away*
Thanks four effort (again) Taylor :yes:
Oh this stupid bug...yeah, thanks for fixing that. I remember seeing this way back in the original FS1 FRED. It was one of those things you never noticed but caused problems later on.
-
Try making a shortcut and adding the -fredhtl flag to it if you haven't already.
-
I'll try that out when I get home. I seem to remember that HTL was responsible for most of the FRED2 problems at one point though; do you think enabling it would actually fix things?
-
It may solve some problems and cause others. Remember that the team have had a year or two to solve the original HTL problems.
-
Also, CP, make sure your OGL drivers are up to date.
-
Well, that didn't work. The problem is still there. Any other ideas?
OGL drivers? Do you mean the video card drivers or the OGL dll files?
-
I dunno. Video card, I guess.
I had a problem where FRED refused to display anything in the playing field and would only show the toolbars. I think I fixed it by upgrading my drivers.
-
Originally posted by CP5670
I tried this out with my PI tables (which I use for all of my missions) and it doesn't really work at all. The area where things are rendered just shows a copy of what that part of the screen was displaying before along with a single grayed out title bar type box (hard to explain, can post a screenshot if needed). It also hides the mouse cursor. Might just be my tables, but they work fine on the old 3.65 version. There are some other bugs as well, but they have been around for a while so you probably know about them already.
When this occurs, you wouldn't happen to see a small blue rectangle at the bottom left or top left of the viewing area would you?
-
I dunno. Video card, I guess.
I had a problem where FRED refused to display anything in the playing field and would only show the toolbars. I think I fixed it by upgrading my drivers.
I guess I could try changing drivers, but the one I have isn't really old (77.13). The latest 77.72 official nvidia drivers have several problems (a rushed release for 7800 GTX support, basically) and I don't want to use those.
FRED2 3.65 works fine though; did you make a lot of changes to the renderer since then?
When this occurs, you wouldn't happen to see a small blue rectangle at the bottom left or top left of the viewing area would you?
Actually, I am getting exactly that at the top left. But it looks like the title bar of a window since it's surrounded by a gray border. My windows color scheme shows the title bars of unselected windows in a blue gradient.
-
Originally posted by CP5670
Actually, I am getting exactly that at the top left. But it looks like the title bar of a window since it's surrounded by a gray border. My windows color scheme shows the title bars of unselected windows in a blue gradient.
OK. Your problem is in a debug error. Basically, the debugger has caught a parsing error, or a missing effect, or something. When the FRED debug catches something like this (assuming it doesn't crash the program), it kinda minimizes the viewing area. The solution (other than fixing your debug problems) is as follows:
1. As best as you can given that you can't see your cursor, move it over the blue rectangle and double click. This should result in the box moving/disappearing and being replaced by a mini-grid that looks like the FRED display area, but about the size of the previous blue rectangle. This new mini-grid should either be at dead center, or one one of the 2 left corners of the display area.
2. Again, as best as you can given that you can't see your curser, move it (your cursor) to the top right hand corner of your screen (I'm assuming standard default Windows BTW) and reduce FRED to window mode (IE, not maximized, or minimized, but windowed). You should then see the grid return to fill up the viewing area, in the window.
3. Maximize FRED and continue as normal.
If this doesn't work... well, then you're kinda stuck with fixing the debug errors.
Hope this helps.
-
Thanks for the information; yeah, I get two debug errors with my ships.tbl. I followed that procedure and the full grid came up, but the mouse cursor still keeps getting hidden when I move it into the window so I still can't really do anything.
I can't think of a way to fix those debug errors and they are not really problems at all anyway. Basically, it's an issue with the position of some $Stealth tags. If this flag is used, FS2 doesn't care where it appears in the ship entry, but I think the debugger wants to see it right between $Score and $Trail. The problem is if there are no trails for the ship (I'm using it for those Polaris dock pylons, which behave like cargo), it will give errors regardless of where you put it.
-
Originally posted by CP5670
I can't think of a way to fix those debug errors and they are not really problems at all anyway.
Actually, they are problems. They were just never enforced before. FS2 cares, but doesn't complain if you get it wrong - it just fails silently.
The correct order of the optional tags is $Score, $Thruster Bitmap #, $Thruster Particles, $Stealth, $Trail, and the subsystem list.
-
I already have the things in that order (only Score and Stealth appear). The debugger is looking for more than that. It's either like I said earlier or it does not want $Stealth to be the last thing in the list, and it's impossible to satisfy both that requirement and the optional tag order you listed.
Anyway, the stealth effect works fine in the game, which is all that really matters.
I seem to recall that there was some command line option for suppressing these debug messages. Anyone remember what that was?
-
-nowarn IIRC but it's generally a really bad idea to use it.
-
No, that isn't recognized. I will search around the wiki and see if I can find it.
[edit] The wiki command line says it is -fred_no_warn, but that isn't it either. Simply -no_warn doesn't give any unrecognized option error so that might be it, but it doesn't do anything.
I would like to fix the table "error" but as I said before, it's impossible to do that at the moment. I looked over the debug message again and looks like $Stealth is just not in the debugger's list of valid flags at the end of a ship entry, which is really an issue with the debugger.
-
My FAQ says no_warn and I remember checking my facts when I wrote that piece of info. Either the function is broken or has changed its name.
-
You're thinking of the FRED command line to stop it from complaining if the player ship is a capship,
Try "-noparseerrors", that will restore lax table parsing. Still, like Goober says it's best to actually fix the problem; fs2_open has some minor order-correction stuff in the parsing code but I wouldn't trust it.
The problem you're having is that there's actually a ":" after "$Stealth" in the code. It should really be a ship flag, and not an extra tag, but for now, if you add the : onto the end of your stealth it should work. If not, post the three entries ($Stealth, entry before, entry after) with the data and that should help it get debugged. If you have any outrageous comments that totally spoil your campaign's ending you can go ahead and remove them. :p
-
That colon seems to have done the trick nicely. Thanks. If it needs the colon though, how come it doesn't complain about the original $Stealth flags for the Pegasus and Ptah?
I was using this stealth feature for the polaris pylons, those framework pieces Dark made that have been around since FS1. These things are generally used in large numbers and I don't want them cluttering up the radar and target list.
-
Because they both have the : on the end. :p
Apparently it's a voltion thing :wtf: :sigh:
-
Might be nice to make it more user-friendly though. What about changing the string check to accept both "$Stealth:" and "$Stealth"?