Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: StageTech on November 17, 2003, 02:22:37 pm
-
I looked around the Forum and couldnt find anything pertaining to this. I am running FS2 open 3.5.5, and i tried ht&l version as well. Every time I use the 'select target in front of reticle targeting' and select some type of debris it throws me to the desktop without an error. I have tried just about everything. Even dropping all the graphic options to their minumum possible, as well as changing resolution and it still does it.
System
900mhz athlon
650 meg ram
Gforce2 MX
WIN 2000 Pro
-
we know of this, but many people on the team have been unable to replicate it. its really aggrivating us
-
I ran it againt and got it to crash, doesnt do it on every target click, but will always do it. Dont know if this will help but here is the errorlog listing from the crash
fs2_open_htl caused an Access Violation in module fs2_open_htl.exe at 001b:005a5f56.
Exception handler called in Freespace 2 Main Thread.
Error occurred at 11/17/2003 13:52:48.
C:\games\FreeSpace2\fs2_open_htl.exe, run by Cody Funk.
1 processor(s), type 586.
640 MBytes physical memory.
Read from location 00000008 caused an access violation.
Registers:
EAX=01178920 CS=001b EIP=005a5f56 EFLGS=00010212
EBX=0fbba4c8 SS=0023 ESP=0012f968 EBP=00000000
ECX=0fbba210 DS=0023 ESI=0fbba108 FS=003b
EDX=00000000 ES=0023 EDI=00000001 GS=0000
Bytes at CS:EIP:
8b 42 08 3b 41 08 74 0c 8b 09 81 f9 08 9d bb 0f
Stack dump:
0012f968: 01178944 011da500 00000007 00000022 005a8a33 06073428 011da500 3f7fda0c
0012f988: 3f16c65a bc3dd83e 3f4ede14 005a88a0 00000080 004055bc 45b5f7ed 439d02ea
0012f9a8: 45d822ce 00000a94 0000002f 01178950 01178944 0116c870 0012f9a0 00000001
0012f9c8: 0000000d 00000000 0000002f 00000000 00000000 00000000 00000000 06f0c8c0
0012f9e8: 00162ac0 00000008 ffffffff 00000009 00000007 ffffffff 06f0c8c0 00000007
0012fa08: 00000080 00000000 06f0c8c0 00000001 00518577 00000080 00000007 00518fab
0012fa28: 00000007 06073290 00652f78 00000000 00000000 00000000 005179c2 06073428
0012fa48: 00000000 00000000 00000000 00000000 00000000 00404d9f 00000001 00000002
0012fa68: 0012ff34 7ffdf000 00000000 00000000 00000000 00000000 00407595 00000003
0012fa88: 0041d045 0000008f 00000000 007f0c7f 0012ff34 0041d1f5 004052cf 3e12dc00
0012faa8: 000024b7 00010000 00000001 004053c0 00000001 004070a1 00000006 004d95f6
0012fac8: 00000002 00000000 ffffffff 00407b58 00000020 00000025 27f7c000 18de3000
0012fae8: 62e0e000 48d06000 7ffe0000 6c845000 675c3a43 73656d61 6572465c 61705365
0012fb08: 00326563 5f327366 6e65706f 6c74685f 6578652e 0012fb00 0012fbb0 77f98191
0012fb28: 77f89650 20828313 8e05509c 3f870f7c 06026a57 00000a00 00000000 00000080
0012fb48: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
0012fb68: 00000000 00000000 00000000 00000000 00000000 00000800 00000000 0012fcdc
0012fb88: 00135204 00135200 00000100 77d86288 0013521c 77d86291 00135204 77d98150
0012fba8: 0012fcf0 00000000 77d86662 00134f98 00000002 00000100 00000001 00000000
0012fbc8: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
0012fbe8: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
0012fc08: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
0012fc28: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
0012fc48: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
0012fc68: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
0012fc88: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
0012fca8: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
0012fcc8: 00000000 77d98170 00000100 00000002 00000100 0012fcf4 77d8658b 0012fd5c
0012fce8: 00000001 0012fd30 00000100 0012fd14 77d863de 00000000 0012fd5c 00000100
0012fd08: 00000000 0012fd40 00000100 0012fd40 0012fe64 00135c54 00135c50 00000010
0012fd28: 77d86288 00135c6c 77d86291 00135c54 0012feac 00000100 00000000 77d4a091
0012fd48: 001358c8 00000003 00000010 0012fe9c 0012fe9c 15b2fc4d 4ddd2e09 88410ba4
0012fd68: 70c6ad77 cdd867f9 baa21df5 da74a1eb 8462f736 61155118 e394fba6 6652b0df
0012fd88: d294242a 2bfc5024 ad39cbf8 aee6d9a4 18c1ac30 b4826a9d 929caa26 1d723ae9
0012fda8: 39efc546 f319447d 93b041d9 65512384 f18e519a 50dc05b5 7208797e ef9459a8
0012fdc8: 0f87156c 3f9c0a28 7c2ae212 3e252550 6a118485 ce60be88 f5b8d49c 4924b95a
0012fde8: c7ae194b 40a75ac5 520e2b2c 30f757c5 3c32d9d0 f57fdb41 6b9abfb4 7ec3e586
0012fe08: 574e7b56 3e91e56f c3550f90 7cfd4463 51cb3376 8c03ac65 bedb0f8e ea5296f0
0012fe28: 34c30fd6 1e551b79 175f0a02 31fd627b 760ce87f 58dbac86 bd4c1bee ff052530
0012fe48: 90e4caa6 18d22784 77b2b6e8 77b2b6e8 77aaeec6 77aaeeed 77b2b700 77b2b6e8
0012fe68: 00000001 77aaf1bf 00000017 0012feac 00000001 00000017 77aaac8d 00000001
0012fe88: 00000000 0013ff98 00140008 00140008 77aa6299 77b2b750 8007000e 0012ff00
0012fea8: 00000000 00000000 00000001 00000000 7c57b580 77a98978 0013ff98 00000000
0012fec8: 77a77a27 00000000 00000000 0012fef4 00000002 77a7767c 77a7768b 77b2b0b0
0012fee8: 00000000 00000000 7ffdf000 0012ff34 00407bc0 00400000 00000000 0013395f
0012ff08: 00000001 00000000 00000000 7ffdf000 ffffffff 0012ff0c 0012f5b4 0012ffb0
0012ff28: 005f7b88 00625550 00000000 0012ffc0 005f7f72 00400000 00000000 0013395f
0012ff48: 00000001 00000000 00000000 7ffdf000 bbcc4d04 0013395f 00000000 00000044
0012ff68: 00134610 00134d58 00134f68 00000000 00000000 00000000 00000000 00000000
0012ff88: 00000000 00000000 00000401 00000001 00000000 00000000 00010001 00000000
0012ffa8: 0012ff4c 00000000 0012ffe0 005f7b88 006261f8 00000000 0012fff0 7c5987e7
0012ffc8: 00000000 00000000 7ffdf000 00000000 0012ffc8 00000000 ffffffff 7c5c1bb4
0012ffe8: 7c572b00 00000000 00000000 00000000 005f7e92 00000000
Module list: names, addresses, sizes, time stamps and file times:
C:\WINDOWS\system32\d3d8.dll, loaded at 0x00230000 - 1156608 bytes - 3dedc941 - file date is 12/11/2002 23:14:32
C:\WINDOWS\system32\d3d8thk.dll, loaded at 0x00360000 - 7168 bytes - 3dedc939 - file date is 12/11/2002 23:14:32
C:\games\FreeSpace2\fs2_open_htl.exe, loaded at 0x00400000 - 2564096 bytes - 3f8b0355 - file date is 10/13/2003 14:56:08
C:\WINDOWS\system32\nView.dll, loaded at 0x122d0000 - 852038 bytes - 3f25afde - file date is 7/28/2003 14:19:00
C:\PROGRA~1\Grisoft\AVG6\avgoerun.dll, loaded at 0x12d20000 - 40960 bytes - 3bc2e655 - file date is 4/10/2003 05:00:00
C:\WINDOWS\system32\DDRAW.dll, loaded at 0x51000000 - 257536 bytes - 3dedc926 - file date is 12/11/2002 23:14:32
C:\WINDOWS\system32\dsound.dll, loaded at 0x51080000 - 336384 bytes - 3dedc968 - file date is 12/11/2002 23:14:32
C:\WINDOWS\system32\KsUser.dll, loaded at 0x5ef80000 - 4096 bytes - 3dedcbf6 - file date is 12/11/2002 23:14:32
C:\WINDOWS\system32\DINPUT.dll, loaded at 0x5f580000 - 150016 bytes - 3bd5d93d - file date is 10/30/2001 07:10:00
C:\WINDOWS\system32\USP10.dll, loaded at 0x66650000 - 315664 bytes - 3ef27503 - file date is 6/19/2003 12:05:04
C:\WINDOWS\system32\PSAPI.DLL, loaded at 0x690a0000 - 28944 bytes - 38439a0a - file date is 12/7/1999 05:00:00
C:\WINDOWS\system32\OPENGL32.dll, loaded at 0x69510000 - 692496 bytes - 3ef274fc - file date is 6/19/2003 12:05:04
C:\WINDOWS\system32\OLEPRO32.DLL, loaded at 0x695e0000 - 164112 bytes - 3ef274fc - file date is 6/19/2003 12:05:04
C:\WINDOWS\system32\NTMARTA.DLL, loaded at 0x69bf0000 - 102672 bytes - 3ef274fb - file date is 6/19/2003 12:05:04
C:\WINDOWS\system32\LPK.DLL, loaded at 0x6ca60000 - 20240 bytes - 3ef274f4 - file date is 6/19/2003 12:05:04
C:\WINDOWS\system32\HID.DLL, loaded at 0x6f9a0000 - 18192 bytes - 3ef274ee - file date is 6/19/2003 12:05:04
C:\WINDOWS\system32\GLU32.dll, loaded at 0x6fac0000 - 119568 bytes - 384399ab - file date is 12/7/1999 05:00:00
C:\WINDOWS\system32\SHLWAPI.dll, loaded at 0x70a70000 - 395264 bytes - 3f8ef784 - file date is 10/16/2003 13:38:20
C:\WINDOWS\system32\COMCTL32.dll, loaded at 0x71710000 - 529680 bytes - 3d6e2bf3 - file date is 8/29/2002 06:14:40
C:\WINDOWS\system32\DCIMAN32.dll, loaded at 0x728a0000 - 8464 bytes - 38439988 - file date is 12/7/1999 05:00:00
C:\WINDOWS\system32\lhacm.acm, loaded at 0x74f80000 - 34064 bytes - 3843995e - file date is 12/7/1999 05:00:00
C:\WINDOWS\system32\imaadp32.acm, loaded at 0x74f90000 - 16656 bytes - 3ef274e4 - file date is 6/19/2003 12:05:04
C:\WINDOWS\system32\msafd.dll, loaded at 0x74fd0000 - 108816 bytes - 3ef274f6 - file date is 6/19/2003 12:05:04
C:\WINDOWS\System32\wshtcpip.dll, loaded at 0x75010000 - 17680 bytes - 3ef27506 - file date is 6/19/2003 12:05:04
C:\WINDOWS\system32\WS2HELP.DLL, loaded at 0x75020000 - 18192 bytes - 3843995d - file date is 12/7/1999 05:00:00
C:\WINDOWS\system32\WS2_32.DLL, loaded at 0x75030000 - 69904 bytes - 3ef27506 - file date is 6/19/2003 12:05:04
C:\WINDOWS\system32\WSOCK32.dll, loaded at 0x75050000 - 21776 bytes - 3ef27506 - file date is 6/19/2003 12:05:04
C:\WINDOWS\system32\SAMLIB.dll, loaded at 0x75150000 - 49936 bytes - 3ef274ff - file date is 6/19/2003 12:05:04
C:\WINDOWS\system32\NETAPI32.DLL, loaded at 0x75170000 - 311568 bytes - 3ef274f9 - file date is 6/19/2003 12:05:04
C:\WINDOWS\system32\NETRAP.DLL, loaded at 0x751c0000 - 11536 bytes - 3843995b - file date is 12/7/1999 05:00:00
C:\WINDOWS\system32\LZ32.DLL, loaded at 0x759b0000 - 10000 bytes - 3ef274e2 - file date is 6/19/2003 12:05:04
C:\WINDOWS\system32\msadp32.acm, loaded at 0x75d40000 - 15120 bytes - 3843994f - file date is 12/7/1999 05:00:00
C:\WINDOWS\system32\MPR.DLL, loaded at 0x76620000 - 55056 bytes - 3ef274f5 - file date is 6/19/2003 12:05:04
C:\WINDOWS\system32\msacm32.drv, loaded at 0x77400000 - 21264 bytes - 3844d039 - file date is 12/7/1999 05:00:00
C:\WINDOWS\system32\MSACM32.dll, loaded at 0x77410000 - 66832 bytes - 3844d039 - file date is 12/7/1999 05:00:00
C:\WINDOWS\system32\RASMAN.DLL, loaded at 0x774c0000 - 58128 bytes - 3eb1be31 - file date is 5/1/2003 16:39:14
C:\WINDOWS\system32\rasapi32.dll, loaded at 0x774e0000 - 197392 bytes - 3ef274de - file date is 6/19/2003 12:05:04
C:\WINDOWS\system32\TAPI32.DLL, loaded at 0x77530000 - 126736 bytes - 3ef274de - file date is 6/19/2003 12:05:04
C:\WINDOWS\system32\wdmaud.drv, loaded at 0x77560000 - 21264 bytes - 3ef274de - file date is 6/19/2003 13:05:04
C:\WINDOWS\system32\WINMM.dll, loaded at 0x77570000 - 189200 bytes - 3844d038 - file date is 12/7/1999 05:00:00
C:\WINDOWS\system32\WINSPOOL.DRV, loaded at 0x77800000 - 113936 bytes - 3ef274dd - file date is 6/19/2003 12:05:04
C:\WINDOWS\system32\VERSION.dll, loaded at 0x77820000 - 16144 bytes - 3ef274dd - file date is 6/19/2003 12:05:04
C:\WINDOWS\system32\RTUTILS.DLL, loaded at 0x77830000 - 44816 bytes - 3844d037 - file date is 12/7/1999 05:00:00
C:\WINDOWS\system32\SETUPAPI.DLL, loaded at 0x77880000 - 570128 bytes - 3ef274dd - file date is 6/19/2003 12:05:04
C:\WINDOWS\system32\WLDAP32.dll, loaded at 0x77950000 - 162064 bytes - 3ef274dd - file date is 6/19/2003 12:05:04
C:\WINDOWS\system32\DNSAPI.DLL, loaded at 0x77980000 - 134928 bytes - 3ef274dd - file date is 6/19/2003 12:05:04
C:\WINDOWS\system32\OLEAUT32.dll, loaded at 0x779b0000 - 626960 bytes - 3ef274dd - file date is 6/19/2003 12:05:04
C:\WINDOWS\system32\ole32.dll, loaded at 0x77a50000 - 945936 bytes - 3f47e146 - file date is 8/23/2003 13:48:56
C:\WINDOWS\system32\NTDSAPI.dll, loaded at 0x77bf0000 - 57616 bytes - 3ef274dd - file date is 6/19/2003 12:05:04
C:\WINDOWS\system32\RPCRT4.dll, loaded at 0x77d30000 - 432912 bytes - 3f47e146 - file date is 8/23/2003 13:48:56
C:\WINDOWS\system32\USER32.dll, loaded at 0x77e10000 - 380176 bytes - 3f302c32 - file date is 8/5/2003 14:14:12
C:\WINDOWS\system32\GDI32.dll, loaded at 0x77f40000 - 222992 bytes - 3f302c32 - file date is 8/5/2003 14:14:12
C:\WINDOWS\system32\ntdll.dll, loaded at 0x77f80000 - 491792 bytes - 3ef274dc - file date is 6/19/2003 12:05:04
C:\WINDOWS\system32\msvcrt.dll, loaded at 0x78000000 - 286773 bytes - 3e6e3115 - file date is 6/19/2003 12:05:04
C:\WINDOWS\system32\SHELL32.dll, loaded at 0x782f0000 - 2383632 bytes - 3ef274dd - file date is 6/19/2003 12:05:04
C:\WINDOWS\system32\USERENV.DLL, loaded at 0x7c0f0000 - 385808 bytes - 3f302c32 - file date is 8/5/2003 14:14:12
C:\WINDOWS\system32\ADVAPI32.dll, loaded at 0x7c2d0000 - 387344 bytes - 3ef274dc - file date is 6/19/2003 12:05:04
C:\WINDOWS\system32\SECUR32.DLL, loaded at 0x7c340000 - 48912 bytes - 3ef274dd - file date is 6/19/2003 12:05:04
C:\WINDOWS\system32\KERNEL32.dll, loaded at 0x7c570000 - 711440 bytes - 3f302c32 - file date is 8/5/2003 14:14:12
-
We've known about it for several months now. The debug spew isn't going to help. Thanks though.
-
thanks for looking though. you did more than some people do.
-
If you press "y" a couple of times and its a debris peice twice or so it does it. It was fixed for a bit and then it came back.
Its a repeatable bug in my mind. I'm not sure how it hasn't been replicated yet.
-
It can be replicated easily. It just can't be replicated under controlled conditions.
Here's my old post on the matter, which was moved to the internal forum...Originally posted by Goober5000
Now I know what it feels like to be a quantum physicist. :rolleyes:
It seems that the "Y" targeting bug doesn't want to be found out. I have determined that the crash occurs in hud_reticle_pick_target in hudtarget.cpp, but I can't figure out anything more than that, for the following reasons.
1) The crash doesn't occur using the debug build.
2) Any attempt to trace through hud_reticle_pick_target causes the bug to not occur. :confused:
I just compiled and ran two versions of fs2_open_r... one with no modifications to hudtarget.cpp, and one with just three commands spaced at beginning, middle, and end of the function that printed a number to a file. The no-mod build crashed, while the trace build worked just fine. :wtf:
So any attempt to figure out the cause of the bug results in the bug spontaneously fixing itself. :rolleyes: It's an infuriating little thing.
-
A bug that fixes itself when looked for.... Sounds like windows.
-
Heisenbug.
-
probably the only (hackish) solution to this is to disallow debris from being targeted
edit: i think i may have figured it out. RandomTiger's debug file system works in release builds. all we have to do is have the function write to the debug file periodically so we can isolate what is happening. to be honest, i've _never_ encountered this.
-
yes this is a quantum bug, when ever you look for it it disapears
the big problem is we can alomst never reproduce it when we are looking for it, I know it's there, it crashes me out constantly but as soon as I try to trigger it, it mysteriusly diisapears, so the work around for it is simply try to make it crash.
and we don't even know for sure if debris is what's causing it
-
I dont know if this helps. In the 'Rebels and Renegades' mission (the one where you shot asteroids and protect the Icini..sorry for the spolider hahahaha) this bug always accur, for me anyway.
-
Asteroids and debris both trigger it, so disabling targetting of debris won't solve the problem.
-
asteroids are debris
and you know I just thought of something, what if it targets something that it thinks is a ship but realy isn't, and it trys to get at it's ship stuf that isn't there
-
Stupid question, ive looked and cant find where to disable debris targeting. I am prolly gonnna feel like a fool for not finding it...
-
that's something were gona have to do
-
Originally posted by StageTech
Stupid question, ive looked and cant find where to disable debris targeting. I am prolly gonnna feel like a fool for not finding it...
That's because this is not currently possible.
-
Originally posted by Bobboau
asteroids are debris
and you know I just thought of something, what if it targets something that it thinks is a ship but realy isn't, and it trys to get at it's ship stuf that isn't there
'tis possible; didn't you say you found something in the code where things were trying to reference ship data and the function kept returning -1?
-
I think I remember somethng, but I don't think it was related to this (I think it was the function that found a ship based on it's name)
I looked through the general vacinity of the targeting function in question but I don't think there is anything inside it that would cause the problem, maybe we should make accesor functions or macros for the debug build that would assert a valid ship is getting returned
-
I looked at the bug a few weeks ago and I managed to figure this out:
First I found that an easy way to replicate it is to start an asteroid mission (into the maelstrom is my favourite to create crashes with), target an asteroid with the reticle function and then immidetly press the reticle key once again (within 750 ms). It is possible that it could crash during other curcmstances as well but it didn't seem so, at least after the short testing I made.
I went through the code that handels the target in reticle part (all of what I could find acutally). The game keeps a list of recently targeted ship via the reticle function so that you can press the key quickly again to get a diffirent ship that also is within the reticle. This list is cleared every 750 ms. My guess one could start there.
I think I understood most if not all of the code except for the part wich calulates if a ship is in the reitcle or not (neither method used). I couldn't see anything that was faulty. But I'm not that great coder so I would be suprised if I actually had found anything.
As mentioned before the bug doesn't appear in debug builds. Somewhere (but unable to refind it) I read that it could be that debug builds allocated a bit of a safety buffer around each memory block and simply ignored if that buffer was used and continued. The release build does natrually not do that.
Originally posted by Goober5000
Originally posted by StageTech
Stupid question, ive looked and cant find where to disable debris targeting. I am prolly gonnna feel like a fool for not finding it...
That's because this is not currently possible.
When the code is about to figure out which target is the correct one to choose it first checks if there are any real ships (not debris or asteroids). If there are real ships it removes the debris and asteroids (they are acutally differently flagged) from the possible candidate list. You could make it so it always removes those crashy objects.
I don't remember if it was exactly that way but it should at least be something similar.
-
So if you aren't sure it's debris that cause it, ehy don't you make a simple mission, only debris and see if it crashes again. It may not solve the problem, but it'll give you a hint to what you should be looking for...
-
iv encoured this bug when targeting normal ships. Iv had this bug when: A ship is still exploding and i target its debris right after the ship explodes. but mostly when i target normal ships
-
I hate to drag up an old question, but I was talking to my roommate (a CS major) and he said this sort of bug can occur with floating point variables (especially in comparisons) and that inserting a print command before the offending line can cause them to behave properly. It makes very little sense, but I figured I'd put up the input ASAP. If someone could post (or PM if it's long) the offending function in its original form, I'd like to take a look at it. I don't know enough C to mess with CVS or I'd dig it up myself.
-
that makes no sence...
have your frend post here
-
I dont really understand the difference between the open-source and the original coding so this may sound like I am a fool for asking, but why would it not crash on the retail release yet does on the open-source release? I guess my lack of knowledge on this kinda is confusing me.
-
Originally posted by StageTech
I dont really understand the difference between the open-source and the original coding so this may sound like I am a fool for asking, but why would it not crash on the retail release yet does on the open-source release? I guess my lack of knowledge on this kinda is confusing me.
I belive it does crash in the old Volition FS2 retail as well. It's with a special kind of build to eliminate bugs, called a debug build, it does not crash.
-
The reason fs2_open crashes is that somebody somewhere along the line accidentally let a bug into the code. It never crashed in retail fs2.
Debug builds do not "eliminate bugs"... they are designed to make bugs easier to see. The fact that this particular bug does not appear in a debug build is highly unusual.
-
ah, thank you for clarifying that, was curious.
-
Ah, not fair, newbie while I was having a night on the town. ;)
Welcome to HLP, StageTech!
:welcome:
-
Originally posted by Goober5000
Debug builds do not "eliminate bugs"... they are designed to make bugs easier to see.
That was what I meant :p. They are built to eliminate bugs with, of course you have to do the hard work yourself. And ok I wasn't sure about the original FS2 part, you're probably right.
This code below is the first half of the function that decides which one of the targets that are in the reticle that will be the new target. Code starting at line 2686 in HUDtarget.cpp (of whatever version I have).
Is it possible that this might do a hackish fix to alter the code to always culls the debris out (it's not altered below, but you get it)? I haven't made a succeful build yet so I can't tell.
[EDIT] Changed the function to a much simpler one. This is a function called to determine if it's a allowed target to target through the reticle function. It's called from hud_target_in_reticle_new() and hud_target_in_reticle_old(). As before this is the original one below.
// Return !0 if target_objp is a valid object type for targeting in reticle, otherwise return 0
int object_targetable_in_reticle(object *target_objp)
{
int obj_type;
if (target_objp == Player_obj ) {
return 0;
}
obj_type = target_objp->type;
if ( (obj_type == OBJ_SHIP) || (obj_type == OBJ_DEBRIS) ||
(obj_type == OBJ_WEAPON) || (obj_type == OBJ_ASTEROID) || (obj_type == OBJ_JUMP_NODE) ) {
return 1;
}
return 0;
}
-
I haven't experienced the crashing yet, but I've seen that the debris models lack any kind of detail when I'm playing with HT&L, Large Textures and FS2_Open_3.5.5 with the latest media VP.
I mean that when a ship explodes and I target in reticle a piece of the ship...... It looks like a model with no texture at all.
-
kakis could be right with this 750 ms stuff. I encountered this bug for the very first time today, when I looked at a exploding ship an pressed "target-in-reticle" very fast, which resulted in targeting various debris parts and then a crash to desktop.
If I do the same thing slower no crash occurs.
-
The procedure that Kakis gave seems to work fairly reliably to reproduce the bug, but I have had the same thing occur (spontaneous in-mission crash to desktop) in a number of other situations that did not involve targeting or debris at all. I have had it happen when I launched missiles, ships fired beams, messages were sent and a number of other things. Maybe we are dealing with more than one bug here.
-
Can I get a comment on my code suggestion from one of the real SCP coders that actually knows their stuff?
-
Bumping thread (I know this about bumping old threads...sorry...I just really want this bug solved)
Any updates? If not a bit of a guess follows below:
I was talking to a friend the other day and somehow got into coding and stuff and for some reason I mentioned this weird bug. He replied that it would probably be that somewhere there is apointer that isn't initalized. I didn't understand it fully but in some way debug builds would always initlaize it to null which the release build won't do (sort of).
Then there is perhaps some place in the code that checks if it's a null pointer and if so then something happend and do this instead, otherwise carry on...which would lead to a crash with a bad pointer.
-
here's a part of the dev log sticks posted on the new webpage
1. The "Y" Targeting Bug
Unfortunately, this week the "Y" bug has not yet been solved. There were a number of theories. Here's what Goober had to say.
Okay, the 2/19 build crashes, which means the bug was introduced between 2/14 and 2/19. I'm guessing it all happened in Bobboau's commit on 2/16.
A CVS diff between those dates produces a fair amount of output... there are modifications in twelve files: freespace.cpp, grd3drender.cpp, gropengl.cpp, multimsgs.cpp, object.cpp, managepilot.cpp, aicode.cpp, ship.cpp, shiphit.cpp, beam.cpp, weapon.h, and weapons.cpp. Can you guys take a look, do a date diff, and see what you come up with?
The slipperiness of the bug reared its ugly head as well. Sticks said, "Debug and release work fine for me, I did the same thing as RT." After much confusion, the probable source has been located, although no devs can say why exactly. From Goober:
Okay. Following Phreak's suggestion, I systematically rolled back each file committed on 2/16 to pinpoint the error. The results are disturbing.
The 'Y' targeting bug was introduced in weapons.h, when version 2.6 was updated to version 2.7.
This doesn't make any sense! Look at the CVS diff between those two versions. The changes were trivial - one #define and two float declarations. Why on earth would this introduce a bug?!? Could the size change of the BWI struct have anything to do with it?
The issue currently remains unresolved.
-
Looks like you're getting somewhere though...
-
Actually, we reached a dead end. We'll have to turn around and try something different now. :sigh:
-
I'm no programmer, but could it be a memory issue? As I said before, it occurs with many seemingly disparate events, but the one thing I noticed was that whatever causes it has always done so in its first instance of a game session. For example, firing bombs caused it when I did so for the first time since the exe was opened up, and so on. It may well just be coincidence, or it could point to some problem if stuff is being loading into memory in the middle of a game.
-
Yay! The Dev Log got quoted already!
The problem with this type of bug is that they are very unreproduceable, which means that tracing through the code is almost impossible unless you just happen to stumble upon it while debugging.
-
StrattComm your roommate is talking out his arse
he found a 'solution' that solves the symptom, not the problem
floating points in comparisions don't cause any problems either
this is a memory overwrite somewhere
-
He didn't find the "solution" and the symptom is of the problem of not accounting for the sometimes odd ways that computers deal with floating point variables. In general a proximity comparison is preferable for floating points (within set range of # rather than logical equals) as it allows for small miscalculations and inconsistancies to be overlooked. He actually pointed me to a discussion on TopCoder that discussed just such a crash, and that was the basis for my post what, two weeks ago. And I didn't say he looked at the code and dug up a the solution either, he just pointed out something (originally discussed on TopCoder I believe) that has appeared before, can cause a program to crash, only shows up in rare instances, and is a genuine pain to trace and debug. As for him "talking out his arse," he is one of the best C++ coders you'll ever meet so it wouldn't hurt to at least take it under advisement. It's not the only possibility for the crash or even a likely one, but it is possible.
-
From reading the posts about the crash I think it might be worth taking in consideration the produced code by the compiler cause when I was working on a big project, I was experiencing strange crashes that was never caught in the debug version, and after testing and going thru the assembler code produced by the compiler for the release code, i found a small bug, a mismatched stack frame register that wasn't supposed to be there. The problem caused by that was that there were too many functions/classes in one file that might have caused the compiler to misproduce one byte of code, and it was gone by just dividing the big source file in smaller files.
Just telling my story in hunting a devious bug.
Ynaig
-
Hm. Ynaig, would you like to take a look at the code? Say the word, and we'll give you an avatar and private forum access. ;)
-
you seem to enjoy pain. you'll fit right in
-
Originally posted by Goober5000
Hm. Ynaig, would you like to take a look at the code? Say the word, and we'll give you an avatar and private forum access. ;)
Well I did a cvs for fs2_open and i saw that the file named hudtarget.cpp is way over 170KB and I know from my experience that big source files always compromises the compilers' ability to produce good code. Please take in consideration to break it in smaller files, as I can't successfully compile the entire fs2_open with VS.NET 2003. I keep getting lots of errors like "code\graphics\2d.h(561) : error C2383: 'screen::gf_set_palette' : default-arguments are not allowed on this symbol". At one moment it barfed with compiler internal error, meaning that the compiler ran out of memory or resources when trying to compile a file. I have 512MB so it's enough for compilation, but again I speak from experience that such big source file spells trouble for compiler.
Best regards,
Ynaig
-
You downloaded the source; you're in. ;)
-
Yes, he is. ;)
-
I tried to compile the source code with VS.NET 2003 but to no avail, I keep getting lots of errors as i stated above. I guess the project is for VC6 which i don't have it anymore. Sorry. If i could have time to edit all the source files to compile under VS.NET 2003 i could help, but my time is limited.
Ynaig
-
I'm missing the file "amvideo.h" which prevents me from compiling. Where can I get it?