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 28, 2005, 04:19:05 pm
-
Latest CVS, except that I hacked in a fix for the fighterbay bug. I'm still trying to find the underlying cause.
http://fs2source.warpcore.org/exes/latest/20050728-Goober5000.rar
I've heard that the bug where videos play real small in the corner is caused by the latest version of the DivX codec. If you get this problem, uninstall it and install a previous version, and see if that fixes it.
Why is everyone using this build all of a sudden? It's really old. Get yourself a build from the CVS builds thread or get the official 3.6.7 instead - Karajorma 11/12/05
-
FYI: Gratuitous Sathanas appearance
This is the first build with
- Second attempt at making turrets not stick straight up. So if your turrets seem to be behaving oddly, boot up the 7/22 build and see if they work any better. If it doesn't work this time, I need to take the code out; you should be able to set the initial position of turrets with Bobb's animation system anyway, that will even let you choose which direction the turret points, although it looks like it might use the same method as I did.
- Multiple shockwavez and 3D shockwaves with working glowmaps
- Fixed camera SEXPs
- Fixed description for show-subtitle
- $Shockwave_model: is now $Shockwave model:
-
Okay this one gets a big :wtf: from me.
I've finally tracked down the cause of the bug I was getting with mv_music. It is being cause by mv_textures. A VP with no table files and no music files in it :wtf: If it's present the mission will crash out on load if it uses any .ogg tunes. When removed they work again.
I'm going to try recompiling it to see if I can get it to work. It may just be that there are too many files in there or something.
Apart from that the only bug I can detect at the moment is that whenever I enter the flight simulator or try to exit the game the background turns 0,255,0 green. In the simulator it's just a flash while it reads in the list of missions but on exit it stays that colour until you choose to quit or cancel.
-
It gets stranger. mv_textures itself isn't the cause of the crash. The textures inside are. Namely the dds ones. I extracted all the textures and put the PCX files in the path (in Freespace2\media_VPs\Data\Maps to be precise) and then ran the game, worked fine. I move a .dds file to the same folder and it crashes. Take it back out runs fine. Put it back. Crash.
Oddly enough though if I leave it in and disable mv_music the game loads again. No idea how a combination of .dds and .ogg files could be causing a crash but it appears to be doing so. :wtf:
-
Originally posted by karajorma
Apart from that the only bug I can detect at the moment is that whenever I enter the flight simulator or try to exit the game the background turns 0,255,0 green. In the simulator it's just a flash while it reads in the list of missions but on exit it stays that colour until you choose to quit or cancel.
Is this with D3D or OGL?
-
Originally posted by WMCoolmon
FYI: Gratuitous Sathanas appearance
:lol: :)
-
Originally posted by WMCoolmon
FYI: Gratuitous Sathanas appearance
This is the first build with
- Second attempt at making turrets not stick straight up. So if your turrets seem to be behaving oddly, boot up the 7/22 build and see if they work any better. If it doesn't work this time, I need to take the code out; you should be able to set the initial position of turrets with Bobb's animation system anyway, that will even let you choose which direction the turret points, although it looks like it might use the same method as I did.
[/B]
No its not.
-
Which part are you saying no to? :p
It's not really supposed to work in the techroom...it's not so big a deal there, I'd have to make more code changes to have it working there. Considering how long it took last time for anyone to notice, I don't want to change more than necessary to make sure the problem doesn't exist. :doubt:
-
The turret code seems to be working for me, as the latest Orion I saw had the big guns facing forward.
Except for the one on the bottom, which was facing the opposite direction. I figure this is because it's upside-down with respect to the other turrets....
-
ok np
I just remember it working their as well.
Is anyone working on the one pixel off set for buttons?
-
Originally posted by redmenace
Is anyone working on the one pixel off set for buttons?
I'm going to fix it when time allows. I pretty much have zero time for SCP right now though and this one doesn't even rate on the priority list at the moment.
-
ok NP!
in regaurds to that TBP bug , did you ever get a chance to look at that?
-
Originally posted by taylor
Is this with D3D or OGL?
Sorry. OGL. And it's vanished now that I've put mv_textures back in place. I have no idea why.
-
Originally posted by WMCoolmon
This is the first build with
- Second attempt at making turrets not stick straight up. So if your turrets seem to be behaving oddly, boot up the 7/22 build and see if they work any better. If it doesn't work this time, I need to take the code out; you should be able to set the initial position of turrets with Bobb's animation system anyway, that will even let you choose which direction the turret points, although it looks like it might use the same method as I did.
[/B]
Yup it works, it works too good actually. The turrets point forward/backwards, but the barrel gets locked in the starting plane. The turret base rotates correctly, while the barrel can't track up/down.
-
Originally posted by redmenace
in regaurds to that TBP bug , did you ever get a chance to look at that?
Yep, forgot about that. Basically it's a TBP problem but we probably need a code check on it too to avoid this. Type D (or 3 in the tbl) beams will fire the specified number of "+Shots:" at fighters. It always needs to fire at least once though it it doesn't process properly. It's set to 0 in the tbl for "WS Neutron Beam" and for "Shadow Slicer AAA" with the White Star beam being the problem here. Setting it to at least 1 shot fixes the problem.
Other than the TBP weapons.tbl being fixed, we just need to add a check in the weapons.tbl parsing code to deal with this situation automatically. I forgot to commit this but I'll go ahead and do it now before you have to remind me again. :)
-
Hmh, thanks for mentioning that. :)
*adds this to list of bugs to be fixed*
-
Originally posted by Col. Fishguts
Yup it works, it works too good actually. The turrets point forward/backwards, but the barrel gets locked in the starting plane. The turret base rotates correctly, while the barrel can't track up/down.
Got the same problem here.
"My barrels can't get up!" :D
-
The shockwaves work correct with this build?
Great! Great! I'm testing some stuff now. ;)
-
Bob, what about the other TBP crash with open gl?
-
Fighterbay departures working correctly now. Thanks Goob. :)
-
I tried this out for a minute but couldn't really stand the 60hz on OGL. Will that refresh control be in the next release?
-
Registry option "OGL_RefreshRate", a DWORD value, set to whatever you want your refresh rate to be. The default is 0 which will use whatever the system default is set to. There is no error checking on this so if you put in some weird value it will either not go fullscreen, go fullscreen but falling back on the default 60Hz value (there will be a message in the log to that effect), or cause your monitor to explode.
Regardless, it's your problem if you try and set it manually and things go wrong. When the updated launcher is released then it will only allow values that your video card can actually support but I just haven't had the time to get that code done yet.
-
Where is this flag located? A search does not turn up anything.
I'm not sure what you mean by the danger warnings. Almost any CRT made in the last five years has some sort of overscan protection; the worst thing that can happen is it will show a message that it can't display stuff at the current setting. I'm sure LCDs have this too when running on a VGA connection. My monitor and almost any video card out there can do 140khz horizontal scanning and anyway, I use it without problems in some other games.
-
Originally posted by CP5670
Where is this flag located? A search does not turn up anything.
In the source you mean? If so then it's in code/graphics/gropengl.cpp in the opengl_go_fullscreen() function. This is the first build that should have the new option.
I'm not sure what you mean by the danger warnings. Almost any CRT made in the last five years has some sort of overscan protection; the worst thing that can happen is it will show a message that it can't display stuff at the current setting. I'm sure LCDs have this too when running on a VGA connection. My monitor and almost any video card out there can do 140khz horizontal scanning and anyway, I use it without problems in some other games.
There's no telling what can happen in older CRTs and cheap LCDs, not to mention crappy video cards. Since changing this setting does affect how hardware works it does carry with it a possibility of damage. I don't expect it to be a problem for most people, just trying to scare off the ones that really don't know any better. Those people are better off waiting for the new launcher which will cover their backs.
-
In the source you mean? If so then it's in code/graphics/gropengl.cpp in the opengl_go_fullscreen() function. This is the first build that should have the new option.
Never mind, I didn't realize it was an FS2 specific flag. I thought you meant that it's some global OGL override that is already there somewhere in the registry, like the DirectX override setting.
Anyway, that works perfectly; I can now finally use 2048x1536 at 85hz. Thanks a lot. :)
There's no telling what can happen in older CRTs and cheap LCDs, not to mention crappy video cards. Since changing this setting does affect how hardware works it does carry with it a possibility of damage. I don't expect it to be a problem for most people, just trying to scare off the ones that really don't know any better. Those people are better off waiting for the new launcher which will cover their backs.
Never hurts to make things idiot proof, I guess. :D
-
I cannot hear a thing when I use ogg's instead of wavs. Ogg's play nicely when played with media player classic.
Edit:
So the problem was encoder, resetting default settings helped.
-
Nice build, fast and stable. Now, that it is possible to use more shockwaves than shockwave01, how do i use them? For example, if i want a different shockwave for torpedos, which flag do i have to set or which table do i have to alter? I´ve searched through the tables and got no idea, where to specify it.
-
Also i found a little bug on this one. In "the sixth wonder" the calypso dies after a few seconds in mission and you make a weird "in-system-jump". It doesn´t happen in 0722.
-
hmm... where's the lighting?
[EDIT] here. (http://img249.imageshack.us/img249/7779/screen00091ik.jpg)
no shinemaps, and no light sources.
Media VP's:
mv_core
mv_models
mv_textures
mv_effects and adv_effects
-
What command lines are you using Cobra? Are you using OpenGL or Direct3D.
-
-jpgtga -nomotiondebris -pcx2dds -d3d_no_vsync -dualscanlines -ballistic_gauge -nobeampierce -3dwarp -tbpwarpeffects -snd_preload -fps -ambient_factor 60
and i'm using D3D.
[EDIT] and for some of the ships like the Fenris, Leviathan, Hippocrates, and a couple of fighters, the glowpoints and textures are missing. :wtf: (pics get too dark so i can't show you anything)
[EDIT 2] oh yeah, i also experienced this problem in 7/22.
-
Have you posted this in mantis?
-
oops... :nervous:
-
Doesn't look like you are using -spec or -glow and the -ambient_factor of 60 will make everything pretty dark. Remedy those things and let us know the difference.
-
oh ****, forgot about that. :o
meh, they were always enabled so i never had a problem with it... :nervous:
[EDIT] and eh... delete the mantis report i submitted about this. :nervous:
-
Hi. Maybe i´ve found an interresting effect. Don´t know, if the code-wizzard are aware of it. If not, maybe you want to check it out, else ignore my post.
The white square bug in D3D mainly occur when an ani is played facing a light source (e.g. a sun). I´ve tested it severel times. Maybe it´s just something, which happens on my machine. To test it, start any mission and face a sun, so it is in the middle of the screen. Then fire your weapon several times. After a few seconds, the squares occur. They disappear, when you´re turning away from the light-source and keep firing.
Hopefully i´ve made myself understandeble.
-
this is 3.6.7, High Max. ;)
[EDIT] and the bugs come from experimenting with the code. i know that much. ;)
-
Wrong on both counts, Cobra.
-
....then why does the 2005728 build say 3.6.7 and not pre-3.6.7? :)
-
Someone updated the version numbers ahead of time. But even so, it's 3.6.7 beta, not 3.6.7 release. The official 3.6.7 release doesn't come until we post a release thread.
-
ah well, 3.6.7 beta works perfectly for me. ;)
-
Hopefully finding out, that the light-sources or the suns have something to do with this bug may help fixing it.
Switching to OGL is a solution, too, but it breaks env-mapping (which is IMHO one of the major improvements of FSO). Let´s hope, that Taylor will succeed in implementing this to OGL soon. That would solve a lot D3D Problems.
EDIT: Sorry folks. Starfox described the sun-effect in another thread. So i think, my post wasn´t that helpful. And it seems, that the problem is much bigger and really hard to fix. This, or every coder already switched to OGL.
-
Most of the bug fixers are using OGL now. I use Linux so D3D isn't an option (I wouldn't use it anyway) and is pretty difficult for me to ever test since I require another computer to do it. Unfortunately that other computer got fubar'd in a recent storm and though I have the parts to fix it, I don't have the time or the desire to do so. I can do builds and basic OGL testing in VMWare running on my Linux box but D3D doesn't work there.
Env mapping in OGL is just waiting on the time to clean up and commit the code. I had it working a few months ago but didn't like how it had to be done. Another solution came along and that works much better but needed driver support. Now that ATI supports it I don't have the time to commit it. It's all interwoven into code that is nowhere near ready to commit so cleaning everything up is going to take a while. Vicious little cycle I'm on but it will go in soon, just not for 3.6.7. :sigh:
-
Lately my only major gripes with OGL has been those green flashes that occasionally happen when you switch to another interface screen, such as tech room. I do not know whether this is a feature or a bug. The other thing is that with OGL things don't look quite as good as with D3D, albeit shinemaps etc works. Using Radeon 9800XT with latest Win x64 drivers.
-
The green flashing seems to be an ATI thing. I've never really found a real way around it but I have tried several possible fixes that have been in the past few builds. Since I don't have an ATI card though it's pretty much impossible to properly test and fix the problem.
As far as quality goes, can you post screenshots for a comparison? My Windows computer had an old video card anyway but a lot of visual improvements were made to OGL, until I couldn't tell the difference anymore with my hardware.
It's never going to be the same but video drivers do have a lot to do with OGL quality, especially ATI's drivers. Sometimes they go more for speed than for looks but often there is some quality setting to let you adjust that balance. OGL looks a lot better with -rlm enabled (will be made default and not changeable after 3.6.7) and when env mapping finally hits CVS it will look even better (effectively gives you per-pixel lighting in OGL). And that strange model geometry rendering problem that only affected OGL has been fixed now too so 3.6.7 won't have that against it.
-
I'm curious, what does the -rlm flag exactly do ?
-
Good question, and here's another. Env-mapping in 3.6.7 or after it?
-
-rlm ("Realistic Lighting Model" in the launcher) makes lighting calculations based on a local viewpoint. It's a little slower since the calculations have to be made on each vertex. By default it's an infinite viewpoint so the light direction never changes. This will cause some moving of light on a model when you view it from different angles. A local viewpoint on the other hand will continually recalculate the lighting direction so that it maintains a more realistic cast of light.
I made it a cmdline option since I wasn't sure about the speed of it. No one has reported and problem though and this stuff is nothing for modern video cards so I'm just going to make it the default and remove any option to do otherwise. I don't want to remove the cmdline option just before 3.6.7 though since most OGL users are already used to having it there. After 3.6.7 there will likely be a flood of new code added and there's no telling what all will break. Waiting to remove the option until then should spare some trouble for users, for this one thing at least.
Env mapping will be after 3.6.7. Don't know how long after since it really depends on what all of Bobboau's new code does. The priority will be to get all of that new material code working well and after that happens env mapping will go in. I've got way too much new code to plow through and near zero time to do it so this will have to wait until more important things get done (Real Life (TM) type things mostly).
-
oh yeah, speaking of flags, what exactly does the analog ballistic ammo gauge flag do?
-
It displays an analog ballistic ammo gauge.
-
but i never see any difference in the ammo gauges.
-
Are you using Ballistic weapons?
-
if you mean like machine guns, no.
-
Then what the F**k did you expect to see? :rolleyes:
-
Actually I found they work without machine guns too. It's harder to see, but they do display the weapons energy.
-
Originally posted by Axem
Actually I found they work without machine guns too. It's harder to see, but they do display the weapons energy.
It's not supposed to. It's supposed to display a curved triangle on the right side of the HUD that corresponds to the amount of ammo remaining on all banks.
Can you post a screenshot?
-
Is this it? It's not triangled shaped or anything, but it does appear when I tick the analoge gauge.
The Slayer PDC is an energy weapon, and the 100mm is a ballistic weapon.
(http://img.photobucket.com/albums/v109/NarfPics/notgoingcrazy.png)
Top pic is the PDC nearly drained, and it has recharged a bit in the lower ones.
-
Yeah, that's it. Not a curved triangle - my mistake.
I guess the gauge appears even if one weapon is ballistic. What if none are ballistic?
You might have to ask WMC about this.
-
I first tried it with a ship with no ballistic weapons and didn't see it. I thought you guys fixed it until I tried it with nukemod's ships, which have both energy and ballistic weapons.
I just thought it was to replace the energy bar it takes away.
-
personally, i rather like original energy bar, although that's what i thought at first, too.
-
Can anyone explain me why that happens ?
Something is really wrong with the effect.
(http://img365.imageshack.us/img365/4077/screen00558uf.th.png) (http://img365.imageshack.us/my.php?image=screen00558uf.png)
-
what media vp's do you have? and your commandlines?
-
I figured I'd post this here. What's the status on OpenAL? I recall that Taylor was releasing some OAL-enabled builds along with non-OAL ones in early summer, but that was discontinued due to the resulting size of the downloads, and I haven't seen one in a while. Will OAL become command-line-enabled, default/integrated, or part of a drop-tab in the audio settings?
-
It was only put on hold since there wasn't going to be an OpenAL version of 3.6.7 and I didn't want to confuse everyone with the extra set of builds during testing. I'm not sure exactly how OpenAL will be used but most likely the current DirectSound code will be dropped and OpenAL will just completely replace it. If it's decided not to do that then it will be runtime selectable by a reg entry just like D3D/OGL are. Either way, OpenAL will be a loadable library during run so that if it's not available sound will just not be available (but the game will still run), and so that we can support both 1.0 and 1.1 rather than forcing the use of one or the other.
-
-spec -glow -pcx32 -jpgtga -d3dmipmap -2d_poof -rlm -dualscanlines -targetinfo -orbradar -ballistic_gauge -smart_shields -3dwarp -snd_preload -env -alpha_env -decals -ambient_factor 75 -fov 0.39
G-20050728
mission_package.vp
mv_adveffects.vp
mv_core.vp
mv_effects.vp
mv_models.vp
mv_textures.vp
-
About OpenAL matter. Wouldn't it simplify development if Direct3D and DirectSound along with EAX would be completely dropped and OpenGL and OpenAL would be developed instead? And before people complain about dropping EAX, OpenAL also supports 3D sound. And developing OpenAL would probably also be easier to developers because it's open standard unlike EAX.
-
It would make things unnecessarily slower though, since EAX is done in hardware when it can be used (and software sound can sometimes cause a significant framerate hit). I would like to see EAX kept in there even if it's not going to be updated.
-
There still needs to be concensus but I think that all of the current DirectSound and related code will be dropped in favor of just OpenAL. I had started working to this point already and will get back to it when time allows me to do so later this year. OpenGL is a slightly different story. D3D is starting to become bug filled and more people are starting to use OpenGL but many still refuse to use anything but D3D. It has already been seriously suggested to drop D3D but Bobboau only knows D3D. Since he adds most of the graphics related improvements there is some hesitance to dump D3D. Getting rid of it would make things easier though.
As far as EAX goes, OpenAL does support and will use it under Windows. Remember that Creative is a major supporter and developer of OpenAL so they wouldn't just abandon a technology like that. We'll just have to use the relevant extensions and that will be that. The cool thing though is that EAX is integrated into OpenAL (but just on Windows, and in binary form) so aside from initializing it there is nothing special to do afterwards. This allows it to still be cross-platform friendly and easy to work on, something that the DirectSound code can't match on either point.
-
It is of course a problem if Bobboau only knows D3D, but doesn't all of his new features also find their way to OGL eventually anyway? So wouldn't it really make that much difference?
-
Originally posted by Mr. Fury
It is of course a problem if Bobboau only knows D3D, but doesn't all of his new features also find their way to OGL eventually anyway? So wouldn't it really make that much difference?
He's got to implement them in something though. If he only knows D3D then D3D is what he has to use to make those new features. That means that we can't drop D3D and that OGL always has to play catch-up feature wise since it's takes two people to do any one thing. That's how we get most new graphics features though so it's a necessary evil.
-
Search (http://dynamic.gamespy.com/~freespace/forums/search.php) is your friend. ;)
(reminds self to start using that, too. :nervous: )
-
There is a known nebula slowdown with D3D (don't know what causes the slowdown just that there is one) but as far as I know it doesn't affect OpenGL. If you are using D3D then switch to OpenGL and that should fix it. If you are already using OGL then, uh, say so. :D
-
Latest version of OGL should come with your graphics card drivers IIRC.
Albeit, was there not some finicky bug with one of the versions not detecting OGL versions properly? I'm sure I remember something to do with not checking decimals correctly or similar.
-
That bug should be fixed with the most recent builds. I'll be very surprised if you're getting it with 0728
-
How up to date are your drivers? OGL comes with them; I think with Nvidia drivers 55.xx and above, not sure from which version of the ATi drivers.
-
You almost certainly already have OpenGL 2.1. You wouldn't be getting this error if you didn't despite what the error message is saying.
Unless of course your drivers are so old that you actually DO have OpenGL 1.1 in which case you need to go to the nvidia or ATI site and update them pretty sharpish.
If you updated your graphics card drivers any time in the last two years I doubt it though.
-
Ah, was the error only checking after the decimal point then? (so 1.1 became .1, 2.1 became .1 as well, etc)
-
Yep. Basically it was Y2K all over again :D
-
Tut-tut.
-
What driver version are you using?
Some of ATI's older drivers have the white squares and upgrading fixes it. If you just installed what was on the CD then it's likely just too old. Grab something newer off of the ATI website and give that a try.
-
I located a bug in the _vm_* functions in Windebug.cpp related to the code enabled by defining NEW_MALLOC.
I think i have it all cleaned up and using malloc,realloc,free again - but for the moment i think memory usage tracking is broke in relation to realloc.. i'll fix it tonight if it is.
-
Yanno, I don't know why, but I get intermittent NTDLL.DLL error messages in FSO these days. -_-;; --- i be darned if i figure out what is causing it.
I use OpenGL on a Radeon 9800 Pro. My PC is using the 2.6.42 version of Radeon Omega Drivers, has display driver version...
Display Driver version "8.14-050512m-023864C-ATI-OMEGA".
When I installed those on my laptop its Mobility X600 started "snow-freezing" in GTA: San Andreas periodically. Returning to the original ASUS-supplied ATI spec drivers for my ASUS V6V laptop fixed it.
If I ever choose to run FSO on the laptop in future, and I probably will, I'm going to have a problem reporting bugs to you guys ... the ASUS drivers provided aren't Catalysts, but they have the Control Panel, which reports this version:
Display Driver version "8.11-050212a-021287C".
I have no idea which Catalyst driver corresponds to that...anyone know? If it's too old a Catalyst i may have a problem -_-;;
-
Originally posted by Gregster2k
Yanno, I don't know why, but I get intermittent NTDLL.DLL error messages in FSO these days. -_-;; --- i be darned if i figure out what is causing it.
mv_music.vp
Remove it and all will be fine.
(If you're using mv_zPack from 3.6.5 then you should simply extract the music.tbl from this (http://homepage.ntlworld.com/karajorma/freespace/Downloads/musicTBL.rar) link and stick it in your data\tables folder or upgrade to the 3.6.6 VP files and delete the old version of zPack).
-
Ok, first as I stated in the other topics, this build worked very well for (though still having the white squares problem and briefing icons/debriefing text misalignment) before I tried to get some old mods of mine to work.:) :(
Currently the trouble isn't that serious (the rest of the screen getting black if some dialogue box pops up, showing again as soon as the box is closed; and yes, even if I don't use said mods...), but I'm starting to fear for my windows install, as the trouble with my old PC started in this manner... :wtf: :nervous: :( :(
Now, what I actually wanted to ask here is, when I tried to debug one of these mods with Fred-debug, I got several errors that I could solve, but also one that I have no idea what it refers to (it's only there with that specific mod). The error message I get is:
"Assert: count < max_ints
File: C:\Languages\Visual Studio Projects\Visual C++\fs2_open-CVS\code\Parse\PARSELO.CPP
Line: 1914
[This filename points to the location of a file on the computer that built this executable]
Call stack:
------------------------------------------------------------------
fred2_open_G-20050715-dbg.exe 004fef34()
fred2_open_G-20050715-dbg.exe 00501d62()
fred2_open_G-20050715-dbg.exe 005020ae()
fred2_open_G-20050715-dbg.exe 0044f092()
fred2_open_G-20050715-dbg.exe 00447581()
fred2_open_G-20050715-dbg.exe 00905fa2()
fred2_open_G-20050715-dbg.exe 00905904()
fred2_open_G-20050715-dbg.exe 009034a9()
fred2_open_G-20050715-dbg.exe 00903945()
USER32.dll 77d18709()
USER32.dll 77d1d297()
USER32.dll 77d1b368()
USER32.dll 77d1e840()
ntdll.dll 7c91eae3()
USER32.dll 77d218a4()
------------------------------------------------------------------"
Now, why the hell is it complaining about a value being below a max value?:confused: Could it actually mean the opposite? And really "count" is a damn explanative name for a variable - WHAT actually does it count ???
Please nobody get insulted, I'm just a bit stretched on non-explanative error messages. ;) And the other messages did a good job in helping me with debugging.:)
Oh, and while I'm at it - another mod seemed to be more or less working, but there were several models where fred complaind about their geometry and that it had to cap several normals or so (but it still did load those models). Any idea what might be the cause for this?:confused:
(I thought this might be the right thread for this, but on the other hand, I possibly should have posted it in the modding thread? If this is an issue, some admin move this post over there, please. Or just someone point me to post it there anew.)
-
Originally posted by Mav
Now, why the hell is it complaining about a value being below a max value?:confused: Could it actually mean the opposite? And really "count" is a damn explanative name for a variable - WHAT actually does it count ???
What mission or mod are you trying to use?
Basically this is just saying that it's trying to load in a series of numbers, up to a particular amount ("max_ints"), and for each one that it finds it increments "count". So this error is that, in a list of numbers, there are more numbers than it's expected to find. This can cause a memory overwrite problem if it's only got "max_ints" worth of storage space and it attempts to load more than "max_ints" into that memory location. Basically, it will either crash or have bugs if the mission or table in question continues to have this error in it.
-
Hmmm... I didn't load any mission, I just started fred-dbg and got that message. The mod I'm using is my personal shuffling-together of things, it's quite possible that there are errors in it. It just would be nice to know where I have to search for them.:( One thing I though in-between is that I might have too many weapons defined in my weapons.tbl - could it be this?
-
Originally posted by Mav
It just would be nice to know where I have to search for them.:( One thing I though in-between is that I might have too many weapons defined in my weapons.tbl - could it be this?
It wouldn't be too many weapons, just too many things in a list. So, say that the problem was in ships.tbl, with "$Default SBanks:". The maximum number of secondary banks is 4, it's hard coded in the source. So if you specified more than 4 items in that list then it would give you the error you received. A list is anything inside of parenthesis (unless it has XSTR in front of it) so you can just search for those in your tables and that will help figure out where the problem is.
And since you are running a debug build it should produce a fs.log which would have parsing errors in it. You may have to create an empty txt file named "debug_filter.cfg" in your freespace2 directory to get all of the parsing errors to be reported but that will help you figure out where the problem is hiding.
-
Thanks, I'll see if I can find anything (including the fs.log you mentioned). :)
I know about secondary/primary bank limits more or less though, so I'm rather sure this isn't the point. On the other hand, quite some of the bugs FRED found for me are rather stupid - I really wondered about me making these... :nervous:
-
A new thing. It possibly is not that specific to this build, but since I got it with this one, I'll post it here...
What I'm talking about is capship shieldmeshs like on the SSD Diablo that can be downloaded at F2S.
I tested them pretty often when I was still using SCP v.3.5.5 and below, and there they did work almost flawless . (no yelling intended :) )
I always wondered people stating over and over that they didn't work. Now I tried again with this build (which, as I already stated, works fine for me elsewise), and guess what - FS crashed upon some (beam-)bombers firing at the Diablo! :( :(
It showed exactly the same symptoms as a faulty shieldmesh (too far away from the ships' hull) would have in 3.5.5 or earlier and retail (trust me, I made enough of them :sigh: ).
Only point is that the Diablo's shieldmesh wasn't faulty...
So it seems, somewhere in-between it was broken... :(
I jumped from 3.5.5 over a short stop in 3.6.0 directly to this build, so I can't say when it actually started.
I'd just like to have them working again... :(
Does anyone know what's wrong and/or with what version it started? :confused:
And is anything planned for solving it? (please?)
-
Have you tried a debug build?
-
I tried a few days ago (after seeing your reply...) . The debug build gives me the same count-error as fred-debug, and thus refuses to start. So I'd first need to solve that error - problem is, I don't have any idea where to search for it... :(
I don't have any ships with more than three primaries and four secondaries. Could too many ship flags or too many allowed weapons for a ship-type cause it? :confused:
Well anyway, no insult intended (the SCP-team is really doing a great job :yes: ), but when I get an error-message, it would be quite helpful if it points me to the point that caused the error (even if it only says "error is in line xyz of file ###.tbl" ) . Granted, most error messages already do so (and that was really helpful to me), but it would be nice if this could be extended to all possibly mod-specific error-messages, like this "count"-thing (maybe it's already being worked on and I just don't know - I apologize if this should be the case).
Other idea... could all those limits be comprehensively listed somewhere?:nervous:
-
I've tried to give the relevant limit in the error messages I've made.
However, there's a problem with making a lot of 'em. Right now there are only Warnings (which only show up in debug builds, but don't kill Freespace 2) and Errors (which DO show up in all builds, but kill the app)
There's no room for a middle-ground problem AFAIK, which is a problem because either won't show up to people and they'll forget about them or they will stop execution of the program (even if they aren't critical).
EG, right now, if you have two ships with the same name the second will be excluded. It's not a problem that'll kill missions, unless the name was changed from one used in another mission accidentally, but it should be something the person running the app should know about.
-
I was particularly thrilled to see the error message for "web cursor not found" with an explanation that the executable was in the wrong directory (ok, so I double-clicked an executable in WinRAR) since that has come up more than once. There are still a few loading/parding errors that I wish people saw and could fix, but the situation is pretty well-handled ATM I think.
-
Originally posted by WMCoolmon
and Errors (which DO show up in all builds, but kill the app)
It doesn't, actually. If you click OK the game will keep on running, as long as the code recovers gracefully from the Error.
We might have to make this more explicit in the Error message.[/B][/quote]
-
(http://arunk.speedpost.net/screen0000.jpg)
The thrusters on the cruiser is locked to on. Is this a known bug?
I'm running the build in this thread with the following vps:
(all downloaded today off SCP)
core
effects
textures
models
My commandline params:
-spec -glow -pcx32 -jpgtga -2d_poof -rlm -ballistic_gauge -snd_preload -env -ambient_factor 75
Any ideas?
I also notice the white box problem. But I saw another (older) build which had fixed this problem and the coder said that the fix was commited to CVS. If so, why is it still here?
P.S: My vid card is an X800XT running Catalyst 5.5.
-
i think it's supposed to be that way to make a little realism. no flare would look unrealistic, IMO.
:welcome: by the way. :)
-
Ok, I can take that.
One more thing, there is no environment mapping or specular maps visible in D3D mode; only in OGL. (The Perseus looks da bomb!). Is this also supposed to be so? I've been reading the forums for 2 days now and I got the impression that OGL lags behind D3D in getting features implemented.
Edit : Thanks for the welcome! :)
I'm an ardent fan of FS2, used to FRED back in the day. Maybe when I get some time off college, I can join up with the Academy and refresh some of my (pathetic :nervous: ) skills. This is some major @#$% you've done with the source:eek: :yes: My congratulations to team/contributors!
Edit 2 : Corrected above, thanks kara.
-
Originally posted by Cobra
i think it's supposed to be that way to make a little realism. no flare would look unrealistic, IMO.
:welcome: by the way. :)
Actually it'd look better if there was no engine trail, but the glow was still there.
I dunno if it's possible to gradually fade the flare, though.
-
You won't see bump mapping in any mode. They've not been implemented yet. :p The spec maps may be designed to look like bumps on some ships though.
The lack of Shine maps in d3d is also a known error with ATI cards and will be fixed after 3.6.7 is released (hopefully soon). At this point we'll be getting a whole host of graphical improvements :)
-
Bump mapping : I meant environment mapping. I saw somewhere in the Wiki that it was implemented and is supposed to look beautiful.
Also, there is one more thing I discovered.
I changed over to OGL and immedietely noticed the colours being off (I could see green and red shades in the hangar interface). It looked like a gamma problem, but I couldn't reduce it from the game options. The gamma settings in my graphics control panel is not changed in anyway.
Then suddenly enough I started getting "Error reading from registry. Stopping" from the loader (gave me one hell of jump). I went in regedit and found the key and lo and behold, there were two gamma entries. One at 1.00 and one at 1.80. Changed the latter to 1.00 and I was in graphics heaven with OGL.:cool:
-
Is it just me, or is the texture replacement broken here?
I cna't seem to get any of my nameplates t o switch...
-
Originally posted by karajorma
The lack of Shine maps in d3d is also a known error with ATI cards and will be fixed after 3.6.7 is released (hopefully soon).
thank God for nVidia then. :p
-
Originally posted by Cobra
thank God for nVidia then. :p
Thank God for OpenGL, you mean :p
-
Indeed. I couldn't even play the SCP without it. I've made it my goal in life to see how much FS2_Open I can squeeze out of my Laptop's integrated graphics, since I'm at college and what I've got is what I've got. :p D3D craps out the instant anything larger than a fighter explodes, so my only option is OGL.
-
Originally posted by Cobra
i think it's supposed to be that way to make a little realism. no flare would look unrealistic, IMO.
Since when is having engine glows on a DISABLED ship realistic? The Trinity had it's engines knocked out.
-
If you'll notice, the ship isn't disabled. That's a mistake on :v:'s part in mission design, as engine flares do indeed turn off if the engine subsystem is destroyed.
-
AHA! :p
-
Yeah. If you scan the engines specifically, they're down to 2%. Not exactly what you want if you're trying to get away from Shivans.
-
Unecessary bumping of old threads != FTW
-
Unecessary bumping of old threads != FTW
:wtf: :lol:
Wrong thread?
-
I suspect someone edited something and it bumped the thread.
Best not to say anything more on the matter :)
-
ok, I am locking this thread it is from JULY!
-
Seeing as I'd been complaining about locking threads on Grognards I was going to try to avoid that :)