View Issue Details

IDProjectCategoryView StatusLast Update
0001781FSSCPFREDpublic2012-07-01 06:05
ReporterKeldorKatarn Assigned ToGoober5000  
PrioritynormalSeveritycrashReproducibilityalways
Status closedResolutionunable to reproduce 
Product Version3.6.9 
Summary0001781: FRED crashes if a mission is lacking a referenced object or variable
DescriptionThis 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.
TagsNo tags attached.

Relationships

has duplicate 0001658 resolvedGoober5000 More elegant exception handling for Undocked containers. 

Activities

Zacam

2008-09-28 07:44

administrator   ~0009731

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.

karajorma

2008-10-10 18:37

administrator   ~0009926

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.

KeldorKatarn

2008-10-15 09:48

reporter   ~0009985

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.

karajorma

2008-10-15 09:53

administrator   ~0009986

Then fix it yourself since I have so much to learn.

Tolwyn

2008-10-15 09:54

reporter   ~0009987

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.

KeldorKatarn

2008-10-15 10:00

reporter   ~0009988

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.

KeldorKatarn

2008-10-15 10:07

reporter   ~0009989

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.

Shade

2008-10-15 10:16

developer   ~0009990

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.

Goober5000

2008-10-15 16:11

administrator   ~0009991

Last edited: 2008-10-15 16:11

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.

Zacam

2008-10-16 18:06

administrator   ~0010011

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.

Goober5000

2012-07-01 06:05

administrator   ~0013745

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.

Issue History

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