Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Sololop on January 04, 2009, 09:57:59 pm
-
I've noticed I have a problem with ships jumping in and out since I have started using FSO a week or so ago. Basically, when a ships warp hole appears, the ship is visible behind it with no animations such as glowing engines, and it comes through activating the engines, etc. The same thing happens when they warp out, they are visible as they pass through the rift, and then once 100% through, they blip out of existence. I have a screenshot showing a Ravana departing. It is already mostly through the rift, and looks dumb to me. I am using FSO 3.6.10, and none of the MediaVPs.
[attachment stolen by Slimey Goober]
-
I heard about this bug a while ago, but I don't know if there's a Mantis issue about it yet. If not there should be.
-
What revision of 3.6.10 are you running. I remember seeing that as well bug thought it was fixed.
-
I think I saw this on a recent build within the last month or two, so it may still be around.
-
Not sure what revision I am using, the entire filename is fs2_open_3_6_10d-20081216_r5005.exe, im guessing r5005=revision 5005?
Edit: Just downloaded the latest build (5032) and there is no change is this bug.
-
fs2_open_3_6_10d-20081216_r5005.exe is the debug version of freespace 2, Try the fs2_open_3_6_10r-20081216_r5005.exe. Might work on the normal one.
-
Yeah, copied-pasted wrong one, I am using the real one. Sorry for the confustion.
-
Those kind of bugs typically manifest in both debug and regular builds anyway. Wouldn't expect the luck to be any better.
-
I couldn't find this in the Mantis. Think I should put it in, or is it well enough known?
-
Links at the top of this board, this forum and in the sig right above your last post.
-
I've noticed I have a problem with ships jumping in and out since I have started using FSO a week or so ago. Basically, when a ships warp hole appears, the ship is visible behind it with no animations such as glowing engines, and it comes through activating the engines, etc. The same thing happens when they warp out, they are visible as they pass through the rift, and then once 100% through, they blip out of existence. I have a screenshot showing a Ravana departing. It is already mostly through the rift, and looks dumb to me. I am using FSO 3.6.10, and none of the MediaVPs.
That Ravana also appears to be warping in backwards.
Probably just a matter of fixing the "fvec" vector in the WE_Default class. IIRC there was some issue with dotprod being negative in certain cases or somesuch.
As a general rule of thumb you should put bugs in mantis even if they are "well known" (which generally only lasts for as long as people are talking about it). Not only does it offer a visual record of the bug being fixed, it can be consulted for the solution that somebody used to fix the bug or who actually reported the bug or who was experiencing the bug, plus the coder that was working on the bug, so that if there is no progress, somebody can quickly e-mail everybody to ask "Is this still a problem? Are you still working on this?"
So that is a definite yes to putting the bug in mantis.
-
I've seen this too with recent builds.
In both the main FS2 campaign and blueplanet.
-
@WMCoolmon, the Ravana is not warping in backwards, it is jumping out, but already passed through the rift but did not vanish, it will stay visible until the rift almost closes, then blip out of existence.
I should also add, that although you cannot target it when it is through the rift, warships will still fire their turrets at it until the "blip" occurs.
Also, I attempted to make an account on Mantis but have yet to receive the email to activate the account. Been over a day...(Waits patiently)
-
Also, I attempted to make an account on Mantis but have yet to receive the email to activate the account. Been over a day...(Waits patiently)
I'm waiting now for months for the activation mail.
-
I'm waiting now for months for the activation mail.
Same thing for me. Actually, I'm waiting for two activation mails(I created two separate accounts).
:blah:
-
I'm waiting now for months for the activation mail.
Same thing for me. Actually, I'm waiting for two activation mails(I created two separate accounts).
:blah:
Well, i created several accounts from different email accounts.
The good thing is, after a while, it resets/ deletes the account, so i can try to register again.
The bad thing...well, guess... :D
-
if your stuck for a mantis account then ask a mod or someone to create it for you and pm the password or just leave it empty , as i remeber i think goober created my account after i failed a few times to get one set up....
-
Yeah it pretty much doesn't work, I almost feel bad asking people to mantis it when I know they probably can't get an account. It's usually more of a plea for someone with an account to do it.
-
Yeah it pretty much doesn't work, I almost feel bad asking people to mantis it when I know they probably can't get an account. It's usually more of a plea for someone with an account to do it.
It's supposed to go through the GW server since I set up all of the authorization stuff on it so e-mails wouldn't get blocked from the mail server. Looks like Mantis is setup wrong for using that however, as it fails the SPF check since the mail doesn't actually go through GW but merely uses the e-mail address. So, any server that hardfail's SPF will discard the message as spam.
Mantis just needs to be fixed to use GW SMTPS and that should prevent so many discarded/missed Mantis emails for everybody.
-
I see... :blah: Well, consider this a plea. Anyone with a functional Mantis account, could you add this to it? Full information is:
Jump in-Warp rift appears, ship is created behind the rift, and passes through, instead of slowly emerging from the rift. Warping out-Warp rift appears, ship passes through completely, and does not slowly vanish into the rift, but is 100% visible as it completely goes through the rift, and as the rift starts to close, it will eventually disappear all at once. During the warp out, until the ship disappears, it is not targetable, but AI ships will still shoot at it.
I can get more screenshots if needed.
Thanks so far for all the feedback. :D
-
Reported:
http://scp.indiegames.us/mantis/view.php?id=1866
-
Awesome! Thanks a lot. :) Hope someone will find a fix for this soon.
-
Me too, but as it isn't detrimental to gameplay it's not going on the hotlist for 3.6.10. Hopefully for the next release though.
-
Hey guys, maybe this is not a bug but bad pof data. Check my note in the mantis report 1866 (http://scp.indiegames.us/mantis/view.php?id=1866).
Some testing should be done. (Retail vs. Media vps model, different ships...)
-
Yeah I was just going to suggest seeing if this ever happens with retail data.
-
I've still yet to see it with media VPs. Are we sure this isn't a problem with a rogue pof file or vp file somewhere?
-
I have a feeling me and FUBAR are two of the more obsessive at keeping our stuff clean, if we've both seen it recently I'm pretty sure it's some sort of bug. So you mean you've _only_ seen it with retail data?
-
Just to clarify I haven't actually seen this I just reported it for him since he couldn't. I thought I saw an old report in Mantis that was fixed but apparently that one was for Knossos warps only.
-
Must have been another bug you confirmed recently, there's so many new ones I get them confused.
-
Yea that was "The Blinding White Light of Death" one. I don't think that one made Mantis yet either.
-
I'm quite obsessive with keeping things clean myself. I don't have any extraneous items in /data or subfolders. I must admit to never having gone back to retail once I had mediaVPs to work with. I'm using the 3.6.10 VPs and the latest radar icons build I know of with a radar icons VP. Is there any particular build I should test with to see if I can find this bug?
-
Well I am getting the bug constantly, and Im using build 5032 of 3.6.10 with no mediaVPs, and I haven't changed anything in any folders or whatever, and followed instructions carefully
so I did not fail this session. I've had this since day one of my FSO experience.
-
So it's retail only? How odd.
-
So even if I'm using the FSO exe, with no mediaVPs is a retail problem? I would have thought it was still a Freespace open issue. I may have my terminology wrong.
Edit: I now do believe this bug is with the MediaVPs. More importantly, something that is included in the MV_Core.vp. Reason for this being, I copied this to a separate folder a few days ago, and forgot to delete the original, and overlooked it when I checked a bit ago. :sigh: Didn't mean to lead in the wrong direction, but the problem is there, nonetheless. So far, now that it (mvcore) is moved, the problem is gone. However by re-enabling the MediaVPs, or MV_Core, or alternate mods like blueplanet or derelict, the problem re surfaces. Every time.
I'm now going to search every nook and cranny in my FS folder to avoid further confusion in troubleshooting. :nervous:
-
The term 'retail' is often used to describe either a retail .exe, or the retail game data (.vp's). Normall you can get the meaning out of context, but if I just say I'm "playing retail" it could be hard to interpret what I mean.
-
Might be a good time to have you run the debug build and attach the fs2_open.log from the data directory. You only need to start the game and get to the menu then you can exit.
-
It's not a model issue. Setting the clipping plane is handled on a lower level than the rest of the graphics code. Anything that would be rendered to the right of that line, before the clipping plane was reset, just wouldn't appear in that image. Once the ship is all the way through the effect, it should be instantly removed from gameplay, rendering, and physics. Before the ship is all the way through the effect, the clipping plane should be active.
Now the model might have a bug in it that's causing the issue. But the underlying code should be rigorous enough to handle that sort of thing (Say, the bounding box being improperly set up - although the code used to use the radius rather than the bounding box). If the code is dumb enough that it's closing the warp effect before the ship is all the way through, but smart enough that it knows the ship isn't all the way through yet and doesn't remove it from gameplay, then the bug is the dumb code being used in conjunction with the smart code.
-
Please check mantis info...
:confused: :confused: :confused:
I cannot reproduce the error.
-
Still waiting on a log file from Sololop.
Can anyone else reproduce this?
-
Something to consider might be the video card you're using. It might be that it doesn't properly support the clipping plane, so the effects get turned off by the FS2Open code, but the video card doesn't have any way to handle clipping the model itself. I seem to remember there being an issue with at least one older version of video card, I think it was the GF4MX440, where that would be the case.
-
Haven't had much time for freespace lately, I'll post the debug log file sometime this weekend probably.
-
You don't have to play just start the game and exit. Would take about 30 seconds.
-
Okay, here it is.
[attachment stolen by Slimey Goober]
-
640x480 with 16 bit color? 640x4800 shouldn't hurt but you should be using 32 bit color.
-
16 bit? Oops. Thought I changed it. Guess not. Im using 640x480 because thats just what I'm used too.
-
I know this is a really old bump.
Can anyone who was experiencing this issue try the latest Knightly build and see if it's been fixed?
Also Mantis registrations are working again so if you are still experiencing the issue please add the information to this report http://scp.indiegames.us/mantis/view.php?id=1866
-
I experienced this way back when I was using Windows XP. I am now solely using Mac OSX, so I cannot check to see if it still exists. However, I copied the FS folder from my old XP Partition to OSX, and have not had any issues. I assume it was just a problem with my Windows itself, and not FSO. Currently, I am running the newest MediaVPs with zero problems, on any settings.
-
Sorry to bump up an ancient thread, but I still experience this issue. I've tried 3.6.10 and 3.6.12 executables, and the glitch is in both. In my case, it is Mac-specific. Using the exact same Freespace 2 directory on Windows XP (on the same computer) does not demonstrate the issue. It happens with all ships, and only with MediaVPS enabled.
-
Sorry to bump up an ancient thread, but I still experience this issue. I've tried 3.6.10 and 3.6.12 executables, and the glitch is in both. In my case, it is Mac-specific. Using the exact same Freespace 2 directory on Windows XP (on the same computer) does not demonstrate the issue. It happens with all ships, and only with MediaVPS enabled.
Apologies for bumping, but my experiences are identical to Gordon's, with the exception that I have recently upgraded to the 3.6.12 mediavps. But the problem persists! I've searched these forums for a fix, but have come up empty. I've been able to ignore it for the longest time, but I'm playing Vassago's Dirge right now and it is just so unbelievably out of place to see the ships pass right through the warp plane amidst all the other graphical awesomeness that occurs in that campaign :) I can post additional information, if it helps. Thanks in advance!
-
Please post an fs2_open.log. Instructions on how to do this can be found in the FSO FAQ (http://www.hard-light.net/forums/index.php?topic=56279.0).
-
Please post an fs2_open.log. Instructions on how to do this can be found in the FSO FAQ (http://www.hard-light.net/forums/index.php?topic=56279.0).
Lol, you probably always have this phrase on your clipboard :P I did see that earlier, actually, but missed the part about creating log files if the problem isn't listed.
Anyway, you can take your pick from the either the standard or improved log files I've created (the latter is compressed...hope tarball is OK). Both involve me jumping out as soon as I enter the second mission in the standard FS2 campaign, using the 3.6.12 MediaVPs. Again, my ship just flies right through the warp plane with the engine glow being disabled once completely through, but model disappearance doesn't occur until roughly a second later.
Specs:
OS: Mac OS X 10.6.4
Processor: 2.6 GHz Intel Core 2 Duo
RAM: 4 GB 667 MHz DDR2 SDRAM
Graphics Chipset: NVIDIA GeForce 8600M GT
Thanks for your help!
[attachment deleted by admin]
-
This is strange.
I know that a bug like that affected all warpouts at some point, which got fixed prior to the .12 release. Can you check other warpouts to see if the problem appears there as well? Can you provide screenshots showing the problem?
Also, can you try a nightly build to see if the problem appears there as well?
In addition, there's no need to provide the "improved" log until one of us specifically requests it.
-
Oh, does it ever happen with other warpouts. Near as I can tell, all classes of ships are affected. It does kind of spoil the immersion when the awe-inspiring Ravana warps out, only to do, well, this:
(http://img444.imageshack.us/img444/8306/screenshot20100910at701.png)
You can also see some Manticores back there; the fact that they're facing the "wrong way" leads me to believe that they have already passed the warp plane.
Here's one more taken a few seconds later, for kicks. The Ravana is completely through, but still visible.
(http://img22.imageshack.us/img22/8306/screenshot20100910at701.png)
Is a nightly build the same thing as the 3.6.13 version? I'll look around for it.
EDIT: All right, I found the nightly build thread, downloaded v3.6.13 Revision 6449 for OS X, and played the first mission of Vassago's Dirge again. Same issues.
-
This is very strange. We may need to get one of our Mac devs to take a look at this, as the same effects work as normal on Windows at least.
-
I appreciate it. Looking forward to a fix!
-
OK, so I've been playing a bit more over the past week, and I've discovered something that I think might be related to the warp animation issue. It's a graphics glitch that occurs whenever a large model such as a cruiser is destroyed (it probably affects all models, but isn't noticeable for fighters). Instead of breaking into fragments as the explosion occurs, it looks as if the model is multiplied and several full ship models will go off in different directions as dictated by the physics of the explosion. The full models will eventually disappear and be replaced by debris, but this occurs many seconds after the pretty smoke clouds and shockwaves. Since both issues are graphics glitches that involve model disappearance, I'm willing to bet my left arm that they have similar origins. I'll work on getting screenshots and log files this week.
-
And you would be wrong. The debris-ification of destroyed models works by running a plane through the model from the midpoint to the endpoints, and gradually revealing the debris pieces. If you know how to implement a better way, please consider working on the SCP.
-
/me scratches head at E's comment
I've never seen an effect like he's describing when ships blow up. Yea you get a couple of partial ships and then the debris spit out from them but several whole ships that turn into debris? That's not right.
Of course a screen shot of these ships would help avoid any confusion.
-
I do remember seeing it in action on several capship explosions....
-
I used to get that problem myself, quite some time ago. I think that it was when I had an nVidia card. Switching to an ATI card solved the issue... along with many others, as I increased my VRAM side by a factor of 8.
-
I remember having a similar problem (both the warp in/out and the explosion problem) with... I think it was my laptop? It was just the glow maps that remained visible, however.
-
/me scratches head at E's comment
I've never seen an effect like he's describing when ships blow up. Yea you get a couple of partial ships and then the debris spit out from them but several whole ships that turn into debris? That's not right.
Of course a screen shot of these ships would help avoid any confusion.
Here's a Ravana biting the dust, and it's pretty clear that it's breaking up into two whole ships. There are times when I could swear there are more than two full models, but that could just be me. Most of the time, only two are noticeable.
(http://img823.imageshack.us/img823/8930/screenshot20100919at906.png)
(http://img706.imageshack.us/img706/8930/screenshot20100919at906.png)
(http://img227.imageshack.us/img227/8930/screenshot20100919at906.png)
A couple more screenshots are attached, but no log files yet. I'll try to get one for you tomorrow. Hopefully, my problem isn't simply the fact that I'm using an NVIDIA card (as Trivial Psychic pointed out). If that's the case than I may just have to deal with it.
[attachment deleted by admin]
-
Those are the weirdest issues I ever seen.
I didn't even knew that something like that could happen.
-
Ravana mitosis!
-
Ravana mitosis!
1 is bad enough!!!!!
-
You're using OpenGL, right?
-
You're using OpenGL, right?
There is no other option in FreeSpace Open.
This is a truly bizarre bug.
-
I only asked because the last time I recall this was back when I was still playing D3D. Come to think of it, I think that it had something to do with the Z-Buffer... not that I really know what that does, but I seem to recall that bug.
-
OK, got the log file. Something new happened this time -- the game actually crashed when the Ravana was about to jump in. Not sure why that was the case; it didn't happen in the non-debug version. Regardless, some good capital ship explosion action going on in there.
[attachment deleted by admin]
-
Sorry to bump this (again), but I want to say (a) that this bug is probably platform related, as I experience it on OSX as well and (b) It disappears with -no_glsl enabled. I think it boils down to the fact that clipping isn't working properly.
-
Can anyone reproduce it with the latest nightly? r6627 or higher
-
I'm happy to say that for me, this mystery has been resolved with the solution stated in blowfish's post. By enabling -no_glsl in the launcher (I was using v3.6.13 r6449) the warp animation problem AND the explosion mitosis issue were both corrected! Perhaps it's even a fix for the FAQ page, since it does indeed look like a general OS X thing. Unfortunately, the r6662 release with -no_glsl disabled does nothing to resolve the problem. But at least there's a (seemingly) general fix for these issues.
EDIT: I first reported that it worked with r6662 but then I double checked my Launcher settings, and turns out -no_glsl was still on. Oops. At any rate, a fix exists.
-
A fix does indeed exist, but you loose normal maps and post processing.
-
I'm happy to say that for me, this mystery has been resolved with the solution stated in blowfish's post. By enabling -no_glsl in the launcher...
As blowfish said, using -no_glsl also disables a range of other graphics features, so it is non-optimal.
-
Sorry, but I'm bumping this topic as the bug still seems to be an issue.
These mods are amazing, for the sheer fact that I'm playing this ancient game (easily one of the best ever) at full resolution on my Mac so many years later. But this one really puts a damper on the pivotal warps and explosions in the game.
I downloaded nightly build 7355 last night. In addition to -no_glsl, it has an option for -disable_glsl_model, which I assume is a subset of -no_glsl. Disabling "glsl_model" at first glance seems to do the trick. So maybe that narrows it down a little further?
I don't like the fact that I'm missing some effects because of it, but I guess that's my other question: does anyone know what exactly -disable_dlsl_model disables? Is it less than -no_glsl? The description says "don't use shaders for model rendering", but isn't that all shaders are used for? Or are they applied to beams/warps/background as well?
-
Per default, shaders are used to render every 3D model in the game. That applies to the warp effect as well as skyboxes and normal models. -disable_glsl_model overrides this and hands the models off to the fixed-function pipeline instead (which is orders of magnitude slower, and doesn't allow things like normal maps), while still allowing the use of post-processing.
-
Thank you for the reply and explanation.
I meant to also ask in my post: was it ever determined whether this is strictly an nVidia issue, and AMD cards don't have the problem? I'm not above buying a new video card for this game, if I know it will work.
-
It's probably a Mac-specific problem, since OSX has (had?) very out-dated OpenGL support.
Are you using OSX Lion?
-
I'm still on Snow Leopard (10.6.7...*just realized he never upgraded to .8*), but intend on upgrading to Lion soon.
From reading around the web, is appears that Lion does add support for OpenGL 3.2 and GLSL 1.50, but some new Lion functions must be called to use them, rather than the old "compatibility" 2.x tree that still exists.
Links, for example:
http://www.ode2.com/?p=149 (http://www.ode2.com/?p=149)
http://developer.qt.nokia.com/forums/viewthread/8047 (http://developer.qt.nokia.com/forums/viewthread/8047)
http://www.idevgames.com/forums/thread-9205-post-71487.html (http://www.idevgames.com/forums/thread-9205-post-71487.html)
http://forums.macrumors.com/showthread.php?t=1165524 (http://forums.macrumors.com/showthread.php?t=1165524)
I don't know enough about it to have a concept of how much work it would be to add support for, but it would be awesome if it was added. The newer version of GLSL could be all that's been missing?
-
*sigh*
And I thought Linux drivers were sucking hard. This is just beyond ridiculous.
-
Anyhow, I agree that this appears to be unique to OS X, so I've created a new thread in the Cross-Platform forum regarding the bug and the new GLSL in Lion.
http://www.hard-light.net/forums/index.php?topic=77268.0
Thanks.
-
Just wanted to let you know that I'm having exactly the same issue here. Win7, Radeon HD6670, 3.6.12 final, launcher 5.5g. So I'm afraid it's not really OSX-specific. :/
Upgrading to 3.6.14 RC7 did not help, but -no_glsl did.
Any idea how to fix this yet?
-
I have the same bug. A few weeks ago everything was fine, now I'm having this issue.
I tested r8095, r8670, Shadows_Beta, RC5 and RC7. The bug appears on each build.
Could be a driver update Radeon HD 5770, but I'm not sure, cause I didn't start FSO for a while.
-
Looks like a driver issue - as per this thread (http://www.hard-light.net/forums/index.php?topic=76166.0). Substituting a 12.3 dll did the trick in my case. :)
-
I have the same bug. A few weeks ago everything was fine, now I'm having this issue.
I tested r8095, r8670, Shadows_Beta, RC5 and RC7. The bug appears on each build.
Could be a driver update Radeon HD 5770, but I'm not sure, cause I didn't start FSO for a while.
Hmm, I have a HD 5770 with latest drivers, and everything works fine? Which version are you using?
-
i bet this is fixed by the change in the shaders where we set gl_ClipVertex even if its an ati card.
-
I have the same bug. A few weeks ago everything was fine, now I'm having this issue.
I tested r8095, r8670, Shadows_Beta, RC5 and RC7. The bug appears on each build.
Could be a driver update Radeon HD 5770, but I'm not sure, cause I didn't start FSO for a while.
Hmm, I have a HD 5770 with latest drivers, and everything works fine? Which version are you using?
I'm using the 12.6 drivers. And according to this:
Looks like a driver issue - as per this thread (http://www.hard-light.net/forums/index.php?topic=76166.0). Substituting a 12.3 dll did the trick in my case. :)
I could solve both Issues (spontaneous cloning while exploding & not dissappering on departing) with the atioglxx.dll 11.4 (HD5770 and Windows 7).