View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001781 | FSSCP | FRED | public | 2008-09-27 12:29 | 2012-07-01 06:05 |
| Reporter | KeldorKatarn | Assigned To | Goober5000 | ||
| Priority | normal | Severity | crash | Reproducibility | always |
| Status | closed | Resolution | unable to reproduce | ||
| Product Version | 3.6.9 | ||||
| Summary | 0001781: FRED crashes if a mission is lacking a referenced object or variable | ||||
| Description | This is a really annoying problem. Sometimes we try to copy and paste certain events form one mission to the next to reuse them and sometimes we forget to copy a necessary object or variable over. FRED immediately crashes on mission load without error message or anything. The fun thing is.. if you load the mission in the game, the game actually DOES give you a detailed description of the problematic event that is using the missing object/variable. FRED should do the same and not simply crash. It does so with missing events already. Not even having an error message make finding the problem that causes the crash very difficult. | ||||
| Tags | No tags attached. | ||||
| has duplicate | 0001658 | resolved | Goober5000 | More elegant exception handling for Undocked containers. |
|
|
Sort of like the events outlined in 1658 maybe? Finally loaded a test mission like I described into FRED to notice the same results: The game (sort of) gives an error when it crashes, but FRED does not. |
|
|
To be honest my point of view is that if you are using notepad you've already broken out of using FRED and any crashes you receive as a result of you being overly ambitious with your cutting and pasting are really your own fault. FRED goes through all kinds of elaborate type checking when you close down the editor. To expect FRED to be able to deal with your attempts to circumvent that strikes me as being like expecting FS2_open to deal with crashes caused by you getting out a hex editor and altering the code, As far as I'm concerned this isn't a bug and is a feature request really. |
|
|
kajorama, you have a LOT to learn about code design and error handling. Besides.. I requested a feature to copy and paste events from one instance of FRED into another. It was turned down with the comment I should simply use the editor instead. So don't give me this now. And again.. a program should NEVER just crash and burn. NEVER. A simple message box telling me what the problem is would suffice. I don't expect FRED to automatically fix the problem. But if it told me something like "variable missing" or "referenced ship missing" I'd immediately know what I forgot to paste. That is called program stability and user friendliness. Go try to work in IT for a few weeks, you might learn something about those things. |
|
|
Then fix it yourself since I have so much to learn. |
|
|
Just to clarify the situation: Notepad is generally the only way to update a set of complicated SEXP: be it autopilot, a cutscene you use in several missions and so forth. Unless you know some way to transfer a set of SEXPs from one mission to another in an easy way... Keldor is right - it can be really annoying trying to figure out what is going on. Sometimes a variable is missing, sometimes some event gets broken during copy & paste. |
|
|
kajorama.. just to point this out.. YOU are part of the SCP.. I am the user.. not the other way around. If you don't want to support this project then get the hell out. |
|
|
This is not fixed.. and don't you dare close this again.. I'll bombard Mantis with clones of this until finally someone takes a look If you don't know how to fix it shut up and fix some other bug but don't close it just because you're pissed. |
|
|
See, now that's the perfect way to make sure no coder EVER touches this bug. Congratulations. Never forget that this is a volunteer project with no paid staff. Further, being condescending is not exactly the thing that'll motivate people to deal with the problem, especially a problem that is caused by messing around with files using a program not designed for it. Finally, when you use an outside program you do so at your own risk. The game was never designed with the intent that missions be modified using Notepad or other similar programs, so don't go ballistic and accuse the team of not supporting the project if it fails. I think that covers it. Have a *nice* day. |
|
|
I'm willing to take a look at this... but be aware that it might take several days, as this is a busy week. We are not going to change the copy+paste functionality. However, Keldor is right; FRED should not CTD on bad data. But, karajorma and Shade are also right. Condescension and throwing tantrums are a good way to discourage coders from fixing bugs. Please attach the mission that FRED CTDs on. |
|
|
For a plausible scenario NOT involving Notepad for how this problem MIGHT occur in FRED alone: As under Mantis 1658, I had changed the Name of a cargo ship that had cargo connected to it, but the reference in the cargo container was still to the old (now non-existant) name. Now, suppose there is an Update to FRED itsel which breaks that system check and FRED fails to update the cargo container attachment to the new name. The user now has no idea what happened, because there is no elegant exception handling by either FRED or the FSO exe. And the bug reporting on it would be made more difficilt because there may be other changes also being made besides a simple re-name operation. |
|
|
Since KeldorKatarn hasn't attached a mission in the past four years, I'm closing this ticket. I'm happy to fix or improve any error messages with mission loading, as demonstrated by my fix for Zacam's reported bug 0001658. But I will need a mission that demonstrates the behavior, or at the very least, specific instructions on how to reproduce it. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2008-09-27 12:29 | KeldorKatarn | New Issue | |
| 2008-09-28 07:44 | Zacam | Note Added: 0009731 | |
| 2008-10-09 17:10 | chief1983 | Relationship added | related to 0001658 |
| 2008-10-09 17:12 | chief1983 | Relationship replaced | has duplicate 0001658 |
| 2008-10-10 18:37 | karajorma | Note Added: 0009926 | |
| 2008-10-15 09:48 | KeldorKatarn | Note Added: 0009985 | |
| 2008-10-15 09:53 | karajorma | Note Added: 0009986 | |
| 2008-10-15 09:54 | Tolwyn | Note Added: 0009987 | |
| 2008-10-15 10:00 | KeldorKatarn | Note Added: 0009988 | |
| 2008-10-15 10:01 | karajorma | Status | new => resolved |
| 2008-10-15 10:01 | karajorma | Resolution | open => no change required |
| 2008-10-15 10:01 | karajorma | Assigned To | => karajorma |
| 2008-10-15 10:07 | KeldorKatarn | Status | resolved => feedback |
| 2008-10-15 10:07 | KeldorKatarn | Resolution | no change required => reopened |
| 2008-10-15 10:07 | KeldorKatarn | Note Added: 0009989 | |
| 2008-10-15 10:16 | Shade | Note Added: 0009990 | |
| 2008-10-15 10:17 | Shade | Status | feedback => resolved |
| 2008-10-15 10:17 | Shade | Resolution | reopened => no change required |
| 2008-10-15 16:11 | Goober5000 | Note Added: 0009991 | |
| 2008-10-15 16:11 | Goober5000 | Assigned To | karajorma => Goober5000 |
| 2008-10-15 16:11 | Goober5000 | Status | resolved => acknowledged |
| 2008-10-15 16:11 | Goober5000 | Resolution | no change required => reopened |
| 2008-10-15 16:11 | Goober5000 | Note Edited: 0009991 | |
| 2008-10-16 18:06 | Zacam | Note Added: 0010011 | |
| 2012-07-01 06:05 | Goober5000 | Note Added: 0013745 | |
| 2012-07-01 06:05 | Goober5000 | Status | acknowledged => closed |
| 2012-07-01 06:05 | Goober5000 | Resolution | reopened => unable to reproduce |
