Transport Tycoon Forums

Ruudjah wrote:My question: Is this patch usable on the client only? In other words, does the server need this patch also for it to work?

The server does also need the patch, as the server must know, whether it should build a new station or join an existing one (and which station to join).

Here you can found a version of the distant-join-stations patch for the "passenger and cargo destinations" openttd version.

It based on the distant-join-stations for r14121, and working great with dev branche of cargodest on the mercurial repository revision 63f84835344d (2008-11-04).

Just download sources, apply patch, copy data files and play ! Links :
OpenTTD wiki : passenger and cargo destinations
OpenTTD mercurial repository : cargodest

Nice work! Merci!

I would like that patch more because you can build adjacent stations to the part you like. For distances, you can stationwalk...

I'm strongly opposed to the CTRL modifier, as much as posible advanced keyboard shortcuts shouldnt be avoided. Players should have access to as many features as possible without having to remember a stack of shortcuts., let alone if via shortcut most players wouldnt even know about its existance. The list would only show stations within range as already stated, and even the window could be resized to the minimum required. Alternativley there could be a button which would toggle the list display. The button could be on the build station window and could either pop up a new window or stretch that window to incorporate the list.

A lot of things in openttd already use ctrl, and you'll find it tells you in the tooltip if you right-click on the button.

Anybody know the status of getting this in to trunk? I'm lovin the cargodest patch for making awesome stations but would be nice to get it in to trunk already(I don't think there are any more problems? The last comment on flyspray was late November and it kinda died after that

As far as I know, this patch doesn't work with NoAI, or the other way, so I think that won't get in trunk until we fix it and people don't understand that is already possible to use station walking without this patch.
Because this patch was not made for helping cheating by avoid station walking but mainly to help in situations like in cities or near very crowded industries where you don't have space to build anything because competitors already cut you off

Well, station walking is also ugly; it takes playing time better spent on building nice junctions, or pseudo-undergrounds, or whatever... And it can sink your ratings with the town authorities.

As for NoAI, is NoAI to be merged into trunk at some point, then? And why is this patch incompatible? I thought NoAI was all about a better AI - surely the AI doesn't have to use the dialogs and such? Or is the AI practicing stationwalking in the NoAI branch?

I don't see how avoiding station walking is cheating, especially since it makes little sense from a game play perspective or a realism perspective. If stations with non-connected parts are allowed, why not allow them to be built that way? Also, if you're using a .grf that increases base-costs, station walking is a wasteful expense that isn't always easily made up.

Well, honestly? Even if we do count it as cheating, it's a label I'm willing to bear if it means we can connect road services to rail services without needing to demolish entire city blocks to create stations large enough to service the passenger volume, and even then still have to deal with incredible bottlenecks as every single vehicle insists on using the same platform.

MJS wrote:As for NoAI, is NoAI to be merged into trunk at some point, then? And why is this patch incompatible? I thought NoAI was all about a better AI - surely the AI doesn't have to use the dialogs and such? Or is the AI practicing stationwalking in the NoAI branch?

The patch is incompatible with NoAI, because it needs to rearrange some bits in the station building commands and of course the NoAI API still invokes the commands with the old arrangement. I say of course, because it's tracking trunk not a patched trunk. In the same way distant join is against clean trunk and thus can not care for something that is not there.

Whatever would go last to trunk (though I have no good feeling distant join will ever, but wonders happen, especially in Christmas time ) had to care for the other. So, if NoAI went to trunk soon, I would adopt distant join to "fix" the NoAI commands as I did with the classical AI, recently (unless somebody else did and of course anyone who wants can just prepare a version of distant join against NoAI branch now).

Hi,
i tried the simple Distant Joint station patch for R14121, but i have errors when compiling.
errors are on GetPlayer and _current_player in the station_cmd.cpp
it said its undeclared (first use of this function)

do you have a solution ?

thx

Chico008 wrote:do you have a solution ?

Yes, either

• take the latest one from the flyspray task [LINK] and apply it to r14600 (some higher revisions might also work, newest trunk will definitely not apply cleanly), *)
• wait for a new patch to current trunk be uploaded there (I'm working at it and hope to have Rubidium's homework task list finished by tomorrow, but I can't promise ),
• wait for the patch to hit trunk.

*) Please note that it is a Mercurial patch and thus needs to be applied with patch -p1 (or whatever is the equivalent with your favorite patch program).

Sorry, for double-posting, but I think this message excuses it :

It's done (more work than I thought in the final stretch):

Thank you to Rubidium for his effort that was still needed to finalize the patch.

Congratulations, Frostregen and PhilSophus!!

An other great addition of a bunch of very useful additions lately

Could you post a detailed description of the feature, e.g. when it does what and all cases where one can/need to press Ctrl, so we can add this information to the wiki? (I try to extract it myself like I did with the past dozen of features that recently hit trunk, but that diff here is quite big..)

edit: but very well structured, I must say. Well, otherwise it wouldn't have been committed of course..

edit2: From what I read, I understand that clicking without Ctrl should result in the same behavior as before, regardless of the advanced setting.
Ctrl-Clicking will create the new joining window, but only in some cases which have to do with the setting, and the number of stations adjacent and/or nearby.
But what exactly it does is a bit obscure to me right now.. care to enlighten me?
(relevant code snippet from StationJoinerNeeded:)
edit3: reading some more.. and there's @return information missing at the function FindStationsNearby. The function description is a bit misleading in itself because it says it returns stations we are able to join; but it doesn't return them, it stores them in a global var. It returns the station we are overbuilding if we are doing so, else NULL.

Basically if you try to build a station piece touching only one station or zero it behaves as before. Touching two or more it asks which you want to join to. Ctrl-clicking when touching one will create a new station, not part of the one it is touching, or give the choice window if other stations are in range. Ctrl-clicking next to none with another station in range will give a window asking what to join to.

I think.

The description in this post should still be valid concerning behavior with adjacent stations (I hope, I didn't change it now, and I think the patch wasn't changed in-between feature-wise, except for introducing the advanced setting).

Edit: I just re-checked, and the statements in the above post are indeed still valid.

Ah thanks; sorry for not reading back in the topic myself. That post cleared everything up for me