|
|
Update: Starting to have the "not so sure" feeling now when it comes to crashes with the debug. Using the 5700 nightly and in some places where my compiled Release builds exit with weird errors, some of the 5700 builds tested exit cleanly. 5700 nightly appears to still have the bug above, I'm just no longer so sure about the crashing going on here, that's all. Will assume for now that maybe it's caused by my non-Unicode language setting set to something other than English, but that's another topic. Edit: GTDR Amazon Advanced, not GTDR Amazon |
|
|
This issue seems to be related to the rather varied use of memcpy, malloc and STL vector containers in the code. |
|
|
Can we get a means of reproducing this reliably? In the absence of a more recent report, the changes in the code over the last year could well make this redundant. |
|
2010-12-20 10:09
|
|
|
|
Attached a file. File has two tbm's that just need to be... exchanged (e.g. load one tbm, not both, at any one time). This is as close as I can get to reproducing it reliably, using only the table entries on the wiki. One tbm has the tech description in the template, other one in the ship class entry. I tested the zip contents with AP8 SSE2 both debug and release builds, with one (new) pilot used on both tries. Testing only done in Tech Room using the view-all cheat, no missions were loaded, no campaign tested etc so I didn't see if loadout screens are also affected (for those other multi_text strings). I can't find the tables where I found this error, probably lost to time. There was also one instance where I tested the two attached tbm's with a new mod attempt I'm still tabling, the words "Ship distribution." came from out of nowhere in AP8 debug. Release - blank entry. As though the tech room sentence got cut off, or something... but I searched my current tables in Notepad++ and couldn't find those words anywhere, so I retested the tbm's in the attached zip as a separate mod. Also the AP8 debug crashes with some Windows error message (Debug Assertion Failed! blah blah blah). |
|
|
Can you provide the AP8 debug crash - the "Debug Assertion Failed!" and following text. |
|
2010-12-25 02:54
|
ap8.JPG (18,895 bytes) |
|
|
ARGHHH COPYPAST FORGOT TO MOVE EXISTING PILOTS TO A SAFE PLACE have to make them all over again and rebind controls oops >_< ~~~ Image uploaded, and this crash occurs on exit. Doesn't matter if shortcut keys to exit were pressed, or if I exit the game from the mainhall. Side note, I normally get a crash like this (as in, it occurs the same way, but error message is less detailed, just "Assert Failed") when I use debug builds I compile myself - this is the first time I see it on a different build. Didn't think too much into it because I assumed it had something to do with my language setting for non-Unicode applications not being English at the time - the crash doesn't happen when I set it back to English and recompile. |
|
2011-08-08 13:29
|
|
|
|
2011 update - r7430 Inferno SSE2 Referring to Artemistest_New.zip: FRED and FSO builds always throw up Windows error messages on exit, so long as template ships exist in the tables read by the executables In-game: Normal tabled Artemis ships, both ---> works okay Template tabled Artemis ships, both ---> Call in a support ship, game crashes with Windows error message when ship finishes warp-in sequence Discovered this with new mod tables, since I'm using quite a few templates in them. Might be other errors I haven't found yet. Unable to verify if this bug also affects missions crashing the moment I press 'Launch' in the loadout screen - I deleted the missions already partly because they were old. Hence not sure if the crash is related to not editing them after so many build revisions, or because of this template issue. |
|
|
In addition to all the weird stuff* that occurs, the mod I'm tabling is now impossible to FRED due to this bug. I cleared out all templates from my tables and put them back as individual ships. For now just to add one more: Templated station/capital ship that has been placed in the mission (hence appears right at the start) results in an instant crash on Commit/Launch button. FRED doesn't 'crash' - it does throw Windows errors on exit - but the game does crash. Change the tables so that each ship is individual instead of template cut-outs, and the error is gone. Observed this with an Arcadia installation which I converted into templates. Probably an Orion and a Hecate too. (Now I regret deleting those missions, they were fine all along.) I think the way the game crashes is different for the player ship, small ships under AI, and big ships/stations, and maybe if the instance exists in mission. Don't have time to test it now though. *Windows error message crashes, support ship crashes, Commit/Launch crashes, wrong text in tech room, etc... |
|
|
Verified still an issue with artemistest_new.zip. Game will crash when the support ship is called in the mission. I suspect based on these notes that there is a more pervasive issue with templates going on. (Does anyone ever actually use templates?) |
|
|
Adding to what Wanderer said, this may have to do with the fact that the code does a memcpy directly from the template to the ship using it, while there are several components of ship_info which really need to be deep-copied (mainly structs and vectors). If this really is the cause, then the solution would be to replace that memcpy with a function which copies each element individually, making sure that the things which need to be duplicated are in fact duplicated. |
|
|
Assigned this to Goober for attentions because he was thinking his memset memcopy fixes may fix this. |
|
|
Oh, good catch. I wasn't sure if this was already in Mantis. Wanderer was correct in his hunch: the problem is indeed related to memset and memcpy. Specifically, you can't copy the ship_info "struct" because it's now a class. The class fields and sub-fields all have member functions which get hosed. Unfortunately, it's not fixed, just bypassed. The code will now detect an attempt to perform a ship copy, display a warning message, and refrain from corrupt the object tree. But ship templates will not actually work unless and until someone can implement a copy method for ship_info. (Or an "assign" method, similar to the player struct/class.) And that is going to be a fairly big job. I'm bumping this over to Turey since he was the one who created ship templates in the first place. |
|
|
In that case, I think it would be good to start an official discussion about removing this feature. It's never really worked. Now, at best, it's a way to get a warning and not a crash. Mods can't have relied on this "feature" ever. Additionally, Turey hasn't been active in several months. It doesn't hurt to ask, I suppose, but I'm betting we won't get this big job finished any time soon since he as never commented on this bug, for one. So I think it would be better to remove a half-completed feature than allow it to remain in the codebase and rot. |
|
|
Well, I started a discussion in the SCP internal about memset, memcpy, and memmove -- a discussion which mentioned ship templates as never working -- but it didn't get much response: http://www.hard-light.net/forums/index.php?topic=85667.0 Which is fairly disappointing, as this is a major strategic concern with our design. But I agree with you about removing the feature rather than leaving it to rot, and I'm glad to see that another person has independently reached the same conclusion. So I think I'll go ahead and do exactly that. |
|
|
I can look into setting up a deep copy function for ship_info, but I don't mind the template feature being removed until such a thing is completed. |
|
|
Ah, well, that changes things a bit. If you're going to set up a deep copy in the near future, then I'll leave the template function alone. On the other hand, if that's not something you'll be able to get to for a while, then I'll remove it. |
|
|
I will have time to do so in November. |
|
|
November should be fine. |
|
|
That's good. I'll go see about downloading the code and getting back into it. |
|
|
It's November. What do you think your schedule will be like this month, Turey? |
|
|
I should have time for it, it's just a matter of relearning the code base. |
|
|
Okay, cool. |
|
|
Someone on the forums seems to have been asking about this feature... we are 8 months overdue on that possible fix. Should probably make a decision about the ship templates feature altogether soon. |
|
|
I don't have time to fix it, we can go ahead and remove it. |
|
|
Okay, removed. Marking as WONTFIX. |
- Anonymous
