Page 24 of 32

Re: NotRoadTypes

Posted: 05 Jun 2018 14:44
by Wahazar
andythenorth wrote:
McZapkie wrote:Are there any nml project involved into NRT.
https://github.com/andythenorth/nml-and ... d_tramtype
Thanks for the link. I was asking rather about definition of road vehicles, because I want to prepare my grf to work with existing NRT grfs rather than making own one.
I found this example:
https://github.com/andythenorth/nml-and ... ehicle.nml

PS. I don't mind that I can use only nml, not assemblerish nfo :)

Re: NotRoadTypes

Posted: 05 Jun 2018 15:33
by wallyweb
acs121 wrote:You should know, to code NRT NewGRFs, as far as i know, you can only use NML.
NML is an upper level language that renders NFO. Each of those NML instructions represents a block of NFO code. Conclusion? You can code NRT NewGRFs directly in NFO. Actually, if one were to have a masochistic bent, one could code in binary. :twisted:

Code: Select all

0000 0000 0000 0000   0000 0000 0000 0001  0000 0000 0000 0010  0000 0000 0000 0011  0000 0000 0000 00100 ...
:lol:

Re: NotRoadTypes

Posted: 05 Jun 2018 18:32
by acs121
wallyweb wrote:
acs121 wrote:You should know, to code NRT NewGRFs, as far as i know, you can only use NML.
NML is an upper level language that renders NFO. Each of those NML instructions represents a block of NFO code. Conclusion? You can code NRT NewGRFs directly in NFO. Actually, if one were to have a masochistic bent, one could code in binary. :twisted:

Code: Select all

0000 0000 0000 0000   0000 0000 0000 0001  0000 0000 0000 0010  0000 0000 0000 0011  0000 0000 0000 00100 ...
:lol:
Sure, but then you can't compile the grf. Only that special NML compiler can do it, while neither m4nfo or GRFCodec can do it.

Re: NotRoadTypes

Posted: 05 Jun 2018 19:03
by andythenorth
McZapkie wrote:PS. I don't mind that I can use only nml, not assemblerish nfo :)
As far as I remember, grfcodec will compile NRT grfs fine. grfcodec is pretty relaxed about the nfo you feed it

renum will complain about NRT properties though. :twisted: (just don't use it)

Re: NotRoadTypes

Posted: 05 Jun 2018 19:46
by wallyweb
acs121 wrote:Sure, but then you can't compile the grf. Only that special NML compiler can do it, while neither m4nfo or GRFCodec can do it.
andythenorth wrote:
McZapkie wrote:PS. I don't mind that I can use only nml, not assemblerish nfo :)
As far as I remember, grfcodec will compile NRT grfs fine. grfcodec is pretty relaxed about the nfo you feed it

renum will complain about NRT properties though. :twisted: (just don't use it)
I have run into this nforenum issue before when in his New Map Features cirdan added a property to bridges Action0 in order to make the menu sprites accessible and also when he increased the number of bridge Ids from 13 to 16.
Run nforenum to verify the code that it knows. When coding GRFs in NFO for clones such as NRT and NMF, it is safe to ignore warnings for new items that those clones have added.
Keep in mind that nforenum is a lintner. It is not a compiler.
Conversely, grfcodec is a compiler. It is not a lintner.
As Andy said, grfcodec is pretty relaxed about what you feed it.

Re: NotRoadTypes

Posted: 05 Jun 2018 21:46
by Kruemelchen
McZapkie wrote:Are there any nml project involved into NRT, to lurk into its code?
I want to make horse carriages capable to run on off-road but not on highway.
May I suggest you use the label "OFFR" for your off-road horse carriages then?

I use this label in my off-road vehicles set, together with this code defining the compatibility:

Code: Select all

roadtypetable { HAUL, OFFR, SAND, DIRT, GRAV, ROAD, ASPT } //roadtype translation table 

item(FEAT_ROADTYPES, off_road, 0) {
	property {
		label: "OFFR";
		powered_roadtype_list: ["HAUL", "OFFR", "SAND", "DIRT", "GRAV", "ROAD", "ASPT"];
	}
}

Re: NotRoadTypes

Posted: 20 Jul 2018 04:03
by Andrew350
So I was just messing around working on some stuff for my roadtype newgrf when I discovered that NRT seems to have an infinite money glitch. If you convert one road type to another of a similar or equal cost, you will always be refunded money, allowing you to endlessly convert road types back and forth for a limitless supply of cash. If the two roadtypes are of a sufficiently different value however, costs seem to work as expected (I think). Tested with several road type grfs to make sure and all exhibit this behavior, the easiest one to see this is probably Country Roads.

Sorry if this was already known; did a quick search in the usual places and didn't find anything. :)

Re: NotRoadTypes

Posted: 20 Jul 2018 04:37
by acs121
Andrew350 wrote:So I was just messing around working on some stuff for my roadtype newgrf when I discovered that NRT seems to have an infinite money glitch. If you convert one road type to another of a similar or equal cost, you will always be refunded money, allowing you to endlessly convert road types back and forth for a limitless supply of cash. If the two roadtypes are of a sufficiently different value however, costs seem to work as expected (I think). Tested with several road type grfs to make sure and all exhibit this behavior, the easiest one to see this is probably Country Roads.

Sorry if this was already known; did a quick search in the usual places and didn't find anything. :)
I wonder if you used any GRF altering base costs ?

Re: NotRoadTypes

Posted: 20 Jul 2018 20:37
by Kruemelchen
Andrew350 wrote:So I was just messing around working on some stuff for my roadtype newgrf when I discovered that NRT seems to have an infinite money glitch. If you convert one road type to another of a similar or equal cost, you will always be refunded money, allowing you to endlessly convert road types back and forth for a limitless supply of cash. If the two roadtypes are of a sufficiently different value however, costs seem to work as expected (I think). Tested with several road type grfs to make sure and all exhibit this behavior, the easiest one to see this is probably Country Roads.
I can confirm that bug. The Country Roads road types use the absolute same (equal) cost, which is probably causing this.

Re: NotRoadTypes

Posted: 19 Aug 2018 03:33
by wallyweb
While working on Suspended Monorail (not NRT ... yet) we came across an old TTDPatch/OpenTTD bug where trams would appear to be traveling behind the far side pylons. The fix hack was to draw the pylons off tile. Has NRT taken this into consideration and provided a real fix?

Re: NotRoadTypes

Posted: 19 Aug 2018 06:38
by Eddi
probably an issue with overlapping bounding boxes.

a screenshot with the issue visible might help, both with and without bounding boxes visible (ctrl+B with newgrf developer tools active)

however, this does not sound like anything that would be affected by NRT one way or the other (neither does or should NRT fix this, nor the fix will depend on NRT in any way)

Re: NotRoadTypes

Posted: 19 Aug 2018 10:14
by wallyweb
Thanks Eddi.

A screenshot with the problem is here.
I was able to repeat it without Suspended Monorail in both TTDPatch and OpenTTD.
The NRT version of Suspended Monorail is still being worked on, so that image is not NRT.
I vaguely remember this issue being discussed many years ago, just after trams were introduced into TTDPatch.
My concern was not to fix a ten year (?) old issue that nobody seems to notice very often, but rather to inquire if the NRT devs were aware of it and if so, were they able to handle it?

I'll certainly try your bounding box suggestion. Hopefully get some screenshots later this morning, after I solve my need-for-breakfast problem. :wink:

Screenshot and save are here.

Re: NotRoadTypes

Posted: 19 Aug 2018 14:01
by U.N.Owen
Here is another example of this bug. Unspooled GRF screen:
Image
bad-tram3.png
bad-tram3.png (152.11 KiB) Viewed 1333 times
As you can see, this GRF has correct catenary_front and catenary_back layers.
It seems that OTTD itself draws catenary_back over trams.

P.S. This is not just for trams. For trolleybus wires, we can see this bug too.

Re: NotRoadTypes

Posted: 19 Aug 2018 16:42
by wallyweb
!!!!!!! PROBLEM SOLVED !!!!!!!!
Bridges have two sprite types: Front&Top and Back&Floor. so why can't tram tracks? :idea:
So, I moved the back pylons over to the track sprite.
Susmon_Bug_Solved.png
Susmon_Bug_Solved.png (4.46 KiB) Viewed 6139 times
Worked like a charm! :mrgreen:

Now if y'all will excuse me, I have a big bunch of sprites to redraw. :P

Re: NotRoadTypes

Posted: 19 Aug 2018 16:54
by Eddi
U.N.Owen wrote:Here is another example of this bug.
i think what's happening here is that the pillar sprite has two pillars at the beginning and end of tile, so each pillar actually gets drawn twice. once as second pillar of the first tile, and once as first pillar of the second tile.

the "correct" solution here would be to have only one pillar per sprite, and then draw pillars more like rail catenary pillars.

Re: NotRoadTypes

Posted: 19 Aug 2018 17:01
by wallyweb
Eddi wrote:
U.N.Owen wrote:Here is another example of this bug.
i think what's happening here is that the pillar sprite has two pillars at the beginning and end of tile, so each pillar actually gets drawn twice. once as second pillar of the first tile, and once as first pillar of the second tile.

the "correct" solution here would be to have only one pillar per sprite, and then draw pillars more like rail catenary pillars.
You're reading my mind, aren't you? :lol:

Re: NotRoadTypes

Posted: 19 Aug 2018 18:39
by U.N.Owen
wallyweb wrote:So, I moved the back pylons over to the track sprite.
This hack probably works, but not looks as very good solution. Rails and pylons is complete different things, it would be better to keep them separately.
For example, if we have this and decide to change track sprites, we cannot just get good sprites from another set but should to add pylons to them too. Situation get worse if they also use this solution and have they own pylons/pillar at the track sprites…
wallyweb wrote:Now if y'all will excuse me, I have a big bunch of sprites to redraw.
…And we will have this problem right now because I changing rails in NRT version.
Eddi wrote:the "correct" solution here would be to have only one pillar per sprite.
This variant looks much better (if it will work). We should try, I guess.

Re: NotRoadTypes

Posted: 19 Aug 2018 19:18
by wallyweb
U.N.Owen wrote:
wallyweb wrote:So, I moved the back pylons over to the track sprite.
This hack probably works, but not looks as very good solution. Rails and pylons is complete different things, it would be better to keep them separately.
For example, if we have this and decide to change track sprites, we cannot just get good sprites from another set but should to add pylons to them too. Situation get worse if they also use this solution and have they own pylons/pillar at the track sprites…
wallyweb wrote:Now if y'all will excuse me, I have a big bunch of sprites to redraw.
…And we will have this problem right now because I changing rails in NRT version.
Eddi wrote:the "correct" solution here would be to have only one pillar per sprite.
This variant looks much better (if it will work). We should try, I guess.
I'm taking this conversation over to the Suspended Monorail Topic because that is where it belongs.

Re: NotRoadTypes

Posted: 21 Aug 2018 23:20
by Kruemelchen
This issue is due to the bounding boxes of the pillars being fixed at the centre of the tile. So only a pillar that fits the bounding box does not clip. You can easily see this, when you activate bounding boxes ingame.

This clipping would become hilarious in my GRF for water canals, as I coded pedestrian bridges as catenary, but bridges obviously do not fit a pillar bounding box. :lol: The solution was to put the bridges at the centre of the tile so clipping was minimised.

Re: NotRoadTypes

Posted: 06 Jan 2019 16:36
by SimYouLater
Is this still being worked on? It was so promising, and JGRPP is now only missing this one feature to make it perfect for my 500 year marathon run server!