The place to talk about Transport Tycoon
https://www.tt-forums.net/
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.SPolygon wrote: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?
You mean "not nearly as complex". Trust me, I've used both.Andrex wrote:or the almost equally complex NML syntax.
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.FooBar wrote:You mean "not nearly as complex". Trust me, I've used both.Andrex wrote:or the almost equally complex NML syntax.
Apart from its shortcomings, it´s just overkill with all the additional Python/libs/make/gcc stuff needed and to be installed properly.kamnet wrote: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.FooBar wrote:You mean "not nearly as complex". Trust me, I've used both.Andrex wrote:or the almost equally complex NML syntax.
planetmaker wrote: The only thing you need to write a NewGRF in NML is nmlc itself - and python, if you are not on windows.
regards#openttd wrote: 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#openttd wrote: 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
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.michael blunck wrote:Apart from its shortcomings, it´s just overkill with all the additional Python/libs/make/gcc stuff needed and to be installed properly.
Well, to be fair, m4nfo is loads better than raw nfo, and it supports Stations while NML does not.planetmaker wrote: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
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.Supercheese wrote: Although other than the Station support bit, NML is superior.
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.Eddi wrote: 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"?
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.michael blunck wrote: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
