MAPINFO conversion tool

[Graf Zahl]

Here's something I did this afternoon to convert a larger number of MAPINFOs to the new format.

It converts the definitions fine but due to the way the old MAPINFO was parsed it will mess up the positioning of comments.

Download

[Siggi]

I can't help but think Enjay's recent adventure with mapinfo lumps had something to do with this.

[Enjay]

Now you tell me.

This'll com in handy. Thanks.

[edit] It doesn't seem to cope with the old GL_Renderer sections. Is that expected? [/edit]

[Graf Zahl]

I can't help but think Enjay's recent adventure with mapinfo lumps had something to do with this.

Rather the fact that I did not want to endure something similar...

[Enjay]

Probably better to post this as a new post rather than my edit above.

It doesn't seem to cope with the old GL_Renderer sections. Is that expected?

[Enjay]

I notice that it does enter and exit texts differently to how I'd done them (to get the line returns). Here is one of mine. It works at present but I'd like to know if it will be OK in future of have I done something that will break?

Basically, I enclosed every new line in "" with a , after it whereas the conversion tool seems to use a double carriage return for a new line. A single carriage return didn't give me a new line in game and the text spilled off the screen. So I experimented until the text worked and it was the "", system that I found first.

Code: Select all • Expand view

clusterdef 19
{
flat = FLAT14
music = N_0027
//
entertext =
"The Red Giant Orbital Station SW3Z ",
"is an old craft, but it is still the ",
"centre for many of Red Giant's ",
"listening activities.  ",
"",
"Your ship has been equipped with a",
"clearance code message to get you",
"onto SW3Z.",
"",
"Once onboard, get to the main comms",
"room and plant a data chip there to ",
"intercept the transmissions that",
"Red Giant are listening to.",
"",
"After you place the chip, return to",
"your shuttle and leave."

exittext =
"Well done.  The chip is in place. We ",
"can now monitor what red giant are ",
"spying on."
}

[Graf Zahl]

It doesn't handle the GL_Renderer stuff because there's probably only a handful of MAPINFOs out there using it and doing the added work to the tool would be more than manually editing these files.

The endtext stuff is simply an incomplete implementation. I totally forgot that I haven't done that part yet when uploading the file.

[Nash]

Does this mean old maps that use the old format won't work anymore?

[Ceeb]

Does this mean old maps that use the old format won't work anymore?

I would guess it's like the old DECORATE format and DeHackEd; kept around so as to not break old WADs.

[esselfortium]

[...] DeHackEd; kept around so as to not break old WADs.

...or new ones...

[Graf Zahl]

LInk updated. Now it's capable of handling multiline texts.

Ceeb, why are you even asking. Have you seen anyone mention that old MAPINFOs don't work anymore?

Of course they will remain operational but their feature set will not be expanded anymore. So if you want to add some of future features you need to convert it.

[Enjay]

Does this mean old maps that use the old format won't work anymore?

No, the old format is supported. Not supporting that would suddenly break many, many pre existing mods. The only type of pre existing MAPINFO that will break with newer versions are any that used GL_Renderer sections in their map definitions. However, as Graf said, these are so few (and perhaps no public ones) that dropping support for them was considered OK and their options are properly supported in the new format. So, if you have a map that uses a GL_Renderer section, it will have to be converted to the new format because new versions of (G)Zdoom will refuse to start with the old one.

eg

old

Code: Select all • Expand view

map MAP36 "Space Station SW3Z"
cluster 19
sky1 SBOX07 0.1
forcenoskystretch
gravity 600
music N_0005
fallingdamage
airsupply 20
gl_renderer
{
skyrotate 1 0 1
}
next MAP255

new

Code: Select all • Expand view

map MAP36 "Space Station SW3Z"
{
cluster = 19
sky1 = SBOX07, 0.1
forcenoskystretch
gravity = 600
music = N_0005
fallingdamage
airsupply = 20
skyrotate = 1 0 1
next = MAP255
}

The new format is much neater IMO, but the old format is still supported. However, as with old DECORATE or any deprecated feature, people should move to the new format for any new projects. As a side note, you cannot mix formats in one MAPINFO. It has to be one format or the other.

[Enjay]

OK, my experience with the revised tool

The good:

It converted the mapinfo that took me the best part of two hours to convert to the new format manually in less than a second.

enter/exit texts converted (as far as I can tell) properly

The not so good:

GL_Renderer sections, as expected, broke the conversion process slightly. Basically it seemed to read the closing } of the section as a top level keyword, put an = sign after it and everything in the map definition was out of step from that point on. Or, if the GL_renderer section was the last thing in the map, the start of the next map definition was messed up. However, in both cases the effect was limited to a few lines and was easily fixed manually and it is an issue that will simply not affect most people.

In cluster definitions, the word "cluster" was used instead of "clusterdef" giving an "Unknown top level keyword" error when I tried to run the mapinfo in Zdoom. Again, an easy manual fix and most people will not have as many clusters as I do (75). However, this is clearly a bug/typo and if the tool is to be supported it should be fixed.

Something is confusing Zdoom's ability to report which line the error is on (perhaps the way that comments get moved around or the fact that additional line breaks seem to get added near comments). This hampered the ability to track down where the errors were. Zdoom would tell me that there was an "Unknown top level keyword" on a certain line but the actual error could easily be 100 lines away from the reported line according to my text editor. When I did the manual conversion, the line numbers were always reported 100% spot on and were a great help in tracking down the errors.



So, overall, 2 hours of work was reduced to a split second of conversion followed by about 5 minutes of tracking down minor errors. I'd say that was an improvement.


And finally, not related to the tool, I noticed that Zdoom is still reporting unknown map keywords in black in the startup window. Do you want a separate bug report for this in the bugs forum?

[Graf Zahl]

In cluster definitions, the word "cluster" was used instead of "clusterdef" giving an "Unknown top level keyword" error when I tried to run the mapinfo in Zdoom. Again, an easy manual fix and most people will not have as many clusters as I do (75). However, this is clearly a bug/typo and if the tool is to be supported it should be fixed.

You missed the corresponding change in ZDoom. The only reason the old parser used 'clusterdef' was because 'cluster' was already used as a keyword inside map blocks and having it a top level keyword, too would have caused problems. Now it isn't anymore and the much better 'cluster' can actually be used.

And finally, not related to the tool, I noticed that Zdoom is still reporting unknown map keywords in black in the startup window. Do you want a separate bug report for this in the bugs forum?

Yes, please report it as a bug. This is something Randy should look at.

[Enjay]

You missed the corresponding change in ZDoom.

It was Zdoom that was complaining about the word "cluster" being used, not me. I assumed that it was a bug in the tool, not a problem with Zdoom. When the problem occurred, I'm pretty sure that I was using a build of whatever the status of the SVN was at the time. However, I noticed a little while afterwards entries in the changelog relating to it. I've only just got around to trying it and, yes, cluster does indeed now work where clusterdef was previously required.