Map converter (SOE->SEQ) in Java

[AnotherCoreDump]

Yo!

I was bored and did write a java version of the awk-script, which is much faster and offers a map optimizer (tries to merge multiple lines into one (not tested yet)).
And as a plus, it does not only make one map at a time, no, it can convert whole directories...

If anyone wants it, here is it: (see attachment).

=== Edit: ===
New Version allows to convert any .txt file, not just _1.txt ones.
Also allowes to set a destination directory.

[AnotherCoreDump]

Bah, 5 days without reading the board, and the tool is useless :)
In Devel-Forum is a patch that can load native maps, dunno if it works.

Anyway, this thingy should work anyhow.

[Mapfiend]

Not sure if you know this, and I haven't tested your app, but here's some info:
I did the whole optimizer thing when I wrote my php converter, and I found that SOE maps are written from the bottom up, so when you are converting from SOE to SEQ, flip the order of the lines and the optimization will work much better.

[AnotherCoreDump]

Well, as my optimizer loops till no further optimisation can be done, it doesn't really matter in what order the lines are stored.
It runs on e.g. Hateb_1.txt 5 loops:

D:\workspace\txt2map>java txt2map -o D:\Priv\EQ\allmaps\Hateb_1.txt
Converting D:\Priv\EQ\allmaps\Hateb_1.txt
Optimizing...Done: 7762
Optimizing...Done: 1479
Optimizing...Done: 164
Optimizing...Done: 5
Optimizing...Done: 3
Optimizing...Done: 0
Optimized 9413 lines.
Finished.

The final map is only 3917 lines, longest is 43 points, map size is 253.440 Bytes.

[CybMax]

Love the tool :)

Just a sidenote.. the file HAVE to be named _1.txt and not just eg. mira.txt ... Renamed to mira_1.txt and it converted.. if i did not, it would not work..

Cyber

[AnotherCoreDump]

If you want I can the _1-Part, but if you do whole directories with other .txt files in there, it might cause problems.

[Mapfiend]

AnotherCoreDump - Your optimizer is obviously much more efficient than mine, and to tell the truth mine isn't *really* an optimizer. I was shocked at the size of the SOE map files, and the fact that they use one file line per line segment; really ineficient, IMHO.

In my first attempts to convert SOE maps to SEQ, the SEQ maps were actually larger than the SOE maps, since I was doing a direct line-for-line conversion. It was then that I realized I need to consolidate continuous line segments into single lines.
I added code to compare the last point of the current line with the first point of the next line, and if they matched (and the color did too), just continue the line.

The maps turned out the same size as before, with the resulting SEQ map being larger than the SOE map.

Then I actually looked at the SOE maps, and found that consecutive points do match, but not from the top down, from the bottom up. The LAST point of the next line, matched the FIRST point of the current line.

So I started reading the SOE maps from the bottom up, and it worked. The test I used was converting an original SEQ map to SOE, then back again. The file size of the "new" SEQ map was within a few bytes of the "original" SEQ map, so I was happy.

To make a long story (sorry yall) short, I'm guessing that your optimizer compares all lines against all other lines. I don't have the luxury of that, since I'm working in an interpreted environment, and web-based at that, so that would just be too much overhead. My "optimizer" (and I use the term loosely) was written with the assumption that the maps are drawn by hand, with consecutive lines being drawn consecutively, and it does work well for that.

The other point I was trying to make (which doesn't apply to your app) is that SOE writes the files backwards. When you add a new line segment to a map, the old ones are pushed down, and the new one is added to the top of the file, and I have no idea why they do this :)

Anyway, I will definitely take a look at your code, if you don't mind, and see if I can incorporate some form of your optimization into my code without using too much overhead :)

[Catt]

OK, I'm not that great with Java, and is sounds simple enough, however, when I try to run the program I'm getting:

Exception in thread "main" java.lang.NoClassDefFoundError: txt2map

I load txt2map.java in JCreator, it compiles, it'll run from tool bar, well it spits out the 'help' info, but I'll be damned if I can get it to run from cmd line.

I have the 1.4.1_102-b06 runtime installed.

Any ideas, or pointers?

[AnotherCoreDump]

Well, you don't have "." in your CLASSPATH i guess.
Here's a new txt2map.cmd that takes care of that.

===========SNIP=============
@set OCP=%CLASSPATH%
@set CLASSPATH=.;%CLASSPATH%
@java txt2map %1 %2 %3 %4 %5
@set CLASSPATH=%OCP%
===========SNIP=============

[AnotherCoreDump]

For quick'n'dirty checks of maps and because I wanted to test swing gui a bit, I made a small tool, that uses some of the the txt2map classes to show a .map file on the screen.
If anyone is interested, here is it (just unzip to the txt2map dir).

I wanted to have both in same archive, but it's too large for board attachments.

[AnotherCoreDump]

Originally posted by Mapfiend
AnotherCoreDump - Your optimizer is obviously much more efficient than mine, and to tell the truth mine isn't *really* an optimizer. I was shocked at the size of the SOE map files, and the fact that they use one file line per line segment; really ineficient, IMHO.
Yeah me, too!
I always wonder what kind of people they employ at SOE to make up such strange data formats.
My "optimizer" isn't really optimized, too, testing with it I found that it doesn't really find line-segments, that match ... that will have 2 or more points in common on the screen. Hateb.map has alot of them due to the nature of it's origin. I bet it could be optimised down to e.g. 50k if those would be removed.
Just look at those big stairs, noone needs all these lines!



Anyway, I will definitely take a look at your code, if you don't mind, and see if I can incorporate some form of your optimization into my code without using too much overhead :)
Sure no problem, thats why I did post it with the source code.

I don't know how I would put it in php, in java, the class concept helps alot, I did just write my own equals() methods for lines, which just use the equals() method of their end-points to compare if they have one in common.

[Catt]

That fixed it!

Thanks, and thanks for the work on the program too.

[Alfred]

FYI

You post in your readme that you need 1.3.1 when you are using a 1.4.x feature: String.replaceAll()

So... anyone that wishes to compile this on their own will need to write their own replaceAll() or upgrade to 1.4.x.

[AnotherCoreDump]

Hmm ok didn't check this, my Eclipse is set up on 1.4.1, didn't check if it would actually run on 1.3.x...
Will check how to make it work, thanks for the hint.

[Jules]

I just commented that out and set the string to ""

That line only preserves the path to the map file. Removing it causes the output to land in the current directory.

[AnotherCoreDump]

True. maybe I should add a command line switch.
here's a (now really even for java 1.3.x) compiled version with a substring() instead of replacerAll().

[AnotherCoreDump]

New version with destination dir option and possibility to use txt files without "_1.txt" is attached to first posting off the thread.

[BlueAdept]

Thanks alot ACD. This is nice.

[Pit Boss]

This worked great for me. The only problem I had is when I clicked the file it would open up and then close immediately. I just had to open the command prompt and do it that way. Thanks. Great job.