Transport Tycoon Forums

Railwaymodeler wrote: For what it is worth, there is a GRF that removes the roofs and walls from truck/bus stations and looks like a parking lot. That GRF plays nicely with this set.

I have been looking for this GRF for quite some time but have been unable to locate it. Any help would be appreciated. Apologies for the thread hijacking.

Nite Owl wrote:

Railwaymodeler wrote: For what it is worth, there is a GRF that removes the roofs and walls from truck/bus stations and looks like a parking lot. That GRF plays nicely with this set.

I have been looking for this GRF for quite some time but have been unable to locate it. Any help would be appreciated. Apologies for the thread hijacking.

Right here, sir. And here's a pic of what they look like with ARRS:
Personally, I don't like the outcome since it kinda spoils my idea. The solution would be to re-draw this set and provide my own base graphics that matches ARRS. One of these days if I get enough time and interest I'll learn how to code this with parameters so I can throw in support for multiple road sets.

Thank you sir. Much appreciated.

there were a few missing pixels (one to be precise) ... I updated it at the issue http://dev.openttdcoop.org/issues/5555

Hm, on closer inspection it looks like you've used the wrong desert ground sprites for the no-grid version(s) of the tunnels. The desert sprites included in the main ground tile spritesheet of the OpenGFX+ Landscape source aren't correct, they have red pixels in them for some odd reason. There is a separate set of gridless desert tiles elsewhere in the repository that have the correct sprites. I think this is the file: http://dev.openttdcoop.org/projects/ogf ... desert.png Why in the world it was done that way I don't know.

Sorry to be such a pain

I was wondering about the red myself! Thanks, great discovery

fixed and updated to the issue again

Thanks for that observation and the quick fix of the sprites also from here. Fixed in OpenGFX+ Landscape as well.

This set works great in my new game! Thanks for this.

When can we expect a new release btw?

V453000 :) wrote:When can we expect a new release btw?

How about now?

New version featuring V453000's improved tunnel graphics now available via the online content or in the first post of this thread!

By the way V453000, I hope you don't mind that I went ahead and did a snowy version of the tunnels using the "ugly snow". It felt like a step backwards leaving them bare Also, I found two missing pixels in the ground sprites on one of the views that might be good to fix for other projects. I've highlighted them here in red:
All ground sprites in this view are missing these pixels, causing 1-pixel artifacts in-game. Very minor detail, but if you're anything like me it will drive you crazy

oh god not again ... will fix :s

I noticed ARRS does not detect ogfx-landscape is in alpine mode :s

and it somehow has grid even though ogfx-landscape is set to nogrid

https://dl.dropboxusercontent.com/u/204 ... UTS72a.sav

V453000 :) wrote:and it somehow has grid even though ogfx-landscape is set to nogrid

As a word of caution: I inverted the grid parameter's meaning in r175 for the sake of easier understanding: double negatives are bad

All parameters and their values are described in the code here. Mind the parameter numbers given there explicitly. They're different from the visual order you see ingame.

You find an example on how to query another grf's parameters in the code of OpenGFX+ Airports where I check for av8 version and parameter.
EDIT: maybe to make it a bit clearer than there:
check for presence of newgrf: grf_future_status(GRFID_AV8)
check for its version being >= 2200: param[GRFID_AV8, 254] >= 2200
access its 5th parameter: param[GRFID_AV8, 5]

Okay, the problem is that although I'm checking the right parameter number for the grid setting, it is actually multiple "sub"parameters tied to the same number, so when the Transmitter to Rock parameter gets turned on like in this case, everything breaks. And that's a major problem I'm surprised it hasn't been spotted before.

I don't see (or rather, understand) how you check for these sub-parameters explicitly. I imagine it has something to do with finding the 'bits' of the parameter, but that is something I can't find how to do in the documentation, and the code in OpenGFX+ Airports really doesn't shed much light on how that all works, at least to me anyway. I can play around and try to figure it out, but I get the feeling some basic programming knowledge would probably be useful here if that's the case.

Also, I notice in OpenGFX+ Airports that the check for another NewGRF uses grf_future_status, whereas I am using grf_current_status. What is the benefit to using one or the other, is the one I'm using correct?

And one more, about this bit of code, Is 254 a fixed parameter number for finding the specific version number of a GRF? I couldn't find anything anywhere about how to do that when I originally coded up the GRF, not that is was important then. It might be useful in the future though.

Sorry for all the questions.

Andrew350 wrote: I don't see (or rather, understand) how you check for these sub-parameters explicitly.

You need to understand bit operations for this as you need to mask out the bits you're not interested in and check for that result:
(grfparam[GRF_OGFXL, 0] & 0x00000001) will set every bit to 0 except the least significant one (bit 0). So you can then test the variable for either 0 or 1.
(grfparam[GRF_OGFXL, 0] & 0x00000002) similarily can only have the values 0 or 2, checking bit 1
(grfparam[GRF_OGFXL, 0] & 0x00000004) similarily can only have the values 0 or 4, checking bit 2
(grfparam[GRF_OGFXL, 0] & 0x00000008) similarily can only have the values 0 or 8, checking bit 3

In the latter cases some shifting might then be interesting to end up again at 0 or 1:
((grfparam[GRF_OGFXL, 0] & 0x00000002) >> 1) will give values 0 or 1, checking bit 1
((grfparam[GRF_OGFXL, 0] & 0x00000004) >> 2) the same, checking bit 2
((grfparam[GRF_OGFXL, 0] & 0x00000008) >> 3) the same, checking bit 3

Also, I notice in OpenGFX+ Airports that the check for another NewGRF uses grf_future_status, whereas I am using grf_current_status. What is the benefit to using one or the other, is the one I'm using correct?

The difference is in the order in which NewGRFs are activated in the list of NewGRFs. grf_current_status only returns true if the grf you check for is above yourself in the user's list, grf_future_status will additionally also return true when it is below you and become active.

And one more, about this bit of code,

Code: Select all

param[GRFID_AV8, 254] >= 2200

Is 254 a fixed parameter number for finding the specific version number of a GRF? I couldn't find anything anywhere about how to do that when I originally coded up the GRF, not that is was important then. It might be useful in the future though.

Yes, parameter #254 is the version number, and yes it's not documented anywhere, waiting for a nicer, more user-friendly way to make this available

planetmaker wrote:(grfparam[GRF_OGFXL, 0] & 0x00000001) will set every bit to 0 except the least significant one (bit 0). So you can then test the variable for either 0 or 1.

Thank you very much planetmaker, that seems to have solved the issue

Now unfortunately I'm also going to have to add in some of those NewGRF version checks since the nightlies of OpenGFX+ Landscape use different parameters which mess everything up again I guess that information will come in handy sooner than I thought!

I'll try to get a new version with the fix(es) out soon

landscape_nogrid = (grf_future_status("OG+4") && (((param["OG+4", 254] < 175) && (param["OG+4",0] & 0x01)) || ((param["OG+4", 254] >= 175) && !(param["OG+4", 0] & 0x01))));

might do the trick.

: DDDDD

Alrighty, new version uploaded to Bananas and the first post of this thread! It fixes a mistake where the parameters weren't always read correctly from OpenGFX+ Landscape, causing landscape mismatches. I also took the time to add support for the upcoming release of OpenGFX+ Landscape, so this set should now work correctly even with the new parameters. Thanks planetmaker for helping me along with all of this

Please do let me know if any more problems occur

If anyone is interested, I did find that ARRS and NARoads can play nicely with each other. This way, I got the ARRS road surfaces, including on bridges, and the NARoads streetcars and carbarn (Which I like better than the default carbarn), and the walls for bus terminals, and sidewalk "furniture" for drive through stops from NA Roads, but with ARRS surfaces.

The attached picture shows how it looks.