Transport Tycoon Forums

You don't...
This was discussed before I put it in.

My reason for putting it in is that it adds a little extra to the game - you can tell which routes have low traffic.
My arguement for not excluding it because it couldn't be turned off, was that aside from the graphical change (the grass) it does nothing.

If, on the other hand, the patch caused a slowdown in train speed, then I would remove it unless it could be disabled.

Alright. Here's the current news.
This pack is undergoing heavy reconstruction, from the ground (trunk) up right through.
There is, as yet, no patchfile because I'm still working on this, and I'm running into a LOT of problems. So BE PATIENT and if anyone asks when I'm putting one out, they're to slap themselves with a wet fish, because there's no way to do that over the internet. YET.

This is what's known so far:
Diagonal Level and Clear - barring unforseen clashes, this patch (two patches, actually) WILL be included.
Airport Close and upgrade - will remain in the pack, provided my suspicions are not wrong (which is that it clashes with the above in one place. Still working on that.)
Grass Growth on Old tracks - POSSIBLY not making it in due to not being disableable, despite the fact that aside from a small graphic change, it does nothing.
Improved reliability - WILL be included
Build while paused in Scenario Editor - WILL be included, even though it isn't really needed, because I found some use for it.
Reduced Tree Growth - This is in a state of extreme uncertainty right now. I want to include it, but I need to fix some issues first, that are not trunk related.
Caternary over 3rd rail - for the Japanset. This too is uncertain, but for a different reason - not everyone uses it. However, if no one minds seeing caternary over monorail as well, then it's a certain.
Autoload face - WILL be included
No Air Crashes - WILL be included
Query Land Shortcut - WILL be included
More Airports - MAY be included after further testing with some of the above patches
Transfer with Shift-Click - WILL be included
Save to trunk - WILL be included, upon making it compatible with CargoDist (See below)
Improved Timetable Management - I'm sorry to say, this will NOT be included.

Patches of special note:

CargoDist - there is a high probability that this will actually be the base of the patch. How it will actually be done is the latest trunk-cargodist patch will be applied against corresponding trunk, and then the patch will be build from there. As of now, it is only a POSSIBILITY

Copy and Paste & Infrastructure Sharing - Don't misinterpret what I'm saying here - they're both good patches. But at this time, I'm not willing to support them, nor include them. In the case of IS, this is because of numerous conflicts with the rest of the patch, and when I have managed to successfully patch it in, a lot of crashes.
As for Copy and Paste... I'd like to include it. I really would. But I think the OpenTTD Developers are right on one point - it takes too much away from them game. They may not have said it exactly like that, so here's a better explanation.
When the patch is done, if I've read it correctly, it'll allow the use of pre-made templates. This means to me, that anyone could download these templates and build a network, having done almost nothing. No planning, no forethought, just a clump of templates together. And I can see that leading to complaints to whoever made this or that template, about it not working, etc.
I don't think it's a fair advantage. In a network game, it should be disabled, no argument. In a single-player game, until it can support NoAI (Or vice versa) I think it should ALSO be disabled. Because the AI cannot use it. And for a truly single-player game, with just the human player, I think people need to learn to build networks their way. Not off a template.
In short... it doesn't take much time to learn how to do it. The OpenTTDCoop site has all kinds of examples, as does Owen's Transport Tycoon Terminal. It's not too hard to pick up some ideas from them and do it. Yes, it'll take a bit longer - but if you're not using build while pause (Something I'm guilty of...) then just plonking down a pre-built chunk smacks of cheating.
Sorry to anyone who was expecting me to include it, but I won't.

Finally, please bear in mind that this post is not a final say! I can and will revise this several times over the next few weeks while I finish making my tests and experiments with all these patches. So stay tuned.

Could I suggest one patch? Smallmap and Minimap Zoom? A newer version can be found here: http://fickzoo.com/fonsinchen/patches/ (smallmap-zoom-in_rxxxxx.diff has zoom in and zoom out)

Smallmap zoom, as previously said, is included in CargoDist.
If I decide not to use CargoDist as the base, then I'll consider adding it to the list.

Yes, I was thinking of that when you wrote that CargoDist was only a probability. Also, good idea to use trunk-cargodist and build from there. Saves A LOT of conflicts.

Actually, it's because I can't stand GIT as a version control system. HG I don't mind, aside from the annoying seemingly randomized string of characters that represents the revision.
SVN is clean and simple, and has just R#####, which makes it far easier.

Plus trunk-cargodist I can match to trunk revisions more easily.

People are welcome to submit their requests and even complaints that I'm not including such and such a patch, or that they don't want some other patch. At this stage, as I've said, nothing is set firmly in stone - only firmly written in the current potential outcome.

Gremnon wrote:Actually, it's because I can't stand GIT as a version control system. HG I don't mind, aside from the annoying seemingly randomized string of characters that represents the revision.
SVN is clean and simple, and has just R#####, which makes it far easier.

I agree, but making an SVN diff is so easy.
Just use these commands: which automatically generates an SVN diff file.

The issue remains that I still have to checkout from a GIT repository, and it seems to take far too long, and take up far too much space to suit me, which is where, IMO, HG wins out - it's a little slower than SVN, true, but you don't have to check out so much, and seems to offer at least similar capabilities to GIT.

Gremnon wrote:take up far too much space to suit me

I've also noticed that. Lots of random folders and files which really don't need to be there. I say SVN because it's quick and painless, and easy for someone new to version control.

And limited HD space - The finished patches for the pack, and the Linux Pre-compiled builds are all made on my laptop, which has highly limited space and resources, so I have to be as economical as possible. I'm hoping that with a possible distro change from Ubuntu Karmic to Slax, I might be able to save even more space, but we'll see what happens, as I'm still working on how to do that.
Also, if I do change, it'll mean I'll be able to provide Debian packages as well as RPM packages. I've previously gone against actually using packages, especially RPM until I learned more about it recently, but I'm going to start making them too when there's a finished pack - which make still take some time yet.

I can provide debian packages for you. But you can easily assume that anyone running Ubuntu/Linux OS should be able to/know how to compile.

While that's true, it's not always the same - look at Gentoo, for example. There's no way I could provide anything but source for Gentoo.
Also, no offense to you in this, but I'd prefer to make the packages myself. I'm trying to learn how to provide my own Launchpad PPA, and if I can manage that, then Debian users and users of any distro based off it, can grab easy updates - also, I'm toying with the idea of providing unmodified nightly builds through it too. In RPM as well, if I can, but that'll have to wait. The main reason is though, that I can sign the packages with my PGP key, thus helping verify that it's a trusted package.

If I could do all that twice, once for DEBs and once for RPMs, then that's a major part of the Linux community outfitted with not only nightlies of OpenTTD, but easy access to updates of the patchpack too - and that could prove to be helpful to both the patch pack and OpenTTD itself.

Gremnon - Just a comment re:no copy/paste. Your reasoning about AI not being able to use it is only somewhat valid, yes they can't use these potentially downloadable templates but isn't the AI itself designing all of it's construction based on hardcoded templates?

this project gets better and better... great! i have a small suggestion. i don't remember the name of the patch or diff file, or the thread (sorry ) but it s regarding the new grf window. i had another patch some time ago that had it. it's a newgrf handling window. it's very very practical. you have on the left side all your data folder grfs and on the right the games grfs. and you can change, move, load, everything in very little steps. it's a very confortable tool. if there is not very much to work at it, i think it worths. but you should try it to see

Bye and thank you very much all for your great work on this project!!!

As you you know from the copy and paste thread im very pro that patch. But actually ican easily see your Arguments against it hitting trunk/ ur patchpack! Maybe the solution simply is to make it a cheat? That means people like i wouldnt need to play with very old and outdated builds, i use magic bulldozer anyway. And people that thinks it a cheat could simply avoid it by not turning it on...

Sensation Lover wrote: it's a newgrf handling window. it's very very practical. you have on the left side all your data folder grfs and on the right the games grfs. and you can change, move, load, everything in very little steps.

It's called NewGRF GUI window and it's an awesome tool. Gremnon, could you include it?

Not without it being updated to trunk, I'm afraid. If I understood how on earth nesting worked, then I might be able to get some of it working, but as it is, it's not something I can do. Sorry.

As to C&P - yes, I imagine in a way, you could say the AI is using templates, but to me, it seems more like their 'templates' change depending on terrain, costs, vehicle types and other things - saved templates wouldn't. Unless of course, they modified the land underneath to be flat or hilly in the right places, but again, that's the terrain changing, not the template.
I would say making it available as a cheat would be a step in it's favor, at least to me - but the problem then remains that a lot of people would use it, and no doubt some would complain because you can't use it in multiplayer, thus bringing the idea into question again.

There's also another potential problem I see, that I've only just realised.
If you take my analogy of dynamic templates that the AI uses, the human player can do this as well - we, or at least I, often steal little ideas from screenshots we see, the OpenTTDCoop site, and so on. The AI libraries were written by players, to mimic the player, which essentially means the AI is also taking from those screenshots, just in a different way. So far it's even.
Now if you introduce a series of prebuilt templates that would allow someone to just plonk down a few stations, junctions, depots and then they build trains. How much of that is really theirs? Also, can the AI replicate that exactly?

There's arguements both for and against it, but for now, I don't really have much in favor of including it. Some conflicts in patching are also inconveniencing me, which makes it a little difficult to properly test.

I couldn't agree more. C&P really doesn't belong in patchpacks. It's a nice tool for personal use, but it really only takes away from your skills as a builder/player.

I wouldn't say it doesn't have a place in patchpacks - just that it should be considered carefully.

Update, by the way. The base of the patchpack is going to be CargoDist, for certain. And as said before, it'll be the trunk-cargodist against matching trunk, because then we have sane revision numbers.

Great! Should bugs with cargodist in GPP be reported here, or at the CargoDist thread.