Map Editing Tools?

[Catt]

Hi

I have been working on a map editor for a bit, I have it working, but have a few questions about the .map files.

What tools other than SEQ are being used to edit maps? The reason I ask is:

Temple of Veeshan,Temple of Veeshan,265,262,593,550,3340,4073

Does not seem to follow SEQ's source code format:

LongName,ShortName,Xvalue,Yvalue

Has there ever been use of the A, H, or Z values, or are they for future expansion?

[Mr. Suspicious]

That line you take as example, follows the Map format perfectly.

Taken from http://sourceforge.net/docman/displa...roup_id=10131:

first line

"Long Zone Name,shortname,X,X,X,X,X,X"

Long Zone Name is the full name of the zone, shown to the player when they zone in and in the showeq status bar shortzonename is the short name, shown in /who all and used as file names X are values set by showeq when the map is saved, has to do with the limits of the zone and such. When editing the map X=0 is fine, showeq will automatically fix it.

[Catt]

Given that line all points are in a rectangle that is 265x262 pts (clicks, or what ever you wish to call the unit) which is incorrect, thus not written by a current version of SEQ.

3340 x 4073 is more believable. (last pair)

SEQ really doesn't seem to care, it adjusts the bounds if a point is outside them, and only seems to save 2 values (X,Y of bounds) not 6 like this example has.

I'm asking for compatability reasons, my map editor is nearing completion, I have intentions to go through the maps and clean them up, and make a new website to host them, posibly viewable on the site, not sure about that part yet, but definately available.

Some other 'improvements' I intend to make are:

* Eliminate the L lines, by conversion to M (z=0, unless known)

* Eliminate double lines at waters edge, and other places where not useful, on some maps.

* Ensure colours (colors) are properly named, used. (no more grey or SkyBlue for example, using source as guide)

* Square up walls, buildings and such.

* General cleanup.


If anyone has map suggestions, I'd be glad to listen to them.

[Mr. Suspicious]

265,262,593,550,3340,4073

Lets look at these values and we'll see:


3rd and 4th digit:

593 pixels high, 550 pixels wide

1st and 2nd digit:

265 pixels from top = y-0 location

262 pixels from left side = x-0 location

5th and 6th digit:

total width in locations (max(negloc * -1) + max(pos_loc)): 3340
total height in locations (max(negloc * -1) + max(pos_loc)): 4073

So looking at this first line tells you how big the map should be when drawn in a .png format, what the offset for the 0 locs are and the bandwidth for the height/width of the ingame coordinates, and subsequently can calculate the ammount of pixels away from the 0-line a certain point in ingame loc is.

The reason width and height "seem" to be _reversed_ compared to x and y axis is due to the fact that images are described in height - width, so Y - X

thus not written by a current version of SEQ.

The current code (if you look at it, you'll understand it fast) doesn't use any boundries specified in the 1st line, it doesn't even "care" for the name and longname), it just parses the entire map, gets all max pos and neg locations, determines the map width and height for view in "1x" that way and dispalys the map, if spawns are found outside the perimiters it'll adjust the map (make it smaller) to make the spawns fit into the map window.

The source uses the GD Library to display the map (http://www.boutell.com/gd/) and so did mapfiend when it was still operational. Xylobot, who uses an inprogram mapviewer aswell, uses the same library and format to display the maps. Have a look at their specifications if you like.

There's absolutely no need to change the format of mapfiles, the format is well thought out. Just match YOUR program to be able to work with the specified format. Going away from a specified format is silly and breaks the "uniformity" of any mapfile ever developped.

[Catt]

I fear the point has been missed.

SEQ does not save but the X & Y, thus any editing of the example map within SEQ will result in:

Temple of Veeshan,templeveeshan,3340,4073 (to use the proper short name)

Loosing the extra info, that is why I questioned what they are. THE specified format I would have to say IS SEQ, thus the above format is correct.

However, if there is an editor/utility that makes use of the info, I can (may) figure and include it the map file.

I will take a look at the GD library, it sounds as though it may shed some light.

Thanks for the input.

[Mr. Suspicious]

One more thing I need to add =)

I dove deep into the mapgenerator thing when Mapfiend stopped it's work and noticed a very important thing: Most maps follow the format and are correct on the info on the first line, a lot of maps have the wrong information in the topmost fields tho. This is especially true for maps that have been editted and changed by people manually, rather then using the parsing program Mapfiend offered. Those "mappers" didn't remember to change the values in the first line according to their maps. That's why (for example) the Temple of Veeshan map has wrong values.. the 5th and 6th digit are even wrong there, altho digit 1 through 4 are still correct. Can't blame the format for that, but rather the people not following it =P "bad! bad! mapmakers!"

I was able to "salvage" the php source of the mapfiend pages that convert the maps to .png and .ai, it might be interesting for you to look into those aswell (attached to this post)

[Zaphod]

A few comments/responses:

A, H, and Z values are all used in SHowEQ. Look in mapcore.cpp at the MapData::loadMap(const QString& filename) routine.

Eliminate the L lines, by conversion to M (z=0, unless known)

Don't! It will accomplish nothing for SEQ but decrease map painting performance and increase the memory footprint for everybody. Unless you are actually changing the Z to different values along the line, don't change L lines to M. Many lines actually don't need a varying Z, others may, it very much depends on the line and it's purpose. Lines around buildings, platforms, and ponds/lakes rarely if ever need a varying Z.

Eliminate double lines at waters edge, and other places where not useful, on some maps.

Just make sure not to eliminate double lines near certain cliff faces (this is very useful when running through Paludial caverns at SOW speed without Levitate).

Ensure colours (colors) are properly named, used. (no more grey or SkyBlue for example, using source as guide)

You can actually use any color that appears in the X11R6 rgb.txt file (see attached) and they will appear properly in ShowEQ (except for drawmap.cgi which will be fixed) and the MapFiend viewers. BTW, to use the attached rgb.txt files with the MapFiend viewers rename it to RGB.txt and remove the first line of the file.

Format of zone file. The format in the current version of ShowEQ is:

longname, shortname, width, height

where width and height are in EQ distance units (whatever you wish to call them). Previous versions of ShowEQ 2.x and 3.x series had some screwyness where they actually loaded the format with the width and height following, but then turned around and saved the map in different formats (some versions using the 6 digit form to which Mr Suspicious refers). Some other non-ShowEQ tools for generating maps (using /loc info in a log for example) may write the top line of the file in one of these screwy formats. The common screwy format (used for save but not load in ShowEQ 3.0.6 and ALL versions of SINS) was:

longname, shortname, screenCenterX, screenCenterY, screenLengthX, screenLengthY, width, height

The screenCenterX,screenCenterY, screenLengthX, screenLengthY are all very viewer dependent and of limited utility. No version of ShowEQ that I can find in CVS has ever read this long format (they always read the format with just width and height). MapFiend's viewers don't actually use any of the information beyond the longname and shortname.

The width and height values don't matter that much, they are merely a starting point, and starting with width and height equal to 0 will generate a perfectly acceptable map, the width and height will automatically be increased within ShowEQ to encompass all points appearing on the map, and then by all points that spawns appear. The only values that would impact ShowEQ would be if the width and height were larger then the actual zone sizes. ShowEQ will save the new X and Y values upon saving changes to a map. The extra info that appears in these other map variant formats is not useful and actually misread/misused by all versions of ShowEQ and SINS.

Also, one word of warning about editing maps with a mouse, there is a large loss of accuracy in the transition from screen space to map space. This is part of why we never added a window for map editing.

Enjoy,
Zaphod (dohpaZ)

[Catt]

Hmmm, guess I have a bit more work to do.

Based on input to this thread, my thanks to those who responded, current intentions are:

Preserve object colours, or better, make use of them, based on the rgb.txt file.

Preserve/allow editing of "A", "H", & "Z" entries, if I find any, so far I've not seen any in a map file.

Convert "L" lines ONLY if supplying "Z" info.

Allow editing "P" points titles, and make it possible to add a "Z", currently SEQ does not support this, though it could be useful in multi level maps, I may look at SEQ code to add that, unless some else does it first. Currently the "Z" would be ignored by SEQ and thus lost if a save is done in SEQ.

Preserve / allow editing of "L" & "M" line titles.

This one took some consideration, for now, I'll follow the SEQ suggested 1st map file line of:

Long name,shortname,0,0,0,0,0,0

Clean up the actual maps (whole point of my editor work ), square up buildings, remove redundant line points/lines.

To ease concerns, using the example of Paludial Caverns, the white cliffs are not redundant and would stay, the islands (like where The Reishicyben is) would have the extra darkBlue line removed, leaving the island edges in gray.

I do understand the limitations of the mouse resolution, the actual editing in my editor is done on the keyboard, moving points/line nodes 1 EQunit at a time, while providing feedback of the current x,y[,z].

[Ridian]

I tried to figure out how to use that script for php - but since I know nothing about it (and I went to the official php site, read up on it from different boards, etc) - I still know nothing about it

All I want to do is convert these maps into AI format so I can mess around with them - does anyone know an easier way to do this? Or even an easier setup to use the script for a newbie?

Worst case senario - does anyone have all the maps already in AI format? That would work too

Thanks so much...

Ridian

[Mr. Suspicious]

Install it on a PHP supporting webserver. It's not my script, so it comes "as-is".

[Ridian]

Ok - I have a hosting service that supports PHP, but there must be a step I dont know about. If I just simply upload the aigen.php then go to that url, it just shows the text within that file on the page. Is there something I need to do?

Thanks again for the help...

Ridian

[Mr. Suspicious]

As stated before, you need the GD library installed on the server to have it work:

http://www.boutell.com/gd/