Page 2 of 3
Posted: 10 Aug 2006 09:27
by Aegir
Actually, you know what's interesting? Jonty, WhiteHand and I are all active users of GRFMaker, we're all under 18, and we all have zero to minimal programming experiance. Okay, I have a bit more than 'minimal', but anyways, it again shows, using GRFMaker isn't _hard_, but it isn't trivial.
Creating grf files is never (In my oppinion) going to get to the point where it's just 'push a few buttons and ZOMG! ITS TEH .GRF FILE', It's just something you have to put a bit of effort into learning.
Posted: 11 Aug 2006 09:22
by Raichase
Had to split the bad part off this topic.
Can we please stick to the topic? Thanks.
Posted: 11 Aug 2006 09:46
by michael blunck
Anyhow. First step would be to write a specification. BNF anyone?
Then the real discussion may be started.
regards
Michael
Posted: 18 Aug 2006 22:09
by Ronstar
Just some thoughts from someone who used to be a coder...
The problem I found with the NFO was not all the tedious things you had to make correct, but more the rapid expansion in things that could be done with the code with little or no explanation as to how it works or what function it serves.
I was getting by okay with simple stuff like new vehicles, wagon over-rides, partial loading graphics, rear-vehicle looking different, etc., but suddenly there came a burst of a whole new bunch of things.
What, in essence, seemed to strike me is that there was basically an 'in-crowd' of coders who were trying to do a lot of things inside the code that was impossible, and the developers responded by adding it in. Which is fine... Except only really the developers who'd implemented it and the in-crowd who'd ask for it knew what it was all about.
In the end, I had enough stuff to get done in my life without learning the nuances of a proto language that ultimately only existed to tweak a single game from years back.
I'd be quite interested in re-learning NFO coding. Even now after nearly two years I can look at my old code and know how it worked and what it did. But there's very little by way of demonstration to help people ease into the ever expanding functions. Just descriptions on syntax... For things which serve *what* purpose exactly?
Ronnie
Posted: 19 Aug 2006 00:09
by DaleStan
Ronstar wrote:For things which serve *what* purpose exactly?
There are parts of the NFO format for which I, too, am wondering if that question has an answer. But I trust that it does, and I proceed to file those parts under "Things to deal with later".
Posted: 19 Aug 2006 06:04
by Patchman
There are several things that I added because they were cool, easy to do and might potentially be useful (like procedure calls), but for which I didn't see an immediate use.
Still, most things do get used eventually... but you're right, most of the specs describe how things work, not what they're useful for. But I'm not in a position to fix that, since I only make sure they work as advertised, making them useful is up to the grf coders...
Posted: 20 Jun 2007 16:42
by RK
I am sorry to digg this topic out, but I changed my opinion.
Yes, it is not that hard to work with the NFO code if you understand it. But that changed nothing to the fact, that the Code structures are unclear and hard to read when you look over it after months.
I suggest to to put an XML-layer on top. There tons of libraries available, so no parser engine is needed. It's very common, easy to learn and human readable.
Locomotion uses it as well. OK, NFO is more powerful, but XML is very flexible.
just my 2ยข
Posted: 20 Jun 2007 20:21
by Red*Star
I think the major problem with nfo (as far as I've understood it so far) is the lack of re-usability.
If you program with a high-level programming language, especially object-oriented, you can divide your project in many many kind and smart pieces (in OO that are the classes), that may be re-used in other projects or even the same project at another point, which increases efficiency (you "don't have to invent the wheel again and again").
The only question is how to implement something like this for nfo language. I have had the idea of a "compiler" that converts directly from a high level nfo language to grf files - or maybe a two-step-compiler: High level -> nfo text file -> grf file (where the last step is done by the already existing grfcodec).
The following was a very rough and quick mockup of a possible description language made by me in the beginning of this year. I neither know if it's useful, nor do I know if it really fulfills my own specification - as stated above: 'reusability' - but I nevertheless will put it here, maybe it inspires someone to overthink the problem more in detail, or at least it shows that a framework set on top of nfo does not make sense at all.
Code: Select all
// this is a comment, it will be ignored on compiling
name
"my set"
description
"my desc"
grfid
"TW" & 0x0305
spritelist
myfirstsprite = sprite(
"sprites/train.pcx",
pos(98, 8),
compressed,
size(18, 8),
relative(-3, -10) )
mysecondsprite = sprite(
... )
// this list could be autogenerated by a program that checks the pcx
// file for "blue boxes" and creates proper sprite definitions
spritesets
mygreatloco = set( nameofsprite1, ..., nameofspriteN )
actions
mylocomotive = create_rail_vehicle()
mybus = create_road_vehicle()
myship = create_ship()
myboeing747 = create_plane()
mystation = create_station()
mygoldengatebridge = create_bridge()
myhomesweethome = create_house()
myindustry = create_industry()
myufo = create_object()
mycargo = create_cargo()
mylocomotive.add_sprites(mygreatloco)
mylocomotive.set_props(weight, power, maxvelocity, color, ...)
loco1 = mylocomotive.clone()
loco2 = mylocomotive.clone()
loco1.set_velocity(x)
loco2.set_velocity(y)
// this is how a callback could be implemented:
if ( simulation.get_year > 1950 )
mylocomotive.use_sprites(mygreatlocowithRedColor)
else
mylocomotive.use_sprites(...)
etc....
// how to change game internal variables:
myvars = new global_variables()
if ( simulation.get_year > 1950 )
game.use(myvars)
else
...
// or maybe instead:
global_variables.inflation.set(100%) // set a hyperinflation period ^^
Posted: 20 Jun 2007 20:37
by michael blunck
I have a strong feeling that RK digged the wrong thread.
The more interesting discussion had been here.
regards
Michael
Posted: 20 Jun 2007 23:23
by PikkaBird
Red*Star wrote:I think the major problem with nfo (as far as I've understood it so far) is the lack of re-usability.
I dunno, I find my nfo is pretty reusable. It's all standardised action 0s and blocks of action 2s that do particular things (and have a lot of comments to remind me exactly what they do!). When I make a new vehicle that doesn't have to do anything that I haven't done before, I copy and paste what I need, change a few values, and bosh it's done.
Posted: 21 Jun 2007 00:39
by RK
I don't think NFO needs an OO abstraction. That would lead into a lot work.
I am sorry for that. Maybe I can bring that discussion to life again.
Posted: 21 Jun 2007 04:07
by PPT
I don't know much about this, but expecting artists to deal with programming code doesn't seem like a good idea.
There should be templates or an overlay or something.
Posted: 21 Jun 2007 06:07
by chipetke
RK wrote:...
I suggest to to put an XML-layer on top. There tons of libraries available, so no parser engine is needed. It's very common, easy to learn and human readable.
Locomotion uses it as well. OK, NFO is more powerful, but XML is very flexible. ...
Actually I made some preliminary XML specs for NFO coding, it's somewhere in my docs folder.. I can dig it up if someone is interested...
Posted: 21 Jun 2007 15:37
by Red*Star
PikkaBird wrote:Red*Star wrote:I think the major problem with nfo (as far as I've understood it so far) is the lack of re-usability.
I dunno, I find my nfo is pretty reusable. It's all standardised action 0s and blocks of action 2s that do particular things (and have a lot of comments to remind me exactly what they do!). When I make a new vehicle that doesn't have to do anything that I haven't done before, I copy and paste what I need, change a few values, and bosh it's done.
Maybe I still understand the nfo language not good enough to see where things could be reused. The only thing that got me to think about a higher-level nfo was that I regularly get confused by this assembler-like nfo language, or assembler in general
, but well, that's my problem of course.
RK wrote:I don't think NFO needs an OO abstraction. That would lead into a lot work.
Of course it would be ^^. But I haven't said that it has to be explicitly OO. OO isn't even possible, because OO is a /programming/ paradigma, and nfo coding is not programming.
Posted: 21 Jun 2007 18:05
by DaleStan
Red*Star wrote:and nfo coding is not programming.
And where exactly did you get that idea?
Posted: 21 Jun 2007 18:08
by Csaboka
Red*Star wrote:nfo coding is not programming.
I wouldn't say that. Not all of NFO coding can be called programming, but handling non-trivial action2 chains (for callbacks, variational graphics and animations) is indeed programming, I've learnt that while coding the three TTRS versions. And if you don't believe me, ask George whether coding the complex behaviour of his industries is programming or just putting some sprites together...
I agree with your main point, though. OO would be overkill for NFO.
Posted: 21 Jun 2007 19:28
by Red*Star
DaleStan wrote:Red*Star wrote:and nfo coding is not programming.
And where exactly did you get that idea?
Here: [1]
wikipedia wrote:Computer programming (often shortened to programming or coding) is the process of writing, testing, and maintaining the source code of computer programs.
I know, it's kinda grey area, because you also could understood [O]TTD[Patch] as a kind of "interpreter" for "the nfo language". It's not that clear a I stated above, and I does not meant to do harm to any of you coders, out there
. I think Csaboka hit the point quite right.
[1]
http://en.wikipedia.org/wiki/Computer_programming
Posted: 21 Jun 2007 20:23
by michael blunck
Even producing something like this
Code: Select all
1001100011110010110001111110100010001101010
0100011000111110111110100100010000000010000
101001010000101010100101000101010 ...
would be filed under "programming".
regards
Michael
Posted: 21 Jun 2007 20:30
by RK
NFO is my personal definition of
Brainfuck.
Posted: 21 Jun 2007 21:10
by AndersI
I definitely prefer
WhiteSpace
(Now, why didn't that url come out right??)
http://tinyurl.com/ywp8kq