ID:117987
 
Applies to:
Status: Open

Issue hasn't been assigned a status value.
As of right now, there seems to be no fool-proof method to acquiring from screen_loc which map a screen object is displayed on. This is because a colon is used as a separator between both tile and pixel coordinates and between map names and tile coordinates. I know that the only way to fix this is to break backwards compatibility but it's really an issue that needs to be amended. Something as simple as using a semi-colon as a separator would be a tremendous help.

Fortunately, I ran into this issue while attempting to implement iconx/y coordinates into my mouse library and I have to loop through the list maps the library is using and look for their names in screen_loc. Obviously, this isn't an appropriate solution for almost any other situation.
Can't you use a text library, call split(":"), and always take the first position in the list?
"map1:23:15,14:3"
"123:4:5,67:8"
"map:13,12:5"
"5,5"


Can you think of a uniform procedure to separate the five distinct values from these four strings? You can split at the comma and get distinct x and y values. With y, you can check for a colon. With x, if you have two colons, you're golden. If you have one colon, there's no 100% guaranteed method of determining wether that colon dictates a pixel offset or a map declaration.
Not the second and the fourth, no. I see your point now, though. I was thinking that the map was always going to specify mapelement:x:offset,y:offset, or just mapelement:x,y (in which case, it would always be the first one before the colon, but as you've shown, that isn't always the case).
There is another request somewhere to make the defualt map show up in screen_loc but that would break combatibility with every old version, whereas this would only break it for everything since multiple maps was implemented.
This may actually be better suited for a Bug Report. Can I get a moderator's opinion on this?
If you run isnum(text2num("[map]")) it should tell you if the screen_loc is referencing a map or not. You should then be able to determine the rest of the layout.
Yeah, but if the name of the map element is a number, as in the second example, then that doesn't help either.
Give the object an extra var that stores the map you put it on. While there's no simple way to extract it out of screen_loc, you're the one setting screen_loc so you must have a way to know which map control is specified.
I'm not looking for workarounds. I have workarounds, as stated in the first post. If I wanted a workaround, I would have asked for it in a forum.

I posted a feature request because I wanted it to be addressed. I asked for this to be changed because it is inherently flawed in it's current format.

The best I can do for my library is tell developers not to use numbers for map element IDs because screen_loc is flawed.
If people are naming their map controls numbers, that's their fault. You can't stop people from shooting themselves in the foot.

I wouldn't say this is flawed. If you want to remember what map control a screen object was placed on, it's up to you to create the var that stores it. It's not a big deal. If I want to remember what a player's health is, I have to create the var for it. That doesn't mean DM is flawed because it lacks a built-in health var.
No, it's flawed because it uses the same symbol as a separator for two different sets of information, with no indication of which is which.

A procedure cannot be written to read screen_loc correctly one hundred percent of the time.

flawed /flôd/ Adjective:
1. (of a substance or object) Blemished, damaged, or imperfect in some way.
2. (of something abstract) Containing a mistake, weakness, or fault.
As long as the map control's name isn't a number you can parse it correctly 100% of the time. Giving a control a name that's just a number is not common, so there's a very good chance that nobody will ever run into this problem. It should be fixed for the sake of fixing bugs, but it's not causing any problems in the meantime. If you let small issues like this derail your whole project you're not going to get anywhere.
Do you read anything? I said that I had workarounds, i.e., my project is not derailed. It has caused me problems, twice, else I would not have even noticed it. I've posted it here, not because it's an immediate problem, but because it's a problem nonetheless.
Bump. Now that Forum_account isn't here to discourage absolutely every report, maybe this could get an actual response?
I absolutely agree. We need some wrapper objects for anything that uses text for properties.

How much text handling you have to do for interface building is absolutely asinine.

Additionally, I'd like to see screen_objs be an internal object type, rather than any kind of /movable.
This was actually an issue in FA's own Mouse Position library. It didn't account for when there are two colons instead of one. There's a simple fix, though, for that case, since it's known that there may only be one or two colons.
A lot of the issue isn't whether or not the feature is possible on not, it's whether it's inelegant to otherwise work with.

Strings and DM don't play together very nicely in high use cases. I suppose I could easily write my own wrapper library for these sorts of issues, but I feel here that it is necessary to channel FA on this issue to state that the current implementation is at best inadequate, at worst wasteful and needlessly obfuscated.
Actually, if you'll take a look at the example above, it's possible for there to be three colons, which is why it is an issue. That is, unless you're simply referring to what occurs before the comma.