ID:2968632
 
Resolved
Leaving the new path blank in the Pending Map Errors dialog would not delete objects with the unrecognized path, but instead continue looping and asking for a change.
BYOND Version:516
Operating System:Windows 11 Pro 64-bit
Web Browser:Firefox 136.0
Applies to:Dream Maker
Status: Resolved (516.1660)

This issue has been resolved.
Descriptive Problem Summary:

Mapped items do not get removed when replacement field is left blank after removing definition of item.

Numbered Steps to Reproduce Problem:

1 Create a turf
/turf/grass
/turf/snow

2 Map said items in a dmm.

3 Remove one of these turfs.

4 leave the replacement blank, and click ok.



Code Snippet (if applicable) to Reproduce Problem:


Expected Results:
At this point, it should either
A: Replace the removed turf to world/turf or
B: leave it /turf as a black square ready to be mapped if turf was never set.

Actual Results:
Nothing happens, and it requests input again.
If you enter "/" it will replace all removed instances with the first turf it finds in your code.


Does the problem occur:
Every time? Or how often?
In other games?
In other user accounts?
On other computers?

When does the problem NOT occur?

Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? (Visit http://www.byond.com/download/build to download old versions for testing.)

Workarounds: Remove instances before deleting definition.

I can't find evidence in the code that this was even supported in 514, before the map editor overhaul. I'm not sure this is a bug.
... it literally says it works this way on the UI, and has worked this way since before you started using BYOND.
Hrm, yep, I wasn't paying attention to the text in the UI.

But what's weird is that the code for this, even going back to 514 before the map editor update, is basically the same as what's there now. The method of replacement has changed a little, but it was always treating a blank entry in the replacement column as reusing the original type path. Somehow, though, it was rewriting the map file with /turf instead of the original path, which doesn't track.

The change in behavior is very confusing because I can't find what's causing the old behavior.
Are you sure it's not just doing what the map editor always does when you delete a turf? Which is to replace that turf with whatever world.turf's type is if there's no other turf on the tile, if there is, the turf is removed without touching the others.
Okay, I found the issue. This was a complex interplay of behaviors.

The old way the map error dialog worked was by presenting the user a list, running with whatever replacements they offered, and if anything was wrong on the retry pass, the unrecognized objects were just deleted. This meant however that a typo on the replacement would basically always delete, which led to a bug report. To fix that bug report, I made the retry always keep going until all errors resolved—but this eliminated the behavior where leaving an unrecognized path blank, which counted as leaving it alone, deleted it.

I've managed to fix this by adjusting how the map editor does business. The load routine has a list of pops that you plan to delete, and passes this to the error dialog every time it might pop up. Any items you leave empty, the old path gets added to the deletion list. If the error dialog is shown and there are replacements being made (not just deletions), it will save a new copy of the map and try to load that again, and show the error dialog again if the process re-failed. If however the only changes left are deletions, it will simply re-save the map based on the data it loaded, where all of the unrecognized paths got deleted.

This was a weird one for sure.
Lummox JR resolved issue with message:
Leaving the new path blank in the Pending Map Errors dialog would not delete objects with the unrecognized path, but instead continue looping and asking for a change.

Login to reply.