Transport Tycoon Forums

This patch allows to show the acceptance and catchment area of a station. It is just a first version to get feedback (and see if people like/want it).

Features :
- add a button in the station gui (another train square icon between Location and Ratings button)
- display acceptance and catchment areas in, respectively, blue and red "selection" squares (temporary sprites)

Known Bugs :
- if using "more realistic catchment size" for station, adding or removing tiles to a station with different catchment size can crash the game (on remove). Will be fixed in v2

Next :
- fix bug 1 (more an unfinished feature)
- add specific sprites : toggle button + acceptance / catchment tiles.
- differentiate between companies with colors / patterns / ... (how to do when station areas overlap ?)
- toogle catchment in stations from town ?
- optimize / change way to get catchment area
- ...

Infos on how works acceptance and catchment areas : http://www.tt-forums.net/viewtopic.php? ... 94&start=0

Feel free to comment ...
(don't mind the code yet, also i will comment it and check code style for next version)

At first, i dont like the small tag for turning on/off. Also the Red highlight is not very nice, use the standart ( gray - blue, when building station ... ) one? But nice patch for concept

I think that's a cool patch. I also agree that the red is a little too much, I'd like white better.

Very nice patch, something similar was already around some time ago. I would like a "global" switch, where the catchment view is enabled for all stations. What is the difference between your red and blue tiles, or rather what's the difference between blue and unmarked tiles?

Greets
Ammler

Ammler, blue tiles are also covered in acceptance area. His patch show the direct ones (red tiles) and also the one described in other topic (link at forst post)(blue ones).

I like the look of this, it reminds me of the areas you can set workers to in RCT. (Maybe you could use the same colour blue as a homage )

I think it'd be very handy for bus routes. Maybe if you are running a feeder service to a train station or airport to make sure you get 100% coverage in cities.

update to R17532

removed becuse of bug and updated below

Also a great patch cant wait for V2

There is a small bug the coverage is not updated if you remove part of a station.

All so if you end a game with it showing it will also show on the main screen on the background game

bug fixed with romoveing lorry stops becuse of my bad update heres a working one

code should never been changed We all hope gehene will get back to this patch

Is this patch always in production ?

I think this is an important function to see stations coverage.

If needed, I can help to develop this, but I'm not very familiar with openttd code (and I'm French )

maybe this patch is more developed: http://www.tt-forums.net/viewtopic.php?f=33&t=33701

Eddi wrote:maybe this patch is more developed: http://www.tt-forums.net/viewtopic.php?f=33&t=33701

This patch works with other NewGRFs, and more robust against performance

Fixed & updated

i made this simple modification in "rail_cmd.cpp" file and get a correct draw of coverage over rails (was not happening before).
"//DrawOverlay(ti, MP_RAILWAY);" is on the original place.

Thank you for the update & fix

I love this patch therefore dedicated some time looking it.
probably big changes are beyond my knowledge
but somehow this one is working in the beta4 and without crashes, so i'll ask to someone test it too (more then I )

thx again

Edit: added diff file against trunk

Patching against a release is not very useful.

After patching a release the program is not the same as the release itself (so use as a drop-in version of that release does not work), and in general the patch will fail in trunk due to changes between the release and trunk (making it impossible to merge it into trunk).
(Although, since beta4 is relatively young, the latter may still work in this particular case.)

Alberth wrote:Patching against a release is not very useful.

IF (and only if) the patch maintains network compatibility - i.e. most (though not all) GUI improvements would fall in this category - then it is useful to create patch against the release. Then you can use such modified release to connect to unmodified servers too (you just have to override the build to not add "M" to the end of the version)

Alberth wrote:... in general the patch will fail in trunk due to changes between the release and trunk (making it impossible to merge it into trunk).

Yes, but sometimes patch from release may work within some range of revisions and with reasonably small modification within quite large range of revisions. Creating patch for trunk from patch for reasonably new release is usually not very hard - though there are exceptions ... .

Bilbo wrote:

Alberth wrote:Patching against a release is not very useful.

IF (and only if) the patch maintains network compatibility - i.e. most (though not all) GUI improvements would fall in this category - then it is useful to create patch against the release. Then you can use such modified release to connect to unmodified servers too (you just have to override the build to not add "M" to the end of the version)

I am aware of that, but for many patch creators/updaters the notion of "network compability" is too complicated to understand. As a result, I simplified the rules to just exclude releases entirely. It makes sense as in leveling the playing field. Also, the number of patches that are adversely affected is very small, and people understanding the deeper issues will understand why I say it, and also know when it does or does not hold.

Even then, from a development point of view, making a patch against a release is not helping in getting it in trunk.

Bilbo wrote:

Alberth wrote:... in general the patch will fail in trunk due to changes between the release and trunk (making it impossible to merge it into trunk).

Yes, but sometimes patch from release may work within some range of revisions and with reasonably small modification within quite large range of revisions. Creating patch for trunk from patch for reasonably new release is usually not very hard - though there are exceptions ... .

I thought I covered that in "in general ..." already.

I think getting the general idea across that patches and releases should not be combined is more useful.

People without good understanding cannot do anything with "sometimes" and "there are exceptions".
Like above, people that understand working with patches also know that the limits are less hard than I state them.

ok, lets make it in simple words...
1 - i'm not a pro in coding knowledge. Fact!
2 - not even average level!
2 - i've pick this patch and made couple changes (few)...
3 - starts working stable (no crashes) in SP and MP (yes, overriding !!VERSION!! and !!REVISION!! when needed to test in MP)
4 - after many many tests, no crashes, i shared the code that i got, here! (yes, was beta4 at the time - but good in RC1 and in r24000)

now, the 5th point can be:
a) i keep the code to myself as a "precisous opensource" code secret?
b) or i share it to community, that previously shared it to me? (imo, the way to get improved)

probably not a big improvement/changes i made... but i shared it!!! (this line will hit someone)
I didn't wanted that version to trunk/stable... i've only shared some code i think i got stable (PS: "i think" is important), and that i found somewhere in "OpenTTD Development" forums
i use it, even in release versions! So what!!

finally, questions to Alberth:
- have you tested it? (before you post a answer)
- if not, can you explain me better your fundaments? (patch i have changed VERSION and REVISION, patch i shared doesn't)
- better, can you explain any answer without testing it?
- if you're so worried with patched versions (network compatibilities), why those still appears in MP list?
- and the last question, any bug found, can you post it at this thread, right?!

PS: Alberth got my respect because gave huge help to solved some problems when i was compiling using MSYS earlier times.
PS2: When i make questions is because i'm prepared for all possible answers (side effects of working in a newspapper)
PS3: "I'm not big enough to start a war but powerfull enough to fight on it" <<-- quote

JRC/ST2

Edit: typo

ST2 wrote:- have you tested it? (before you post a answer)

What can I find out by testing?
Does it patch cleanly against beta4? I believe you without trying it.
Does it work? You say it does, I did not try it, so I believe you.

So, you have a good working patch against 1.2 beta 4.
And now?

ST2 wrote:- if not, can you explain me better your fundaments? (patch i have changed VERSION and REVISION, patch i shared doesn't)

So you have a modified beta4, and hacked the protection mechanisms to fake it as beta4. Ok.
In a MP game, you now get two things:
- You get an unfair advantage compared to others.
- If you hit a desync, we are the people that get the report at our doorstep, and have to look for days only to come up with nothing, because you are using other software than we think.

The other thing you may want with a patch is inclusion in the OpenTTD program.
However trunk is not the same as beta4, so it cannot be applied.
(Yes I am aware that there is a non-zero chance that it works, but you're talking 1 in 1000 or so, and I am not prepared to download a patch, create a copy of the repository, apply the patch, try to compile, and mess around with improvements with about 0.1% chance of succes. I have better things to do with those hours.)

ST2 wrote:- better, can you explain any answer without testing it?

I just did, didn't I?
In fact, I don't even have source code of any released version at my machine in a state where I can work in it. I only use trunk. There are two simple reasons for it. One is that we make many many releases, so I'd have to keep lots and lots of source code around just in case. Second, if I'd download the sources, setup a working environment around it, apply your patch, compile, try it, it works. Then what?
The only thing I can do then is report "it works". Well, you did that already.
Moving it into trunk does not work in general (see above). My conclusion is therefore it is a futile exercise in the first place.

ST2 wrote:- if you're so worried with patched versions (network compatibilities), why those still appears in MP list?

Because 'network compability' is not something you can detect without actual playing, and getting a desync. If you get one, you know it is not compatible. If you don't get one, either you are compatible, or you did not test good enough. There is no way of being sure the software is fully network compatible at all times. Heck, we had desyncs between servers and clients where all programs were known to be an official version. These bugs can linger for several years before being triggered, just because the specific condition is so rare, it almost never happens. In other words, "I tested and it worked" is just reducing the chance, not eliminating existence.
(And thank you for proving my point about network compability being too complicated to understand for many people.)

ST2 wrote:- and the last question, any bug found, can you post it at this thread, right?!

How does a player or do we know the bug was due to your software changes?
If you fake to be an official version, there is no way to decide the software was actual a different version.
Such bugs just get filed un 'beta4', and we waste hours finding out how the problem may have happened in the official version. If we are very lucky, the crash log gives weird line numbers, and we can see it was actually a faked version, but which patch was added then? It could be any of the patches floating around, including non-published ones.

ST2 wrote:PS3: "I'm not big enough to start a war but powerfull enough to fight on it" <<-- quote

I don't fight wars, it's just a waste of energy and time. Writing this post cost me one hour, time I could have spend more usefully.
I am however willing to explain why I think like I do, and am willing to accept good arguments against it.

Albert