ID:86060
 
Resolved
Fixed in 461
BYOND Version:459
Operating System:Windows XP Home
Web Browser:Firefox 3.5.5
Status: Resolved (461)

This issue has been resolved.
Descriptive Problem Summary:
When doing a replace on a map with lets say an area and you want to replace that area with a turf instead, find/replace will give the not found message.
Numbered Steps to Reproduce Problem:
Place some areas then try to replace them using the find/replace into turfs.
Code Snippet (if applicable) to Reproduce Problem:


Expected Results:
The areas become the turfs you selected.
Actual Results:
You get the not found message.
Does the problem occur:
Every time? Or how often?Everytime
In other games?Dream Maker only
In other user accounts?Dream Maker only
On other computers?Only one to test

When does the problem NOT occur?It always occurs in versions 455 and up.

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.)454.
[Moderator note: 454 shows the exact same issue. It is likely that this bug has existed as long as the Find/Replace command has.]

Workarounds:To manually place each new turf yourself.

After seeing a simular post like this, but with multitiled, I want to add, I am getting this error with single tiled.
You can only change
/turfs/ into /turfs/,
/obj/s into /obj/s,
/mob/s into /mob/s,
/area/s into /area/s
/atom/s into /atoms/s
or
any of the above into nothing.
Super Saiyan X wrote:
You can only change
/turfs/ into /turfs/,
/obj/s into /obj/s,
/mob/s into /mob/s,
/area/s into /area/s
/atom/s into /atoms/s
or
any of the above into nothing.

Not very useful, I'm moving this to suggestions and stuff.
Bug fix: When trying to use find/replace to replace an object of one type with a completely different type (e.g., replacing /area with /turf), the map editor gave the wrong error message. The correct error message, that the two types are not alike, is now displayed.

Please note: The information included in this report is incorrect. This behavior was the same in version 454 and probably for a long time before that.