JGR's Patch Pack

[Captain Rand]

Will the Linux versions of JGRPP run on a 32 bit PC?
I desperately want to get away from Windows. I'll probably go with Linux Mint, or one of the lightweight Ubuntu variants.
At this point OTTD is about the only reason I'm running Windows at all.
Thanks,

Pete.

[JGR]

Will the Linux versions of JGRPP run on a 32 bit PC?
I desperately want to get away from Windows. I'll probably go with Linux Mint, or one of the lightweight Ubuntu variants.
At this point OTTD is about the only reason I'm running Windows at all.
Thanks,

Pete.

For 32 bit Linux you will most likely have to compile it from source yourself, the various Linux binaries on Github are for 64 bit x86. Once compiled it should run with no problems though.

[Emperor Jake]

Just saying, lots of computers were shipped with 32 bit Windows even though the CPU was capable of running a 64 bit OS, so you might want to double check that

[Captain Rand]

Just saying, lots of computers were shipped with 32 bit Windows even though the CPU was capable of running a 64 bit OS, so you might want to double check that

OK just checked. You may be on to something.
My ancient PC has a Pentium E6300, which has "Intel 64" and a 64 bit instruction set.
I had no idea.
Thanks!

Pete.

[Argus]

Next crashlog
Too many characters, game crashes while buying a tram.

[JGR]

Next crashlog
Too many characters, game crashes while buying a tram.

This appears to be a font/text issue.
I'll look into this further in due course.

[Revenge_of_KioTheDev]

can i get explain why road and tram types are limited to 64 for both? i understand you will not fix it but even though 64 rail types is good the 32 trams and 32 roads very hard to work with so would like to know why

[JGR]

can i get explain why road and tram types are limited to 64 for both? i understand you will not fix it but even though 64 rail types is good the 32 trams and 32 roads very hard to work with so would like to know why

That is the way that the feature was designed.

There is rapidly diminishing returns from adding more and more types, and it makes the associated in-game UI issues worse, arguably 64 types is already excessive.

[Quast65]

A separate (from the original 64) eyecandy type would be nice though...

[Eddi]

not too long ago you only had 16 rail types... give them a finger, and they take the whole hand...

[Quast65]

not too long ago you only had 16 rail types... give them a finger, and they take the whole hand...

Not too long ago you only had 1 type of station... Thank The Almighty Spaghettimonster for progress...

[kamnet]

can i get explain why road and tram types are limited to 64 for both? i understand you will not fix it but even though 64 rail types is good the 32 trams and 32 roads very hard to work with so would like to know why

The New Roadtypes and Tramtypes (NRT) specification is only a few years old. Sets that were created within the first year or two after this tended to create new hidden types of roadtypes and tramtypes in order to make vehicles compatible across different types of roads. This has resulted in players finding that they're not able to use the entire 64 slots with visible types, and has also made it difficult to use multiple sets together easily.

A few sets have started to adopt a standardized system of labels which vehicle set developers can use to ensure compatibility with specific types of roads. So far this has resulted in some small changes and it will take a lot more time for it to get worked out.

[Revenge_of_KioTheDev]

can i get explain why road and tram types are limited to 64 for both? i understand you will not fix it but even though 64 rail types is good the 32 trams and 32 roads very hard to work with so would like to know why

The New Roadtypes and Tramtypes (NRT) specification is only a few years old. Sets that were created within the first year or two after this tended to create new hidden types of roadtypes and tramtypes in order to make vehicles compatible across different types of roads. This has resulted in players finding that they're not able to use the entire 64 slots with visible types, and has also made it difficult to use multiple sets together easily.

A few sets have started to adopt a standardized system of labels which vehicle set developers can use to ensure compatibility with specific types of roads. So far this has resulted in some small changes and it will take a lot more time for it to get worked out.

then is there need for modified vehicle and/or roadtype sets to standard labels?

also am very disappointed that ufibys set uses very many slots which is why i ask. i dont mind that he does not have time to change set to standard or disable some type with parameter and probably not want to post source, but he use 42 types and would just be nice to use conveyor belts and quast roads with it never mind i think most roadtypes tend to use unique labels and then assign alternative and powered types?

[kamnet]

If you find that the full U&Ratt set is using too many for your liking, you might want to consider using the U&Ratt Mini set.

I would love it if all of the set authors made each road/tramtype to be individually enabled (and also with speed limits individually set), but that's a lot of work and I can't fault them for not offering that option at all. There's several great options for road sets out there. And if you're aggrivated enough, you can create your own set.

(BTW none of this is specific to JGRPP, NRT has been a part of the core OpenTTD code for a few years now).

[Quast65]

There is rapidly diminishing returns from adding more and more types, and it makes the associated in-game UI issues worse, arguably 64 types is already excessive.

not too long ago you only had 16 rail types... give them a finger, and they take the whole hand...

To be honest, I dont understand this kind of reasoning.
The hardcore player probably doesnt even activate these kind of eyecandy GRFs anyway.
Maybe just some that change/improve the base-look of the game (like the extrazoom CZ ones or the one Zephyris is working on).
They are more focussed on GRFs that improve actual (economical) gameplay.

Whereas the die-hard eyecandyplayers, (who probably "play" the game, mostly 99% of the time, with the PAUSE-button on)
dont mind spending hours, scrolling through huge amounts of items to find that one little bundle of perfectly stacked pixels that makes that one tile,
of the thousands available on the map, look just perfect. (and then never ever look at that tile again )
Trust me, you dont want to see my station- and object-menu's

The only thing I can understand is if road/tram- and possibly even train-track developers are kindly asked to use parameters to en/dis-able each individual track.
Because that is not

a lot of work

at all

Is there no comprimise possible?
Like that you can increase those numbers via the game-settings?
Standard on a low setting, but with an option for those who really dont mind searching through a cluttered UI, to increase it?
Maybe even also a larger amount of active GRFs?

[Eddi]

Is there no comprimise possible?
Like that you can increase those numbers via the game-settings?

that sounds like a nightmare to implement.

[Argus]

I guess you are hitting the walls of an outdated DOS kernel again and again.
By the way, it still tells me if I use dump_info roadtypes, 62 types at most. But I personally think it's a fairly sufficient limit, although... I wouldn't be mad if it went up

[Eddi]

there's nothing "outdated" about this. it's a design decision to keep the map data compact. it could be done differently, but there's no argument why that would be "better".

about the 62 types: there's an implied "no road" and "no tram" type (for having bare road with no tram, or bare tram with no road), making it a full 64 types

[Argus]

Sure, the two extra types, that's logical, I could have guessed it.
If I understand correctly, the more data is added to the map, the less compact and stable it becomes?

[JGR]

I guess you are hitting the walls of an outdated DOS kernel again and again.
By the way, it still tells me if I use dump_info roadtypes, 62 types at most. But I personally think it's a fairly sufficient limit, although... I wouldn't be mad if it went up

there's nothing "outdated" about this. it's a design decision to keep the map data compact. it could be done differently, but there's no argument why that would be "better".

about the 62 types: there's an implied "no road" and "no tram" type (for having bare road with no tram, or bare tram with no road), making it a full 64 types

The road/tram types start from 0, so you can have up to 63 types active at once.
There is only one "invalid road/tram type" value.

Sure, the two extra types, that's logical, I could have guessed it.
If I understand correctly, the more data is added to the map, the less compact and stable it becomes?

Adding more stuff to the map means that it doesn't compress quite as well when making savegames, but that is not that big an issue really.
In principle there should not be any stability issues, however having more GRFs active makes it more likely that there will be some sort of GRF conflict.