Higher level NFO?

[AndersI]

Maybe this post of mine drowned in the other thread...

NFO is really a form of assembly language. All it needs is someone to write a proper HLL on top of it...

Sounds like a fascinating project Do you have any initial ideas how it should look? Any abandoned starts on such a project? Any formal descriptions of the NFO grammar (in addition to the text descriptions in the Wiki)?

I've written both compilers and interpreters during the years, but the problem with a HLL is mostly that everyone has their own view how it should look, what's natural, '{' or 'begin' etc.

I was educated in the seventies, actually doing my first programming assignments on punched cards, and I started programming for a living in 1980 (In a BASIC dialect created here in Sweden), has touched most (mainstream) programming languages (and some not so mainstream) through the years, but since 1996 I've been mainly using Pascal (Delphi), which means that I would spontaneously make something Pascal-like. I know C, and use it at work (when forced to), but IMO Pascal is so much more elegant...

See, we'll soon be entering a language war here

[Patchman]

I wasn't entirely serious with that remark; I'm not sure there's a demand for a HLL on top of NFO. It might be more helpful to add a level of abstraction to GRFMaker, which at the moment is little more than a graphical interface for writing pseudo sprites with some helpful functions for managing real sprites.

If you do go ahead, I personally don't really have a preference as to what the language should look like, as long as it exposes all of NFO's capabilities in some way. Properly designed it should make easy things trivial to do and complex thing easier.

But you'll really want to get input from the people who actually do serious grf coding on this, both whether it's really useful and if so, how to design it.

[Uwe]

Hmm, I have seen about a dozen different programming languages during my studies, from ASM up to functional programming, and indeed, this knowledge is somewhat helpful when trying to learn NFO coding. It also gets you to a point where you say that it doesn't matter anyway if its begin or { or an extra tab.

However, instead of putting a HLL over NFO to make it more accessible, I think it would be much more useful to add examples to the wiki that show how one can do a certain effect or how certain actions have to be used. The wiki is a great resource to get the specification of the actions and stuff, but I found it very hard to read through the pages without having a short example code to see whats going on.

The short tutorial to get the first vehicle coded is really great, thanks to whoever did that. With that tutorial I was able to code my first vehicle within one afternoon, but then you're somewhat lost... The next learning steps I did was by decoding several grfs, decipher the actions and look them up in the wiki. This isn't exactly an easy way to go.

AFAIR, the wiki already has some unfinished tutorials, it would be very nice to see these filled with content by those who have the experience.

[broodje]

the only 'hard' part in the NFOs was the 'positional' coding especially action 00 springs to my mind in that perspective, every function has to be in the correct order to work and it is a pain in 'the appropriate body part' to find something back.
I always found the other actions (including the calbacks) not to hard to use once I finally understand how they worked. The only other thing were the bit-shifts. Josef has explained it a few times to me 'in my days' but I still don't understand it completely .

Anyway I'm not really the person to answer how such a toplevel language should look like, I have never coded anything else then trains and I got obsolete since the GRFmaker was build.

[krtaylor]

Well, I'd always hoped that GRF Maker would evolve into a complete GUI with no programming ability required, but useful as it is, it hasn't gone that far. Of course, there aren't really that many people who even attempt to code GRF files, so the user community is not that large.

[Lakie]

Personally, I see no need for a HLL for nfo code.
I find the hardest part just keeping track of how many bytes in your are or how many you wrote, nforenum helps me fix that though.
Admittedly I have spent more time patchdeving that nfo coding recently though...

Just my two cents worth,
~ Lakie

[RK]

Coding isn't so diffucult if you know what to do. But asking other people how to do it is very annoying.

[Aegir]

Well, I'd always hoped that GRF Maker would evolve into a complete GUI with no programming ability required, but useful as it is, it hasn't gone that far. Of course, there aren't really that many people who even attempt to code GRF files, so the user community is not that large.

Krtaylor, may I request that you stop blabbing on about GRFMaker? You have shown quite a many times that you don't know squat about how the tool works. You have done it plenty throughout the Japanset thread, my threads for my various projects, and in other places, and it is really starting to annoy me, especially considering how incorrect a lot of your comments are.

Thankyou,

---

However, in regards to the current discussion about a HLL to sit ontop of NFO, I have nothing to really add, except that I am amazed at how much TTDPatch continues to advance. Half the developments that have occurred recently, I would never have anticipated, back when I started using TTDPatch in the 1.8 days.

[Csaboka]

I think the analogy would be better if you compared machine code to assembly. For NFO coding, you need to remember a lot of arbitrary numbers and in what order you need them, much like in machine code. Assembly language doesn't abstract away from machine code, but it's still easier because mnemonics are easier to remember.

I, for one, have very bad number memory, and I keep forgetting which numbers should go where. Having some English words instead of arbitrary numbers would help me.

Of course, I'm just one dev; if no one else likes the idea, I can still use GRFMaker, even though I don't like some aspects of it.

[michael blunck]

OK. here´s my 2cc:

To do it well would be a lot of hard work. Remember that .nfo doesn´t only deal with vehicles but also with buildings and industries. And handling of vehicles and buildings/industries isn´t exactly 1:1.

What I like best in .nfo is its terseness. If you´re in business after a short introduction phase you may well be able to design things in a very short time without the usual text overhead of a high-level language.

OTOH, the biggest drawback of .nfo is its error-prone syntax consisting mainly of hex digits (resembling machine code), which is far less intuitive than human-readable key words or mnemonics (thanks Csaba). But with Dalestans excellent .nfo linter there´s already a very good program to handle many of those sources of error. Maybe it would be even possible to built upon it for further development ...

And indeed, this isn´t the first discussion on this issue. After the last round we got grfmaker, which isn´t a very helpful program IMO because it´s more or less a graphical interface - even more tedious to use than coding directly in .nfo.

Anyway, I think the general problem will remain that people who are fit in using .nfo directly won´t need any extra high-level language on top of it, but those "newbies" would still have to learn the specifications underlying the current .nfo syntax furthermore to be even able to program in such a HLL.

regards
Michael

[jonty-comp]

After the last round we got grfmaker, which isn´t a very helpful program IMO because it´s more or less a graphical interface - even more tedious to use than coding directly in .nfo.

I've tried NFO and GRFMaker, and I must say I find GRFMaker several thousand times less tedious than coding directly in NFO.
But that's just my opinion.

[AndersI]

OK, a lot of comments, but the gist of it seems to be:

"It's not difficult when you know how to do it" - If it's so easy, why is there a shortage of coders? The difficulty lies in getting to the "know how to do it".

The old coders that has been around a long time has learned new things piece by piece when they became available, starting now it's quite overwhelming, it isn't easy to grasp the whole NFO language in one go.

"GRFMaker" - This program definitely took me over the first threshold. I did code my first NFO file by hand, but with GRFMaker, I can get a lot more done in a shorter time, as long as I want to do something GRFMaker knows about (and I know how to tell GRFMaker), and it eliminates a lot of ways for me to screw up the NFO. GRFMaker does what it does, and helps a good deal, but it doesn't really teach me NFO coding. The learning curve just becomes larger (GRFMaker + NFO).

A symbolic level 'above' the plain NFO would probably help, there are repetitions of grfids again and again that could use defined constants, 'structural' actions (if ... then ...) would definitely be easier in plain text, named parameters instead of positional eliminates a lot of errors, text strings as "this is a string" also helps. Parts of this is probably already supported in grfcodec, but searching the Wiki I didn't find much info (OK, the strings are there, I see).

Whatever is put on top of the NFO (if anything), one still has to understand the actions to be able to write the right thing, and I do agree with whoever it was that said "More examples". A 'cook book' of practical solutions helps a long way, and is probably much more important than a symbolic level on top.

[broodje]

yep the IF-Then Structure could be handy for the calbacks for example. but for example the the max speed in action 00 would not gain a lot by making it 'Maxspeed=90' etc, although for new coders it would look less daunting. In fact I think it would help to recruit new coders with a 'toplevel' language. So in that perspective it might be not such a bad idea.

[LittleHelper]

... and I do agree with whoever it was that said "More examples". A 'cook book' of practical solutions helps a long way, and is probably much more important than a symbolic level on top...

I tried to become acquainted with some coding structures for beginners. The Wiki "tutorial pages" at the beginning are really helpful. After having coded some basic road vehicle grfs, I wanted to introduce specific sound(s) for the vehicles. Therefore I went deeper into the Wicki pages and investigated an example code from a different grf ... Oh... oh... quickly I had to surrender for the moment.

Therefore any further help regarding some actions, callbacks etc (esp. basic examples) on the Wiki pages would be very helpful. In principle, everything, which helps to shorten the learning curve would be really welcome by anyone who starts to become familiar with coding or tries to solve a specific problem.

Take a small group of interested "students", each one with (a) specific coding task(s), and name one "mentor" for each of them to give some help in that specific respect. After having solved it, the "student" writes a short summary about the task, the final code combined with some short comments ... and this paper will be attached to the appropriate Wicki page.
And in a short time the Wiki will be full of helpful examples!

regards
LH

[krtaylor]

Krtaylor, may I request that you stop blabbing on about GRFMaker? You have shown quite a many times that you don't know squat about how the tool works.

No. And that's entirely the point. I have every right to wish that it had gone in a particular direction, as of course you have every right to take it in whatever direction you please. As indeed with all things TTD, my hope is for things to always eventually reach the ultimate possible ease of use. In no way am I knocking GRF Maker, or saying that it is useless, absolutely not. But as AndersI and many, many others have pointed out, if GRF coding (by whatever means) is so easy, then why are there so few GRF coders? Because it's not easy. And, ideally, by means of various tools, GUIs, etc., it might someday become so. If you disagree, fine, you have that right. But I can still argue for that evolution, which would most naturally involve GRF Maker.

[jonty-comp]

as AndersI and many, many others have pointed out, if GRF coding (by whatever means) is so easy, then why are there so few GRF coders? Because it's not easy.

Actually, I think that the problem is rather that people just think it's really hard, and cast it off without trying. Since I've started using GRFMaker I've done most of the GRF-Making tasks with ease, the only help I needed was on articulated locos and I can do that now too.

[Villem]

GRF Coding is easy when you bother to learn it, i thought it was hard, then i took a look at the wiki's nfo tutorial, and next thing i know i coded a mostly working locomotive.

[BobDendry]

Well, I'd always hoped that GRF Maker would evolve into a complete GUI with no programming ability required, but useful as it is, it hasn't gone that far. Of course, there aren't really that many people who even attempt to code GRF files, so the user community is not that large.

You don't need programming ability to use GRF Maker. How do you think I code the ausset?

[jonty-comp]

You don't need programming ability to use GRF Maker. How do you think I code the ausset?

I agree, the most one needs is a little intuition to look for an initial tutorial, then the rest is pretty much self-explanatory once one has the basics.

[BobDendry]

Heck, I taught myself how to code. Without tutorials. I had GRFMaker before all of that stuff came up.