kamnet wrote:
I don't think there's a lot of interest in coding much of anything until the last six month. Even with vehicle sets most of those who did code have slowed down or stopped working altogether.
This is not a problem, since there are more newgrfs in the wild than necessary. IMO, "the problem" rather is that there are too few "good" newgrfs (functional, bug-free, visibly appealing, actively developed/maintained, etc).
kamnet wrote:
But, yes, the amount of time and work that it takes to code anything, particularly station sets, certainly discourages development. Lack of easy tools 12 years after all this really got started doesn't help, either.
Coding was never the culprit. The majority of existing newgrfs had already been coded in plain nfo, which needs a lot more amount of time and work than programming in a decent modern programming language. Even graphics is not the culprit, either pixel drawing nor rendering (from different reasons). But to produce a "good" (s.a.) train set needs even more than just drawing and coding. Especially today, not so in the starting years of TTDPatch or OTTD, when expectations were considerably lower.
kamnet wrote:
Yes, I'm aware of m4nfo, but most people are not. NML gets highly promoted by the devs because of their own personal involvement, but I rarely see you promote m4nfo. The more visible it is, and the more projects that are openly developed using it so that people can track and see functional examples of how live code works, the more interest it will develop.
Well, I´m aware that that other programming language gets exclusively promoted by some OTTD developers/crew, as well as the small number of "their" newgrfs (FIRS, CHIPS, Iron Horse, Nuts, Yeti, ...). They´re even propagating rubbish like "if it´s not on bananas, it doesn´t exist". O/c, such behaviour is totally counterproductive and massively contributes to the ongoing demise of OTTD at all (just to remind you to the existence of this forum, or see some very popular new developments like JGR´s patch pack and Cirdan´s fork, picking up requests from the user base which had never been responded to by the developers, etc). In fact, many productive supporters of "the game" have given up because of such childish behaviour from a certain group of OTTD´s developers/moderators. Not to mention all that bad talking about m4nfo, that I don´t care about.
The main area of this application is my own sets, which are all coded in m4nfo. Besides, there are a small number of other sets having been coded, e.g. the German RV set. But most of "foreign" m4nfo usage is - or has been - for sets which still are not finished (or never will be) for different reasons (Snail´s sets, SAC´s Swedish train set, JVassie´s BMSS, DanMack´s Canadian Stations, some bridge sets, one building set, etc.). Progress here could have been better, but given the dwindling overall interest, this is not really surprising.
Even from the vast number of "projects" on devzone (and a certain number of them using that other programming language), the majority is "dead". In fact, nobody could provide the help needed for newcomers to produce a functional set in either of the three existing languages, not me (prefering to work closely with a small number of dedicated people, if any), nor some OTTD developers, trying to explain the shortcomings of NML, Python, setting up makefiles, fighting with lib versions, ..., on IRC. Most of those clients are never seen again.
As SAC once said, the base of quite a number of "problems" lies with a fragmented "scene", pursuing quite different goals.
But this is all quite general, let´s move on to more specific facts:
Quast65 wrote:
I do also think that the problem is not just coding.
Stations can lead to a lot of different versions of the same building [...]
Drawing all these versions is also a lot of (mostly boring copy/paste) work.
That´s right. There´s usually a lot more to draw than for the 8 views of a vehicle. OTOH, the drawing work required for a rail set is far more boring, IMO. Or the need to do a snowy version from an already finished buildings or station set!
Quast65 wrote:
Furthermore, stations also require a lot of cutting up of the graphics, you need front parts and back parts so that trains run through them visually correct.
This is the fundamentally easy part. More challenging is cutting up of tiles because of bad handling of foundations and/or roofs by the game engine, resp the sorter. There are edge cases where there´s no proper solution.
Quast65 wrote:
And I dont think this can be helped by what kind of easier understandable coding language, its just the nature of the beast... And you need to have the patience to do that work.
The fundamental difference of stations compared to buildings (or objects) is not the needed handling of 3D coordinates and dimensions, but the fact that station sprites are multiple resolved by the game. I.e., even in the standard sprite layout, a station tile is resolved for the ground sprite, the building sprite(s) and the foundation. With OTTD´s advanced sprite layout, this number is increased to 8, which allows the use of different sprite blocks for different types of graphics and/or for different situations in one and the same invocation of callback 14. This opens up a large amount of coding possibilities which is not available for buildings or objects, but o/c makes station coding even more challenging, and - I presume - beyond comprehension for the novice coder.
regards
Michael