VAB delete

[vossiewulf]

Can someone explain why if I stick two parts together in one stage and then try to leave the VAB or load a different file, it prompts me to save, but if I detach the entire 15 stage launcher, forget that I've done that because I can't see it, hit save and leave it will happily delete hundreds of parts and days of work without any warning whatsoever? You can't check on save and notice that the save will be deleting hundreds of parts across a dozen stages and at least ask if that's the intention? You know, if (partsDeleted > 5) { ASKFIRST()}? I've been using MAX since it was 3DSr4 for DOS and every piece of graphics software and most of the coding tools out there for 25 years and I never lose anything, and I just lost many hours of work to that "feature".  Of course with all of those, the only way something gets deleted from a scene is by explicit delete actions of the user, not just by the user detaching objects in the same way they do hundreds of times in each VAB building session, but forgetting to reattach before they save.

[MrWalrus123]

If you want to save a detached section, make it a subassembly

[qzgy]

Because the game isn't gonna check what your thing is. It goes "Has user saved file? Ok yup, nothing to see here keep going"

 

[vossiewulf]

2 hours ago, MrWalrus123 said:

If you want to save a detached section, make it a subassembly

Wasn't trying to do that. I had stuff to add to the launch vehicle and the aero shell gets in the way visually so I detach it and everything below so I can see what I'm doing. Theoretically I re-attach it before saving.

2 hours ago, qzgy said:

Because the game isn't gonna check what your thing is. It goes "Has user saved file? Ok yup, nothing to see here keep going"

 

Yeah I know, that's the point, it sets a trap for the user to all too easily fall into, in the process losing god knows how much work. Seriously, if any real modeling program did something like this, police protection of the offices would be called for in days - the one thing a UI flow CAN'T do is set traps that cause people to lose work.

Squad you know it wouldn't be rocket programming to put a check in at the point the user saves/leaves the VAB for situations in which a significan't number of parts (5? 10?) are about to be deleted permanently with no recourse, and maybe mention that to the user and give them a chance to confirm.

[MrWalrus123]

17 hours ago, vossiewulf said:

Wasn't trying to do that. I had stuff to add to the launch vehicle and the aero shell gets in the way visually so I detach it and everything below so I can see what I'm doing. Theoretically I re-attach it before saving.

Yeah I know, that's the point, it sets a trap for the user to all too easily fall into, in the process losing god knows how much work. Seriously, if any real modeling program did something like this, police protection of the offices would be called for in days - the one thing a UI flow CAN'T do is set traps that cause people to lose work.

Squad you know it wouldn't be rocket programming to put a check in at the point the user saves/leaves the VAB for situations in which a significan't number of parts (5? 10?) are about to be deleted permanently with no recourse, and maybe mention that to the user and give them a chance to confirm.

But the game does warn you if you haven't saved when making a new craft, loading one, or exiting the VAB/SPH, it warns you if you've made an unsaved change, even if the change was taking off a parachute and putting it back on. Squad wouldn't set traps for you to loose work, and it should be on you to remember what parts you de-attached. If you spent an hour or more on building a lander/rocket, de-attach it, only to save it without putting it back on; thats on you.

[GluttonyReaper]

Yup, definitely have wished this was a thing sometimes, especially when testing a payload and realizing I've deleted the launch vehicle by pressing launch. The only thing I can think of is that it might be slightly annoying if you lose a detached piece in the rest of the rocket it'll prompt you unnecessarily, but that's honestly pretty minor.

[Spricigo]

21 hours ago, vossiewulf said:

Can someone explain why if I stick two parts together in one stage and then try to leave the VAB or load a different file, it prompts me to save, but  if I detach the entire 15 stage launcher, forget that I've done that because I can't see it, hit save and leave it will happily delete hundreds of parts and days of work without any warning whatsoever?

 

In the first case you altered the vessel and didn't save. later you removed those parts and saved the vessel without those parts. You didn't even considered it important enough to save as subassemble. The criteria is simple and evident: If there is some unsaved changes to the vessel there is a warning/prompt else just proceed.

No matter how much you want to blame the game, that was just your own mistake. You should had noticed that 15 stages with hundreds of parts were not attached and, like  in previous instances, those would be lost when you left VAB.

Not to say that  a  "unattached parts will be lost. Proceed?" warning is not a good idea. Personally I have no use for it but, as long there is a [don't ask again] option, no problem.

18 hours ago, vossiewulf said:

Yeah I know, that's the point, it sets a trap for the user to all too easily fall into, in the process losing god knows how much work. Seriously, if any real modelling program did something like this, police protection of the offices would be called for in days - the one thing a UI flow CAN'T do is set traps that cause people to lose work.

 KSP is a game . If you want to convince the devs to change a feature you need to convince that makes a better game. Whatever a "real modelling program" can or can't do is totally irrelevant

 

 

[scottadges]

22 hours ago, qzgy said:

On 9/4/2017 at 8:55 PM, vossiewulf said:

You can't check on save and notice that the save will be deleting hundreds of parts across a dozen stages and at least ask if that's the intention? You know, if (partsDeleted > 5) { ASKFIRST()}?

Because the game isn't gonna check what your thing is. It goes "Has user saved file? Ok yup, nothing to see here keep going"

I thought I'd jump in, because I can sympathize with the OP, but at the same time understand the dev choice regarding attached/unattached parts. I've done it myself when I accidentally remove parts, quick hit save (but don't exit), then realize they're gone. Wait, CTRL-Z!

I would assume in order to check for all unattached parts, the VAB editor would need to have an instance (or keep track of) of every single part placed in the editor at any time, which when saving/exiting/re-opening the parts are gone means it's only checking based on parts attached to the root. Otherwise, you'd have very hefty craft files with every unattached part lying around the VAB. So probably to combat bloated craft files, the game doesn't check whether parts are in the editor window when saving, only whether they're attached to root.

Otherwise, making this function like significantly more robust 3D editors is probably not something the devs would (or even could?) do. IMO it's not really meant to be a 3D editor tool, the editor is just the minimum necessary to build a spacecraft, etc.

Edited September 6, 2017 by scottadges

[vossiewulf]

3 hours ago, MrWalrus123 said:

But the game does warn you if you haven't saved when making a new craft, loading one, or exiting the VAB/SPH, it warns you if you've made an unsaved change, even if the change was taking off a parachute and putting it back on. Squad wouldn't set traps for you to loose work, and it should be on you to remember what parts you de-attached. If you spent an hour or more on building a lander/rocket, de-attach it, only to save it without putting it back on; thats on you.

No, it isn't. It's extraordinarily bad UI design. As mentioned if MAX or Maya or whatever started deleting elements just because they weren't attached to the main model, the entire Autodesk company would have to rapidly go underground to avoid the roving gangs of modelers who had lost work to such an insanely bad idea as that.

Further...

Why does it auto-assign crew? If you get all the way to Duna and only then realize you've been flying on the OKTO, and you can't even remember to assign crew to your vessel, that's on you.

Autosave? If you can't remember to save, that's on you.

Engineering report? Who the hell needs that? If you can't remember to check that your decouplers are oriented the right way and you've stayed under part limits, that's on you. And again when you get all the way to Duna to just then notice the only hatch is blocked and the crew can't get out? Well, that's on you too.

[vossiewulf]

2 hours ago, scottadges said:

I thought I'd jump in, because I can sympathize with the OP, but at the same time understand the dev choice regarding attached/unattached parts. I've done it myself when I accidentally remove parts, quick hit save (but don't exit), then realize they're gone. Wait, CTRL-Z!

I would assume in order to check for all unattached parts, the VAB editor would need to have an instance (or keep track of) of every single part placed in the editor at any time, which when saving/exiting/re-opening the parts are gone means it's only checking based on parts attached to the root. Otherwise, you'd have very hefty craft files with every unattached part lying around the VAB. So probably to combat bloated craft files, the game doesn't check whether parts are in the editor window when saving, only whether they're attached to root.

Otherwise, making this function like significantly more robust 3D editors is probably not something the devs would (or even could?) do. IMO it's not really meant to be a 3D editor tool, the editor is just the minimum necessary to build a spacecraft, etc.

Close, but not quite I think.

The issue is the file structure, that is a tree. It has no conception of two trees in the same file. In the VAB they can keep a detached tree no problem because it's already instanced in memory, but when you go to save, the save file (as designed) must be a single tree with each object attached to N children but only one parent.

There are several options. First, it should be extremely easy for them to be aware. I know how many objects (trees) I have rendered in the VAB, and I know which one is attached to the master pod and any that aren't. So when the user goes to save, I would know what needs to be saved in the file but also know how many detached trees there are and how many objects are in each.

With a minor addition, I could also pretty easily track the number of elements (parts) that were present the last time this file was changed. So the easy part is knowing that with this save the user is attempting, he/she will be deleting X number of elements in Y trees. That's an alerting threshold problem, use judgment to set a value past which, if it wasn't intended, the user will be very upset about losing those parts.

What to do with detached trees is the tricky part. If the user says "NOOOO I DIDNMEANIT!", you can't just randomly attach those detached trees to the existing model and then save that, that would create as many problems as it would solve. The correct solution is to save any detached tree of > x number of parts as a separate file, using the main model's file name as the root. E.G., Atlas IIIA _detached_parts_1. There may be other correct (as in fulfills requirement in a way the users are happy with) solutions but I think most people would be happy with that one.

Then in the game general settings, there would be two new flags for the user, defaulted to on, and two fields to set the threshold:

(*) Save detached parts in VAB        Threshold: 10

(*) Save detached parts in SPH        Threshold: 10

If you want a really good implementation you add a couple more fields to specify root name(s) to be used and also to set the path if you want to saved detached parts to something besides ThisCareer/Ships/VAB/.

Edited September 6, 2017 by vossiewulf

[vossiewulf]

1 hour ago, Spricigo said:

No matter how much you want to blame the game, that was just your own mistake. You should had noticed that 15 stages with hundreds of parts were not attached and, like  in previous instances, those would be lost when you left VAB.

See my response to Mr. Walrus, that exact argument can be made against every single safeguard in the game, up to and including the autosave feature that if they were to disable it, would result in a disaster with thousands of complaining customers. And you'd say, hey, not our problem, if you can't remember to save your own game, you deserve to lose all the progress, and an autosave feature doesn't make the game any better, so you unhappy folks don't even bother requesting one.

And then you'd be out of business not long after that. And I'll hope you're not in the design loop on any product/software I have to use. For reference, the ONLY reasons that are valid to not include a safeguard that prevents your users from accidentally losing hours of work progress are 1) it happens so rarely it's clearly an edge case and 2) the cost of adding that safeguard is clearly much more than would be gained by implementing it.

If there's any doubt at all, you build in the safeguard. And with this situation, this is NOT an edge case. And I don't think the cost of fixing is out of scale with the protection against liquided-off users that is gained, but I can't say that for sure. It seems to me what I suggested above wouldn't be difficult to implement based on what I know, but what I know is very limited and there could be factors that make a solution much more complex and costly.

[Hotaru]

Personally, having lost work to this issue more than once myself, I think a message to the effect of "Caution: vessel has detached parts that will be lost if you proceed" before saving or exiting the VAB would be an extremely good idea. 

And for everybody saying this is OP's own mistake--it is and it isn't. Operator error is connected to human factors engineering: human users will always make mistakes, but a well-designed UI will usually catch or prevent them. In a case like this, where the mistake is common, potentially serious, and reasonably easy to detect, I can't think of a reason why the user shouldn't be warned about it. 

 

[Spricigo]

1 hour ago, vossiewulf said:

See my response to Mr. Walrus, that exact argument can be made against every single safeguard in the game

The only "argument" I made was that you are overreacting about something avoidable and , honestly, of very little consequence.

You are talking as if the game didn't offered the opportunity to save your ship but in fact there was enough opportunity to you save in the wrong moment. And that is the mistake (your mistake) that caused your  problem annoyance.

So is up to you to decide if you will focus your energy in avoiding repeating that mistake or in pretending that KSP is a 3d modelling tool .

 

 

[vossiewulf]

1 hour ago, Spricigo said:

So is up to you to decide if you will focus your energy in avoiding repeating that mistake or in pretending that KSP is a 3d modelling tool .

That's a relevant point   You know way better than I do the number of things broken that are worse than this, I'm certainly not bothering to report on or discuss those items even though it boggles the mind that some of them are still there that I remember from five years ago when I briefly noodled around with KSP right after it came out. So no, I try not to make a general habit of jousting at windmills. But this one got me because, it got me, and I lost about 6 hours of designing and testing.

Although in the end I have to agree with you that it's not MAX, I still say this is 1) BAD and 2) it appears on the surface to be easily fixable in a way that will in fact make the game a bit better for everyone.

And that's the end of the tilting yard, no more jousting on this one.

5 hours ago, Hotaru said:

Personally, having lost work to this issue more than once myself, I think a message to the effect of "Caution: vessel has detached parts that will be lost if you proceed" before saving or exiting the VAB would be an extremely good idea. 

And for everybody saying this is OP's own mistake--it is and it isn't. Operator error is connected to human factors engineering: human users will always make mistakes, but a well-designed UI will usually catch or prevent them. In a case like this, where the mistake is common, potentially serious, and reasonably easy to detect, I can't think of a reason why the user shouldn't be warned about it. 

 

Yes, exactly what I'm saying. Not an edge case but a fairly common one, and they can prevent serious bad feelings about their game fairly easily, although that comes with a big asterisk still because I really don't know the architecture. But if it's not really bizarre for some reason, it seems like something where most if not all of the variables they'd need already exist, and it can be driven by user-controlled settings so they just need to make a reasonable guess at default values and implement.