View Issue Details

IDProjectCategoryView StatusLast Update
0001953FSSCPFREDpublic2010-04-13 14:39
ReporterKeldorKatarn Assigned ToGoober5000  
PriorityhighSeveritymajorReproducibilityalways
Status resolvedResolutionfixed 
PlatformIBM PCOSMS WindowsOS VersionVista SP1
Product Version3.6.11 
Target Version3.6.12Fixed in Version3.6.12 
Summary0001953: Departure locations and anchors are destroyed by the ship editor dialogue
Descriptionhere's what happens:

I have several fighters in wings and one fighter without a wing.

I select all of those.

Hat results in an intialization of the ship editor dialogue:

[code]fred2_open_3_6_11d.exe!CShipEditorDlg::initialize_data(int full_update=1) Line 583 C++[/code]

Now.. this one initalizes the dialogue, and among other stuff it does this check:

[code]if (Ships[i].wingnum < 0) {[/code]

If this holds true (ship is not part of a wing) it does (among other stuff) this:

[code]m_departure_location = Ships[i].departure_location;[/code]

Since this is done for all selected ships, it finds my one fighter which is not part of a wing and hence initializes m_departure_location with the departure location of that ship (in my case a docking bay).

Since all other ships are part of a wing, this is not changed after that, so m_departure_location remains 1 (1 = docking bay)

later on the ships are updated

[code] fred2_open_3_6_11d.exe!CShipEditorDlg::update_ship(int ship=20) Line 1232 + 0x32 Bytes C++
     fred2_open_3_6_11d.exe!CShipEditorDlg::update_data(int redraw=0) Line 1024 C++
     fred2_open_3_6_11d.exe!update_dialog_boxes() Line 1267 + 0xc Bytes C++[/code]

And inside there, this happens:

[code] if (m_departure_location != -1)
        MODIFY(Ships[ship].departure_location, m_departure_location);[/code]

So every single ship is set to what now is m_departure_location. Including the ships in a wing... you see the problem. Now ships have a departure location that doesn't even fit them.

I'm not exactly sure how to handle this, since this is probably not the only thing that can go wrong here.
Updating a dialogue with a departure location when multiple ships are selected... that just HAS to overwrite many many departure locations if not all ships have the same one...

I'm not sure how this can be fixed. I don't even know why all this initialization and updating is called...

I mean that a selection updates a dilogue is ok.. I mean the dialogue could be open and needs to display the data of the new selected ships

But why does updating the dialogue write back data to ships? That should only happen when I close the dialogue and confirm what I entered. Not before a dialogue was ever opened for the first time just because I select some ships...
Steps To ReproduceAnother way to reproduce:

- Create two fighters and one ship with a docking bay.
- Give one fighter the docking bay as departure location and the capship as departure anchor. The other fighter keeps hyperspace as departure target
- Now select both fighters.
- Open the ships dialogue and close it again
TagsNo tags attached.

Relationships

has duplicate 0002096 closed Setting departure cue to docking bay causes ships in wings to have invalid departure target 

Activities

chief1983

2009-11-10 03:31

administrator   ~0011231

This is FRED so I'm throwing it Kara's way. It's a Saga showstopper so it needs some lovin'.

KeldorKatarn

2009-12-10 06:51

reporter   ~0011395

Any news on this? Last time I checked (Nightly Build 20091125_r5686) this still happened.

karajorma

2010-01-29 10:14

administrator   ~0011601

Well this is definitely annoying and it needs to be fixed but I don't see how it's a show stopper.

KeldorKatarn

2010-01-29 11:12

reporter   ~0011602

Because we're still editing and finalizing missions and this can accidently destroy missions during beta testing and introduce bugs that we might not find before release. Having a FRED build that potentially destroys missions if you just open the ship dialogue with a seletion that you haven't thought about twice is very problematic.
Call it what you want but it should definately be fixed in time for 3.6.12 RC.
We need it fixed by the time out beta test starts to ensure the correctness of our missions.

chief1983

2010-01-29 15:30

administrator   ~0011603

You do version your missions and compare diffs before committing changes right? That tends to catch those kinds of issues. Not saying it's optimal but at least you won't destroy anything irreparably.

karajorma

2010-02-01 09:16

administrator   ~0011610

To be honest I'm baffled about this one. This is a V bug not an SCP one but the arrival target does not show this behaviour and try as I might I really can't figure out why the hell not as the code is virtually identical for the two.

KeldorKatarn

2010-02-01 11:49

reporter   ~0011611

Last edited: 2010-02-01 11:50

Yeah. I tried to provide a fix myself when I found this. You have to step through the code step by step to find this crap.
I found exacty WHERE it happens but I didn't (and don't unfortunately) have the time to find out WHY it is happening. The code at that position is really strange. I've never seen code for opening a dialogue before that actually writes data.
But then again I've never seen code like FRED anyway. It's a real mess at some places.
I'll see if I can dig into this further later this week or so if I can make the time. This is really hard to track down. That dialogue might need some serious overhaul in places.
You're saying this has been around since Retail? Strange. Maybe some other change triggered the behavior? I never noticed it before.

karajorma

2010-02-12 06:47

administrator   ~0011653

It's definitely retail behaviour. I fired up FRED2 and tested it. The exact same circumstances will result in the data being wiped there too.

Goober5000

2010-04-13 06:54

administrator   ~0011878

A very sneaky bug! Fixed in revision 6051 (6052 in 3.6.12 branch). The fix will be in 3.6.12 final.

Thanks to Keldor's "steps to reproduce" which were very helpful in allowing me to pinpoint the problem. :)

Issue History

Date Modified Username Field Change
2009-07-06 22:45 KeldorKatarn New Issue
2009-11-10 03:31 chief1983 Note Added: 0011231
2009-11-10 03:31 chief1983 Assigned To => karajorma
2009-11-10 03:31 chief1983 Priority normal => high
2009-11-10 03:31 chief1983 Status new => assigned
2009-11-10 03:31 chief1983 Target Version => 3.6.12 RC1
2009-12-10 06:51 KeldorKatarn Note Added: 0011395
2010-01-24 22:27 Goober5000 Relationship added has duplicate 0002096
2010-01-29 10:14 karajorma Note Added: 0011601
2010-01-29 11:12 KeldorKatarn Note Added: 0011602
2010-01-29 15:30 chief1983 Note Added: 0011603
2010-02-01 09:16 karajorma Note Added: 0011610
2010-02-01 11:49 KeldorKatarn Note Added: 0011611
2010-02-01 11:50 KeldorKatarn Note Edited: 0011611
2010-02-12 06:47 karajorma Note Added: 0011653
2010-04-13 06:54 Goober5000 Note Added: 0011878
2010-04-13 06:54 Goober5000 Assigned To karajorma => Goober5000
2010-04-13 06:54 Goober5000 Status assigned => resolved
2010-04-13 06:54 Goober5000 Resolution open => fixed
2010-04-13 06:54 Goober5000 Target Version 3.6.12 RC1 =>
2010-04-13 14:39 chief1983 Fixed in Version => 3.6.12
2010-04-13 14:39 chief1983 Target Version => 3.6.12