Importing duplicate reactor features

[12345ieee]

The following:

SOLUTION:An Introduction to Bonding,Zig,0-0-0,Unnamed Solution
COMPONENT:'tutorial-research-reactor-2',2,0,''
MEMBER:'instr-start',180,0,128,5,5,0,0
MEMBER:'instr-start',180,0,32,4,6,0,0
MEMBER:'feature-bonder',-1,0,1,1,2,0,0
MEMBER:'feature-bonder',-1,0,1,7,1,0,0
MEMBER:'feature-bonder',-1,0,1,2,5,0,0
MEMBER:'feature-bonder',-1,0,1,3,0,0,0
MEMBER:'feature-bonder',-1,0,1,1,2,0,0
PIPE:0,4,1
PIPE:1,4,2

imports cleanly, even though first and last bonders are overlapping.

Should we reject this stuff? SChem rejects them.

[csaboka]

I'm not sure if we need to do anything about these, either. I've checked the code just now and this looks harmless in the sense that it won't let you create a solution you couldn't create normally. The last feature "wins" because every time a new member is loaded from the save, conflicting members already in the reactor are deleted. Validation happens after the reactor is fully populated, so you can't get around the feature count limits this way.

The worst that happens when you import a doctored solution like this is that you'll have inactive records in the DB for all the members that were removed because of place conflicts. I guess if you overlap instructions like this, then remove the "winner", you can resurrect one of these inactive records, so you could get weird behavior where undoing and redoing doesn't get you back to the original state (and exiting and re-entering a level won't give you the state you exited from).

I'm inclined to not fix this, and just tell people not to do funny things in their solutions unless they're prepared for weird behavior. If we find any way to turn this into an exploit, on the other hand, then we have a strong enough reason to check for it.

[12345ieee]

Marking WONTFIX and closing for now.