Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Test Builds => Topic started by: Goober5000 on July 08, 2006, 10:29:19 pm
-
http://fs2source.warpcore.org/exes/3.6.9-RC5.rar
Blah, blah, blah. Plus voice synthesis and recognition.
mv_alphapatch.rar (http://fs2source.warpcore.org/mediavp/mv_alphapatch.rar)
mv_advalphapatch.rar (http://fs2source.warpcore.org/mediavp/mv_advalphapatch.rar)
EDIT(taylor): Build updated with both Goober's and my changes. Should have all of my fixes plus speech and voice recognition.
-
BASTARD!! I just hit the server to upload mine, and what do I find, IT'S ALREADY THERE!!. :p
I knew I should have waited to go to the bathroom. ;)
Oh well, I'll just put it in the second post, and you can move/replace it if you want. :D It's current CVS, and has speech, but not voice. But it has code which isn't in CVS yet, and a new Launcher, so I don't want to start a new topic for it.
New changes to build and Launcher, it requires OpenAL 1.1 now, and will tell you if you don't have it. Also, some changes to application window creation, modification (ie, going fullscreen/mimized), and destruction, mainly for OpenGL. Plus some movie fixes that will hopefully get AVI movies working in OpenGL, even fullscreen, without it going bonkers. Oh, and it has the animated glowmap endless-loop/div-by-0 fix too, which isn't in CVS for another few minutes. Plus the optimizations are a bit better so hopefully the release builds will be faster/smaller, but still not have the Y-bug.
(EDIT: Original RC5 build in first-post updated with same changes from both builds)
-
:lol:
Well, people have been clamoring for voice recognition for a while. :D Can you rebuild with all voice stuff activated (FS2_SPEECH, FS2_VOICER) and call it 5.2?
-
Rebuilding now. I'll just replace your original RC5 file (renaming it to RC5.0 so that it's saved) and remove my RC5.1, since it won't really be needed anymore.
EDIT: Done! :D
-
this looks like a build worth moving to.... :nod:
-
Hey, about missions in simulator:
+ There are no "holes" in played mission list anymore.
+ Ctrl+Shif+S does work in mission list (no need for -allslev anymore).
GREAT WORK :yes:
-
Some ships are FUBARed.
Most animated glowmaps are going much too fast, generating a "flickering" effect that is not likely a feature. The ships in which this is most apparent are:
-Anuket
-Nephilim
-Nahema
-Seraphim
-Azrael
-Mephisto
-Asmodeus
-Lilith/Cain
-Rakshasa
-Demon
-Ravana
-Trident
-Moloch
-Sathanas
-SpaceHunk
-CommNode
For some reason, Shivan Fighters seem to have more normal speed animated glows. Which leads me to believe that in this build, any glowmap is repeated inside a certain, invariable timeframe. This probably leads "shorter" glows, those with less frames, to appear as super-fast.
Does this has something to do with some added code that makes the Cloaking/Decloaking Pegasus glowmaps work? Which, I'm not sure that they work either, but I haven't seen them before so I don't know what they are supposed to be like... But the Shivan glows go through WAY too fast in this build.
RC4 plays them properly.
Additionally, there WAS a glitch that for some reason made more than half of the Setekh and Hatshepsut disappear (specifically, the parts where there were glowmaps), but that disappeared when I restarted the game... and now they show themselves properly. :confused:
-
Some ships are FUBARed.
Most animated glowmaps are going much too fast, generating a "flickering" effect that is not likely a feature.
I think your answer is here (FYI thread) (http://www.hard-light.net/forums/index.php/topic,40847.0.html)
It seems all media vp animations must be fixed as they were tuned with a buggy playing code.
-
So... until the animations are redone, what point is it putting this new fix into builds? :wtf:
I'll not be able to use that build anyway because the animations are too fast. And I bet quite a few others will also keep to RC4/other build in which the animations work... And while this RC5 build can't be used, all its other advantages are also unavailable to users.
So, are you going to hold the official 3.6.9 release build until official, fixed 3.6.9 mediavp's? Or is there going to be another effects patch for 3.6.8zeta VP's?
-
Got the following on TSM-104.fs2. Crashed _r but allowed continuation on _d
Warning: Couldn't fix up turret indices in spline path
Model: cruiser01x.pof
Path: $path02
Vertex: 1
Turret model id:13
This probably means that the turret was not specified in the ship table(s).
File:C:\temp\fs2_open_3_6_9.rc5\code\ship\Ship.cpp
Line: 8473
[This filename points to the location of a file on the computer that built this executable]
Call stack:
------------------------------------------------------------------
parse_create_object_sub() parse_create_object() mission_did_ship_arrive() mission_maybe_make_ship_arrive() mission_eval_arrivals() mission_parse_eval_stuff() game_simulation_frame() game_frame() game_do_frame() game_do_state() gameseq_process_events() game_main() WinMain() WinMainCRTStartup() kernel32.dll 7c816f97()
------------------------------------------------------------------
Warning: Couldn't fix up turret indices in spline path
Model: cruiser01x.pof
Path: $path02
Vertex: 2
Turret model id:13
This probably means that the turret was not specified in the ship table(s).
File:C:\temp\fs2_open_3_6_9.rc5\code\ship\Ship.cpp
Line: 8473
[This filename points to the location of a file on the computer that built this executable]
Call stack:
------------------------------------------------------------------
parse_create_object_sub() parse_create_object() mission_did_ship_arrive() mission_maybe_make_ship_arrive() mission_eval_arrivals() mission_parse_eval_stuff() game_simulation_frame() game_frame() game_do_frame() game_do_state() gameseq_process_events() game_main() WinMain() WinMainCRTStartup() kernel32.dll 7c816f97()
------------------------------------------------------------------
Warning: Couldn't fix up turret indices in spline path
Model: cruiser01x.pof
Path: $path02
Vertex: 3
Turret model id:13
This probably means that the turret was not specified in the ship table(s).
File:C:\temp\fs2_open_3_6_9.rc5\code\ship\Ship.cpp
Line: 8473
[This filename points to the location of a file on the computer that built this executable]
Call stack:
------------------------------------------------------------------
parse_create_object_sub() parse_create_object() mission_did_ship_arrive() mission_maybe_make_ship_arrive() mission_eval_arrivals() mission_parse_eval_stuff() game_simulation_frame() game_frame() game_do_frame() game_do_state() gameseq_process_events() game_main() WinMain() WinMainCRTStartup() kernel32.dll 7c816f97()
------------------------------------------------------------------
While it allowed continuation on the debug build, graphical corruption akin to the opengl -env corruption occcured (yes, I have one of _those_ ATI cards, and yes I'm running -disable_fbo) save that it's a reflective corruption (as in, the corrupted spots react to explosions/etc just like an -env mapped ship) as well as random flashes into white occuring across bizare segments of the screen. Further corruption carries on into the next TSM (TSM-105.fs2).
Constant attempts to reload TSM-104 in _r met with failure, even after successfully passing it under _d, but I can load _r at TSM-105.fs2 and so far is playing just fine. (now up to The Great Hunt with no other issues.)
However, I did notice this in FS.LOG and normally would think nothing of it, except I made sure I had the latest OpenAL installed.
Initializing OpenAL...
Using 'SB Audigy 2 Audio [B000]' as OpenAL sound device...
OpenAL Vendor : Creative Labs Inc.
OpenAL Renderer : SB Audigy 2 Audio [B000]
OpenAL Version : OpenAL version 1.0
----------and then further into the file:----------
SOUND: C:\temp\fs2_open_3_6_9.rc5\code\sound\audiostr-openal.cpp:1323 - OpenAL error = 'Invalid operation attempted.'
..........
SOUND: C:\temp\fs2_open_3_6_9.rc5\code\Sound\ds.cpp:3631 - OpenAL error = 'Invalid operation attempted.' (this one exists 3 times)
..........
SOUND: C:\temp\fs2_open_3_6_9.rc5\code\sound\audiostr-openal.cpp:1137 - OpenAL error = 'Invalid operation attempted.'
I even uninstalled my slipstreamed drivers for a fresh install of the regular Creative drivers and OpenAL 1.9.1 package (which is 1.1). Theoretically, that should be no different from my slipstreamed drivers as I updated the OpenAL32.dll and wrap_oal.dll in the driver package with the ones from the OpenAL package. (The fs.log is from loading TSM-104)
-
So... until the animations are redone, what point is it putting this new fix into builds? :wtf:
Because if we don't put it in the builds no bugger ever bothers to change things.
Look at all the complaints we're getting about graphics files with bad alpha channels even though Taylor had spent months telling people to use the alpha correctly.
-
Valid point. I stand corrected. ;)
-
With this and the two previous RCs, the briefing music will run normally for a random amount of time, and then sort of stutter, lag the game up for a few seconds, and then dissappear. The game is unaffected, and ingame music doesn't seem to be affected thus far, it's more of an annoyance than a serious glitch, but any chance anybody'd have a solution?
-
When I use this build my shields will not recharge at all, the only way to restore shields is to call in a support ship. This doesn't happen with RC4.
-
Same here. Increasing the shield energy had no effect at all although the energy allocation system itself still works.
Apparently it's broken in CVS "fs2_open_r-P420060708" too.
I've just MANTISed it as bug 0000980.
-
hi,
and the bug, that the desktop use the gama setting of FS2 after ending, is back too.
Mehrpack
-
Is it just me, or does a Corvette - or vessel of comparable size - appear when not fully through its subspace portal, as in the back-end will appear when it isn't actually out of the portal yet?
-
and the bug, that the desktop use the gama setting of FS2 after ending, is back too.
Really? I didn't remove that, but I did change the order it's reset in when you exit the game. I'll try to tweak that up and get it working properly again for the next build.
Is it just me, or does a Corvette - or vessel of comparable size - appear when not fully through its subspace portal, as in the back-end will appear when it isn't actually out of the portal yet?
I noticed that too yesterday. Not sure why it's doing that, or when it started. I don't remember it being that obvious for a while though.
With this and the two previous RCs, the briefing music will run normally for a random amount of time, and then sort of stutter, lag the game up for a few seconds, and then dissappear. The game is unaffected, and ingame music doesn't seem to be affected thus far, it's more of an annoyance than a serious glitch, but any chance anybody'd have a solution?
There is already a Mantis bug about this. The problem is that I can't recreate it and I can't find a reason why it happens.
Regarding the OpenAL error messages, just know that I have an absolutely insane amount of error checking in there. To say I went overboard with that is a vast understatement. There are going to be warning/error messages for just about everybody but 90% of them will be completely harmless. The audiostr-openal.cpp errors that you saw were related to some strange sound context issue (what may be causing the briefing voice thing) but I haven't been able to fix it yet for some reason.
As far as the too-fast glowmaps go, like karajorma said, if we don't do it now then they will be broken indeffinitely. Remember that we are about ready to release 3.6.9 officially so if we don't go ahead and fix this now in code then the data can't change or it's still wrong. I am working on all fixed/tweaked glowmaps and will post them when I'm done (probably tomorrow).
-
Is it just me, or does a Corvette - or vessel of comparable size - appear when not fully through its subspace portal, as in the back-end will appear when it isn't actually out of the portal yet?
I noticed that too yesterday. Not sure why it's doing that, or when it started. I don't remember it being that obvious for a while though.
Well I do remember it being so obvious for ages (I think for ever). I have just tested 20060323 and it's the same. I've also tried a build from january and other from february but it crashes I suppose because of initial stuff in turrets.
-
I haven't noticed the tail end of ships being visable while warping in until RC5. Granted, I started with 3.6.7 and kept it until RC1 was released and I haven't tested any of the CVS builds.
And yes, you can target nodes in this build since RC4.
I am also having the no shields regenerate problem as well.
-
I wonder if you can target nodes in this build. I noticed something for quite some time though. In the tech database in the ships section, no matter what campaign you are using, the only ships that are being displayed are from the Ulysses through the Hatshepsut or the Myrmidon through the Hatshepsut. The Shivan ones aren't being displayed in the tech database
Where did you get the idea that they are meant to be displayed?
If you've never played a mission where they were added to the techroom they won't be displayed unless the tables say that they should be.
-
Really? I didn't remove that, but I did change the order it's reset in when you exit the game. I'll try to tweak that up and get it working properly again for the next build.
[...]
hi,
aha, doesnt know that, but i works, so that if i ending the game the desktop had his normal gamma.
the only time if i had the wrong gamma was, when the game crash to desktop.
another question: its possible to adding a slider or dropdownmenu for FSAA in the luncher, maybe?
Mehrpack
-
I've got shield recharge problems with this build too. It doesn't seem to stop, it's just reeeeeeallly slow.
The 'ship sticking out the back of the vortex' problem has been more or less present with different ships for a long time. Most work fine, but some have always had their ass visible behind the vortex. I don't know enough about how it works to suggest a solution.
-
another question: its possible to adding a slider or dropdownmenu for FSAA in the luncher, maybe?
Someday, but not soon. I've got code for it but it's post 3.6.9 at the earliest. And it's enough of a change that I'll probably wait until after I finish some of the newer OpenGL code before I try and merge it in.
-
I just got a new laptop HP pravilion dv8210 with a AMD Turion 64 processor and ATI Radeon express 200M 128mb graphics card and I have a total of 1.25Gb ram, though 128mb of it i'm sharing with the graphics card.
on my other computor I ran evreything on Open GL because Direct3D8 was ran as a silde show but on this computor I found Open GL to be slow and D3D8 to be just fine. The only problem though is that evironment lighting doesnt seem to work on Direct 3d8 mode and when i select environment maping not only does it do nothing but the clear cockpits turn white. Is this a problem with direct 3d or could it be something i could fix?
-
Currently, there are close to nothing but problems in D3D mode, as far as I know.
What I would do is to first try OpenGL with different builds of FS_Open, and if the OpenGL mode still didn't work, I would try to install either newer or older drivers for the graphics card and try the OpenGL mode with different driver versions. If it still didn't work, I would only then turn on the D3D.
As for D3D, I don't think it has been actively supported in a while, so the latest mediavp's for example will quite likely cause bugs like the white cockpit glass and stuff. If you have to use D3D, get an older build and older media_vp's, they *should* work...
I don't understand why OpenGL shouldn't work on your laptop.
-
realy thats odd. as far as models were concerned I thought D3D8 looked alot better, why hasnt it been supported? Id rather not revert back to old drivers, that could posably cause trouble, but who knows. As I said D3D is fine on 1024x768 resolution and if i lower the ambiance it looks great. I guess i could live with out env maping. I tried use specular alpha env mapping and that seems to have ok results. oh well.
When i say Open Gl is slow it particularly slows down when ever a high poly model shows up. I already tryied pre-pofspewing. D3D doesnt have this problem
even on low resolutions
-
realy thats odd. as far as models were concerned I thought D3D8 looked alot better, why hasnt it been supported?
For a very simple reason: we don't have any active D3D8 programmers.
Find us a programmer who's willing to maintain D3D8 and we'll be more than happy to support it again.
-
... as far as models were concerned I thought D3D8 looked alot better ...
Which often times has more to do with video drivers (especially where ATI is concerned) than you might think. Often the drivers are optimized for speed over quality, and the quality can vary wildly even between driver versions. Sometimes it will look really bad, other time it will look great. Make sure that your drivers are actually setup for good quality in OpenGL before just writing it off as a basic OpenGL quality issue.
-
I think most of the image quality differences between D3D and OGL stem from the fact that they use different default values for the ambient factor (or possibly interpret the same value differently). If you adjust that properly, it will look practically identical in both of them.
I do agree that the high poly models occasionally slow down the game too much (the Hecate model is a good example), but from what I've seen that also happens under D3D and on both green and red cards.
And the image quality differences between driver versions are very subtle unless there is a bug. I doubt you could tell without comparing screenshots side by side. There are sometimes significant speed differences, but the only IQ differences will come from bug fixes or changes in the default settings that can be easily adjusted back to the old configuration.
-
Indeed. I make it a habit whenever ATI moves from one version number to the next (Say, 5.x to 6.x) to getting ALL of the drivers in said (5.x) series and then testing them on my card. It takes about 2-3 weeks, is often frustrating, boring and intensive as hell, but I _know_ beyond a doubt that whatever driver get's settled on is the best for my machine.
Don't forget that for driver settings (ATI COntrol Panel or Catalyst Control Centre *shudder*) some options are tied to BOTH forms of rendering. I've noticed the best results in OpenGL games with AA and AF if D3D is set to the same level as OGL, even if the game isn't even D3D capable. It's strange, but true.
-
Indeed. I make it a habit whenever ATI moves from one version number to the next (Say, 5.x to 6.x) to getting ALL of the drivers in said (5.x) series and then testing them on my card.
AFAIR the ATI drivers version is made of year and month of their release. So change from 5.x to 6.x doesn't mean that there are some revolutionary changes.
-
... as far as models were concerned I thought D3D8 looked alot better ...
Which often times has more to do with video drivers (especially where ATI is concerned) than you might think. Often the drivers are optimized for speed over quality, and the quality can vary wildly even between driver versions. Sometimes it will look really bad, other time it will look great. Make sure that your drivers are actually setup for good quality in OpenGL before just writing it off as a basic OpenGL quality issue.
unfortionatly if I do that for open GL it would run slower than ever. I think i should just wait till the next driver update and see what happens
-
unfortionatly if I do that for open GL it would run slower than ever. I think i should just wait till the next driver update and see what happens
Exactly how slow is it? What FPS are you getting for OpenGL and for D3D?
-
In open GL mode framerate is real good somewhere around 50 then as soon a high poly herc or alot of ships come into view it will drop down to 5.
In Direct 3d It wil go as high as 60 frames and then drop to a reasonable 30 frames when alot of action is taking place.
-
Hey, about missions in simulator:
+ There are no "holes" in played mission list anymore.
+ Ctrl+Shif+S does work in mission list (no need for -allslev anymore).
GREAT WORK :yes:
I have just noticed that unavailable missions are still unavailable. In pre-RC5 builds sometimes you get blank lines instead of them. Now these lines are erased (so I thought there were no holes), but you still can't access them.
Example: Due to "Replay mission" bug, I cannot access "The Stars are Right" in my new Derelict pilot. In RC4 I got a blank line in its position, in RC5 its line doesn't appear.
Is it a bug? or is it done in this way by design?
(Nevertheless if I press Ctrl+Shift+S I get the full list even "missing" missions, as expected)
-
is anyone else getting a hard ctd without explanation on script errors? a script i was working on for a new lead indicator, which ran fine on rc4, caused a crash under this build, and didnt give an explnation.
-
I am having a problem where my Alt+Pause doesn't work in the Freespace 2 main campaign, not sure if this is a bug or not or if there is another reason, i dont' play the main campaign very much.
-
Also, there is a bug with alt-tab switching to the desktop causing BSODs on windows intermittently (not every time) in the nvidia minport driver since around the last couple builds.
-
In open GL mode framerate is real good somewhere around 50 then as soon a high poly herc or alot of ships come into view it will drop down to 5.
In Direct 3d It wil go as high as 60 frames and then drop to a reasonable 30 frames when alot of action is taking place.
Yea godz. You _start_ at 50? And it drops to _5_? That is bad. Do you have vsync enabled or disabled?
With vsync enabled on my system I start at 85 and maintain it pretty consistantly. The lowest it's ever droped to is 45. Without vsync I start at 120 and rarely drop below 80. (40 fps is still pretty significant a drop though.)
-
I have just noticed that unavailable missions are still unavailable. In pre-RC5 builds sometimes you get blank lines instead of them. Now these lines are erased (so I thought there were no holes), but you still can't access them.
Example: Due to "Replay mission" bug, I cannot access "The Stars are Right" in my new Derelict pilot. In RC4 I got a blank line in its position, in RC5 its line doesn't appear.
Is it a bug? or is it done in this way by design?
The holes were a bug by itself, but merely a cosmetic one. The holes were created by missions which shouldn't be shown because they weren't previously completed, but they would still count in the addition to determine where the next entry should go. This was as issue for banch or alternate version missions since there would be a blank line for them. If the mission isn't marked as completed then it shouldn't show up, but the bug caused there to be a blank line.
So, the "replay mission" bug is causing an issue for you where the mission is unavailable, but the blank line thing was a different bug and only related to it in a cosmetic sense.
I am having a problem where my Alt+Pause doesn't work in the Freespace 2 main campaign, not sure if this is a bug or not or if there is another reason, i dont' play the main campaign very much.
Works-For-Me.
-
I am having a weird problem with this, and other builds (Both CVS and This) after the 20060702 CVS build. The player ship's shields do not recharge after taking hits, they just remain damaged after a battle, and when they go down, they stay down.
Anybody else have anything like this happening? I am using Lightspeed's Weaponpack but, I doubt that would really matter. I have 3.6.8 Zeta
-
The problem with shields will be fixed in the next build (it's fixed in CVS now).
-
I just figured out that in the RC5 build the mantis bug #0000853 has come back. Additionally what I posted back then, I can't also play briefing and debriefing wavs anymore. You might want to reopen that mantis bug then again :) (if I'm not the only one with that problem)
-
can anyone confirm if Speech Recognition is working again? i would assume if it still wasnt it wouldn't be in the build. I'd download it and find out myself, but by the sounds of it i'm better off sticking to RC4 for the moment.
-
can anyone confirm if Speech Recognition is working again? i would assume if it still wasnt it wouldn't be in the build. I'd download it and find out myself, but by the sounds of it i'm better off sticking to RC4 for the moment.
Read the first post, dude...
-
For some reason the sound is not working when I launch the game but in RC4 everything worked just fine.
-
For some reason the sound is not working when I launch the game but in RC4 everything worked just fine.
Run a debug build and post the fs.log file somewhere that I can look at it.
-
Here.
http://rapidshare.de/files/25681382/fs.log.html
-
Here.
http://rapidshare.de/files/25681382/fs.log.html
Make sure that you have OpenAL 1.1 installed, you should have gotten a message box which said as much. It can be download from here (http://developer.creative.com/articles/article.asp?cat=1&sbcat=31&top=38&aid=46&file=OpenALwEAX.exe). If you have already installed OpenAL 1.1, and have an NVIDIA motherboard, then be sure to (re)move nvopenal.dll from your c:\windows\system32 directory as it will force the OpenAL version to be 1.0.
-
Here.
http://rapidshare.de/files/25681382/fs.log.html
Make sure that you have OpenAL 1.1 installed, you should have gotten a message box which said as much. It can be download from here (http://developer.creative.com/articles/article.asp?cat=1&sbcat=31&top=38&aid=46&file=OpenALwEAX.exe). If you have already installed OpenAL 1.1, and have an NVIDIA motherboard, then be sure to (re)move nvopenal.dll from your c:\windows\system32 directory as it will force the OpenAL version to be 1.0.
Are you sure ? I have that file in my system32, and after I installed OpenAL 1.1, it's still there, but there is no warning message and freespace open runs normally...
-
Thanks, now its working just fine, is there any command line to show all ships in the techroom and all levels (since -allslev is not recoginsed anymore)?
-
Thanks, now its working just fine, is there any command line to show all ships in the techroom and all levels (since -allslev is not recoginsed anymore)?
Read the thread. It's mentioned in the sixth post on the first page.
-
Thnaks again, but is there nothing for the techroom?
-
Are you sure ? I have that file in my system32, and after I installed OpenAL 1.1, it's still there, but there is no warning message and freespace open runs normally...
I've heard that it can, but techically nvopenal.dll should be completely ignored by the OpenAL 1.1 drivers. NVIDIA abandoned the extra interface, at least temporarily, and that NVIDIA specific lib shouldn't be used except by OpenAL 1.0 (which some software may actually use if they don't use the system version of the dlls). If you have OpenAL 1.1 installed and it works fine, regardless of nvopenal.dll, then don't worry about it. If it happens to cause a problem (it may, but shouldn't) then remove it.
Thnaks again, but is there nothing for the techroom?
Same key-combo works everywhere (simroom, techroom, and where ever else we later decide to need/use it).
-
I thinkt the absolute biggest problem in the recent builds is the way that ships look when they're warping in. They now start showing their ass about halfway through coming through the warp animation which looks totally unrealistic and ruins the effect. That should be a #1 priority to fix - it happens on all ships larger than fighters (crusier class and up)
-
I thinkt the absolute biggest problem in the recent builds is the way that ships look when they're warping in. They now start showing their ass about halfway through coming through the warp animation which looks totally unrealistic and ruins the effect. That should be a #1 priority to fix - it happens on all ships larger than fighters (crusier class and up)
I've actually been working on this the past couple of days. The problem is that it's only some of the hi-poly models, and retail models work perfectly for me. That would indicate a model problem, since all of the problem models appear to have an incorrect radius specified, but I can't seem to replicate a working effect through code/data manipution. I was able to fix it by adding some time to the timestamp for moving past the second stage warp (where it removes the clip plane), but that could be considered a model bug. So, is it a code bug, or is it data related? That's pretty much where I'm at right now and I can't decide which option to focus on. If you, or anyone else for that matter, can figure out exactly which RC (or other) build this started with then that would be a big help.
-
Heh. Recursive bug hunt, eh? Count me in on it.
*Edit: Using "Rebels and Renegades" as a template, the GVCv Asar (GVCv Sobek) clips the arse visible on warp-in on all RC builds. Testing redmenace standard builds since 20060601 now.
*Edit 2: Same behaviour all of the way back to 20060601 Redmenace Standard builds. I made sure to make a new pilot for every build and I'm running 3.6.8z's with taylors 20060710 updates.
C:\Games\FreeSpace2\fs2_open_r.exe -mod mediavps -spec -glow -env -jpgtga -mipmap -nomotiondebris -2d_poof -no_vsync -cache_bitmaps -dualscanlines -targetinfo -orbradar -rearm_timer -ship_choice_3d -3dwarp -warp_flash -snd_preload -disable_fbo -alpha_env -fps -ambient_factor 0.75 -spec_exp 11 -spec_point 0.6 -spec_tube 0.4 -spec_static 0.8
I also noticed in testing that _some_ of the rm cvs builds (but not all and not greater than 50%) managed slightly higer FPS than the RC's. Namely 20060615 and 20060712, though 20060712 seem's a little washed out in terms of overall lighting (seems to disregard the -ambient_factor that was set.) I can tolerate that though, as shields now recharge.
-
I also noticed in testing that _some_ of the rm cvs builds (but not all and not greater than 50%) managed slightly higer FPS than the RC's. Namely 20060615 and 20060712, though 20060712 seem's a little washed out in terms of overall lighting (seems to disregard the -ambient_factor that was set.) I can tolerate that though, as shields now recharge.
For a slightly-better-than-RC5 build, grab http://icculus.org/~taylor/fso/testing/multi_test.rar. It's RC5 plus various fixes that aren't in CVS yet, plus fixes that are (like the shield fix).
-
Grabbed. Grokking now.
edit: HOLY CRAP! Slightly? Only slightly? I'd hate to see what a complete overhaul would do.....er wait, that is what you're doing, n/m.....
This blows anything else away FPS wise. The only time any staggers occur are during the first time use of beams firing or shockwaves or if it still hasn't either created the IBX or copied it out of the vp yet. And the "stagger" is less significant of an FPS drop than before and it recovers from it FAR quicker.
And YAY! I can see Pharos Becons now! RC5 and 20060712 with the mp-710's for some reason were not displaying those.
-
Another serve of HOLY CRAP: massive performance improvements, no stuttering regardless of activity, all good. The Hippocrates LODding seems broken (no lighting at 800m, lod0 not till 400m). It's a fantastic improvement performance wise! :D
-
The Hippocrates has absurd values for its detail distance in ships.tbl. This has nothing to do with the build itself.
-
For a slightly-better-than-RC5 build, grab http://icculus.org/~taylor/fso/testing/multi_test.rar. It's RC5 plus various fixes that aren't in CVS yet, plus fixes that are (like the shield fix).
Taylor, this build suffers the RC2>RC3 performance drop (Mantis 961) (http://lore.maxgaming.net/~scp/mantis/bug_view_advanced_page.php?bug_id=0000961).
OTOH animation speed seems to be fixed. Keep on it :yes:
-
If there's any kind of performance drop, I don't notice it. On 8xS AA, 16x AF, Trilinear mip mapping and high quality settings on GeForce 6600, ti gives FPS in range of about 40-60... and if I lower the AA setting to 2x or 4x, the FPS hits the VSync limiter practically continuously.
Good work, I dare say. :)
-
If there's any kind of performance drop, I don't notice it. On 8xS AA, 16x AF, Trilinear mip mapping and high quality settings on GeForce 6600, ti gives FPS in range of about 40-60... and if I lower the AA setting to 2x or 4x, the FPS hits the VSync limiter practically continuously.
Good work, I dare say. :)
Have you tried that particular mission (Derelict: "The Stars are Right")?
-
Just tried...
It seems that that "particular" mission is a bit of a stress test. I did have to lower the AA setting to 2x, but on the other hand, it was completely playable even a bit higher. With 2xAA, the FPS stayed in ~25-35 when there were HTL ships visible (meaning the Ganymede Rings and the Nyarlathotep), otherwise it stayed above 30.
Explosions, of course, surge the FPS down to about 15-20 FPS, but not lower than that, and it can't be even seen as staggering any more IMO, because the recovery is so swift...
-
Taylor, this build suffers the RC2>RC3 performance drop (Mantis 961) (http://lore.maxgaming.net/~scp/mantis/bug_view_advanced_page.php?bug_id=0000961).
Yeah, I didn't make that change for this build. The multi_test build is to check out two specific issues before I commit the code to CVS (a mutiplayer issue, the and gamma getting reset). But I didn't bother to change the compiler optimizations (should have mentioned that) since I didn't originally plan to make this build public. The performance will be back to normal in the next real public build.
OTOH animation speed seems to be fixed. Keep on it :yes:
That fix isn't in CVS yet though, but I've have had it fixed for almost a week. It still needs to be better to allow for better control and effects but those changes are coming too.
-
did you change any of the built in scripting functions? scripts that used to run on rc4 dont run on rc5. below is a script that runs fine on rc4 but not on rc5.
http://www.hard-light.net/forums/index.php/topic,37992.msg835551.html#msg835551
i also have a half finished script that crashes as well. it should find the nearest target in your view and put a crosshair over it. if you compair the 2 scripts you should be able to id the problem.
#Global Hooks
$GameInit:
[
w = gr.getScreenWidth()
h = gr.getScreenHeight()
cx = w / 2
cy = h / 2
chxpos = cx
chypos = cy
fade = 16
xtarg = 0
ytarg = 0
if w == 640 or w == 1024 then
w = 1
elseif w > 1024 then
w = w / 1024
else
w = w / 640
end
if h == 480 or h == 768 then
h = 1
elseif h > 768 then
h = h / 768
else
h = h / 480
end
drawgunsight = function(x, y, f)
gr.setColor(128,0,0,f)
gr.drawCircle(60,x,y)
gr.setColor(255,50,50,255)
gr.drawGradientLine(x+30,y,x+15,y)
gr.drawGradientLine(x-30,y,x-15,y)
gr.drawGradientLine(x,y+30,x,y+15)
gr.drawGradientLine(x,y-30,x,y-15)
end
]
$HUD:
[
range = 3000
target = nil
for i=1, mn.getNumShips() do
thing = mn.getShipByIndex(i)
if thing.Position:getScreenCoords() ~= false then
dist = plr.Position:getDistance(thing.Position)
if dist < range then
range = dist
target = thing
end
end
end
if target ~= nil then
xtarg, ytarg = target.Position:getScreenCoords()
xtarg = xtarg * w
ytarg = ytarg * h
chxpos = xtarg
chypos = ytarg
if fade < 80 then
fade = fade + 1
end
else
chxpos = cx
chypos = cy
if fade > 10 then
fade = fade - 1
end
end
drawgunsight(chxpos, chypos, fade)
]
#End
-
Try running with debug builds... I'm not sure but it seems to be somehow related to compiler settings and to the use of plr in the scripts.
Related Mantis bug nro0000975 (http://lore.maxgaming.net/~scp/mantis/bug_view_page.php?bug_id=0000975)
-
This is the first newer release I've tried since 3.6.7 official.
I have a problem with my own beams and cap ship beams not being rendered at all. Is there some new option somewhere I should be aware of or is it a known issue?
-
Did you get mediavps 3.6.8 zeta & the alpha patch?
-
Do you accpet FRED RC5 questions/problems here, or is that for the FRED forum?
Either way, my FRED builds have done something bizarre lately. ALL of them, have mysteriously stopped working, up to and including RC5. NO matter which mod, nor which RC, none of them work, and this is bad news for me since I'm in the middle of writing a campaign! any suggestions?
-
If the problem is based on the program itself it belongs here.
In what way have they stopped working? They don't load? They crash on load?
-
Unfortunately I found a few other bugs. Please tell me if they are already known and If I should mantis them (I'm going a little more into detail, since a few of you coders already have access to our data)
1) The third primary is broken under certain conditions (broken = third weapon doesn't appear ingame). I already had this problem in a similar
configuration in 3.6.7
In 3.6.7 the third primary worked fine (in the campaign game itself, the campaign single missions (finished campaign missions) and in the normal single mission). But when you start 3.6.7 with the -allslev parameter the third primary disappear inside the campaign-story (but NOT in the single missions). I has driven me nearly crazy until I figured that out :D
Now, in this build here, the same seems to happen ONLY inside the campaign game. I have no more the 3rd primary, but this time I DON'T have the -allslev parameter active. Single missions still work.
Coders with access can try this with our Beta, Mission 3
2) While the autopilot formation is now fixed, I encountered a problem with the -set-nav-carry and -unset-nav-carry parameters. These two conditions control which ship is supposed to follow you into autopilot, and you can "unset" them to drop them at any navpoint. In this build a few (not all) ships are following you, example Shuttle BS-80 and escort in Mission 2, and on the other the transport in Mission 2 is following you back to the carrier, but I made a unset nav-carry (two, to be sure) on him.
3) With this build the engine-glows for our fighters are suddenly 3 times bigger than they should (capital ships are normal). Maybe there is a problem with our species_def.tbl, since it was made for 3.6.7. Any hints were the problem could be ? Maybe it's a problem with our files.
-
3) With this build the engine-glows for our fighters are suddenly 3 times bigger than they should (capital ships are normal). Maybe there is a problem with our species_def.tbl, since it was made for 3.6.7. Any hints were the problem could be ? Maybe it's a problem with our files.
There was a bug in the code where the values for radius and angle were swapped for tertiary thruster glows. This was broken when the batcher was implemented, but worked as it does now prior to that. You should be able to modify the tertiary thruster glow radius factor in your species_def.tbl to compensate for the difference, since that tbl value actually has an affect now.
-
:wtf: Radius in species_defs.tbl? I though it can only be changed ship by ship basis in ships.tbl
-
:wtf: Radius in species_defs.tbl? I though it can only be changed ship by ship basis in ships.tbl
Oops! :D
You're right, has to be changed in for the ship.
-
There is a value for that in the ships.tbl ? For fighter crafts ?
Not familiar with me, could you please be more specific and post me the synthax ? That must be a change to the table I completly missed.
-
Sigh...
'Nice' to know that no one bothers to check the FSwiki...
http://www.hard-light.net/wiki/index.php/Category:Tables
http://www.hard-light.net/wiki/index.php/Ships.tbl#Customized_Thruster_Effects
More precisely the $Thruster03 Radius factor: (default: 1.0)
-
O.K, sorry :) Sometimes I do, but this time I just didn't thought about that (not that I understand it right now :) )
Most probably, that stuff is related to the strange static particle effect on the end of each thruster that our ships have too :)
-
You better check the graphic files too as if the problem appeared when the alpha blending was introduced.. That is make sure that you have either proper alpha on graphic files (to use alpha blending) or no alpha at all (to use old fashion additive blending)
-
Yeah, we checked that. It has no alpha at all. There is a strange 'line' at the end of each thruster, and I can't think of a good reason for it to be there because the image itself looks fine.
Does a thruster need to be a certain length, or fill the entire image? These thrusters (AFAIK) are the old version Lightspeed made, before his current version in the mediavps.
-
I'm getting gamma correction staying on after RC5 exits, making the screen extremely bright and forcing me to restart to fix it. Has a fix been implemented for this, or should I go back to D3D8 until a fix/new RC is posted?
-
I'm getting gamma correction staying on after RC5 exits, making the screen extremely bright and forcing me to restart to fix it. Has a fix been implemented for this, or should I go back to D3D8 until a fix/new RC is posted?
Try http://icculus.org/~taylor/fso/testing/multi_test.rar and see if it's working any better. That build is basically just an unofficial RC6 (and has been updated since it was posted earlier in this thread).
-
I'm getting gamma correction staying on after RC5 exits, making the screen extremely bright and forcing me to restart to fix it. Has a fix been implemented for this, or should I go back to D3D8 until a fix/new RC is posted?
Try http://icculus.org/~taylor/fso/testing/multi_test.rar and see if it's working any better. That build is basically just an unofficial RC6 (and has been updated since it was posted earlier in this thread).
That build CTDs while loading a mission (tried both main campaign and Derelict) and still has the gamma bug.
-
That build CTDs while loading a mission (tried both main campaign and Derelict) and still has the gamma bug.
Are you using D3D or OpenGL?
No one has reported any crashing, and it's worked perfectly for me for days, so this is new. And the gamma gets reset properly as well (one of the two fixes special for this build) so I'm a bit curious as to why it doesn't work for you.
-
That build CTDs while loading a mission (tried both main campaign and Derelict) and still has the gamma bug.
Are you using D3D or OpenGL?
No one has reported any crashing, and it's worked perfectly for me for days, so this is new. And the gamma gets reset properly as well (one of the two fixes special for this build) so I'm a bit curious as to why it doesn't work for you.
OGL. I don't know either.
-
Did you get mediavps 3.6.8 zeta & the alpha patch?
Hmm, apparently not. Had the alphapatch but not the newer mediavp's. I'll check back in, unless it works lol.
-
Does this build cause my fighter to not be able to recharge its shields when it takes damage?
I'm having this problem with this build, it really is a pain.
-
Does this build cause my fighter to not be able to recharge its shields when it takes damage?
I'm having this problem with this build, it really is a pain.
As already stated earlier in this thread, it's fixed in this test build (http://icculus.org/~taylor/fso/testing/multi_test.rar). That build was for testing some multiplayer specific fixes, but it's basically an unofficial RC6.
-
Is anyone else having a problem where when a Capital ship explodes, the shockwave Alpha layer doesn't work right and covers up nearby ships? I was watching a Ravana pop a Fenris, and when it did the Shockwave Alpha Channels covered the Ravana in a box of background space! I'm pretty sure this wasn't in previou builds, as I tested with the 3.7.6 and it worked fine. Am I doing something wrong, or is something wrong with the build?
-
Taylor do you noticed that since we are which 3.6.9 Build, Microsoft sam talk in briefing/debrief even if their have a sound file??
-
Well, turns out the error isn't just for shockwaves. It's for -all- effect!
(http://img130.imageshack.us/img130/217/errortp5.jpg) (http://imageshack.us)
Everything has black background squares around them... I'm running in OpenGL mode, but I've never had this problem before. If I use 3.6.7, it all works fine, but in this new build all the Alpha goes crazy. Am I just doing something wrong? It doesn't seem anyone else is getting this problem. I have a Geforce 6600LE 256mb, so I believe I meet requirements.
-
TigerVX... are you using the additional mediavp files from here http://www.hard-light.net/forums/index.php/topic,39905.msg834347.html#msg834347 ?
And those are meant to be used with 3.6.8 zeta mediavps so i hope have those too.
-
TigerVX... are you using the additional mediavp files from here http://www.hard-light.net/forums/index.php/topic,39905.msg834347.html#msg834347 ?
And those are meant to be used with 3.6.8 zeta mediavps so i hope have those too.
Uh... Whoops! Thanks a bunch Wanderer, everything work like a charm now!
-
I just re-playing FS1 when I noticed in the first mission which Shield, that they does not recharge :O
-
I just re-playing FS1 when I noticed in the first mission which Shield, that they does not recharge :O
That was broken in RC5 but Taylor has posted a beta (pre-RC6) with that issue solved.
PLEASE read through the thread. There's a lot of people posting the same thing so you're going to make Goober, Taylor or any other SCP guy very furious.
-
Yes i know, sorry
-
Has the extremely little niggle in which a targetted ship's hull-integrity-indicator flashes when any target is damaged been mentioned?
-
Quick question, possibly OT: Is the merge of Inferno and Regular going to take place at the same time as the Pilot changes? Are they even dependant on each other? (AFAIR, Inferno just allows more than the current max number of ships, but breaks multiplayer.)
Also, just to note that in multi_test and light_test and all cvs from 20060710 up to (but not including) 20060725 in training missions for countermessures, missiles are never fired from the ships. RC5 and 20060725 launch missiles. Occurs in both FS1 and FS2 missions.
-
Inferno no longer breaks multiplayer. You can play FS2_Open online using an Inferno build. You will however break your pilot file if you ever try to go back to a non-Inferno build. That's why the pilot changes are needed.
-
So, the pilot changes would see the going away of a standard and an inferno build then? Or would they still be seperate but more/completely compatible?
-
It should hopefully get rid of the Inferno build.
-
Isn't it about time for a new Release Candidate?
I've been avoiding RC5 because of the shield bug, and I haven't bothered downloading a CVS build since RC1 came out. Is the next Release Candidate pretty much going to be whatever's in CVS right now?
-
how come my shields wont recharge? I have the 3.6.9 RC5 Installed with the 3.6.8 Zeta Vps and the extra files required for it and the alpha patches.
Why dont they recharge???
-
Did you actually read this thread? New 3.6.9 build is already there, multi_test or the light_test builds
-
Did you actually read this thread? New 3.6.9 build is already there, multi_test or the light_test builds
That still doesn't address my point in saying that I think we need an official RC6
Updated builds in the middle of threads are too easy to ignore, and I could probably also achieve the same effect from downloading from CVS, no?
The point of having an official RC6 would be to have one standard build that we know everyone is testing.
-
How many RC's we gonna have before 3.6.9 official is released? I don't remember this happening for 3.6.8
-
That still doesn't address my point in saying that I think we need an official RC6
Updated builds in the middle of threads are too easy to ignore, and I could probably also achieve the same effect from downloading from CVS, no?
It hasn't been time for RC6, too many little fixes have been going on and we don't want to release a dozen RC builds. Either use the light_test build, use RC5, or wait for the official RC6 build. There is not ETA for it though, just when it's ready.
The code that the RC builds are made with and the that the CVS builds are made with is NOT the same. The RC builds are coming from a stable code branch, the CVS builds are from the unstable code branch. All bug fixing effort is focused on the stable branch right now so you aren't likely to get any help with problems you have on normal CVS builds until after 3.6.9 is officially released. Use standard CVS at your own risk.
How many RC's we gonna have before 3.6.9 official is released? I don't remember this happening for 3.6.8
There was no 3.6.8, we skipped it. For 3.6.7 I think that there were about 7 or 8 test builds before release. We were just a lot less organized about it then than we are now.
And there will be at least one more RC build for 3.6.9, when we're ready to release it. 3.6.9 official will also be released when it's ready. There is still a lot of work going on behind the scenes.
-
The code that the RC builds are made with and the that the CVS builds are made with is NOT the same. The RC builds are coming from a stable code branch, the CVS builds are from the unstable code branch. All bug fixing effort is focused on the stable branch right now so you aren't likely to get any help with problems you have on normal CVS builds until after 3.6.9 is officially released. Use standard CVS at your own risk.
Yep. There are only a few good reasons to use a CVS at the moment.
1) You're developing a campaign which needs an Inferno build.
2) You're developing a campaign which uses the enhanced Team Loadout options (I can dream that someone is using it surely! :) )
3) You're developing a campaign which uses WMCs new limbo code
4) You've had a problem with Taylor's light test build and you want to see if the same problem exists in CVS so the coders have more info to resolve it
That's pretty much it. I wouldn't use CVS for anything else. I certainly wouldn't use it as the standard build I use when playing FS2.
There was no 3.6.8, we skipped it. For 3.6.7 I think that there were about 7 or 8 test builds before release. We were just a lot less organized about it then than we are now.
And we paid the price as a result. 3.6.7 was current for about all of a month and then we were telling everyone to upgrade to CVS builds to solve problems with dual core CPUs and then a whole host of other problems. The idea is to not have that happen this time. 3.6.9 should be stable when you get it. we may end up having to release a 3.6.9.1 build if we find a major flaw but you should never have to download a CVS build to solve a problem (except possibly as a temporary fix).
The only people who should be using CVS from now on are mod devlopers and bug testers. You should never see someone with one or two posts being told to get a CVS build again with luck. :)
And there will be at least one more RC build for 3.6.9, when we're ready to release it. 3.6.9 official will also be released when it's ready. There is still a lot of work going on behind the scenes.
Yep. It's not as if we're sitting on our hands. Taking a quick look at the commit logs I see about 20 different commits for the last week alone. That means at least 20 different bug fixes and improvements. We don't want to delay the release of 3.6.9 any more than we have to but the quality of the code is improving with every day we make you wait so the end result will be worth it :)
-
CVS builds are also important as they allow me and anyone else to track when bugs were introduced into CVS. This can simplify bug hunting and allow up to pinpoint exact commits that might have broken something.
-
Yeah. I meant to write that as part of reason 4 but got distracted :)
-
upcoming RC6 will have various autopilot fixes in it
-
**cough** please fix the bug with the 3rd primary also. It's vital for us :) **cough**
-
PLEASE!! I cant get my shields to recharge...
Someone directed me to this thread but I dont see anything to fix the problem!
I'm using 5.4.1 Launcher, 3.6.8 Zeta VPs, etc etc etc...
-
the speech system needs to be fixed. It plays regaurdless of their being a wav file or not.
-
ZmaN:
http://icculus.org/~taylor/fso/testing/multi_test.rar
http://icculus.org/~taylor/fso/testing/light_test.rar
-
**cough** please fix the bug with the 3rd primary also. It's vital for us :) **cough**
You'll have to bug someone with access to the data though, or provide some basic mission/data for us to test with. I don't know how many devs actually have access to your betas, I just know that I'm not one of them. Makes fixing this sort of bug rather difficult. :)
the speech system needs to be fixed. It plays regaurdless of their being a wav file or not.
That one deffinitely needs to be in Mantis. I don't have the ability to actually test/replicate this so it's not something that I can fix, but I'm sure that either Goober5000 or karajorma might take a crack at it.
-
ZmaN:
http://icculus.org/~taylor/fso/testing/multi_test.rar
http://icculus.org/~taylor/fso/testing/light_test.rar
what exactly are these? which one am I s8upposed to use? The light or the multi?
-
light, it's newer.
-
Reflash Rate is fixed with 60hz... (This happens regardless of V-sync)
it's bug?
-
You'll have to bug someone with access to the data though, or provide some basic mission/data for us to test with. I don't know how many devs actually have access to your betas, I just know that I'm not one of them. Makes fixing this sort of bug rather difficult. :)
I did take a look actually using the old beta Starman gave me a while back but it gave me so many errors due to it not being compatible with 3.6.9 that I gave up in disgust. If the WCS team want to give me their newer tables (and they work) I could look at this pretty soon. Otherwise I believe Kazan's got access anyway :)
the speech system needs to be fixed. It plays regaurdless of their being a wav file or not.
That one deffinitely needs to be in Mantis. I don't have the ability to actually test/replicate this so it's not something that I can fix, but I'm sure that either Goober5000 or karajorma might take a crack at it.
Hmmm. I haven't had speech synth on in a while but I'm happy to check this one out.
-
I was going to track that down.
-
Feel free :)
-
Well, what is the difference between the RC 5 and the one in the CVS ?
I didn't try mod with the RC, but with the 27.07.2006 release version from CVS, I can't play anymore to my Star Wars mods (he's place into a folder) so I'm wondering why I can't see any change. When I go to the techroom, I see no SW ships neither the custom mission I made.
PS : I'm sorry ,if I put this post in the wrong topic. But, /me think it is related to fs open build, so ...
-
I think this post (http://www.hard-light.net/forums/index.php/topic,40886.msg841780.html#msg841780) (including the quotes from Taylor) pretty much sums up the differences.
-
Just a guess, but have you tried 'Ctrl+Shift S' in the techroom? Maybe you're used to having -allslev but that's been replaced now by this hotkey.
-
So -allslev is somehow hardcoded now ? That explains why the 3rd primary is missing in the campaign game, since it has vanquished in older builds too when using -allslev in the launcher. See my mantis post in conjunciton to that :)
-
Just a guess, but have you tried 'Ctrl+Shift S' in the techroom? Maybe you're used to having -allslev but that's been replaced now by this hotkey.
I've just try the Ctrl + Shift S, and there is no change. I still see the Fs2 models, and nothing in custom missions.
-
So -allslev is somehow hardcoded now ? That explains why the 3rd primary is missing in the campaign game, since it has vanquished in older builds too when using -allslev in the launcher. See my mantis post in conjunciton to that :)
Using -allslev should have made absolutely no difference for the missing 3rd primary though. All that option did is just let it show all campaign missions in the mission simulator rather than only the ones that you have completed. The hotkey does exactly the same thing. It does nothing outside of the mission simulator screen.
Just a guess, but have you tried 'Ctrl+Shift S' in the techroom? Maybe you're used to having -allslev but that's been replaced now by this hotkey.
I've just try the Ctrl + Shift S, and there is no change. I still see the Fs2 models, and nothing in custom missions.
And you are doing CTRL+SHIFT+S in the mission simulator screen, right? The simroom is a separate interface screen from the techroom, though they look largely like the same place, so using the hotkey in the techroom doesn't automatically carry over to the simroom interface.
-
And you are doing CTRL+SHIFT+S in the mission simulator screen, right? The simroom is a separate interface screen from the techroom, though they look largely like the same place, so using the hotkey in the techroom doesn't automatically carry over to the simroom interface.
Yes, that's it. I try as well in shiplist from the techroom, I saw some sort of automatic refresh but, I still see Fs 2 ships instead of having Star Wars ships.
-
Using -allslev should have made absolutely no difference for the missing 3rd primary though. All that option did is just let it show all campaign missions in the mission simulator rather than only the ones that you have completed. The hotkey does exactly the same thing. It does nothing outside of the mission simulator screen.
I know it's sounds completly unlogic, but I can prove it :)
In the old december builds from 2005 I stumpled over the problem that suddenly my third primary (to be more detailed, the second primary weapon) suddenly was missing inside the campaign-game, while at the same time the mission works fine when being launched from the techroom.
I search long to find that error, first I looked into FRED, changed ship-types for and back, resaved and renamed, but no go.
Then I redid the campaign-file (since it only fails in the campaign-game).
Finally I thought about, what else is related to the campaign, and it was the allslev-flag. I removed it from the launcher, and voila, my 3rd primary was there again. Then I put it back, and it was missing again :)
Now it's your turn to tell me why :D
-
A lot peeps are saying that u shouldn't be using the CVS build but if there ain't an RC5+ Linux build out there how am I supposed to use non-CVS then?
This is the reason why I use CVS builds in Ubuntu as explained in the Linux wiki http://www.hard-light.net/wiki/index.php/Fs2_open_on_Linux
-
A lot peeps are saying that u shouldn't be using the CVS build but if there ain't an RC5+ Linux build out there how am I supposed to use non-CVS then?
Get CVS, but use the "fs2_open_3_6_9" tag to get the stable branch. Then you'll have the current code for 3.6.9.
I just keep a "fs2_open" checkout, which is HEAD, and a "fs2_open_3_6_9" checkout which is the stable branch. That way I can keep up with both branches easily. You can (basicaly) just do a "cvs co -r fs2_open_3_6_9 -d fs2_open_3_6_9 fs2_open" to get the stable branch and put it in a directory called fs2_open_3_6_9.
-
So what exactly do I need to change in this script to get the latest non-cvs 3.6.9?
#!/bin/bash
# CVS Checkout and Update Script for fs2_open
CVS_LINE="cvs -d:pserver:anonymous:[email protected]:/home/fs2source/cvsroot" # The cvs command
if [ "$UID" = 0 ]; then # check if user is root, and if so, echo a warning.
echo "You are root. If this is a checkout, all files \
will be created with root as the owner."
sleep 3
fi
if [ -e ./fs2_open ]; then # check if directory fs2_open exists
echo "Found fs2_open, We are updating an old checkout."
CVS_ATTEMPT=0 # This updates the checkout.
until [ $CVS_ATTEMPT = 1 ]; do
$CVS_LINE login && \
$CVS_LINE update fs2_open && \
let CVS_ATTEMPT=1
done
else
echo "No fs2_open found, This is a new checkout."
CVS_ATTEMPT=0 # This creates a new checkout.
until [ $CVS_ATTEMPT = 1 ]; do
$CVS_LINE login && \
$CVS_LINE co fs2_open && \
let CVS_ATTEMPT=1
done
fi
-
#!/bin/bash
# CVS Checkout and Update Script for fs2_open
CVS_LINE="cvs -d:pserver:anonymous:[email protected]:/home/fs2source/cvsroot" # The cvs command
if [ "$UID" = 0 ]; then # check if user is root, and if so, echo a warning.
echo "You are root. If this is a checkout, all files \
will be created with root as the owner."
sleep 3
fi
if [ -e ./fs2_open ]; then # check if directory fs2_open exists
echo "Found fs2_open, We are updating an old checkout."
CVS_ATTEMPT=0 # This updates the checkout.
until [ $CVS_ATTEMPT = 1 ]; do
$CVS_LINE login && \
$CVS_LINE update fs2_open && \
let CVS_ATTEMPT=1
done
else
echo "No fs2_open found, This is a new checkout."
CVS_ATTEMPT=0 # This creates a new checkout.
until [ $CVS_ATTEMPT = 1 ]; do
$CVS_LINE login && \
$CVS_LINE co fs2_open && \
let CVS_ATTEMPT=1
done
fi
I think you need to replace the red line above with:
$CVS_LINE co -r "fs2_open_3_6_9" fs2_open && \
Then delete the fs2_open folder and run the script.
-
That did the trick.
Thnx alot pal.
-
i got this error when i try to compile
sound/ds.cpp: In function ‘int ds_init(int, int, unsigned int, short unsigned int)’:
sound/ds.cpp:1788: error: invalid conversion from ‘const char*’ to ‘const ALubyte*’
sound/ds.cpp:1788: error: initializing argument 1 of ‘ALboolean alIsExtensionPresent(const ALubyte*)’
make[1]: *** [ds.o] Error 1
what i have to do?