Copy & Paste patch, reworked

[jaank]

Is there any chance to get it working under 1.0.1?

[Anon]

I use this similar patch.

[Klaatu]

Too bad that similar patch hasn't been updated in over 6 months. I would have liked to have seen that other patch go somewhere, but it appears that adf88 has given up on it.

At least Bilbo has updated this one to close to 1.0. Oh, BTW, thank you Bus for supplying the binary; I tried compiling myself but was unsuccessful.

[Anon]

I may post my updated diff for that patch. I successfully compiled 1.0.2 with it.

[Muzzly]

copypaste_win32_nomusic_r19692.zip [3.96 MiB]

Thanks for binary.

I found an error. Start a new game with 1900 date. And then press CTRL-C.

Error message:
"Assertion failed at line 231 of c:\documents and settings\bus\desktop\cp 19692\src\rail.h: railtype < RAILTYPE_END"

[alex505]

Is there a simple way to get this working on the latest openttd version? 1.0.3?

[ChillCore]

Is there a simple way to get this working on the latest openttd version? 1.0.3?

Yes.
Get the source for OpenTTD 1.0.3, apply the version Bilbo posted for 1.0.0 and recompile. I have not tested if it applies cleanly but there should not be to many conflicts if any.
The 1.0.x branch is only bugfixes backported from trunk.
New features and codechanges introduced in trunk are expected in 1.1.0.

[jez]

This patch is down on http://wiki.openttd.org/Requested_features as 'rejected'. Whilst it may be some way off, is there a reason why it has been rejected in principle? I know some people consider it cheating, but many of us consider it a crucial part of the game (if good track building isn't to be tedious!) it could still be a feature which is included but disabled by default. Network games could also tell clients to disable this feature if the server admin didn't want people using it, and the client would refuse to enable it. Why, in principle, has it been rejected? If it hasn't, can I change it back on the wiki to a percentage?

Oh, and before people start getting pissy with me and saying I should use the search function, guys, I assure you I have read all of this thread and I don't see a reason to list it as 'rejected' on the wiki page. 0% progress, maybe, but I'm talking about the principle here. I see 'it's very complex and would take a long time', which is grounds for 0%, but not grounds for 'rejected'.

[Alberth]

This patch is down on http://wiki.openttd.org/Requested_features as 'rejected'. Whilst it may be some way off, is there a reason why it has been rejected in principle?

Who says the wiki states principle decisions?
The wiki is changable by everybody, so its content is sort of what the last person that changed the page, was thinking.

I don't see a reason to list it as 'rejected' on the wiki page.

It depends on what you talk about. The current implementation versus the global idea. The former is really rejected, the latter has a few fundamental problems as you have read. If you want to make progress with the feature, I believe your time is better spent finding a solution for those problems, rather than discussing the difference between 'rejected' and '0% and going nowhere'.

[Rubidium]

It doesn't matter how often you say that the current implementation is not acceptable, they ALWAYS explain that as "the idea is rejected". I've tried to fix this numerous times, but each time it gets changed to "rejected" again... so I can't be bothered anymore.

Furthermore that wiki page is crap as it's out-of-date, incorrect and just plain pointless. However, removing it will mean people will re-add it and as such it's futile as well.

[Klaatu]

It doesn't matter how often you say that the current implementation is not acceptable, they ALWAYS explain that as "the idea is rejected". I've tried to fix this numerous times, but each time it gets changed to "rejected" again... so I can't be bothered anymore.

It's sad when even an OpenTTD Developer can't be bothered anymore to try to get this feature in trunk because of the pushback from the other developers. To me C&P is the number one new feature I would want to see in trunk, beyond all the other popular patches out there. I've read the threads, but I just don't understand the attitude of those opposed to such a feature. Perhaps this opposition is one of the reasons that development on all the C&P-type patches have ceased since they see no hope in it going beyond its current "rejected" status.

So, for now, we'll have to make do with the kindness of those who keep patches such as this one if not up-to-date at least compilable against trunk. And I will continue to look forward to the day someone starts further development of this or one of the other C&P-type patches.

[Alberth]

It doesn't matter how often you say that the current implementation is not acceptable, they ALWAYS explain that as "the idea is rejected". I've tried to fix this numerous times, but each time it gets changed to "rejected" again... so I can't be bothered anymore.

It's sad when even an OpenTTD Developer can't be bothered anymore to try to get this feature in trunk because of the pushback from the other developers.

It is sad when words of a developer get pulled out of context, and make it look like Rubidium is talking about the patch, while in fact he is discussing his attempts to make the wiki reflect the truth about the state of this patch. (That is, the patch in its current form is rejected, not the basic idea of being able to copy/paste pieces of land.)

[ChillCore]

It's sad when even an OpenTTD Developer can't be bothered anymore to try to get this feature in trunk because of the pushback from the other developers.

I think you have misunderstood.

... the current implementation is not acceptable ...

Read: The way the patch is written now is not acceptable for trunk inclusion.

... they ALWAYS explain that as "the idea is rejected". I've tried to fix this numerous times, but each time it gets changed to "rejected" again... so I can't be bothered anymore.

Read: Every time he has tried to explain that the current implementation is not acceptable, it is understood as it will never be included in trunk. He stopped trying to explain.

I've read the threads, but I just don't understand the attitude of those opposed to such a feature. Perhaps this opposition is one of the reasons that development on all the C&P-type patches have ceased since they see no hope in it going beyond its current "rejected" status.

Some people like it, others do not.
The idea is not rejected ... reread what Rubidium has written.
Many features that have made trunk in the past have been rewritten several times before they got accepted. So will this patch until it is written in a way that is acceptable for trunk inclusion ...
(eg. Diesel smoke patch was not in trunk until it included a switch to turn the behaviour off and included a setting for normal behaviour.)

EDIT: Alberth was faster but I will post it anyway.

[Dante123]

the most recent rewrite is here anyway: http://www.tt-forums.net/viewtopic.php?f=33&t=45488
as far as i know this is the most recent attempt to get it programmed in a clear style that is suitable for trunk. so if you want to put your hopes on one of those versions, try that one

[Rubidium]

It doesn't matter how often you say that the current implementation is not acceptable, they ALWAYS explain that as "the idea is rejected". I've tried to fix this numerous times, but each time it gets changed to "rejected" again... so I can't be bothered anymore.

all the C&P-type patches ... its current "rejected" status

Thanks for providing proof for my claim that people can't wrap their head around the fact that the "current" patch can be "rejected" when the idea behind that patch is acceptable. "Rejected" in the case of this patch is more like not accepted because it is utterly unfinished and buggy; as long as a patch is riddled with "todos" I see no reason to accept that patch as a finished product worthy of (trunk) inclusion. In any case, the author has never finished it... so don't blame us for not including it! Why should we care about something we don't need ourselves when the person that does need it himself does not care about it enough to actually finish the patch?

As I said in the thing you quoted: it is not rejected, it is deemed unfinished by the author and as such he has not presented it as a finished product for us to include in trunk. It is the "morons" that have no clue that translate "unfinished" into "rejected" and then it becomes a self-reinforcing self-full-filling prophecy.


For example PBS has been under development for over a year as a separate patch. When he was more or less pleased with the result he contacted us and we reviewed his stuff, which caused many improvements but still took a long time. All known bugs were fixed as well as anything we could think of. Nevertheless, once it got included into trunk many bugs in it were found so it needed another half year of "love" to get everything working right. The same will hold for all and another other major patches; we once took a someone finished patch and still had to work for weeks on it to get it acceptable for trunk, which was time we could not fix bugs or improve trunk in any other way. So we don't quite like to have to rewrite a whole patch (from basically scratch) to get it included; we "offload" that work to the patch developer. Ofcourse when the patch developer doesn't care about fixing/finishing the patch it (eventually) dies, like this patch is doing.

[Klaatu]

It doesn't matter how often you say that the current implementation is not acceptable, they ALWAYS explain that as "the idea is rejected". I've tried to fix this numerous times, but each time it gets changed to "rejected" again... so I can't be bothered anymore.

all the C&P-type patches ... its current "rejected" status

Thanks for providing proof for my claim that people can't wrap their head around the fact that the "current" patch can be "rejected" when the idea behind that patch is acceptable.

Perhaps I misunderstood you, but it's hard to understand how when you yourself said 'they ALWAYS explain that "the idea is rejected"', which sounds like you're saying "they (the other developers) ALWAYS explain the idea (of C&P) is rejected...so I can't be bothered anymore (trying to convince them)". Then just now you say "the idea behind the patch is acceptable", which seems to directly contradict what you said previously!

"Rejected" in the case of this patch is more like not accepted because it is utterly unfinished and buggy; as long as a patch is riddled with "todos" I see no reason to accept that patch as a finished product worthy of (trunk) inclusion. In any case, the author has never finished it... so don't blame us for not including it!

Who said anything about blame? I have nothing but admiration for all the developers and for all the hard work that must have gone in to this game in it's current form! I think it's wonderful what you all have been able to accomplish. I also have a lot of admiration for the authors of patches such as these C&P patches, but of course would have no idea myself if this or any other patch is trunk-worthy or not.

Again perhaps I have missed it, but in all other C&P threads I've read, and I think I've read them all, I can't remember a single instance until now where any developer has said the idea of C&P is acceptable. In fact it seems to me the very opposite has been true, where no matter what such a feature would never be accepted in trunk. I was speaking of the idea of C&P, not this particular implementation, or any other for that matter. While I might have misunderstood you, it seems there have been plenty of misunderstanding going on then, not just on my part.

Bottom line, though: it is good to hear (for the first time, at least for me) that if the right implementation of a C&P type patch were to be written it would be considered for inclusion in trunk. Thanks.

[planetmaker]

Bottom line, though: it is good to hear (for the first time, at least for me) that if the right implementation of a C&P type patch were to be written it would be considered for inclusion in trunk. Thanks.

He said the very same thing here

[Klaatu]

He said the very same thing here

If you were trying to be funny, you failed. If not, well, you still failed.

[Rubidium]

Bottom line, though: it is good to hear (for the first time, at least for me) that if the right implementation of a C&P type patch were to be written it would be considered for inclusion in trunk. Thanks.

Yup, never said it..

And for what it is worth, some good bits from the earlier copy-paste patches have made it into trunk in some form or another, e.g. "CommandStruct", which is now known in OpenTTD as "CommandContainer".

[Yexo]

Please stop the mud-throwing and keep this discussion civilized. All concerned parties have received a pm.