NuTracks 1.1.2: http://bundles.openttdcoop.org/nutracks ... -1.1.2.zip
MariCo v0.33: Contact Michael Blunck via PM
Hungarian Tram Set 1.1b: Contact Colossal404 via PM
Stolen Trees: Good luck with this one. It's unfortunate that it's still being traded, as the graphics were stolen from another artist, and it took a long time for this file to be removed. The server's operator should really be using it's successor set, INFRA Trees. It might be available from inside the OpenTTD Coop Pack but I cannot clearly identify which version this is.
Thanks, but all this already tried.
NuTracks version is wrong, server uses some very specific file named 1.1.2 but different from link version (and other versions by link).
Contacting people via PM just to return for singe play to good old OpenTTD is really too much. We usually awake for one or two evenings just to forget OpenTTD for another 5 years. And it's already brokes concept of "google it" vandal protection.
For the Stolen trees, of course i ended up with OpenTTDCoop, tried different versions, none of them contained none of 4 grfs. Server must have password.
You'd be better off PMing the server admin (Tintinfan), both for the GRFs and your thoughts/complaints.
Most likely he will not see your posts here, and I have no influence over his server.
Alternatively, setting up your own server (with your own password) is an option.
I don't personally have the free time or inclination to run my own server, especially not a public one.
Do not underestimate how much time and hassle moderation and anti-vandalism requires.
JGR wrote:You'd be better off PMing the server admin (Tintinfan), both for the GRFs and your thoughts/complaints.
Most likely he will not see your posts here, and I have no influence over his server.
Alternatively, setting up your own server (with your own password) is an option.
I don't personally have the free time or inclination to run my own server, especially not a public one.
Do not underestimate how much time and hassle moderation and anti-vandalism requires.
Oh, i thought you somehow directly relate to JGR Servers. BTW, these changes you compile and listed in first posts are tempting to try
I understand and remember all these problems, but ingame protection mechanisms worked well too. In the end, you expect server without password to be allowed for accident visitors (who have some respect to community grf storages).
P.S. Michael, seems played your DBSetXL years ago with just TTDPatch. Impressive that you still active!
Because I read the first posting of the thread again, I found the following under the point "miscellaneous":
Increase maximum permitted vehicle name length (added in v0.17.0), and vehicle group name length (added in v0.17.2)
I would be very pleased, when also the names of stations and, for me much more important, the names of depots had a larger allowed name length. It's very annoying, when I want to rename a depot and not even the length of the actual name is allowed by the name check.
The [tin01] server is no way affiliated to JGR himself, other than we make use of the patchpack for its extensive features to achieve a unique style of co-op gameplay.
It was never foreseen that the multiplayer aspect of such a patchpack would pique very much interest at all, leading an absence of administration. Whilst the server is not strictly closed, it is technically unavailable without asking for some specific GRFs. I understand how the current server name and lack of password makes the server deceptive and I have taken steps to reduce this misunderstanding. The existing playerbase is very keen on having more people join and I am very happy to respond to expressions of interest via PM here (or by PM to Tinny#9938 on Discord or Tinnycan on Reddit) and I'll look into making a separate topic about server in future.
Apologises for non-development related posts of recent, I hope personally responding will help! Otherwise, thank you very much (again) for maintaining an ever more wonderful patchpack.
I think there might be a bug in the latest version of jgrpp
I wanted to build a tunnel in my game, but I couldn't afford it because the absurd price.
I started a new game before testing this, and the same happened there. I started a new game without jgrpp, where the price was more reasonable.
A 248 tile long tunnel without jgrpp cost $16.015,770
A 154 tile long tunnel with jgrpp cost $361.111.935.176
So the tunnel cost $361.095.919.406 more with jgrpp. Is this a bug, or just something wrong with my settings?
Hello everyone! JGR, can i ask u a little to add? There is a DEL button that closes all unfixed windows. Thats cool. Also there is an option that can be activated - right click on a window to close it. Thats very cool. So, can u add a "right click with CTRL on a window to make it FIXED\UNFIXED" option? So i can quicly fix all the windows i need and press del for the rest? Would be just fine!
I was messing around earlier today and built an $8 billion ~100 tile chunnel... I thought that was just because of going under the sea, glad to know they're meant to be more feasable!
I'm curious... (and I'm not sure if this has been asked before, but I don't seem to have asked it myself) how problematic would it be to raise the limit on the number of unique houses? Sure would be nice to load ALL the house NewGRFs and actually have them all in the game! Ah, I can dream.
Add setting to enable improved level crossing safety.
drsid wrote:Hello everyone! JGR, can i ask u a little to add? There is a DEL button that closes all unfixed windows. Thats cool. Also there is an option that can be activated - right click on a window to close it. Thats very cool. So, can u add a "right click with CTRL on a window to make it FIXED\UNFIXED" option? So i can quicly fix all the windows i need and press del for the rest? Would be just fine!
I'm not sure that I see why this is really necessary. Windows already have a button for this.
Tsylatac wrote:
Add setting to enable improved level crossing safety.
What does this actually do?
PBS reservations cannot be made when a road vehicle is currently occupying the crossing, and signal blocks containing a level crossing use PBS.
These prevent accidental collisions between trains and road vehicles at level crossings.
JGR wrote:Tsylatac wrote:Quote:Add setting to enable improved level crossing safety.What does this actually do?PBS reservations cannot be made when a road vehicle is currently occupying the crossing, and signal blocks containing a level crossing use PBS.These prevent accidental collisions between trains and road vehicles at level crossings.
It's not, trunk doesn't switch to another signal type in the middle of a block (I don't believe you can do this in a sane way either).
I also have serious doubts about a vehicle being able to block the path of a train, since it would make crossings a nice source of annoying trains, while afaik, trains currently always win. The latter is easy to try though.
Being a retired OpenTTD developer does not mean I know what I am doing.
Alberth wrote:It's not, trunk doesn't switch to another signal type in the middle of a block (I don't believe you can do this in a sane way either).
I also have serious doubts about a vehicle being able to block the path of a train, since it would make crossings a nice source of annoying trains, while afaik, trains currently always win. The latter is easy to try though.
This, however, is kinda the way it is done in the UK where a signaller only allows a train in their block if they have shut the level cross and most have CCTV to verify its clear too
Alberth wrote:It's not, trunk doesn't switch to another signal type in the middle of a block (I don't believe you can do this in a sane way either).
The whole block is promoted to PBS, using the same mechanism as in trunk for mixed PBS/block signal blocks.
This seems a quite reasonable compromise to me.
Alberth wrote:I also have serious doubts about a vehicle being able to block the path of a train, since it would make crossings a nice source of annoying trains, while afaik, trains currently always win. The latter is easy to try though.
It is not ideal, however it is much better than trunk where level crossings are absolute death-traps.
There are some additional measures in place to prevent users from deliberately stopping road vehicles on a level crossing so as to cause an obstruction.
Ah, it's much less fixed than I thought it would be.
It's always amazing to see that any problem can be reduced or removed by having a different view on things, and not taking no as an answer
I agree that current trunk is quite terrible wrt level crossings.
Being a retired OpenTTD developer does not mean I know what I am doing.
JGR wrote:It is not ideal, however it is much better than trunk where level crossings are absolute death-traps.
Realism!
My solution has just been to make sure the (always PBS) signal block approaching the crossing is long enough that my slowest road vehicle can clear it before my fastest train can reach it. With breakdowns on (or really severe traffic) there's still the chance for a collision, but it mostly keeps things safe, gives something to weigh against building a bridge/tunnel/bypass and/or using waypoints to order trains to slow down for safety, and I enjoy things like trying to engineer that optimal signal distance.
Besides, being from the US, the "UK-style" solution just seems, well, foreign to me.
not in the same way. In trunk, trains pretty much utterly ignore road vehicles in the way. That's not realistic ( a train driver won't deliberately hit a car. It's just that the stopping distance for most trains is pretty much the same distance at which you can see the vehicle. not including thinking time. In absolutely perfect conditions.)
I thought that was just because of going under the sea, glad to know they're meant to be more feasable!
