Two questions...

[didomusicuk]

I want to use rmarkers.grf and copypaste.grf with r17042... neither works. Any chance either will be updated to work with any recent version of OpenTTD? Both seems to rely on older releases.

Also, any chance these two will be integrated into trunk any time soon? Both are very useful additions.

[Yexo]

Both of these have never worked in any official OpenTTD version. They need the patch they were made for.

As for route markers: As far as I know it's very outdated by now.
Copypaste won't be included in trunk (see copypaste topic for why not).

[didomusicuk]

Both of these have never worked in any official OpenTTD version. They need the patch they were made for.

As for route markers: As far as I know it's very outdated by now.
Copypaste won't be included in trunk (see copypaste topic for why not).

Thanks for your help. I have read the relevent official threads for both these GRF's, and I have to say I found them both a little confusing as to what versions are required. Hence this thread.

Sidenote: I've had copypaste working in OpenTTD before now. Can't remember what version I was using at the time though, but I'm sure it was a nightly.

[Yexo]

Sidenote: I've had copypaste working in OpenTTD before now. Can't remember what version I was using at the time though, but I'm sure it was a nightly.

I'm sure it was not. Browse through the topics you find, and most likely there will be some downloadable windows binaries there.

[didomusicuk]

Sidenote: I've had copypaste working in OpenTTD before now. Can't remember what version I was using at the time though, but I'm sure it was a nightly.

I'm sure it was not. Browse through the topics you find, and most likely there will be some downloadable windows binaries there.

Thanks, I will.

Incidentally, can you shed any light as to why the routemarkers thread suggests downloading a nightly only to overwrite core files with those from an older release? Seems pointless.

[SirkoZ]

Both patches have to be updated to work with the current revisions (0-7-2 or r17xxx) of OpenTTD. Perhaps post in their respective threads if anyone would be so kind to update them...

[Yexo]

Incidentally, can you shed any light as to why the routemarkers thread suggests downloading a nightly only to overwrite core files with those from an older release? Seems pointless.

That seems pointless indeed, but if you'd be so kind to give a link to the post you're referring to maybe we could say more.

[didomusicuk]

Incidentally, can you shed any light as to why the routemarkers thread suggests downloading a nightly only to overwrite core files with those from an older release? Seems pointless.

That seems pointless indeed, but if you'd be so kind to give a link to the post you're referring to maybe we could say more.

Sorry, not routemarkers, copypaste patch.

http://www.tt-forums.net/viewtopic.php?p=440743#p440743

This thread is linked from the reworked copypaste patch, as it says you need the original copypaste.grf.

Thread seems to suggest downloading a nightly and then downloading older files. Very odd.

I have to say that I'm really disappointed. A lot of people have done a huge amount of work, lots of dedication has gone into this game from its fans and the people smart enough (and patient enough) to help develop it. Me, I'm just a fan who enjoys playing - I'd never get into the development side.

But I can't help feel that some really useful things are being missed out here. I'd really like to see both these in trunk so other users can enjoy them. I really can't be arsed figuring out how to apply patches and custom-compiling it. I just want to play the game and use some of the great features people are developing. Is that too much to ask? I appreciate there may be some technical limitations but this kind of thing really should be provided as GRF's like everything else. Please, for the sake of sanity, someone make this possible!

[Alberth]

Thread seems to suggest downloading a nightly and then downloading older files. Very odd.

Since I was curious about the copy&paste patch too, I went through the posts in Build Templates (Copy&Paste) (r13911 + 0.6.3 + 0.6.2) and Copy & Paste patch, reworked.

The install procedure is described here.
http://www.tt-forums.net/viewtopic.php?p=463514#p463514
http://www.tt-forums.net/viewtopic.php?p=701469#p701469
what they seem to do is add+replace some files in an OpenTTD installed version. For that, (of course) you need an installed OpenTTD version.

But I can't help feel that some really useful things are being missed out here. I'd really like to see both these in trunk so other users can enjoy them.

With respect to merging to trunk I found these posts:

http://www.tt-forums.net/viewtopic.php?p=734608#p734608 unneeded extra maintenance costs
http://www.tt-forums.net/viewtopic.php?p=777797#p777797 patch is not even close to MP safe
http://www.tt-forums.net/viewtopic.php?p=777867#p777867 patch is neither safe nor interesting, game may become boring

To me, this reads as functionality is doubtful for game play, and the implementation is (very?) buggy.

If an experienced dev can find big holes in the patch in a matter of minutes, that is bad.

As for gameplay, I see the apparent attractiveness of the patch, but I also share the same concern as Belugas, doesn't the game reduce to just having the right collection of templates on your computer, so you can build the whole network in 5 years instead of the 50 you need now? I don't think it would be as much fun.

I also found a lot of 'the program crashed' posts near the end that did not seem to be solved. The development of the patch seems to have stopped at this time.

I really can't be arsed figuring out how to apply patches and custom-compiling it. I just want to play the game and use some of the great features people are developing. Is that too much to ask? I appreciate there may be some technical limitations but this kind of thing really should be provided as GRF's like everything else. Please, for the sake of sanity, someone make this possible!

It is not 'and, ... and ...', it is 'either ... or ... '

What do you prefer, a stable program with somewhat less functionality, or a buggy one that crashes on the weirdest moments with somewhat more functionality.
The devs (now including me as well) prefer a stable program. On the long term that is the only viable route.

[didomusicuk]

what they seem to do is add+replace some files in an OpenTTD installed version. For that, (of course) you need an installed OpenTTD version.

I downloaded the files needed for copypaste to work... those files consist of openttd.exe and all critical lang files for that particular release. There is no point downloading a nightly if you're going to replace these files, since these files represent most of the game core.

With respect to merging to trunk I found these posts:
http://www.tt-forums.net/viewtopic.php?p=734608#p734608 unneeded extra maintenance costs
http://www.tt-forums.net/viewtopic.php?p=777797#p777797 patch is not even close to MP safe
http://www.tt-forums.net/viewtopic.php?p=777867#p777867 patch is neither safe nor interesting, game may become boring

None of these reasons are explained clearly. For example, 1) what unneeded extra maintenance costs? 2) The patch author said desyncs should not occur, and yet a dev came along and wrote it off without even bothering to test it "in the real world", based simply on a quick scan of the patch itself. 3) if all development were based on what the devs found useful and not what USERS found useful, then all software would be useless.

If an experienced dev can find big holes in the patch in a matter of minutes, that is bad.

By the same token, if an experienced dev can't be bothered to test that patch and maybe offer to help iron out any bugs, and be prepared to write the patch off, then that dev doesn't, in my humble opinion, have much right to call themself much of a developer.

As for gameplay, I see the apparent attractiveness of the patch, but I also share the same concern as Belugas, doesn't the game reduce to just having the right collection of templates on your computer, so you can build the whole network in 5 years instead of the 50 you need now? I don't think it would be as much fun.

I appreciate that point of view, but I don't think anyone can really view the game as being about how things are built. If that was the case, it would already be boring, since lots of websites out there offer guides on how to build good stations and networks. The fun of the game is in building YOUR OWN solutions, using YOUR OWN templates, where that's even possible.

What do you prefer, a stable program with somewhat less functionality, or a buggy one that crashes on the weirdest moments with somewhat more functionality.
The devs (now including me as well) prefer a stable program. On the long term that is the only viable route.

I'd prefer a program that doesn't have to trade off that stability for the sake of more features.

[Benny]

You obviously don't know how it is to develop OpenTTD/be an OpenTTD dev, do you?

[didomusicuk]

You obviously don't know how it is to develop OpenTTD/be an OpenTTD dev, do you?

I've already stated that I'm no developer and have no desire to be. I just don't have the time orr patience to devote myself seriously to it. Don't get me wrong here - my first post said that a hell of a lot of work has clearly gone into OpenTTD. Its a wonderful creation with lots of wonderful people doing a lot of wonderful work. It just seems a shame that some co-operation can't help these things along sometimes.

You make it sound like someone is forcing you to develop - if its that bad, don't do it.

[Benny]

You are forcing them.

[Yexo]

None of these reasons are explained clearly. For example, 1) what unneeded extra maintenance costs?

Every new feature adds extra maintenance costs, simply becuase code is never without bugs, so the more code you have, the more likely you are to have more bugs in your code.

2) The patch author said desyncs should not occur, and yet a dev came along and wrote it off without even bothering to test it "in the real world", based simply on a quick scan of the patch itself.

Maybe it wasn't explained in that post, but I'm sure the problem has been explained to (at least some of) the patch developers multiple times. And yes, a lot of bugs can be found by just reading the source code without ever testing it. Of course it's no substitute for testing, but if by reading the code you can already find bugs, that's often a bad sign.

3) if all development were based on what the devs found useful and not what USERS found useful, then all software would be useless.

Then OpenTTD must be useless to you, as I can't recall any feature put in while all devs found it useless.

By the same token, if an experienced dev can't be bothered to test that patch and maybe offer to help iron out any bugs, and be prepared to write the patch off, then that dev doesn't, in my humble opinion, have much right to call themself much of a developer.

So you're saying that we (as devs) should help every patch writer that wants to write a patch for OpenTTD, and include every patch that is written? Let me tell you that it would quickly become a very big mess.

I appreciate that point of view, but I don't think anyone can really view the game as being about how things are built. If that was the case, it would already be boring, since lots of websites out there offer guides on how to build good stations and networks. The fun of the game is in building YOUR OWN solutions,

I agree with you there

using YOUR OWN templates, where that's even possible.

but not here. How is "copying templates" any fun? In my opinion it doesn't matter much whether you or anyone else made the template. Fact is you use a template and don't build it yourself.

I'd prefer a program that doesn't have to trade off that stability for the sake of more features.

That's exactly what I prefer, and that has been one of the reasons the copy/paste patch is not included. Note the "one of", as even if it were stable, it wouldn't be included.
EDIT: above was my original reaction, but I misread your post. I prefer a stable program above one that has some more features. "Not having to trade off stability for the sake of more features" is impossible.

You make it sound like someone is forcing you to develop - if its that bad, don't do it.

Bennythen00b is, as far as I'm aware, not developing for OpenTTD.

You are forcing them.

Can you quit this kind of post? Or if not, enlighten me what's your purpose with creating this post except for making didomusicuk angry?

[belugas]

None of these reasons are explained clearly. For example, 1) what unneeded extra maintenance costs?

The way the feature is coded, ther are lots of duplication in the code. Which means that in order to keep the code sane (both OpenTTD and the feature, once included in trunk), double work would have to be achieve. Thus extra maintenant cost. Do not forget that once the code is merged, it becomes the responsability of the devs to keep it bug free. Even if the bug was introduced by the original writer of the patch. Now, i've heard that the patch has been simplified. Don't know to which extend. But let say that once is enough.

2) The patch author said desyncs should not occur, and yet a dev came along and wrote it off without even bothering to test it "in the real world", based simply on a quick scan of the patch itself.

By real world, of course, we are talking about a game run with the official server and such. That is not always needed. You can have your own little network. That is what Rubidium was refering to. And if HE said that it should desynch, i'd rather believe him than the patch author, mostly because Rubidum has found WAY more desyncs reasons than ANY OF US ALL. Now... would you believe a doctor who performed countless heart surgery or he one that just says that it will be no problem, even if he is visible still in high school?

3) if all development were based on what the devs found useful and not what USERS found useful, then all software would be useless.

There are stuff that obviously, a dev would know better than a user regarding the stability and the coherence of a program. And for your personnal information, in real life, if a user wants a new feature, he has to pay for. IN Open Source world, it's not the same rule. Some users have provided patches that are already in trunk, and quite a lot. But it does not mean that EVERYTHING should go in, simply because SOME users want it. This is not democracy. WE are dealing with the code, WE choose what has to go in or not. IF you want to include stuff, become a dev. For that, you have to spend COUNTLESS of your FREE TIME coding and coding and coding. But you obvioulsy mentionned that it is not the road you want to pursuit. If so, accept the work of those who DO.

By the same token, if an experienced dev can't be bothered to test that patch and maybe offer to help iron out any bugs, and be prepared to write the patch off, then that dev doesn't, in my humble opinion, have much right to call themself much of a developer.

If the patch is interesting, it will be done. If the coder accepts critisisms been addressed and make adjustements, no problem. We did that more than once. If you're not aware of that, take a look at the time line of OpenTTD. You are just spitting out lies and missleading informations

I'd prefer a program that doesn't have to trade off that stability for the sake of more features.

I prefer a stable program that includes well done features in a controlled and safe way. If you want the program to still exist in 2-3 years, even more, that's the only sane way to go.

You want programs that added features a-la-gogo? Look at the patch packs and other MINIin.
The life time of those programs are quite shorter then OpenTTD. I really wonder why.

[Rubidium]

1) what unneeded extra maintenance costs?

What the patch does is add a second different map representation, i.e. double the amount of accessors. That means that for adding e.g. a signal type we would need to update the double amount of accessors. Besides that we would need the double amount of saveload code (we need to load old templates, otherwise we get complaints). So all in all it just doubles any major work to the map's data.

2) The patch author said desyncs should not occur, and yet a dev came along and wrote it off without even bothering to test it "in the real world", based simply on a quick scan of the patch itself.

Patch authors defintion of "no desyncs" is: I have not heard of it desyncing. Patch testers definition of "desyncs": oh, that's normal, it's not the official version and I can't be bothered to report it.
OpenTTD developers definition of "no desyncs" is: there is such thing as no desyncs. Anything is suspectible, however a good review will catch 95% of the desyncs. For the record I am the developer that found the desyncs.
No my question is what "in the real world" means. Apparantly that does not include starting a non-patched server and patched client and then doing the things I need to do to trigger the desync via 'normal' inputs.
For example there have been a number of copy-paste versions where sharing orders between planes and helicopters caused a desync if connected to a unpatched server. I have PERSONALLY desynced a number of people that way. In later versions that has been fixed. The other desync I have also, locally though, reproduced.

Ofcourse claiming that this isn't "in the real world" sounds strange to me.

3) if all development were based on what the devs found useful and not what USERS found useful, then all software would be useless.

If all OpenTTD development were based on patches created by random people with almost know programming knowledge or idea how OpenTTD works, you would not have the stable versions you have now nor the multiplayer you have now. The developers are the gateway that keep the obviously buggy and flawed patches out.

By the same token, if an experienced dev can't be bothered to test that patch and maybe offer to help iron out any bugs, and be prepared to write the patch off, then that dev doesn't, in my humble opinion, have much right to call themself much of a developer.

Ofcourse, claiming that experienced developers don't bother to test patches... How the #$@% do you know what the experienced developers test and do? Who are you to claim that we don't test patches?
The fact that I fracking REVIEW the patch is worth much more than a bit of play testing! Then I report the issues I find to the authors of the patch. Ofcourse this is not helping ironing out any bugs, because I find them which is just the inverse of fixing bugs, right?
I have written of very few patches. Most patches that you think are interesting or important are not finished. Take a look at the copy-paste patch. It contains numerous todos. Or is the job of the experienced developers to take ANY crappy patch and spend a huge amount of time rewriting it from scratch? What about telling the less experienced developers what is wrong and let them fix it? That makes those developers more experienced and in the end is a positive thing. Otherwise there would have been only one experience developer and he stopped quite a few years ago and OpenTTD would have been dead by now.

I'd prefer a program that doesn't have to trade off that stability for the sake of more features.

That is just something that can never be true. Adding features means adding instability and adding unstable/unfinished implementation of features means adding even more instability.