Author Topic: JimsViewer, a tool for extracting paksets info and gathering statistics (Read 18165 times)

vilvoh · « **on:** December 29, 2009, 04:39:03 PM »

I must confess that I don't read the german forum as often as I would like to but Frank sent me a link about this great tool that was hidden there. It's called JimsViewer and the author is Jim Knopf. It's available only for windows 95/98/XP. It just extracts the information contained in pak files, and show it in a friendly way. You can order the entries by several criteria, sort them, display statistics, summaries and visualize the product trees and industry chains.

The TODO list contains some interesting future improvements like:

Sortable lists
Image sources visualization
Representation of industrial chains with plausibility checks
Tooltips and simple presentation of complex data structures (such as waytype)

Seems to be a very helpful tool for pakset maintainers and in general for those people who like explore the innards of paksets. At this moment, it's only available in german, but I'll talk with Frank to add the texts to Simutranslator, in order to give language support to this interesting tool.

You can dowload it here.

vilvoh · « **Reply #1 on:** December 29, 2009, 05:04:55 PM »

That was I read at first time, but while I was translating the posts from the german forum, I saw SimuEdit and I thought that was the definitive name of the project. Imho, It sounds much more related to Simutrans world than the current one, JimsViewer. I even suggest SimuPakEdit or PakEdit.

Frank · « **Reply #2 on:** December 29, 2009, 05:27:35 PM »

Quote from: vilvoh on December 29, 2009, 04:39:03 PM

...
Seems to be a very helpful tool for pakset maintainers and in general for those people who like explore the innards of paksets. At this moment, it's only available in german, but I'll talk with Frank to add the texts to Simutranslator, in order to give language support to this interesting tool.
...

jimsviewer.cfg

Quote

WRKFILENAME = paklist.txt
LOGFILENAME = jimsviewer.log
TXTFILENAME = jvde.txt
LOGFILEMSG = 1
LOGPARSEMSG = 0
LOGOBJECTMSG= 1
LOGVERSIONMSG=1
LOGTYPEMSG = 1

the TXTFILENAME define the language file

z9999+ · « **Reply #3 on:** December 29, 2009, 05:58:54 PM »

Japanese language file which　I made before.

MHD · « **Reply #4 on:** December 29, 2009, 06:57:09 PM »

Here is an english translation with corresponding config-file.

vilvoh · « **Reply #5 on:** December 30, 2009, 09:23:17 AM »

I already realized about that detail Frank, but I was wondering if wouldn't be easier to create a new set for Jimsviewer at Simutranslator, if possible of course.

Btw, the spanish translation is finished too.

EDIT: translation updated

Frank · « **Reply #6 on:** December 30, 2009, 12:15:28 PM »

Quote from: vilvoh on December 30, 2009, 09:23:17 AM

I already realized about that detail Frank, but I was wondering if wouldn't be easier to create a new set for Jimsviewer at Simutranslator, if possible of course.
....

Without giving any file format and character set makes little sense.

vilvoh · « **Reply #7 on:** December 30, 2009, 12:19:11 PM »

What do you exactly mean with file format? The file contains rows of attribute = value pairs...

Frank · « **Reply #8 on:** December 30, 2009, 12:31:36 PM »

Quote from: vilvoh on December 30, 2009, 12:19:11 PM

What do you exactly mean with file format? The file contains rows of attribute = value pairs...

attribute[one spaces]= value

attribute[more spaces]= value

attribute[tab]= value

UTF8, Ansi and so more

The developers have to say what he needs. And then the developer must also maintain the Translator set.

prissi · « **Reply #9 on:** December 30, 2009, 10:05:40 PM »

This tool is not supported officially and will be going down after the next update of the pak set format or the next or the next. It might be even have some problems with tunnels, as this format was extended recently.

And without open source I am afraid no other person can support this in the long run. I would like to keep simutranslator for the program and the paks until those are at least completely translated. For closed source third party software which runs only under windows I am not that ethusiastic.

VS · « **Reply #10 on:** December 30, 2009, 10:46:27 PM »

So... is it editor or viewer?

And as long as it works only with pak files, it isn't exactly worth looking into for pakset maintainers... :-( Obviously dat files are a bit more straightforward to use.

Zeno worked on something similar for vehicles.

vilvoh · « **Reply #11 on:** December 30, 2009, 10:56:00 PM »

Right now, it's just a viewer.

VS · « **Reply #12 on:** January 01, 2010, 12:30:24 PM »

Well, as long as it keeps working, it's going to be quite useful for players, at least

VS · « **Reply #13 on:** January 10, 2010, 04:45:06 PM »

Suddenly an idea came... if the viewer could load dat+png as well, it would be a lot more valuable even for maintainers.

vilvoh · « **Reply #14 on:** January 10, 2010, 05:16:57 PM »

Absolutely agree. In fact, as far as I know that feature is already included in the TODO list...

Quote from: vilvoh on December 29, 2009, 04:39:03 PM

The TODO list contains some interesting future improvements like:
Sortable lists
Image sources visualization
Representation of industrial chains with plausibility checks
Tooltips and simple presentation of complex data structures (such as waytype)

Milko · « **Reply #15 on:** February 20, 2010, 04:33:41 PM »

Wow! Useful tool!

It 'really nice to have a table with all the features of the objects to compare them. I am sorry that the images do not appear ....

Bye

Spike · « **Reply #16 on:** February 21, 2010, 08:24:03 PM »

The way images are stored was changed recently. I don't know if JimsViewer ever could display the images, but even if it could it's likely that it wasn't updated to the new storage format yet (which is more compact and more efficient to render).

Michael 'Cruzer' · « **Reply #17 on:** February 22, 2010, 08:32:51 PM »

Quote from: VS on January 10, 2010, 04:45:06 PM

Suddenly an idea came... if the viewer could load dat+png as well, it would be a lot more valuable even for maintainers.

The development of this tool has stopped shortly thereafter it started, because this function wasn't wanted by the pakset-maintainers in the german forum. The original choice was the paks shouldn't could viewed or changed. (Was also already an included function of the tool!)
This is also the reason why the tool was very hiding in the German forum!

VS · « **Reply #18 on:** February 22, 2010, 09:30:31 PM »

I don't want to load pak and save as png+dat. I want to load dat+png. No saving needed.

wlindley · « **Reply #19 on:** February 23, 2010, 03:19:40 AM »

Data is data... all the information from the .png and .dat is in the .pakfile ... it is all a pretty straightforward compile, thus a straightforward de-compile. "The original choice was the paks shouldn't [be able to be] viewed or changed" is exactly the sort of foolishness that motivates "white hat" (good) hackers to write tools to extract binary formats like Microsoft Word's... and the "locking up" of data is what motivated R. Stallman to write his original free printer driver.

This is supposed to be free software, people... quit the jealousy. There's no harm in a .pak -> .png+.dat program.

The Hood · « **Reply #20 on:** February 23, 2010, 08:59:29 AM »

Quote from: wlindley on February 23, 2010, 03:19:40 AM

This is supposed to be free software, people... quit the jealousy. There's no harm in a .pak -> .png+.dat program.

While simutrans has always been free to distribute, it has only recently been open source, and many of the graphics are still closed source. I don't think it's quite so simple as that (personally I agree with your views, but some people contributed images before open source and they may have different views).

vilvoh · « **Reply #21 on:** February 23, 2010, 09:27:28 AM »

I'm agree with The Hood. The main problem with old stuff released before going open source is that pakset maintainers don't have permission from the author to release the stuff under a open source license (pak128 is a good example of this problem) thus everything they can do is try to put in contact with the author.

On the other hand, nothing prevents you from creating a decompiler, in fact that tool already exists and it's used by some developers, but if you really want share your creations, release the sources instead of trying reverse engineering. In fact, if you put in contact with the author and request the sources, I bet most of them will share their work with you.

Reverse engineering is not evil but imho, respect the work and wishes of others goes first, at least in this case.

Ashley · « **Reply #22 on:** February 23, 2010, 10:30:17 AM »

Quote from: wlindley on February 23, 2010, 03:19:40 AM

Data is data... all the information from the .png and .dat is in the .pakfile ... it is all a pretty straightforward compile, thus a straightforward de-compile. "The original choice was the paks shouldn't [be able to be] viewed or changed" is exactly the sort of foolishness that motivates "white hat" (good) hackers to write tools to extract binary formats like Microsoft Word's... and the "locking up" of data is what motivated R. Stallman to write his original free printer driver.

This is supposed to be free software, people... quit the jealousy. There's no harm in a .pak -> .png+.dat program.

It isn't as straightforward as you might think, makeobj throws away some information when it creates the pak file (to optimise it for purpose).

As others have pointed out, Simutrans hasn't always been open source, and many of the objects (existing and historical) were never released into the public domain or under an open source licence (there is a difference). While it is wrong to think of the pak file format as DRM it is also wrong to think that just because you can potentially reverse-engineer a pak file, you should or are entitled to.

The majority of open source licenses are actually still about keeping control of your creations to an extent you can't by simply releasing a work into the public domain (see the "viral" qualities of the GPL for a perfect example). So even if a tool to reverse-engineer pak files was freely available it would not change your responsibility to respect the wishes of the original author. Generally speaking if the creator of an object in Simutrans wishes to release the graphics into the public domain, or under an open source licence they will do so with the source graphics (this is usually the case). Releasing only a .pak file can be taken as a statement of intent that the author does not wish the source to be freely available, and that they retain their rights over it as their creation.

wlindley · « **Reply #23 on:** February 23, 2010, 02:39:34 PM »

Absolutely. Providing a book in an open format does not reduce its copyright protection.

A "pak decompiler" would be useful for two things only: For personal enjoyment ("Fair Use") without the large trouble of rebuilding entire paks from scratch; and for developers to recover freely released paks for which the source has been lost.

Ashley · « **Reply #24 on:** February 23, 2010, 03:00:04 PM »

Quote from: wlindley on February 23, 2010, 02:39:34 PM

Absolutely. Providing a book in an open format does not reduce its copyright protection.

A "pak decompiler" would be useful for two things only: For personal enjoyment ("Fair Use") without the large trouble of rebuilding entire paks from scratch; and for developers to recover freely released paks for which the source has been lost.

Personal enjoyment is covered by the ability to use the pak file within the game, in the way the original author intended (e.g. with their dat file settings and original graphics). This is entirely fair use. Making any changes to the object IMO requires the permission of the original author, which isn't explicitly given by releasing an object in pak format (since there has always been this assumption of non-decompilation). This is the crux of the issue really, the intention of the original author in releasing only the pak file and not the source was almost certainly because they didn't want to grant usage permissions beyond those normally associated with a pak file.

The latter case is valid, and as has been pointed out there is a tool available to the main development team to do exactly this.