VISIBLE features, that I want to be in OTTD trunk.

[Quark]

Face customization patch

• 

Subsidaries patch — ability to share tracks with other player

• 

Build templates — copy and paste tracks

•     

Route markers

• 

Tramroads

• 

and more…

[Rubidium]

Face customization patch

Horribly out of date; needs to be rewritten completely

ability to share tracks with other player

Horribly out of date; secondly it is a patch of 160 kB with fundamental changes that can cause desyncs, thus it needs a lot of time to do a proper review. Not having comments does not help and causes devs to ignore the patch.

copy and paste tracks

A complete maintainance nightmare in the current form, most likely not MP safe, horribly out of date

Route markers

Not finished (AFAIK)

Tramroads

Not finished

P.S. This is not the way to push stuff into OpenTTD. Several people have tried this before and most have failed. When devs are interested in a patch (or see the real added value of it) and see that the initial quality is reasonable, they will look at the patches.
However patches that are horribly out-of-date or have known bugs or where the author has not said that it is (nearly) finished are no likely candidates.

[gkirilov]

Quark, you are reading my mind. To add one more: the auto-placement of signals patch.

Rubidium, there was time when those patches were up-to-date but the people who made those got discouraged as only a very few of the patches got into the nighlies.

[Ben_K]

I guess its about having them stable enough. I don't know the 'ins and outs' of the main builds however I'm sure you need to not only develop your patch but also when its ready, ensure that it will fit into the current trunk without any major bugs or stability issues. I therefore guess its not easy and people lose steam (Sadly). Bottom line being that if someone made a patch, integrated it to fit without issues, I'm sure the developers would accept it without a question. The question is how many patches reach that state?

[Bjarni]

I guess its about having them stable enough.

stable is needed, but it's not only being stable enough.

when its (the patch) ready, ensure that it will fit into the current trunk without any major bugs or stability issues.

The code also needs to be clean and readable. It will also need to be without memory leaks, not using way too much memory or bandwidth in MP.

Bottom line being that if someone made a patch, integrated it to fit without issues, I'm sure the developers would accept it without a question. The question is how many patches reach that state?

The number of patches that reach a commitable state is not great. Usually patches end up with "it works in the cases that the coder tested so he will not bother to change anything" even if it makes future additions tricky and the code is so messy that it can easily hide bugs. We even had a case of a rejected patch because it would cause desyncs in MP every single time it was used. The coder then stated that it worked for him (in SP) and that we had a f*** up code if it could fail for us and then he left with a message that he would not code any other patches to us.

Having a patch in the MiniIN will not make it more stable and more likely to get it added to the trunk.

We want a pretty stable game and code that is decent to work with and it has the price that we can't accept every single patch that shows up. It's simply not possible to get everything.

Also there is the possiblity that somebody shows up with a patch where we mark it as a bad idea and reject the concept nomatter how the patch is written. It could be patches that ruin the big plan (like a feature on the roadmap) or say making toyland default every the game is started.


I think the best way to make something that should have a fair chance of getting added would be to investigate the code and figure out how to code it. Make some tests if needed and then try to code it. Make use of IRC to contact developers while you code and specially when you are nearly finished. Listen to what the developers say would also help a lot. Also accept the risk of somebody could work on something that will make your patch useles and that it could be rejected because of that. Nobody will get all their patches into the trunk, not even people like me (I usually stop working on them before they are finished when I notice that they went wrong).

[Rubidium]

Rubidium, there was time when those patches were up-to-date but the people who made those got discouraged as only a very few of the patches got into the nighlies.

Maybe up-to-date in the sense of 'applyable' to trunk, but there were either known bugs (face customisation and subsidiaries) or the patch did not comply to the coding style in so many places that the devs did not even think about cleaning it up (copy paste, subsidiaries to lesser extent).

The problem why we are so strict about patches getting in trunk is the fact that debugging takes a lot of time, especially desyncs can take days; if you are really lucky you've found the cause of the desync in half a day.
Secondly coding styles are there for a reason.
Thirdly the developers do this in their own time, so they must be the ones who determine whether to review a patch and commit it, not the users.

[Bjarni]

http://www.tt-forums.net/viewtopic.php?t=30309
At first this sounds like overdoing it, but it's very good for one thing: you should start to wonder about how to ensure that the patch works. The main issue with this approach is that it will take ages to make just one patch. Consider what can go wrong. Can it cause memory leaks. Can it write to an array outside of the allocated size of the array (this can be just as tricky to find as the desyncs). Can it cause desyncs and so on.

If you just change a colour on a button, then it's ok not to test it for hours in MP games to search for new desyncs, but if you add the ability to say place signals automatically, then you will really need to consider how to test for desyncs. I'm not saying that the signal patch causes desyncs (I didn't test). It was just an example of what can go wrong.

[Ailure]

While I'm sad that some patches (spefically Subsidiaries patch, which I really need to look into it's code one of those days) is not in trunk, I understand quite well why they aren't merged.

I seen some other OSS projects where trunk gets very messy as they accept most of the patches, and sometimes it becomes a interesting experience to compile code from trunk and run it.

And of course, Multiplayer is one of the best things with openTTD compared to the original TTD de-synch paradise. I rather be without a feature if it causes de-syncs often...

(To admit though, the feature I want the most from subsidaries is the ability to share tracks between companies. Maybe I should look into making a such patch myself...)

[Celestar]

1) Trams are under development and I guess they'll be included in trunk sooner or later.

2) Route Markers are always a possibility but according to the _author_ they're not yet ready to be included

3) Copy and Paste is a really difficult thing to do to make it MP-safe. If there is such a patch that is remotely stable (MP) and cleanly coded, why not...

4) subsids is _way_ to large a patch for applications. it needs to be broken into smaller chunks. Anyway there is discussion on whether and how we want this included.

5) Face patch. Nice, but what value does it add to the game? Again, if it is clean, why not.

Celestar

[Bjarni]

5) Face patch. Nice, but what value does it add to the game? Again, if it is clean, why not.

It's not a patch with huge value to the game, but it would still be nice to have. The code is cleaned up. I think it can't cause desyncs, but I'm not sure. It does have one issue though. It changes the savegame format without handling loading of the old format. I think the result is that it changes the faces in the savegame into something that will be totally different from what was saved. If somebody decides to write a converter....

[Rubidium]

If somebody decides to write a converter....

That part is already in trunk. However, it is not the same format as in the face patch, thus the face patch needs to be rewritten using the new format. This rewrite would also remove quite a lot of code from the face patch itself because a lot less lines are needed to get and set the different bits of the face.

[VPN-User]

3) Copy and Paste is a really difficult thing to do to make it MP-safe. If there is such a patch that is remotely stable (MP) and cleanly coded, why not...

I wonder why is it so difficult to make it MP-safe? I mean, that patch does nothing more but build on more than one tile at once. Maybe a possible "solution" can be pause the game for a second when placing a large build-template on the map and transfer action to clients tile-by-tile.

But why does placing very long tracks work? There is also built on more than one tile at once...

I have special interest in that patch because building common junctions in OTTD is really causing RSI, especially when you always make huge railway networks like me

[Bjarni]

3) Copy and Paste is a really difficult thing to do to make it MP-safe. If there is such a patch that is remotely stable (MP) and cleanly coded, why not...

I wonder why is it so difficult to make it MP-safe? I mean, that patch does nothing more but build on more than one tile at once. Maybe a possible "solution" can be pause the game for a second when placing a large build-template on the map and transfer action to clients tile-by-tile.

But why does placing very long tracks work? There is also built on more than one tile at once...

I have special interest in that patch because building common junctions in OTTD is _really_ causing RSI.

It has nothing to do with one tile or many tiles. It has to do with ensuring that the same thing will happen on all computers at the same time. Working on one tile at a time is bad because then you will need to send a command (package) for each tile. A solution to minimise bandwidth usage is to make one command and make it call other commands (to execute right away, no network command should transmit anything) to make whatever you want to do. Look at cloning. It's one command that calls other commands (build, move rail vehicles, refit...) and it's still network safe because it's done correctly.

I don't know why the template patch would cause desyncs (didn't read it), but just looking at the screenshot tells me that it sends a command for each tile (the cost animations).

[Rubidium]

But why does placing very long tracks work? There is also built on more than one tile at once...

Because laying long tracks is one single command, pasting a piece of track from some template library means a lot of commands.

Maybe a possible "solution" can be pause the game for a second when placing a large build-template on the map and transfer action to clients tile-by-tile.

That will _never_ _ever_ happen. That would lead to very easy to make denial of service attacks; just by automatically pasting a template every second.

I wonder why is it so difficult to make it MP-safe?

Because copy-paste needs to be ran as a single command because it should either succeed or fail; it should not succeed partly because somebody else thought it was nice to place a road while the copy-paster was actually copying.

[VPN-User]

I don't know why the template patch would cause desyncs (didn't read it), but just looking at the screenshot tells me that it sends a command for each tile (the cost animations).

Hm. How this be done in just one command? I think that' s not possible. So it must be done somehow else. So maybe pausing the game for a seconds isn' t a that bad idea (During pause we could apply tile-by-tile)? Perhaps with a count-down timer to prevent using it all the time and disturb the other players every time.

I just want to make sure that devs are aware that people really need that feature. We got bigger maps, more complex building options etc. and with all this that copy & paste thing becomes more and more necessary to still enjoy all these great features.

[Bjarni]

How this be done in just one command? I think that' s not possible.

Go read CmdCloneVehicle() in vehicle.cpp to see how this can be done.

So maybe pausing the game for a seconds isn' t a that bad idea (During pause we could apply tile-by-tile)?

No command should pause the game. You were just told that

[EDIT] terraforming would likely cause some issues. If it could be copy pasted without terraforming, then we can surely do it with a single command and then we can start talking about how to deal with terraforming later (if anybody gets an idea). The problem would be that it can't estimate how to build a railroad if the hill needs to go away first and it can't lower the hill before it knows what the railroad would cost so it can get an ok to start.

[VPN-User]

No command should pause the game. You were just told that

Sorry, I was still writing when that was posted.

terraforming would likely cause some issues. If it could be copy pasted without terraforming, then we can surely do it with a single command and then we can start talking about how to deal with terraforming later (if anybody gets an idea). The problem would be that it can't estimate how to build a railroad if the hill needs to go away first and it can't lower the hill before it knows what the railroad would cost so it can get an ok to start.

I think I understand what you mean, you mean this new build-on-slopes feature for example. Can the track be built on slope or do we need terraforming? Hmm... What about making copy & paste more strict to circumvent this? I mean, either only paste "overlay" (tracks, roads etc). or copy with terraforming, but then really make the destination area 1:1 the original area.

[Bjarni]

I think I understand what you mean, you mean this new build-on-slopes feature for example. Can the track be built on slope or do we need terraforming? Hmm... What about making copy & paste more strict to circumvent this? I mean, either only paste "overlay" (tracks, roads etc). or copy with terraforming, but then really make the destination area 1:1 the original area.

I didn't mean that. Let's make an example. You want to copy a layout completely without hills (just tracks, signals and bridges). You want to place it somewhere that's not even. There is a hill that is 3 levels high. You can't build a railroad to pass it (wrong slopes). That would be the issue.

I just thought about another issue. What if a nearby town refuses to let you continue because you removed too many trees, terraformed too much? This is no easy task.

[VPN-User]

I think I understand what you mean, you mean this new build-on-slopes feature for example. Can the track be built on slope or do we need terraforming? Hmm... What about making copy & paste more strict to circumvent this? I mean, either only paste "overlay" (tracks, roads etc). or copy with terraforming, but then really make the destination area 1:1 the original area.

I didn't mean that. Let's make an example. You want to copy a layout completely without hills (just tracks, signals and bridges). You want to place it somewhere that's not even. There is a hill that is 3 levels high. You can't build a railroad to pass it (wrong slopes). That would be the issue.

That' s wat I mean with making it more strict. Only paste if destination area is suitable which means it is the same as the source area while the height level is not important.

I just thought about another issue. What if a nearby town refuses to let you continue because you removed too many trees, terraformed too much? This is no easy task.

Simple: Remove that damn stupid town-does-not-allow-thing

Just a joke. No, I wonder how is this handled when destroying town roads (more than one tile at once)?