Include new patches in exitsing versions

Got an idea for OpenTTD? Post it here!

Moderator: OpenTTD Developers

Post Reply

Should patches in dev section be added soon to the official ottd versions?

Yes, after all end users will be able to test them also
6
26%
No, they will make the already clean game bugged
5
22%
The question u are asking shouldn't have been asked
12
52%
 
Total votes: 23

vinaximus
Traffic Manager
Traffic Manager
Posts: 135
Joined: 23 Sep 2004 12:10
Location: Nepal, Kathmandu

Include new patches in exitsing versions

Post by vinaximus »

There are so many patches i saw in the dev section. I think some of these should be added to coming versions of openttd. Even though they might be buggy, they will be open to end users for testing.
Good day building rails
Yexo
Tycoon
Tycoon
Posts: 3663
Joined: 20 Dec 2007 12:49

Re: Include new patches in exitsing versions

Post by Yexo »

I hope you realize a poll like this won't change anything. Patches that have one or more known bugs won't be added until the bugs are fixed. Even then they might not change OpenTTD in a good way.

Also, as long as the patches are available in the dev forum they are open to end users for testing.
Rubidium
OpenTTD Developer
OpenTTD Developer
Posts: 3815
Joined: 09 Feb 2006 19:15

Re: Include new patches in exitsing versions

Post by Rubidium »

Existing versions, e.g. 1.0.5, are finished and will never be updated. If they are updated they become new versions. These updates are, usually new, patches and as such new patches get introduced in future versions.

Ergo, the request it totally bogus. Existing versions will never be updated and new patches already flow into future versions. But only when both the author of the patch and the main OpenTTD developers agree that it is finished and bug free.
User avatar
MagicBuzz
Tycoon
Tycoon
Posts: 1354
Joined: 15 Feb 2003 17:32
Location: Vergezac, France

Re: Include new patches in exitsing versions

Post by MagicBuzz »

In one hand, may some patches should be added faster (such as big patches -IS, CargoDist, advanced timetables, etc.) as they need a lot of work from the vonlonteer to maintain it against the trunk, especially when trunl bumps comes with deep code changes such as GUI or new object model.

Because of this, many "clean" patches got abandonned, and I think in those cases, the dev team may try to implement some patch without waiting for a too long time. Those patches should be separated into small parts to help the devs to integrate it to the trunk and test each part separately.

In the other hand, dev team is small, most of the devs are just coding for a few hours a week. Most of them actually work on other patches, and they all have to maintain the trunk against reported bugs and other asked for features that are requiered to keep OTTD compatible with TTDP (I think about the GRF specification).

So a small effort may be possible, but it's absolutely impossible that a patch can be integrated as soon as it is released. We can't take the risk of having a unstable game nor unmaintainable code.
Rubidium
OpenTTD Developer
OpenTTD Developer
Posts: 3815
Joined: 09 Feb 2006 19:15

Re: Include new patches in exitsing versions

Post by Rubidium »

Those supposedly clean big patches usually have some serious (conceptual) issues that the author didn't think about yet, or didn't care about yet. E.g. infrastructure sharing has, as far as I'm aware, not have a sane way of preventing your vehicle to get stuck onto someone else's network without a way to get it from there except (maybe) teleportation. Yes, it works for many but getting it to destroy multiplayer games (i.e. crash your trains) by griefers just because they easily can isn't something we should aim for.

Likewise the advanced timetable patch does have some serious unneeded duplication of strings (54 strings which can be done by 4 and a few lines of code). Besides that it hardcodes string locations making it fail to work correctly with large fonts (or some translations).

Cargodist, for example, fails (or failed) to work nicely with unordered stops. A feature that has been in OpenTTD for many years to reduce the number of needed orders. With cargodist you'd need to add manual orders for many more stations if you're modelling a local stopper train. By experience I'm fairly certain this is definitely going to cause much complaints if it gets added that way; you can show a patch as often as you like and add it to as many (custom) builds as you like, but only when it gets added to trunk people start to complain about conceptual problems with their playing style. The people playing the patch/patchpack want that particular patch so badly that they ignore any inconveniences and/or conceptual bugs and are happy with many workarounds, but the "general" public generally isn't.

And yes, that makes us look very picky... but we rather try to keep the (conceptual) bugcount low so people actually report bugs than saying: heh, it's a buggy program, they probably know about it and I don't want to search 500 bug reports. Whereas with a few bug reports it's more likely to get bug reports quickly. Besides that some patches have tried to push themselves in basically the "massive feature freeze" just before branching a new stable branch. Adding a massive feature at that moment is just not the right moment.

Finally, I know for a fact that parts of the cargodist and advanced timetable patch have already leaked into trunk. However, the patches are so big that reviewing them is quite hard, which is why we generally like a set of smaller patches. And... if the patch author can't be bothered to keep maintaining their patch, how can we expect them to at least be responsive when it comes to bugs in their code?
User avatar
MagicBuzz
Tycoon
Tycoon
Posts: 1354
Joined: 15 Feb 2003 17:32
Location: Vergezac, France

Re: Include new patches in exitsing versions

Post by MagicBuzz »

Wow, thanks for this long and clear response :)

So here is a small suggestion to help patch autors and dev team to work arround this subject.

May a dev (or some) could spend a few time to :
- Write on the patch thread "yes, a dev took a look at this piece of s***, and here is the list of why we won't integrate it into trunk as this"
- May give some tips on how to solve the problems

Actually, I already wrote some patch, several were very small (group info, town rating in town list, etc.) and some where bigger (timetable based separation).
Most of the time I was discouraged after a few months because I had the impression the dev team wasn't interested at all by my patchs. I know, especially yourself, looked at those patches, but most of the time I was confused about the feedback you gave : I have to admit sometimes, I absolutaly didn't understand what about you where complaining. I think several other autors got the same problem. May be because english is not our native language, or, I think, because we don't know the game code as much as you, so when you tell us "this won't work because ...", we just don't understand which part of the code you're speaking about.
That's why I suggest someone could spend more time to help autors to get their patch conform to the dev style/game spirit.

I tell this because of the IS patch, by exemple.
=> The current lack of this patch is that a player that rent his rails to another company can change the layout of his rails and get lost the opponement trains, or make theim to crash. Ok. You're right, when playing on network, this is a really bad idea.
There are several ways to fix it, or at least prevent most of the cases. First one is to make "readonly" the tiles the opponement PF reserved. This way, it's impossible to change a track a vehicle is actually using. Second one is to use a special GUI that allow a user to confirm or refuse changes on the track as soon as a vehicle he owns uses it. There are certainly many other different (better?) solutions. But here is the problem : if the autor rewrite large portion of the code and the dev team still think it's insufficiant (or to hackish, slow, etc.), the autor could get mad. Also, when I mention reserved track of the PF, some autors (such as me) just have 0 skills about PF : they just can't realise themselves the needed fix.

That's why I think it could be interresting that dev team spend a piece of time to help autors to fix their patches.
When I see that, most of the patches actually got rewritten many times, I think it's really a lack of time, and everyone may saved time if dev team was participating to these devs.

PS : I don't say you actually don't spend time doing this. I just think you may spend more time to do this (and may be update the wiki to help autors to help you on your work : several weeks ago, I actually tried to see on what dev team was working on, but comparing the svn log to the wiki, I have to admit there is absolutaly not any mention about what you actually do. May be with updated FS and wiki, autors should help you fixing bugs or updating trunk instead of rewriting patches that can't be integrated into trunk ;)
User avatar
planetmaker
OpenTTD Developer
OpenTTD Developer
Posts: 9432
Joined: 07 Nov 2007 22:44
Location: Sol d

Re: Include new patches in exitsing versions

Post by planetmaker »

MagicBuzz wrote: May a dev (or some) could spend a few time to :
- Write on the patch thread "yes, a dev took a look at this piece of s***, and here is the list of why we won't integrate it into trunk as this"
- May give some tips on how to solve the problems
It's not like exactly that isn't done, is it?
MagicBuzz wrote: Most of the time I was discouraged after a few months because I had the impression the dev team wasn't interested at all by my patchs. I know, especially yourself, looked at those patches, but most of the time I was confused about the feedback you gave : I have to admit sometimes, I absolutaly didn't understand what about you where complaining. I think several other autors got the same problem. May be because english is not our native language, or, I think, because we don't know the game code as much as you, so when you tell us "this won't work because ...", we just don't understand which part of the code you're speaking about.
That's why I suggest someone could spend more time to help autors to get their patch conform to the dev style/game spirit.
Oh dear. So you complain you may not understand what is being said as your native language is not English? Boy, have a guess of how many of the official devs are English native speakers. Learn English, if you think reading comprehension is your issue.
Or you think you don't understand because you do not know the code base? Oh well. It comes from actually writing. Taking-in feedback. Re-writing. Looking for the clues given. Or asking what exactly was referred to, if understanding still fails. Do you expect that we write a lengthy treatize on why something won't work and is in my eyes conceptually flawed to every person who just thought to write a short hack? Where do you draw the line?
I tell this because of the IS patch, by exemple.
=> The current lack of this patch is that a player that rent his rails to another company can change the layout of his rails and get lost the opponement trains, or make theim to crash. Ok. You're right, when playing on network, this is a really bad idea.
The infrastructure sharing has been discussed in length when it was still updated and feedback was not scarce. All these arguments have been given. The repo was NOT abandoned on lack of feedback or discussion but on grounds that some fundamental gameplay issues didn't find a good answer, neither by the patch author(s) nor by any of the many discussion partners.

Also. what do you think, we don't rewrite our patches? It works exactly the same. Just this repeated review is then not done in a tt-forums thread and it possibly goes unnoticed...
MagicBuzz wrote:several weeks ago, I actually tried to see on what dev team was working on, but comparing the svn log to the wiki, I have to admit there is absolutaly not any mention about what you actually do. May be with updated FS and wiki, autors should help you fixing bugs or updating trunk instead of rewriting patches that can't be integrated into trunk ;)
Flyspray is always up to date. Patches for bugs posted there are always welcome. Other than that: following IRC discussions sometimes helps, too. But you don't honestly don't excpect every dev to make a tt-forum announcement on every idea he might get - whether or not it will see something come from it or not?
User avatar
MagicBuzz
Tycoon
Tycoon
Posts: 1354
Joined: 15 Feb 2003 17:32
Location: Vergezac, France

Re: Include new patches in exitsing versions

Post by MagicBuzz »

My intent was not to offend you.

I just say my feeling. Some time ago I got some answers like "take care at the code style there are unseless spaces in your patch".

After 3 or 4 updates where I tried my best to remove spaces, I still got that reply.
I spent several hours doing this, where the dev could update my file in 2 seconds as he did know which spaces he didn't like.
Finaly I found that Visual Studio replaced every 4 spaces with a tab, so even after fixing the spaces manually, I still got the tabs when editing the file again.
I think this exemple is a good exemple, as the patch was very small, ready to trunk, tested, network safe, etc. but I was stopped just because 2 seconds of help a dev didn't gave me.

You can say I should learn how to work Visual Studio before posting patches. You may also give me 5000$ a month to code patches. I do this as a hobby, don't ask us for professional skills.

My feeling is that devs sometimes forget we are not professionals coding a commercial game, and sometimes the accompaniment isn't the one we may expect.

This feeling does engage only myself, and it's only a feeling. I repeat, my intent is not to offend you or reproach anything to you.
User avatar
planetmaker
OpenTTD Developer
OpenTTD Developer
Posts: 9432
Joined: 07 Nov 2007 22:44
Location: Sol d

Re: Include new patches in exitsing versions

Post by planetmaker »

I'm not offended. Rather something between amused ("oh, this discussion again!") and disappointed. Mostly because if your words carried out mean you value your free time and ease of getting your ideas into trunk over our time. Which is definitely fine from your POV - but as we all do this also in _our_ free time for our fun it's not quite how it works.
MagicBuzz wrote: You can say I should learn how to work Visual Studio before posting patches. You may also give me 5000$ a month to code patches. I do this as a hobby, don't ask us for professional skills.

My feeling is that devs sometimes forget we are not professionals coding a commercial game, and sometimes the accompaniment isn't the one we may expect.
I say that you should be able to handle your tools. If they fail you use other tools. But yes, so-to-say professional - grade patches ARE expected. If you feel you don't want to do that - just don't. It's a hobby for all of us. We're all happy to help, but don't demand help and don't expect anyone else to babysit you and cleanup your mess.
I dare say working properly on patches is also well feasable for people who never had an IT education - especially if it comes to petty things like proper whitespace usage. Not caring kind of sends the message how much you might care about fixing real bugs...

Oh, yes: the OpenTTD wiki even has a script somewhere which automatically fixes the whitespace issue, if run on the source repo. Which then goes back to: use the tools properly and the proper tools to help you.
dihedral
Tycoon
Tycoon
Posts: 1053
Joined: 14 Feb 2007 17:48

Re: Include new patches in exitsing versions

Post by dihedral »

i do not understand why some patch writers are under the impression that they are having a hard time trying to get their patch into the code base.
what do they expect? just write a piece of code formatted to their liking or implemented their way as they do not invest time to find possibly better implementation approaches?
and then they complain that someone tells them that their implementation is not good, or that the formatting does not fit the projects formatting style!

if people expect that writing a patch (or an entire program) is an easy task and does not include to-do's which are no fun and/or involve work nobody likes doing, then they are under the wrong impression.
personally i feel responsible for every patch i have written (and was accepted), and in fact I do feel bad if i am not the one to spot the mistake or fix the bug (yes Rubidium, you have embarrassed me a few times that way by fixing bugs i should have taken care of, but actually that asks for a huge "Thank You" :-) ).

of course, writing patches can be (and is a lot of the times) a bunch of fun. But they are expensive (time wise) and often something can take years until it's ready or implemented correctly.
if you lack patience, or you cannot handle (positive and negative) criticism, etc. - chances are high you should in fact never ever write a patch for any project.
vinaximus
Traffic Manager
Traffic Manager
Posts: 135
Joined: 23 Sep 2004 12:10
Location: Nepal, Kathmandu

Re: Include new patches in exitsing versions

Post by vinaximus »

Yes, its true, the game will become buggy and unstable. I have been playing OTTD regularly since very earlier versions, and as an end user, i didn't feel that the game is buggy (like some other Open Transport games), so fixing bugs could always be second priority.
If most of the developer's patches are added soon to the existing version, the developers will be encouraged also and the users will also be happier. Not really complaining (infact i am thankful and greatful to OpenTTD team). But it is just a suggetion. one patch that I feel could be integrate are : New stations GUI

Thnx
Good day building rails
dihedral
Tycoon
Tycoon
Posts: 1053
Joined: 14 Feb 2007 17:48

Re: Include new patches in exitsing versions

Post by dihedral »

vinaximus wrote:If most of the developer's patches are added soon to the existing version, the developers will be encouraged also and the users will also be happier.
It is a very nice try, but with that concept for project management you would quickly hit a dead end.
a) the developers who would be encouraged are only those developers who write a patch. The developers who need to be encouraged are those who maintain OpenTTD - the official developers of the project. These are the people who keep OpenTTD an active project, and make sure you have a stable game.
to put it even worse: They are the ones who have to put up with users constantly saying 'I want ...' or 'Why is ...' and 'Do this ...' or 'Do that ...'

b) the project is not about making users happy. and definitely not at all costs (e.g. unstable game, unmaintained patches, more user complaints or bug reports).
and i am sure it's a pain up the rear end having to listen to a number of complaints and reading some of those bug reports.


if you change your viewpoint to the perspective of project management, community building, quality assurance, project maintenance, bug fixing, ... any official role actually - i hope you will understand that posts like the one above (which i consider to be a 'i want ...' post) to actually not be encouraging to those who do all the work.
Yexo
Tycoon
Tycoon
Posts: 3663
Joined: 20 Dec 2007 12:49

Re: Include new patches in exitsing versions

Post by Yexo »

Beaten to a reply by dihedral. While I agree with his post I'll still leave my answer below:
vinaximus wrote:Yes, its true, the game will become buggy and unstable. I have been playing OTTD regularly since very earlier versions, and as an end user, i didn't feel that the game is buggy (like some other Open Transport games), so fixing bugs could always be second priority.
The game doesn't feel buggy because fixing bugs has always had a high priority.
If most of the developer's patches are added soon to the existing version, the developers will be encouraged also and the users will also be happier.
If adding more patches also means introducing more bugs the end users will not be happier. Keep in mind that most of the end-users have never seen the development forum so they don't really know what they're missing out on. As such, keeping the game bug-free will result in more happy users than adding a few new features but also introducing bugs.
one patch that I feel could be integrate are : New stations GUI
And why do you feel it could be integrated? Did you study the patch to find inconsistencies and bugs? Did you look at the source code to see if any new code introduced by that patch could perhaps be coded in a more general way so it's also useful in other places? Or did you just use a pre-compiled build with that patch included and decided you like the looks of it?
MagicBuzz wrote:I just say my feeling. Some time ago I got some answers like "take care at the code style there are unseless spaces in your patch".

After 3 or 4 updates where I tried my best to remove spaces, I still got that reply.
I spent several hours doing this, where the dev could update my file in 2 seconds as he did know which spaces he didn't like.
Finaly I found that Visual Studio replaced every 4 spaces with a tab, so even after fixing the spaces manually, I still got the tabs when editing the file again.
I think this exemple is a good exemple, as the patch was very small, ready to trunk, tested, network safe, etc. but I was stopped just because 2 seconds of help a dev didn't gave me.
I hope you don't mind me taking this as example as well, but if you have trouble understanding any hints given to you, feel free to ask for a better explanation. Like in this case, if you really can't find the spaces ask for help on how to spot them (use a text editor where tabs/spaces are visualized).
The same goes for other problems, it's not doable to give a very long explanation of why something won't work every time, so we try to be as clear as possible without taking an hour for every answer. If you don't understand a reaction, feel free to ask for a better explanation.

About a patch not being accepted when the coding style (including wrong spaces) is not ok: Where should we draw the line if not at perfection? Perfectly adhering to the coding style (for every case there is a coding style) isn't so hard, and if we would accept patches that don't comply directly the code would become a mess real fast. A little space there didn't matter, so why does an extra line here? Who cares I use // in one place and /* in another to start a comment? Why care about the difference between "char *tmp" and "char* tmp"? Who cares about "int a=3+b?3:2;" instead of the version with more spaces "int a = 3 + (b ? 3 : 2);"? You see where this is going?

So why doesn't the dev fix those little problems (after all it was only a few spaces)? This time it might only be a few spaces, but if the dev fixed it your next patch would also be one with wrong spaces. And see my argument above, if he can fix some spaces why not fix some other coding style issues? And if those can be fixed, why not fix some more fundamental problems too? And before you know it, the dev who was supposed to be just reviewing your patch is rewriting it from scratch. The "your" in these lasts sentences is to be taken very liberal, and does not apply to you (=MagicBuzz) directly, but as a more general remark.

From a non-dev point of view I know how annoying it can be if you keep being told that your patch does not comply with the coding style. You could just ask TrueBrain how often my patches were wrong at first. However after some time you get used to it and patches get accepted without problems, and a while later you find yourself to be a dev.

Also please note that I have no idea who reviewed your patch and kept complaining about spaces, it might be myself or any other dev. That doesn't change my reply above in any way.

Since my reply become longer than I anticipated, I'll summarize it shortly: Reviewing patches takes time, fixing a patch from someone else takes even more time. That's why generally we try to review only and let the fixing be done by the original patch author. That way not only does he learn how to fix it, it also saves time for the dev (so he can review more patches / code more features / fix more bugs).
vinaximus
Traffic Manager
Traffic Manager
Posts: 135
Joined: 23 Sep 2004 12:10
Location: Nepal, Kathmandu

Re: Include new patches in exitsing versions

Post by vinaximus »

dihedral wrote:
vinaximus wrote:If most of the developer's patches are added soon to the existing version, the developers will be encouraged also and the users will also be happier.
It is a very nice try, but with that concept for project management you would quickly hit a dead end.
a) the developers who would be encouraged are only those developers who write a patch. The developers who need to be encouraged are those who maintain OpenTTD - the official developers of the project. These are the people who keep OpenTTD an active project, and make sure you have a stable game.
to put it even worse: They are the ones who have to put up with users constantly saying 'I want ...' or 'Why is ...' and 'Do this ...' or 'Do that ...'

b) the project is not about making users happy. and definitely not at all costs (e.g. unstable game, unmaintained patches, more user complaints or bug reports).
and i am sure it's a pain up the rear end having to listen to a number of complaints and reading some of those bug reports.


if you change your viewpoint to the perspective of project management, community building, quality assurance, project maintenance, bug fixing, ... any official role actually - i hope you will understand that posts like the one above (which i consider to be a 'i want ...' post) to actually not be encouraging to those who do all the work.
I just posted a suggestion, I am sorry if it felt like a 'I want' post. I apolozise to anyone who felt discouraged. I have and will always praise the OpenTTD Developers who really and volunteerly work silently so hard to make such a wonderful piece. I did not really mean to change anything and actually "I WANT TO see OpenTTD alive forever".

Thnx
Good day building rails
dihedral
Tycoon
Tycoon
Posts: 1053
Joined: 14 Feb 2007 17:48

Re: Include new patches in exitsing versions

Post by dihedral »

Now that is a post one does not see that often :) nicely said.

I'll take that as a thank you to all who contributed to the project just so i can feel included :P

@yexo: you should stiky that post ;)
Kogut
Tycoon
Tycoon
Posts: 2493
Joined: 26 Aug 2009 06:33
Location: Poland

Re: Include new patches in exitsing versions

Post by Kogut »

I think that in general it goes like this:
- devs are doing things interesting for them + fixing bugs
- people are making patches in areas undeveloped due to lack of interest of devs
- devs are not interested in checking patches changing things boring for them
- devs are against including not reviewed patches, because they prefer to keep OpenTTD stable and not change it in crashing heap of untested code.

(it is possible to replace boring by: not interesting, useless etc)

By the way, what I can do to help including more-height-level to trunk? Testing (disasters for example)? Profiling? Sth else?

EDIT: Place to check activity of devs
Correct me If I am wrong - PM me if my English is bad
AIAI - AI for OpenTTD
Post Reply

Return to “OpenTTD Suggestions”

Who is online

Users browsing this forum: No registered users and 1 guest