How to make pakset-creation easier to approach

[Leartin]

This is kind of a follow-up to Loading Sourcefiles Directly Into The Game, just in a different direction.

How can we lower the barrier for new content creators?
That's the main wish behind that other thread. I think it makes sense to discuss different approaches to that goal, rather than discussing one possible approach of loading sourcefiles directly.

To get one thing out of the way: Yes, documentation is useful, and yes, a wiki is a possible location for documentation. Let's not talk about the need for a manual, rather try to make it so it's needed as little as possible.

• "Makeobj doesn't work"

So a new user downloads makeobj, double-clicks and... for a split second, there is a black rectangle. Too bad, doesn't work, **** programming, let's move on.
Everyday people are not used to tools you need to call via command line. Even though there are supplementary tools for makeobj to make it much easier to use, nobody talks about them. Nobody says "You need PakHelper to create pak files", it's always makeobj.
The simplest solution: Always bundle makeobj for windows with a batch file "start_makeobj.bat" with the simple code "start cmd /k makeobj". There is definitelly no space concern with this, and if a regular user clicks on it because they want to start makeobj, they get instructions on how to use makeobj in their face.

• Bundle Makeobj with Simutrans

Not for nightlies (for obvious reasons), but main Simutrans releases (at least for windows) should come with makeobj and a few sample files. So in the Simutrans folder, there would be a subfolder "makeobj" with makeobj.exe, start_makeobj.bat, my_first_vehicle.dat, my_first_vehicle,png, my_first_building.dat, my_first_building.png and a subfolder "128" with  my_first_vehicle,png and  my_first_building.png.
The dat files would just be for a regular vehicle/building (probably a locomotive and a citybuilding), but each line commented similar to how it is done for simuconf.tab, and the picture reference explains that you can add "128/" to the path to reference a different picture. This would be enough of a playground to learn the basics without outside sources.

• About-button

The game kind of has it's about/credits in that opening screen when you start the game. Paksets don't have them (within the game), and the opening screen is not seen much anymore ever since the game resumes with the last save/autosave.
All this really needs is a static message window displaying text (translatable via translator) that allows to tell a paksets license, authors and - and that's why it helps making the whole thing approachable - a link to the sourcefiles. Once such a dialog exists, just allow it to be called via a menubutton.
Pak96.Comic already has such a button in the main menu, which opens the manual at the "About Simutrans" page. Perhaps an easy implementation would be to have an "About this pakset" page in the manual right underneath "About Simutrans".


These are just a few things that should be relatively easy to do, but could improve accessability. I'll think of more later.

[Yona-TYT]

This seems very reasonable to me, making things easier for ordinary users so to speak, that probably motivates new graphic artists.

I would also like to highlight that there are many interesting projects that have been forgotten for many years (such as pak64.ttd, pak64.SciFi), it would really be very nice to motivate new artists to bring those forgotten projects to life. 

[Isaac Eiland-Hall]

Would it be offensive to many if the Windows build of makeobj would, if called with no parameters, just inserted a "press any key to continue" somewhere after displaying a message that advised it needed to be run from a command box?

Not to naysay any of the other ideas there, because those are awesome and I support them, too.

[Leartin]

Would it be offensive to many if the Windows build of makeobj would, if called with no parameters, just inserted a "press any key to continue" somewhere after displaying a message that advised it needed to be run from a command box?

Not to naysay any of the other ideas there, because those are awesome and I support them, too.

If it just said "Open from command box" and disappears after you press a key, I feel like average user still wouldn't know how to open a command box, and it's a bit silly to open a command box to display that the user should open a command box.
[In fact, I don't even know how to open a command box in a directory, since it was replaced by the powershell. Which works as well, except you have to type .\makeobj instead of makeobj - which is not mentioned in any of the many "how does makeobj work" - threads. The powershell suggests it, but only if you trust it, and that's quite scary to someone who doesn't really know what they are doing.]

If makeobj could open a command box that stays open, that would be nice too. Probably harder to do than providing a one-line-bat.
Plus, a user that has problems with a tool called from command probably doesn't know about batch files. Since it's only one line (visible in the windows file preview), it's not very intimidating and might invite them to experiment. Like adding "pak" after "makeobj" to make the bat pack files without further input.

[prissi]

It would be relatively easy for the windows build of makeobj to open a file dialog asking for dat file(s) to convert and then try to guess pak set size from the images or just ask for the size first.

[Ters]

I thought someone had already made tools that did this outside makeobj. Was that just my imagination, or is that tools much harder to come by than a makeobj binary?

[Leartin]

I thought someone had already made tools that did this outside makeobj. Was that just my imagination, or is that tools much harder to come by than a makeobj binary?

Average joe wouldn't know they exist. When you try to find tutorials for custom content, most of them explain that you need a dat and png and combine them with makeobj - but don't mention additional tools to help. Makeobj is linked on Simutrans.com and can be downloaded from sourceforge, two of the first places to look when you try to finde the game, but neither tell you that you might need something else as well.

Though I don't know if there is anything really usable by now. I think the biggest one was PakHelper by Minami Fukuoka, but the website of that person no longer exists. I found a "remake" on github by someone else, but have no idea if that's any good and it seems a bit abandoned. I can't find "PakBuilder" anymore, so chances are it's down as well. Which leaves OnlineDat, that requires internet access and you need to be a registered user on a third-party site.

[Flemmbrav]

I really do welcome changes like that!
Thanks a lot for all the thoughts that go into this.

I found PakBuilder here, distributed with makeobj 53. Does not seem to be state of the art to me.

I do not believe that using makeobj really is an issue, if there is a small tutorial shipped with it.
In my opinion, the pak-ing size should be included in the dat. The bat would look like this in my mind:

makeobj pak64
REM this code will run makeobj for every .dat-file of the folder it runs at. It will produce Simutrans ingame objects for paksets based on 64px wide images.
REM "makeobj" calls the program used to convert sourcefiles into pak-files
REM "pak64" calls for the size of the graphics in use. Change this up, in case your graphics are not based on 64x64px squares.
REM For more, check the wiki: https://simutrans-germany.com/wiki/wiki/en_dat_Files

[prissi]

I think this is a rather a good idea. Probably rather one default_pak_size= and a pak_size= (the latter changes only the entry in question). How about: upon double click without parameters, makeobj will pak all files in the directory with verbose mode and wait for return.

[KneeOn]

I think there is some really good ideas here.

The graphics deposit holds a lot of useful but also a lot of out dated help. I think a full graphical Pak creater would be the ultimate move.

One where you load your graphics, the parameters are written to a DAT file in the programme and the pak file is output. I realise that I'm only presenting more work.

Short term gains would be a pictorial manual for making a Pak file. 128.Britain covers the use of Blender well but things to consider etc.

[prissi]

There is tilecutter https://forum.simutrans.com/index.php/topic,18394.0.html which generates at least the barebone dat file. Of course the details to the actual building still need manual edit.

[Leartin]

I think a full graphical Pak creater would be the ultimate move.

What could that do other than asking the pak creator "What type of object do you want to create" and allowing them to click "building", "vehicle" etc., rather than just typing it?
If properly maintained, the advantage would be to see your options, however it's unlikely if such a tool was created that it was maintained and updated regularly. Plus, you can achieve the same with a simple written documentation of available parameters.


If we are talking about tools, what could be useful is a tool that takes DAT and PNG and gives you a preview of the object it would result in, perhaps with some editing options on the fly. For example, if it was a building, you could get a preview where you set rotations and seasons and can quickly check if they are all correct, rather than needing to pak it, put it in the pakset, restart the game, find it, build it, rotate it and then speed up the game waiting for the other seasons.
Load in the right smoke object with your factory dat, and you can drag it to the chimney, the offset is written in the dat. Load a way with your vehicle dat and you not only see if the directions are correct, you can also see curve behaviour and how it stops at a station. Just drag it a bit if it's wrong, and an offset is added. Load a ground graphic together with a semitransparent objects dat and you can preview how it will look with Simutrans' 343 transparency blending on 565 graphics.

[ampersand]

pak it, put it in the pakset, restart the game, find it, build it, rotate it and then speed up the game waiting for the other seasons

Devs of paks must be very patient people if the above is indispensable stage of testing.

[KneeOn]

Leartin (quote isn't working on my phone!)

I agree, maintaining any graphical too iis going to be a big ask.

I think we need to make the distinction between easy and accessible. Plenty of people who could put together a decent image might not be inclined to learn the various parameters of a dat file, learn how to use command prompt and make a Pak, especially younger ones who may become long term contributers. Although it's an easy process when you know what's what, it's not accessible.

Therefore the easy option is to develop the pakset dat file creator with full options and help in managing the graphics process.

The ultimate goal would be the further options and previews, alongside other buildings possibly - almost a mechanics free sandbox to put objects and nothing more.

Prissi tile cutter isn't maintained I didn't think? I've never been able to use it.

Ampersand, yes. It is a critical part, and very frustrating. When you're doing a modular building you either do them all and track the bugs to fix multiple paks or you spent time getting one module right then hopefully the rest will follow.

[prissi]

tile_cutter is somewhat maintained, and it is python, so very easy (relatively) to extend.

[Leartin]

Devs of paks must be very patient people if the above is indispensable stage of testing.

Honestly, I just don't test that thoroughly and hope any issues come up eventually. When they do, it's easy enough to fix.

I think we need to make the distinction between easy and accessible. Plenty of people who could put together a decent image might not be inclined to learn the various parameters of a dat file, learn how to use command prompt and make a Pak, especially younger ones who may become long term contributers.

Hence this thread that adresses this very issue, to make it both easier and more accessible. I just don't think you gain much accessibility with a tool that allows you to click options instead of typing them out.

Let's look at a random dat:

Code Select Expand

obj=building
name=com_cl3_E4_01_23
copyright=Flemmbrav
intro_year=1970
intro_month=1
type=com
climates=temperate
Level=23
chance=50
needs_ground=0
BackImage[0][0][0][0-1][0][0-1]=images/com/northsea/23_E4_01.<1-$0>.<$1>


In this case, only the last line is directly related to the graphic, and that's tilecutter territory - which is maintained, but that you didn't knew that just reinforces the issue with third-party-tools. Perhaps because it requires python?
So how would you get to this dat with a tool?

The program would ask "What type of object would you like to create?" with a dropdown choice for building, factory, field, vehicle, good, tunnel, bridge, way, wayobj, roadsign, ground_obj, tree, crossing, pedestrian, smoke, cursor, symbol. menu and misc.
I think that's all current options. If your first choice is already between 19 options, you are not really accessible, so you'd have to dumb it down. Eg. split it in categories (building - building, factory, field; vehicle; way - way, tunnel, bridge, wayobj, roadsign, crossing; landscape - tree, ground_obj, pedestrian?; misc - smoke, cursor, symbol, menu, misc, good)

Okay, so the user chose to create a building. Next question "And which type of building should it be?" - res, com, ind, cur, mon, hq, tow, stop, harbour, depot, extension. 11 options, too much even if they are explained. so... citybuilding - res, com, ind; player building - hq, stop, extension, harbour, depot; other - cur, mon, tow? Or are mons and tows citybuildings? Hmmm...

Copyright and name need you to type information, so they are no different from editing a dat file directly.

Next question: Introduction date, retirement date, preservation date. since it's a date, this one is fine, and you don't have to wonder if month=1 is january of february. Except, preservation date shows another thing: There are many options not used in most objects (in this case because it's so new), but the tool would still have to ask about it, introducing concepts the user doesn't need to know at that point.

Climate. This one is weird, because it's pakset dependent. That is, while they are named rather than numbered, most paksets use them differently. The tool would need to know what pakset the user is developing for and download the names of climates from the translator to be really helpful. Otherwise, I guess there are 7 checkboxes.

Level and chance are just sliders, but they are very much pakset dependent, since what everything else uses matters. So while the tool can tell you to enter them, it could never tell what a goo value would be.

We skipped two parameters because they are rarely in citybuildings - noinfo and noconstruction. But they exist, they work, the tool needs to handle them.


I think that would be terrible, and deterr users compared to "You want to create a citybuilding? Check out existing dats (https://github.com/Flemmbrav/Pak192.Comic/tree/master/pakset/buildings/city), copy what you need, change the image reference to yours and pak with makeobj - it can be downloaded here: www.simutrans.com/en/download/ just doubleclick it, it tells you what to do.
[At least my expierience was that makeobj 'not working' and a lack of files to compare to was the issue, never to write parameters in a dat]

Now if you have an idea how a tool could be smoother, please tell. Perhaps you have a great design in mind that's worth realizing, that me and others just never thought of.

[Vladki]

preservation date.

Did I miss some new feature? I know only about intro and retire dates...

[Leartin]

Did I miss some new feature? I know only about intro and retire dates...

Wouldn't surprise me. Preservation is given in year and month like other dates. Once a (city)building on the map has reached it's preservation date it won't be renovated anymore. Nightly only so far, requires nightly makeobj.

[Ters]

It is not too hard for a pak creation tool to just bypass dat-files entirely, and just read and write pak-files directly. At least not compared to all other stuff involved in handling every aspect of pak creation.

If it handles everything, having dat-files around is just a easy way for users to challenge the program with all kinds of syntax errors and similar. (Technically, ruining pak-files is just as easy, if not more, but most users will probably see the "noise", realize they are out of their depth, and close the file.)

[Flemmbrav]

I just want to confirm that I don't test my stuff anymore either.
Stuff lands directly on the Git, and if it doesn't compile, I'll take a look at it.
I don't even remember the last time I've been activly looking for fireflies on my objects.

But on the other hand, I have quite some experience in this regard. The whole process must be frustrating for a newbie. But I don't believe that's the first thing we should solve.

On the topic of a graphical help to create dat files:
If that is supposed to be a thing, it has to be updated automaticly by reading the different parameters out of the Simutrans source code.
Some things change over time, and this project would be useless if outdated.
In plus, if you really want to provide a tool to assist people for easy content creation, helping to find smokes or constraints might be a cool thing too. That might require reading in paksets at the start tho.

[Ters]

If that is supposed to be a thing, it has to be updated automaticly by reading the different parameters out of the Simutrans source code.

That won't work. Unless one establish a complex metadata format for describing the pak format and/or dat format and parameters, programs reading pak or dat files has to be manually updated. Even then, something may come a long that requires a custom GUI component. However, Simutrans doesn't change that often, although the dat format changes slightly more often than the pak format. Any kind of program requires active maintenance anyway. Keeping up with Simutrans is probably less problematic than keeping up with security patches and other changes in components it relies on. A tool written in Python was mentioned. If it was written for Python 2, that will have to be rewritten into Python 3, because Python 2 is history now.

[Leartin]

That won't work. Unless one establish a complex metadata format for describing the pak format and/or dat format and parameters, programs reading pak or dat files has to be manually updated.

I think the point is not so much automatic update, but integration in Simutrans proper. If you add a new parameter to Simutrans, you will (manually) add it to makeobj as well. In this case, you'd make sure that this tool would get the update as well.
Especially if we are talking about a tool that allows you to preview objects, it would make sense to just use Simutrans code in the first place. That is, make sure the display function of that tool is the same as Simutrans's, such that it actually yields the same results. This would be best achieved by making it part of Simutrans development, part of the code, just like makeobj.

[prissi]

Such a preview tool would be a major effort, even more difficult than loading dat files into simutrans.

[Ters]

I think the point is not so much automatic update, but integration in Simutrans proper. If you add a new parameter to Simutrans, you will (manually) add it to makeobj as well. In this case, you'd make sure that this tool would get the update as well.

Well makeobj is part of the Simutrans source code. However adding a user friendly GUI tool to the codebase could easily dwarf out Simutrans itself. Not to mention that it might not be a good idea to write that tool in the same language.

I hava a program that lets me open pak files and preview them in different orientations and seasons. (Although its primary purpose is to see timelines and calculate profitability.) I would never have gotten off the ground if I had to write it in C++ like Simutrans.

[KneeOn]

There are some excellent points raised and I can only talk about my own experience especially regarding how I started painting and making pakfiles.

I did look at pakfiles and continue to do so, especially when considering extended features and agree when you've got a grasp of dat file parameters it is easier to understand what you need to do to implement a new feature. I think command lines do put people off, but concede I don't use tilecutter because I've never used it historically, couldn't get it to work for me this time and found it easier to do it "manually".

I suppose I'm coming at it from a first timer point of view and lowering the potentially intimidating first time is always worth thinking about.

I'm not sure what is more intimidating though, dat files or painting. The quality of work is so high and often takes a lot of practice to get right especially with the number of seasons and rotations for one tile buildings.

From what I can see there are several issues raised with no easy solution or even consensus on if they're an issue or not.

I'm not a programmer and cannot comment on how much work would be required to make the "perfect" tool and then maintain it while others who are say it would take too much work.

Leartin, to specifically address something you raised:

I think point and click is inherently more accessible with the fail safe that you can't mess up syntax as easily. A good example is needs_ground. All parameters are [parameter]=[value] and yet on TikiWiki it is as follows:
***
The parameter needs_groundlink
This parameter indicates whether a building the basic tile/s completely covers or not.

needs_ground = 0 -> tile completely covered (default - can be omitted)
***

I think it is safe to say that can (and has for me) caused confusion. Do we need a space or not? Does it break the syntax or not? A graphical tool will avoid such confusion even without the bells and whistles of previewing in a stand alone viewer.

I also think that although we all know what is what in a datfile, new painters who have made a pretty building will have their first exposure to writing a datfile by looking at things they don't understand yet. This can put them off.

I realise I'm only suggesting more programming while offering none my self. Perhaps a "quick win" is an Idea to Playable guide that covers the entire process with screenshots and a less technical, more user friendly guide? It could remove some of those low barriers that completely new creators may think are beyond their abilities.

[Leartin]

I think point and click is inherently more accessible with the fail safe that you can't mess up syntax as easily. A good example is needs_ground. All parameters are [parameter]=[value] and yet on TikiWiki it is as follows:[...] needs_ground = 0 -> tile completely covered (default - can be omitted)
I think it is safe to say that can (and has for me) caused confusion. Do we need a space or not? Does it break the syntax or not? A graphical tool will avoid such confusion even without the bells and whistles of previewing in a stand alone viewer.

I don't think that's a good example at all.
If there is no mistake in the wiki, both versions are valid, so how could you mess it up?
If there was an error, shouldn't we rather think of what happens if the tool has such an error? That would be even worse than a mistake in the documentation, since it's both harder to fix and harder to work around.

I suppose I'm coming at it from a first timer point of view and lowering the potentially intimidating first time is always worth thinking about.

That's the whole point of this thread, making things easier to approach for beginners.
My worry is, dumbed down, that we exclaim the solution to be "a helpful tool", because, by definition, it would be helpful. So far, nobody described in detail how that tool would work. I described my vision, which wouldn't be helpful, and asked how else it could work - so far, no answer. So what is the "Full graphical pak creator", really?
I'm currently thinking of a custom text editor that highlights dat-syntax with auto-completion and wavy red lines for unknown parameters and an "export as pak" button.

I'm not sure what is more intimidating though, dat files or painting. The quality of work is so high and often takes a lot of practice to get right especially with the number of seasons and rotations for one tile buildings.

The difference is that the ability to create dat files is rather binary - for the most part, you can or you cannot. Look at any dat file, and you won't be able to tell if it was made by an expert or beginner.
For graphics, nobody is completely unable to create a png file. Anyone can draw with MS-Paint. It's only about getting better.
Ask people to program "Hello World" in any language, many won't know where to begin. Ask people to draw a house on a piece of paper, they'll do it. On most, you'll even recognize it's a house.

[KneeOn]

There's some good points thers Leartin.


A fully graphical Pak creator would combine the automatic front/back image generator of TileCutter and a chance to see exactly which graphic will display on a given rotation and your custom text editor which I think is a good idea.


On the needs_ground, the assumption is that there will be some one well grounded in the parameters. Not writing a programme because it might have an error doesn't seem like a reason why a point/click input based dat file creation wouldn't work. On that basis Simutrans might not work so features shouldn't be introduced.


The wiki doesn't have both versions. My point was the difference is confusing and having mixed documentation IS a barrier to new builders. Lowering those barriers by making things somewhat failsafe makes it more accessible.


On the binary nature of Pak files I do largely agree although more advanced features require better knowledge of the parameters required such as signals, extended features, factories and goods and how those interact.


I *could* paint an underground station is 2014, but it would have never made it in to Pak64.


I *could* paint a train for pak96, but it wasn't refined. The quality of graphics are so high that it is daunting. That's absolutely not to say we need to lower the quality, just to consider of the dat file process is even the reason there are less painters or if there is something else x