GRF maker?

[DerekCZ]

Hello, I have a little question; is there some SIMPLE, WORKING and ACTUAL program for making simple GRFs, for example, like new railtype or new train engine etc.. I downloaded GRF Maker and GRF Wizard; If I open GRF Maker, blank window will show up, and GRF Wizard everytime say something about "action sucefuly completed" without doing something. Is there some program what can simply make or edit GRFs?

[PikkaBird]

Notepad++? Both NFO and NML are relatively simple "programming" languages.

Otherwise, no, there isn't.

[Eddi]

it won't get any simpler than this: http://www.tt-wiki.net/wiki/NMLTutorial

[michael blunck]

@SPolygon

There are a few vehicle sets around having been coded by use of GRFmaker (Ikarus bus set, Bob´s British Buses, Anders´ Swedish train set, ...). There´s also a GRFmaker v4 (ask Bob_Mackenzie or colossal404 for it).

regards
Michael

[Andrex]

Hello, I have a little question; is there some SIMPLE, WORKING and ACTUAL program for making simple GRFs, for example, like new railtype or new train engine etc.. I downloaded GRF Maker and GRF Wizard; If I open GRF Maker, blank window will show up, and GRF Wizard everytime say something about "action sucefuly completed" without doing something. Is there some program what can simply make or edit GRFs?

GRF Wizard will only encode/decode existing GRF files. After you decode a GRF file, you can edit the PNG image files to change your graphics, then encode it back to GRF. This method does not allow to create brand new GRF files nor create graphic sets, vehicles or rail types.

Making totally new GRF files requires learning the complex NFO file syntax, or the almost equally complex NML syntax. And create the image files as well, of course. As far as I know, everyone uses Notepad++ or a similar plain-text editor to do so.

[Baldy's Boss]

I just want the most painless way of piggybacking the Union Pacific 4-8-8-4 Big Boy and a representative post-WW II upgrade of the 4-8-4 (NY Central Niagara S-2/N&W "J"/UP FEF-3/C&O J-3-a etc) on top of NARS without disturbing anything else!

[kamnet]

Learn to draw and then learn to code. In addition to the low-level NFO programming code and the higher-level NML, you also have Michael Blunk's m4info macro library, which is sort of in-between. I personally have understood NFO better than NML, but there are good tutorials for both that will teach you how to develop a basic train engine. You'll have to put in the time and effort to learn how to build it into a functional set and to get it to interact with NARS (which is no longer supported by it authors, IIRC).

[FooBar]

or the almost equally complex NML syntax.

You mean "not nearly as complex". Trust me, I've used both.

[kamnet]

or the almost equally complex NML syntax.

You mean "not nearly as complex". Trust me, I've used both.

Having used both, I still can't wrap my head around NML. Nothing about it is straight-forward or intuitive to me. NFO appears more straight-forward, but it is admittedly a lot more work and a lot more tedious to use.

[michael blunck]

or the almost equally complex NML syntax.

You mean "not nearly as complex". Trust me, I've used both.

Having used both, I still can't wrap my head around NML. Nothing about it is straight-forward or intuitive to me. NFO appears more straight-forward, but it is admittedly a lot more work and a lot more tedious to use.

Apart from its shortcomings, it´s just overkill with all the additional Python/libs/make/gcc stuff needed and to be installed properly.

regards
Michael

[planetmaker]

The only thing you need to write a NewGRF in NML is nmlc itself - and python, if you are not on windows.

That's also true when mb wants to make believe otherwise and sell his equally baroque incarnation of libraries of NFO syntax wrappers - which indeed requires installs of further macro languages.

nfo: needs grfcodec / nforenum. complete grfspec support (~Raw grf language)
nml: needs python (for non-windows environments), no station and bridge support
grfmaker: no prerequisites. Limited syntax support but can use direct nfo
m4nfo: needs m4 and grfcodec / nforenum. Limited feature support (no airports, limited industries), limits on what can be done in the same grf

[michael blunck]

The only thing you need to write a NewGRF in NML is nmlc itself - and python, if you are not on windows.

15:31 <kero> mmh, nml wants PIL, but on my system there already is Python-Pillow (a fork), both are in conflict. Would nml use pillow ?

15:33 <@Alberth> kero: yes

15:34 <kero> Alberth : thanks
15:34 <@Alberth> Pillow is supposed to be a drop-in for PIL

15:38 <kero> mmh and nml wants setuptools, but the setuptools in Arch repositories doesnt support python 3 ...

15:38 <kero> Ok, this is becoming boring. I'll try another time.

15:39 <@Alberth> kero: nml is Pythno2
15:39 <kero> python setup.py install
15:39 <kero> WARNING: Sorry, python 3.0 or later is not yet supported. Some parts may not work.
15:39 <@Alberth> and it will run without actual install
15:40 <kero> mmh. All of this is quite cryptic

15:41 <Taede> try python2 setup.py install?
15:41 <Taede> so that itll use python 2.x provided its installed

15:42 <kero> python 2 is installed, as is python 3

15:43 <kero> Taede : i have still the same error : "ImportError: No module named setuptools"

15:45 <andythenorth> urgh
15:45 <andythenorth> setuptools
15:45 <@Alberth> just run it uninstalled

15:46 <kero> Alberth : ok, I'll try.
15:46 <kero> Anyway, I dont like installing as root not repositories-material
15:46 <andythenorth> one day I'll write down a bomb-proof way to get nml
15:46 <andythenorth> kero: same here
15:46 <Supercheese> My first time trying to install nml dependencies was a disaster too
15:46 <andythenorth> it's a cluster f***
15:46 <kero> lo
15:46 <Supercheese> I eventually got it working
15:46 <kero> +l
15:46 <@Alberth> kero I have a soft-link from my ~/bin to the nml main program
15:47 <andythenorth> most python packaging is a cluster f***
15:47 <kero> ok, now let's go for chameleon/markdown (? :/)
15:47 <andythenorth> once setuptools is fixed / replaced (which is happening) life gets better
15:47 <@planetmaker> apt-get install python-markdown
15:47 <@planetmaker> apt-get install python-chameleon
15:47 <@planetmaker> in my case
15:47 <@Alberth> oh, firs source code
15:47 <andythenorth> everyone has their own methods
15:48 <kero> Alberth : what is it the main ? just nmlc ?
15:48 <Supercheese> smells like linux
15:48 <kero> oh yes. nml compiler
15:48 <@planetmaker> yes. just nmlc in binary path suffices
15:48 <kero> planetmaker : i have mardown but not chameleon on Arch
15:48 <andythenorth> I don't want to throw in confusing advice, but I now do zero python without a virtualenv. ymmv. just saying

15:50 <kero> mmh for markdown: do I need the python implementation ?

15:50 <kero> community/python2-markdown 2.3.1-2
15:50 <@planetmaker> ^ sounds about right
15:50 <kero> let's go
15:51 <@planetmaker> and indeed. I'd welcome an addition which allows an easy install of nmlc
15:51 <@planetmaker> current procedure is rather painful
15:53 <@Alberth> more immediate problem might be dropping of python2

http://thegrebs.com/irc/openttd/2013/10/25

regards
Michael

[planetmaker]

You're quoting an ancient, now mis-leading conversation related to a project which implements a code generator as another layer on top of NML. That is not representative for a typical NML project. Andy's code is as much nml as C++ is C.

[michael blunck]

That excerpt above only shows how easy it is to install Python properly for NML to work. O/c, this is just a minor problem, the bigger ones usually start later.

06:05 <andythenorth> o/
06:06 <andythenorth> should nml be rewritten, not-in-python?
06:06 <andythenorth> for faster
06:07 <@Alberth> I don't know what the slow part actually is
06:07 <@Alberth> in my experience, you can guess the cause, but you're always wrong
06:08 <Phreeze> that it takes nearly 0.1s to compile?
06:08 <@Alberth> guessing the cause is a fun game though
06:08 <andythenorth> Snail: is m4nfo fun to use?
06:09 <andythenorth> and is it fast?
06:09 <@Alberth> Phreeze: as in, what part of the nml compile is the bottleneck
06:11 <@Alberth> andythenorth: I agree something should be done, but I don't know what
06:11 * andythenorth wonders if we should use a general purpose pre-processor instead of a scripting language
06:11 <@Alberth> rewriting nml from scratch feels like a blunt sledgehammer solution
06:12 <@Alberth> have fun with m4 then
06:13 <andythenorth> I wonder what the net time would be
06:13 <andythenorth> compile time versus programming time
06:14 <@Alberth> but 90+% of the nml code is fine, the puzzle is finding what the 10% part is, and how to eliminate that bottleneck
06:14 <@Alberth> also, I currently don't have the room to take on another big project
06:15 <andythenorth> usually I totally ignore ‘python is slow’ comments
06:15 <@Alberth> did you measure the time of all the various stages in a make run?
06:15 <Eddi|zuHause> Alberth: in my tests, there were two parts that were extremely slow, first, the ply part that reads in the souzrce, which also uses extremely huge parts of memory, and then the evaluation of (constant) expressions
06:15 <andythenorth> because usually my concern is programmer speed, not code execution performance
06:15 <andythenorth> much easier (and *much* cheaper) to buy more CPU than buy more good programmers
06:17 <@Alberth> Eddi|zuHause: ply builds on re, which requires the entire input string to be in memory
06:17 <Eddi|zuHause> the third part that was slow was that the makefile did this stuff twice, for the very questional result of a dependency graph. but afair that was removed...

06:18 <Eddi|zuHause> Alberth: but if the entire input string is 4MB, it's not a justification for python to use 1GB of memory
06:18 <Wolf01> hello
06:18 <@Alberth> hi hi Wolf01
06:19 <Eddi|zuHause> this memory consumption is the main reason i split into partial compiles

http://thegrebs.com/irc/openttd/2014/06/08

regards
Michael

[Transportman]

I never had problems with nmlc on Linux, but that was in the time that rprms were still distributed (as was the way to install NML on Linux in the Guide for Windows users).

Apart from its shortcomings, it´s just overkill with all the additional Python/libs/make/gcc stuff needed and to be installed properly.

For Windows I can just copy the contents of the NML-windows .zip folder and it works. The make/gcc stuff is not needed for small projects, but for larger DevZone projects which use multiple files they are.

[Supercheese]

The only thing you need to write a NewGRF in NML is nmlc itself - and python, if you are not on windows.

That's also true when mb wants to make believe otherwise and sell his equally baroque incarnation of libraries of NFO syntax wrappers - which indeed requires installs of further macro languages.

nfo: needs grfcodec / nforenum. complete grfspec support (~Raw grf language)
nml: needs python (for non-windows environments), no station and bridge support
grfmaker: no prerequisites. Limited syntax support but can use direct nfo
m4nfo: needs m4 and grfcodec / nforenum. Limited feature support (no airports, limited industries), limits on what can be done in the same grf

Well, to be fair, m4nfo is loads better than raw nfo, and it supports Stations while NML does not.

Although other than the Station support bit, NML is superior.

[michael blunck]

Although other than the Station support bit, NML is superior.

In an attempt to improve m4nfo even further, could you please elaborate in which way "NML is superior"? Especially, with regards to *large* projects, m4nfo has some advantage over NML, simply because it´s way faster, with separate compilation and linking. There´s even more on the plus side: easy installation, modularization, user expandability, built-in powerful macro processor, smaller code generated, etc, pp.

regards
Michael

[Eddi]

i love a nice flamewar as well as anyone, but... what's the point of this discussion? to confuse a newcomer? to diss "the other side"?

[michael blunck]

i love a nice flamewar as well as anyone, but... what's the point of this discussion? to confuse a newcomer? to diss "the other side"?

Someone suggested to use NML, some other suggested NFO as "better understandable", m4nfo was mentioned too, and then someone started to derail the discussion, by giving names.

Nothing special.

W/r to that "newcomer", I already suggested GRFmaker, which is a nice tool for that audience, but unfortunately out of development.

regards
Michael

[Supercheese]

In an attempt to improve m4nfo even further, could you please elaborate in which way "NML is superior"? Especially, with regards to *large* projects, m4nfo has some advantage over NML, simply because it´s way faster, with separate compilation and linking. There´s even more on the plus side: easy installation, modularization, user expandability, built-in powerful macro processor, smaller code generated, etc, pp.

regards
Michael

Well, I do not have any large projects, so I cannot comment on that, but I will have to play around with both some more and get back to you on that.