Hard Light Productions Forums
Modding, Mission Design, and Coding => The Modding Workshop => Topic started by: DefCynodont119 on April 01, 2016, 09:12:36 pm
-
This is my first real post here, sorry for any mistakes.
So anyway, I need a small team of testers for my minicampaign: Legions Demise. It's a two mission reenactment of FS2's opening cutscene. Where you, Roskva 1, are flying alongside the GTI Command ship; The GTD Legion, As it orbits Deneb III. You then find yourself at the forefront of disaster as things begin to go haywire.
I need people to confirm that it doesn't have any major issues/that it's stable before i can continue development. as most/all of the FREDing for the first mission is done.
I just want to make sure it works for other people, because apparently that's not always the case.
Any help will be appreciated, thank you.
If your interested: Post below. then i can send you the link and unzip password.
PS: Thank you for everyone who let me use their assets, and sorry for the first version of this topic post, it was awful. i am a n0ob.
-DefCynodont119
-
Bah, if you'd posted this 24 hours earlier, I'd've been able to get straight onto this - as it is, I'm not likely to have time til Friday. If you still need people then, let me know.
-
Bah, if you'd posted this 24 hours earlier, I'd've been able to get straight onto this - as it is, I'm not likely to have time til Friday. If you still need people then, let me know.
You have no idea how honored i would be if you helped me, whatever time you get id like to know.
Thanks again!
-DefCynodont119
-
Sounds cool. I'm also rather busy but if you can't find a playtester, I'd be willing to take a look.
-
I could certainly do it.
BTW, ignore woutersmits if he asks to beta-test. TBH, he doesn't know what a good FS campaign looks like.
-
karajorma/BW/lepanto,
Being a long-time lurker of this site, i know you all, [citation needed] and I'm surprised this got your attention, if any of you three have time between now and April 5th, PM me immediately.
i only need minor bugfixing help that i can't figure out. plus it's mostly done FREDing wise, so i need some time to finish writing/briefings after i know that this mod doesn't make your computer explode.
so 2-3 testers max, I'll easily make exceptions however.
After the 5th, my free time goes down significantly. but i will still need testers. so if Black Wolf could PM me next Friday that will work as well.
Once again: Thank you for your support.
-DefCynodont119
-
Just a heads up, this is not dead. Progress is being made!
:headz:
-
Well, you can send the mod my way as well, I can play it, but knowing myself, it will not be as accurate or dedicated mod testing as others will do. But still, might spot a bug or two, or have my own opinion on it.
-
UPDATE
I need someone to help us Identify the cause of a highly complicated CTD Error/Bug:
I am having problems with the Change-Ship-Class SEXP, after making multiple test missions I have confirmed that there are more then one cause for the crash:
1: targeting a subsystem on the ship as its model changes. 2: turrets firing as the host model changes.
both these have been prevented by use of destruction of subsystems and stealth, the event in question still has a chance of crashing. The 3rd cause has yet to be determined as no set of conditions that confirms the crash 100% have been found this time, a test mission is pervaded with the mod.
anyone with Log-reading capability, and at least 2/3 hours of freetime is what I need.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Everyone else, here are some Attachments with Screenshots of stuff:
[attachment DELETED!! by Strong Bad]
-
Can you provide a test mission to recreate this crash? Preferably one without those workarounds; they shouldn't be necessary in the first place.
-
Can you provide a test mission to recreate this crash? Preferably one without those workarounds; they shouldn't be necessary in the first place.
sure, basic mod-free test mission incoming.
If it does not crash immediately, cycle the subsystems on the legion until it does.
[attachment DELETED!! by Strong Bad]
-
I found the problem almost immediately (good ol' debugger); the player's targeted subsystem was stuck in the old subsystem list and thus causing out-of-bounds array accesses leading to the crash. Pull request for a fix here (https://github.com/scp-fs2open/fs2open.github.com/pull/634).
-
I found the problem almost immediately (good ol' debugger); the player's targeted subsystem was stuck in the old subsystem list and thus causing out-of-bounds array accesses leading to the crash. Pull request for a fix here (https://github.com/scp-fs2open/fs2open.github.com/pull/634).
Thanks! I should mention that I worked around that by killing all the subsystems and stealthing the ship just before changing the model, and it would still (inconsistently) crash.
just to be safe I'll/my testers will attach some Log files once I/My testers have reproduced it with the workarounds. Stand by.
EDIT: Here is another instance of the test mission, but this time it crashed on model-change. not after messing around with targeting.
I doubt this will help but I just want to make sure I'm not doing something stupid.
[attachment DELETED!! by Strong Bad]
-
OK, so I messed around with a variation of the test mission, only this time with the workarounds and this happened:
Assert: pair2.dist >= 0
File: shiphit.cpp
Line: 1088
ntdll.dll! NtWaitForSingleObject + 21 bytes
kernel32.dll! WaitForSingleObjectEx + 67 bytes
kernel32.dll! WaitForSingleObject + 18 bytes
fs2_open_3_7_3_SSE2_20151222_7e9a798-DEBUG.exe! SCP_DumpStack + 354 bytes
fs2_open_3_7_3_SSE2_20151222_7e9a798-DEBUG.exe! WinAssert + 194 bytes
fs2_open_3_7_3_SSE2_20151222_7e9a798-DEBUG.exe! spark_compare + 119 bytes
fs2_open_3_7_3_SSE2_20151222_7e9a798-DEBUG.exe! std::_Insertion_sort1<spark_pair *,int (__cdecl*)(spark_pair const &,spark_pair const &),spark_pair> + 127 bytes
fs2_open_3_7_3_SSE2_20151222_7e9a798-DEBUG.exe! std::_Insertion_sort<spark_pair *,int (__cdecl*)(spark_pair const &,spark_pair const &)> + 60 bytes
fs2_open_3_7_3_SSE2_20151222_7e9a798-DEBUG.exe! std::_Sort<spark_pair *,int,int (__cdecl*)(spark_pair const &,spark_pair const &)> + 288 bytes
fs2_open_3_7_3_SSE2_20151222_7e9a798-DEBUG.exe! std::sort<spark_pair *,int (__cdecl*)(spark_pair const &,spark_pair const &)> + 80 bytes
fs2_open_3_7_3_SSE2_20151222_7e9a798-DEBUG.exe! choose_next_spark + 899 bytes
fs2_open_3_7_3_SSE2_20151222_7e9a798-DEBUG.exe! ship_hit_create_sparks + 131 bytes
fs2_open_3_7_3_SSE2_20151222_7e9a798-DEBUG.exe! ship_apply_local_damage + 1103 bytes
fs2_open_3_7_3_SSE2_20151222_7e9a798-DEBUG.exe! ship_weapon_do_hit_stuff + 573 bytes
fs2_open_3_7_3_SSE2_20151222_7e9a798-DEBUG.exe! ship_weapon_check_collision + 3077 bytes
fs2_open_3_7_3_SSE2_20151222_7e9a798-DEBUG.exe! check_inside_radius_for_big_ships + 519 bytes
fs2_open_3_7_3_SSE2_20151222_7e9a798-DEBUG.exe! collide_ship_weapon + 367 bytes
fs2_open_3_7_3_SSE2_20151222_7e9a798-DEBUG.exe! obj_collide_pair + 2404 bytes
fs2_open_3_7_3_SSE2_20151222_7e9a798-DEBUG.exe! obj_find_overlap_colliders + 338 bytes
fs2_open_3_7_3_SSE2_20151222_7e9a798-DEBUG.exe! obj_sort_and_collide + 288 bytes
fs2_open_3_7_3_SSE2_20151222_7e9a798-DEBUG.exe! obj_move_all + 1131 bytes
fs2_open_3_7_3_SSE2_20151222_7e9a798-DEBUG.exe! game_simulation_frame + 1121 bytes
fs2_open_3_7_3_SSE2_20151222_7e9a798-DEBUG.exe! game_frame + 501 bytes
fs2_open_3_7_3_SSE2_20151222_7e9a798-DEBUG.exe! game_do_frame + 231 bytes
fs2_open_3_7_3_SSE2_20151222_7e9a798-DEBUG.exe! game_do_state + 403 bytes
fs2_open_3_7_3_SSE2_20151222_7e9a798-DEBUG.exe! gameseq_process_events + 232 bytes
fs2_open_3_7_3_SSE2_20151222_7e9a798-DEBUG.exe! game_main + 787 bytes
fs2_open_3_7_3_SSE2_20151222_7e9a798-DEBUG.exe! WinMain + 328 bytes
fs2_open_3_7_3_SSE2_20151222_7e9a798-DEBUG.exe! invoke_main + 30 bytes
fs2_open_3_7_3_SSE2_20151222_7e9a798-DEBUG.exe! __scrt_common_main_seh + 346 bytes
fs2_open_3_7_3_SSE2_20151222_7e9a798-DEBUG.exe! __scrt_common_main + 13 bytes
fs2_open_3_7_3_SSE2_20151222_7e9a798-DEBUG.exe! WinMainCRTStartup + 8 bytes
kernel32.dll! BaseThreadInitThunk + 18 bytes
ntdll.dll! RtlInitializeExceptionChain + 99 bytes
ntdll.dll! RtlInitializeExceptionChain + 54 bytes
This happened right at the model change. this is what I was looking for to show you, It looks like there's more then just that one bug with the event.
I should note that bombers were attacking the ship when it changed.
EDIT: New Log attached, old one removed:
[attachment DELETED!! by Strong Bad]
-
This happened right at the model change. this is what I was looking for to show you, It looks like there's more then just that one bug with the event.
I should note that bombers were attacking the ship when it changed.
This scenario never would have happened with the test mission you sent me because it has to do with hit sparks: the spark itself contains a reference to the submodel it's coming off of (and since the new ship type has fewer submodels, you're getting out-of-bounds array access again, leading to nonsensical values which are causing problems when it tries to sort them). It's going to be slightly more difficult to solve this problem, but it should also be doable.
-
Log: (here because you can't put attachments in PMs)
(nothing deleted by no one)
-
That "log" file is 0 kB and contains nothing.
-
That "log" file is 0 kB and contains nothing.
Sorry, something must of happened on upload, re-uploading here.
[attachment DELETED!! by Strong Bad]
-
http://www.hard-light.net/forums/index.php?PHPSESSID=a09c5ee7b37a6206cbb0b9d379d8f9eb&topic=92175.0
Yay! Thanks! I'll be sure to check the nighties.
-
http://www.hard-light.net/forums/index.php?PHPSESSID=a09c5ee7b37a6206cbb0b9d379d8f9eb&topic=92175.0
Yay! Thanks! I'll be sure to check the nighties.
The most recent Windows nightly build as of this post doesn't have the fix, but it has been merged now, so it should be in the next one.