JGR's Patch Pack

[andythenorth]

Therefore there is no point in me spending any of my time making it more palatable to trunk, when I can more productively spend that time making it more palatable to my tastes and those of the people who send me feature requests.

And this basically is the strength of stable patch packs, and of open source generally.

The chances of stable patch packs are reduced by

• complexity in trunk
• features that are poorly implemented at the code level in trunk
• features that conceptually poor in trunk

So eh

[acs121]

Developing a patch outside trunk is always simpler than within trunk. For example, you don't have to worry about compatibility with a previous version (required by trunk for loading a save game into a newer version).

Yes, i know, there always is the compatibility with previous versions problem, and that is one huge one for implementing to trunk things like IS, NRT or NMF.

Backwards savegame compatibility is really not difficult.
Even huge and outlandish patches should be able to fully and completely achieve this.

Policy is more of an issue than technical implementation for things like Infrastructure Sharing.
If everyone of influence agreed on how exactly it should work and wanted that specific implementation in trunk, implementing that and putting it in trunk would be easy.
However there is no meaningful consensus at any level for how exactly it should work, and (to my eyes) there is negligible appetite for the feature at all from the trunk devs. Therefore the probability of it ending up in trunk is effectively 0.
Therefore there is no point in me spending any of my time making it more palatable to trunk, when I can more productively spend that time making it more palatable to my tastes and those of the people who send me feature requests.

I think there's more probability than IS would be included than NRT or even NMF.

[andythenorth]

I think there's more probability than IS would be included than NRT or even NMF.

I'll take that bet. I think there's close to zero probability that IS will be included in trunk.

[Gwyd]

I'm happy to bet that no major features will be added to trunk, with good reasons. But still, this is why I use JGR.

Sent from my SM-G935F using Tapatalk

[Redirect Left]

I'm happy to bet that no major features will be added to trunk.

Almost a guarantee at this stage in development. Getting a new feature into trunk is about as difficult as Trump not making a ridiculous statement for more than 7 days.
Locally I play with a few custom modifications i've not put on the forum, purely because I know there's no point. They wouldn't get picked up into anything major worth revising the code and ironing out the bugs for. Sure fun for me to play with multiple trains per platform, if they fit, instead of one at a time and slowing things down.

[acs121]

Let's not be pessimist though : i posted this link in the NotRoadTypes thread. Read the last lines, and you'll see though there is somewhat a chance that NRT, once established correctly, will move to trunk.

[Auge]

Hello

Let's not be pessimist though : i posted this link in the NotRoadTypes thread. Read the last lines, and you'll see though there is somewhat a chance that NRT, once established correctly, will move to trunk.

No one ever said, that new features will never be included into trunk. For the inclusion they (at least) have to be mature in concept and code. People who are involved in NRT stated several times, that the concept is (partially) broken in its current state. So there is no chance for trunk inclusion until NRT is ready for it.

You can insist on possible inclusion again and again. It will not speed up the development and trunk inclusion. Please be patient.

Tschö, Auge

PS: The statement on the linked page was made only a few months after announcement of NRT. The shortcomings of the implementation wasn't known at that time so it seemed to be possible to include NRT in the next main release (1.. Now we know about the shortcomings and we know, that the next main release (1. gets released in the beginning of april this year. Everyone can draw her/his conclusion.

[acs121]

Read again : "Read the last lines, and you'll see though there is somewhat a chance that NRT, once established correctly, will move to trunk.".

[kamnet]

if there was enough demand for it, i'm sure trunk would already have implemented this.

Nope, trunk requires technical maturity no matter how popular a feature would be.

Just to give you an idea of how serious this is, Cargo dist was the must have patch of all time. It took 5 years of development before it was accepted into trunk.

[acs121]

It surely may not take 5 years to IS to be implemented in trunk. 3 or 4 years, maybe. But Cargodist is a patch much more complex than IS.

[Gwyd]

And you know that because?

Sent from my SM-G935F using Tapatalk

[Tintinfan]

Greetings,


I'm not really sure if this is a bug report or an unfortunate side effect of using daylength, not really noticed this till I started playing with the value at 7 and 14. The values for "running cost" shown in the purchase/train information windows remain fixed, while the actual running cost and "train running costs" in the finances window differ. It appears that daylength either scales actual running cost up or down, making a game harder or easier - but the expected running cost remains the same.

A quick test shows that you get the following results, which make even less sense to me;

Daylength 1 = Actual: 878 / Displayed: 878 (x1)
Daylength 3 = Actual: 2525 / Displayed: 841 (x3)
Daylength 5 = Actual: 1286 / Displayed: 832 (x1.54)
Daylength 7 = Actual: 66 / Displayed: 825 (x0.07)


Is this strange behaviour to be expected, is it a bug or is there a way to keep all the running costs values the same I am missing?

EDIT: Added some savegames, might help anybody that wants to observe in-game.

[Leanden]

Can we stop hijacking JGRs patchpack thread now please.

[Wahazar]

Can we stop hijacking JGRs patchpack thread now please.

Good idea. Some general discussion about patches and trunks can be moved by mods to another thread.

Back to the topic. I tried to check Tintinfan report and discovered, that costs are not applied to the stopped vehicle (na matter which kind of grf, either native vehicles).
Running cost is displayed, but not deduced from player account.

[JGR]

Greetings,


I'm not really sure if this is a bug report or an unfortunate side effect of using daylength, not really noticed this till I started playing with the value at 7 and 14. The values for "running cost" shown in the purchase/train information windows remain fixed, while the actual running cost and "train running costs" in the finances window differ. It appears that daylength either scales actual running cost up or down, making a game harder or easier - but the expected running cost remains the same.

A quick test shows that you get the following results, which make even less sense to me;

Daylength 1 = Actual: 878 / Displayed: 878 (x1)
Daylength 3 = Actual: 2525 / Displayed: 841 (x3)
Daylength 5 = Actual: 1286 / Displayed: 832 (x1.54)
Daylength 7 = Actual: 66 / Displayed: 825 (x0.07)


Is this strange behaviour to be expected, is it a bug or is there a way to keep all the running costs values the same I am missing?

EDIT: Added some savegames, might help anybody that wants to observe in-game.

Thanks for reporting this issue, this is fixed now and will be in the next release.

Back to the topic. I tried to check Tintinfan report and discovered, that costs are not applied to the stopped vehicle (na matter which kind of grf, either native vehicles).
Running cost is displayed, but not deduced from player account.

This is the intended behaviour (same as in trunk).

[Wahazar]

This is the intended behaviour (same as in trunk).

Wow, I tough that this feature apply only for vehicles stopped inside depot. Good to know, that it is possible to keep spare vehicles outside depot at no costs:)

[Redirect Left]

Wow, I tough that this feature apply only for vehicles stopped inside depot. Good to know, that it is possible to keep spare vehicles outside depot at no costs:)

Same. Will start parking unused stock i'll need or reuse later in sidings somewhere!

[username_taken]

If anyone has a compiled version for Mac OSX, I'd be eternally grateful if you could share it with me.
I tried compiling it myself, but unfortunately it got way too complicated for me (I'm a OSX user afterall).

[andythenorth]

I can compile for Mac OS, remind me later this week. This is a one time offer, not a repeat service.

[username_taken]

I can compile for Mac OS, remind me later this week. This is a one time offer, not a repeat service.

That's very nice of you. Don't worry, I'll take good care of the compiled files for years to come