ID:2038874
 
Not Feasible
Applies to:Dream Maker
Status: Not Feasible

Implementing this feature is not possible now or in the foreseeable future
Would it be possible to have map parser separate the Y rows with a ';' instead of a line break?

Example:

(1,1,1) = {"
aaaaaaaaaaaaaaaaaa;
aaaaaaaaaaaaaaaabb;
bbbbbbbbbbbbbbbbbb;
bbbbbbbbbbbbbbbbaa;
"}

This would allow for custom formatting of that portion of the map file.
I can't imagine this would be very friendly to backwards compatibility.
How so?
Lummox JR resolved issue (Not Feasible)
This will return 10 for a 10x10 map file.

mob/verb/TEST(){src << dmm_y_size(file2text("Map.dmm"))}

proc/dmm_y_size(string)
var pos = findtext(string,"{\"")
. = -2
while(findtext(string,"\n",pos+1))
pos = findtext(string,"\n",pos+1)
.++
That is not relevant to this request.
In response to Xxnoob
Xxnoob wrote:
That is not relevant to this request.

This was marked (Not Feasible), the best thing at this point is a workaround for whatever you're trying to do- and it being such a simple problem I thought I'd offer some help.
There is no workaround besides doing what I requested, really. As long as DM reads Y rows separated by line breaks, there is a problem.
In response to Xxnoob
Xxnoob wrote:
There is no workaround besides doing what I requested, really. As long as DM reads Y rows separated by line breaks, there is a problem.

At runtime you can grab the map's data and replace the \n with ;
There are workarounds.
I am not sure how that would help. My problem is the formatting Dreammaker needs the maps to have.
The issue is that all old maps would become unreadable because they treat newlines as column breaks. Changing it now would break a lot of things, it's known that the current map format has limitations but any major changes to it would not be feasible in the foreseeable future.
Wouldn't converting old version maps to new version maps be easy, though? Convert if no ';' is found.
Why is the DM format the problem? That's the big question here. What are you doing with the file where you would need to put semicolons at the end of each line? None of this makes any sense.
Because managing maps in a revision system is a pain in the butt.

splitting the format to be brought out to more lines helps alleviate the merge conflict hell that is messing with maps.
I don't understand how having semicolons at the end of each line would make any difference in that regard.
In response to Nadrew
Nadrew wrote:
The issue is that all old maps would become unreadable because they treat newlines as column breaks. Changing it now would break a lot of things, it's known that the current map format has limitations but any major changes to it would not be feasible in the foreseeable future.

That's more misinformative nonsense. There are plenty of implementations available that wouldn't break anything at all. You could simply parse through it the way it does so already, and then default it to a different parser when a semi-column is encountered.

Not that I support this feature request, but you're spouting bs that's just blatantly untrue.
In response to Lummox JR
Lummox JR wrote:
I don't understand how having semicolons at the end of each line would make any difference in that regard.

At present, Models ("aaa" = (/turf, /area), not sure if that's the right term but I've seen them referred to as such) don't rely on whitespace at all, they parse along until they find the next character, be it "," "{" "}" "(" or ")" this is really good because we can (and have) restructure the insides of DMM files to use multiple lines for each model, this is less likely to cause conflicts in git and other version control software as a change to a model now only changes the part of the line that was changed (eg a grass turf was changed to a stone one) rather than the entire model.

But with the actual map hash at the bottom using line breaks to determine when a line of map data ends we can't do any additional formatting here.
Why should you need or want to alter the formatting of that data? Altering the prototypes I can understand fine, but for the raw map data there's no point.
The idea is we can make it split the lines to make merge conflicts less likely to happen. As a merge conflict is strictly triggered if two people edit the same line or immediate neighboring lines.

so rather than have 255 tiles per line, we could do 64 tiles per line or some shit like that.
Sounds like more trouble than it's worth.
Page: 1 2