Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Bobboau on February 15, 2004, 12:20:33 am
-
ok, I'm in a bug fixing mood, what is your most hated bug
currently tested build (http://freespace.volitionwatch.com/blackwater/fs2_open_bobboau_test_2-14-04.zip)
-
Afterburner bug, and the missiles firing thru the cap ship "bug"
-
afturburner but seems to be traked down to some assembly, I don't know asm, but it may have been fixed,
and what is this fireing thru the capship bug, is it just the old fiireing through your own hull bug?
-
Believe so.
-
I'll take a look at the fire through bug
-
You might also try fixing that fighter beam bug I submitted to Mantis :nod:
-
the flickering thingy?
-
ok, I think I've got the fire through bug fixed, but there may be realy bad problems with it, the ships that have problems with this already are likely not ever going to fire at all (becase there fireing points are inside the ship, thus always will colide with the hull) I'll post a build for testing in a bit (just had an idea how to help that a bit)
-
test me (http://freespace.volitionwatch.com/blackwater/fs2_open_bobboau_test_2-14-04.zip)
realy test this make sure all ships can still fire from all turrets, and see if it does what it's suposed to do (ships not fireing through there own hulls anymore)
you will aslo find sevral other fixes (subspace, sky boxes, auto-centering, 3d shockwaves)
pease give quick and many responces, all of you
you, yeah you the guy reading this, down load and test, I don't care if your not involved oor have never posted before, I don't want to wait three days to find out if this is working or not!
-
I think fighter beams are going to be totaly reworked
-
The video crash on explosions is driving me mad... Can you take a look at it?
Also, software (non htl) mode now has corrupted textures... Most ships have large white stripes on them...
-
My most hated bug is targetting boxes and particle trails getting misaligned if the object moves to the edges of my FOV.
When I get the object back into my reticle they will be aligned again.
This causes targetting boxes to be displayed left / right of the ship, and shots 'losing' their trails.
This happens exclusively with HT&L, and started with the first HT&L build there ever was.
:)
I'll go test the new build right now.
-
Alright, that's one messy build.
1) Thanks for the ambient light, could you add a command line multiplier for it? (-amb 0 - infinity)
That way you can have later on FRED adjustable levels of ambient lighting which would get multiplied with the command line. On FS2 standard missions, the level would default to "0".
2) Revert to the old laser code:
(http://www.penguinbomb.com/lightspeed/SCPTest/bug.jpg)
3) There's something... wrong with the models:
(http://www.penguinbomb.com/lightspeed/SCPTest/ohmy...jpg)
Some textures are not displayed. They're pitch black. The shinemaps still work though (if i turn the model around, the black part will be lightened with the shinemap)
-
On the upper left you can see the odd combination of texture parts with ambient lighting and black textures (no texture displayed) with only spec mapping.
-
How's about fixing the press-the-reticle-target-button-too quickly-and-it-crashes bug. You know, the 'Y' bug
-
RT will not be pleased, this is the first distribution with his new texture code in it. and he worked hard on it. :(
hopefuly I did something
-
YY does still haunt me from time to time, other than that, its looking pretty good my end.
-
I doubt I'd be able to fix the 'Y' bug
though I have thought recently about a eplacement, it wouldn't target a serese of ships in your reticle but it would target any ship you are pointed directly at, a ray picking targeting option
-
OK, updated the build, lasers should be rendering corectly again, and I tryed to improve the turret oclusion thingy.
-
Same link as before, right?
-
Originally posted by Lightspeed
My most hated bug is targetting boxes and particle trails getting misaligned if the object moves to the edges of my FOV.
When I get the object back into my reticle they will be aligned again.
This definately should no longer be happening. What's your graphics card? Does this happen with this latest build?
-
is it off by more than 1 pixel?
are you useing non-standard modes?
yes, same link, the thing I'm most worried about is this causeing ships to not fire enough, it seems a little over 1/4th of the shots that should get fired fired are not getting fired, but these numberrs could be wrong (it could be trying every frame untill it can fire, wich would cause a 1% miss rate to seem 25 times bigger than it realy is)
-
Here's something I wouldn't mind seeing fixed... that dock swapping thing I posted in Mantis, where a docked object will suddenly swap to another dockpoint of the ship its docked to, just prior to moving away. It only seems to happen if a ship (not the object) was previously docked to something else. I included a test mission demonstrating this with my bug report.
Later!
-
Tried your new build, Bob - the glowmaps don't work (spec maps do, I think) and nebula backgrounds are a bit fuxored (look like they've been filtered with a half pixelate, half blur effect). Laser shots seem OK. Can't comment on the actual firing-through-the-hull bug as I'm a bit busy with Reci testing at them mo. Oh, and the splash screen doesn't disappear until I press Esc, and the intro movie doesn't play. Seems like you've been tinkering with most of RT's code :) Seems slightly happier than previous builds in terms of loading, if you're interested
-
the movie code was comented out for me as it doesn't want to compile anymore, offical builds won't have this problem.
as of a day or two ago, anything and everything needs a comand line to run, even glow maps (-glow personaly I think this one right here is stupid, but that was the decision)
I had it only go into the 3d laser function if you were in OGL mode (wich is what needs this, and it's only a temporary measure, when we get a proper 3d laser effect both OGL and dx will use it)
by nebula backgrounds, do you mean sky boxes or the normal FS2 background effects
the splash screen thing worries me, as I have no idea why it would be doing that
-
Just tested out the latest build and noticed the problems with glowmap and apparently shinemaps in the techroom. Then, I remembered that I had downloaded a new Launcher from RT's sig, and noticed that it had a newer creation date than the 3.3 I was using. After un-RARing it and loading it up, it came up as v3.4, with flags to activate glow and spec. I then realized that new builds such as Bob's test build here, probably has spec and glow off by default. So I loaded up Bob's build again and tested it out with both of these boxes checked, and voila, glowmaps. Now, it isn't perfect, as certain textures seem to be way to dark, though on some Shivan capships like the Sath, it looks realy cool with the glowmaps on. I'm thinking that the remaining texture problems are related to certain shinemaps not being employed properly in this build. Just for a hoot, I added in a custom -shine flag, just incase RT left it out by accident, but I got an I-didn't-understand-what-that-flag-means message, so the solution wasn't that simple. Here's a screenshot. Notice that some of the textures are rendered properly, but others are not... glowmaps working though.
(http://www3.sympatico.ca/daniel.topps/DemonTest.jpg)
On the positive side, plus-points to the team for fixing the position problem in the techroom, so we can now see all of the Colossus, and others. Haven't tried this build ingame though.
[Edit]
Well, Bob beat me to it with the new flags, but that still doesn't explain the shinemap problem (if that is the problem). I didn't have any problem of the loadscreen hanging.
[/Edit]
Later!
-
you know that might be from something I did to fix a lighting bug
-
found what was causeing that, fixed, I'll have an update in a second.
-
umm... it's updateed
-
I've noticed that I can't actually turn off the -spec option permanently once I've turned it on. If I turn it off in the launcher it's checked again next time I run the launcher.
No reason why I should want to admittedly but it's a bit odd.
-
If it's in the launcher, it's RT's coding... I recon. But you know that...
-
Turns off OK for me, could you give me the complete command line?
-
Originally posted by Bobboau
umm... it's updateed
Actually, the exe you have up has the same size and creation time as the exe you posted earlier (says 12:35pm). Are you sure you updated it?
Later!
-
Slight problem with what looks like the render order for turrets :-
(http://www.aqsx85.dsl.pipex.com/images/image1.jpg)
(http://www.aqsx85.dsl.pipex.com/images/image2.jpg)
(http://www.aqsx85.dsl.pipex.com/images/image3.jpg)
(http://www.aqsx85.dsl.pipex.com/images/image4.jpg)
Flipside :D
And yes, I know the axis is off centre, that can be fixed moderately easily later ;)
-
I can't tell what the hell is going on there, what is your hardware and what settings are you useing
-
Hardware :-
Athlon XP1700+
GeForce MX440
768 Megoram
Windows XP home.
using -htl -jpgtga -spec -glow
What is happening can only properly be shown in a video, but it's almost as though the hull of the ship has rendering priority over the barrels of the turret, so the turret is not drawn if the hull is in the background, for example, on the last picture, the barrel 'exist' when the base is behind it, and when space is behind it, but isn't drawn when the hull of the ship is behind it.
Trust me, if you think it looks confusing there, it scared the living bejeebers out of me in-game, since I was strafing along the ship and suddenly this barrel leapt out of nowhere ;)
I'll try it with a conventional ship and see what result I get :)
Same result, the best bet is to fly along the top of a Deimos you will see it as soon as the hull mesh is behind one of the barrels.
-
I don't know who put in ambient lighting, but in HTL it's goofed up. Some parts of the ship have it while other parts of the ship just don't.
Also, specular is always on in HTL as well, even if the flag isn't there.
As a side note, the Launcher 4.0 flags scroll box is not properly redrawn when focus is shifted to another window or it is minimized.
-
...Your turret barrels glow blue? Coolness. *steals idea*
-
is the exe up still doing that?
I must have put up the wrong exe
I just reuploaded it, and placed a link to it in the first post
-
I think you did.
-
I know for a fact that the build I have doesn't do that (the ambient lighting thing) re DL and see if it's still doing it, if it is I'm going to have to go blow up Redmond.
-
Originally posted by Trivial Psychic
(http://www3.sympatico.ca/daniel.topps/DemonTest.jpg)[/B]
I have managed to recreate this bug on my machine with the latest build. I have an old build that has glide and texture sections taken out but is not fully up to date. This build does not have that bug.
This means that my texture change code is OK and it is changes after that which are causing this problem.
-
yeah I think I just put the thing that sets ambient light into an if that I shouldn't have (fixing a lighting bug, multi-pass lighting system, remember:)) the build up right now shouldn't have that bug
-
Oh good, I crapped my pants there, I thought I had messed the whole texture sectional removal. :lol:
-
sorry to scare you like that
as I said "hopefuly I did something" wich is what it seems to be, I should probly commit that
-
Oh and Bob, remember to use d3d_SetTextureStageState() instead of calling SetTextureStageState() directly or the monitoring system is going to get out of sync.
The monitoring system is really good because it checks for redundant settings which really speeds things up. I believe if you have a pure device it doesnt do it internally so we have to make sure we stick by our interface.
-
did you fix up the ones that were there already?
-
Yes
-
ok, good
-
Redownloading fixed it, although the timestamp on your exe didn't change, strangely enough. :wtf:
Anywho, specular lighting still shows up in HTL even if the flag isn't there, don't know if you meant to fix that or not.
-
I'm not the one diableing things, so I didn't touch that (it was like that sence I got it fresh)
-
I just tried this version and didn't notice any problems with the turret firing. Even that screwed up turret19 on the Hatshepsut worked fine, although that was with my fixed version.
If you want bugs to fix, see if you can do anything with those two gameplay bugs (http://mgo.maxgaming.net/mantis/bug_view_page.php?bug_id=0000082 and http://mgo.maxgaming.net/mantis/bug_view_page.php?bug_id=0000075), as they have been preventing me from testing my missions for a few weeks now. I personally think that such gameplay issues should generally take precedence over graphical ones.
-
Heres a clearer shot of the turret rendering problem....
This is a Deimos with space behind the barrels on the top turrets....
(http://www.aqsx85.dsl.pipex.com/images/deimos1.jpg)
Now I move my ship so that the hull is behind the turret....
(http://www.aqsx85.dsl.pipex.com/images/deimos2.jpg)
I think they are clearer than my last shots.
Flipside
-
has it always done that (in HTL) or just this build?
-
Just this build as far as I'm aware, I'll run the last build and make sure..... 2 mins.....
The 20-1-04 build works fine, whatever has caused this has been introduced since then.
Oh, and CP5670, have you checked the '-nobeampierce' flag on the launcher, that should fix the second problem :)
-
Hmmm... been running the build with the -stats flag enabled and I've noticed something.
When I start a mission, it shows that I have 128MB Texture Memory Free.
I have a 128MB video card.
Then as I look at ships and fire my lasers to undergo the one-time lag, the texture memory free goes down (stuff is being moved into the texture memory). Same goes for when something warps in and I look at it for the first time. Each time it drops by a few megabytes.
This seems to indicate that the textures, while being loaded into main memory (or rather, the pagefile), isn't being loaded into the video card during the beginning of the mission. Perhaps a flag could be made to enable the option of preloading into texture memory.
This is just some idle speculation of course, so don't jump on me. In any case, if the "1 second lag for each new object" bug could be quashed for 3.6, it would be just perfect.
-
Oh, and CP5670, have you checked the '-nobeampierce' flag on the launcher, that should fix the second problem :)
The beams are supposed to go through shields, which is happening fine, but they are fully destroying the shield quadrant they hit along with damaging the hull. It should be as it was in the original FS2, where they went through shields without affecting the shields at all. The -nobeampierce command line makes it so that they damage shields (normally) and only damage hull if the shields are down, so that wouldn't be very useful here.
-
Originally posted by Bobboau
I should probly commit that
Yes please, ASAP
-
Originally posted by Sticks & Bob
This definately should no longer be happening. What's your graphics card? Does this happen with this latest build?
is it off by more than 1 pixel?
are you useing non-standard modes?
happens with 1_20_04, Radeon 9800, it's way more than a pixel ( i can move the ship out of the bounding box at larger diatances, move the particle trail about 20 pixels away from the shot).
I'm running on 1024x768.
-
Originally posted by Bobboau:
Give me something to do
Improve misison loading times cos they're ****ing awful compared to retail
-
Originally posted by Bobboau
give me something to do
I want a linux port of FRED! :ha: :D
Cheers
-
Whether intentional or not, this build is the only thing that's managed to fix the afterburner bug for me in Win2k. Thank you much, bobboau!
-
bobboau,
did you ever fix the fighter beam redering bug. you know the one where the Beam renders behind an object ocasionally. or when you destroy a subsystem with glow points attached to it, the glow points dissapear? these are old ones but I couldn't remember if you fixed them.
-
the thing with glowpoints being atached was designed that way, otherwise you'll have glowpoints floating about in the middle of space for no aparent reason.
-
so on the hyperion model after you destroyed thst one piece on the front you can't have the glowpoints disapear?
-
wait, it doesn't do that?
it should be!
-
a LONG time ago it didn't
I haven't tested it recently
I think they should be disapearing.
-
try this (http://freespace.volitionwatch.com/blackwater/fs2_open_Bobboau_2-26-04.zip) out
also that turret bug should be fixed in that too
you will also be pleased to know I fixed glowpoints for TH&L while I was in there
-
ok will try that out this weekend. Do you still happen to have the hyperion and the tables with the fighter beams in them sitting around somewhere?
-
bob put that in the recent builds forum
-
mkey
actualy it looks like I'm not alowed to post in there
-
PM steak and see if he'll let you post there. it should be for devs only, i thought it was setup that way
-
Bobboau, it is not fixed. this is using TBP_open 2.0 and your recent EXE. better memory handing though.
(http://www.swooh.com/peon/redmenace7/screen03.jpg)
(http://www.swooh.com/peon/redmenace7/screen01.jpg)
(http://www.swooh.com/peon/redmenace7/screen02.jpg)
-
*bump*
Bobboau, just want to be sure that you have infact seen this and know about it
-
ok, so the things have been shot off and there still there... wonder why (they do have the corect object set right?)
-
that is out of the TBP_open 2.0. It could just be the the glow points set on the wrong object.