Transport Tycoon Forums

No - share stations as well. Just leave the 'problematic' payment model in place, as complex transfers will not arise on their own in a game without Cargodist or similar.

After the basic infrastructure portion is tackled, another patch that focuses solely on handling transfer payment could be worked on.

I think that this is good idea!
divide et impera
Well... I will try to...
But if anyone with great c++ skills can do it fast - do it! For me is a longrun task

supermop wrote:After the basic infrastructure portion is tackled, another patch that focuses solely on handling transfer payment could be worked on.

I think it should be done exactly the other way around. Fix the problem (transfer payment handling) first (it's a problem in trunk if you transfer via an oil rig), only then introduce a new feature that depends on it.

Yexo wrote:

supermop wrote: After the basic infrastructure portion is tackled, another patch that focuses solely on handling transfer payment could be worked on.

I think it should be done exactly the other way around. Fix the problem (transfer payment handling) first (it's a problem in trunk if you transfer via an oil rig), only then introduce a new feature that depends on it.

Oops ... oil rigs are "stations" without owner, forgot about that one for a moment.

Yexo wrote:

supermop wrote:After the basic infrastructure portion is tackled, another patch that focuses solely on handling transfer payment could be worked on.

I think it should be done exactly the other way around. Fix the problem (transfer payment handling) first (it's a problem in trunk if you transfer via an oil rig), only then introduce a new feature that depends on it.

That's fine too - either way I see the two problems as separate. It could also be desirable to have some better real rather than approximate way to handle revenue even in single player, either adjustable, or just to stop the questions about negative income. There are plenty of interesting new possibilities the author of a revenue patch could explore..

However, no one has written such a patch yet, but someone has written an infrastructure patch that works quite well, and that does not generally have problems using the standard payment model when not used with a destination patch (not yet a trunk feature), and without payer colluding to actively complicate the delivery path.

As payment should ideally be handled by a different patch, those seeking to develop the core function of this patch further should not attempt to alter revenue handling, nor should they be deterred from their work while waiting for a unplanned change to trunk. Instead effort would be best spent on the 'problems' more specific to infrastructure itself. These would be the potential griefing problems, such as how to remove an opponent's train that has been parked across the throat of your station (tangentially: shortly after the creation of Amtrak, the Long Island Railroad actually feared and prepared for the possibility that striking Amtrak drivers would park their trains in the tunnels to Penn station to obstruct LIRR trains, whose crew belonged to a different union, so this case does have at least a conceivable precedent), or conversely, how to extricate one of your trains that has been stranded on a non-cooperative player's network. I feel that these are the more interesting issue to either address, or debate and decide not to address.

supermop wrote:These would be the potential griefing problems, such as how to remove an opponent's train that has been parked across the throat of your station (tangentially: shortly after the creation of Amtrak, the Long Island Railroad actually feared and prepared for the possibility that striking Amtrak drivers would park their trains in the tunnels to Penn station to obstruct LIRR trains, whose crew belonged to a different union, so this case does have at least a conceivable precedent), or conversely, how to extricate one of your trains that has been stranded on a non-cooperative player's network. I feel that these are the more interesting issue to either address, or debate and decide not to address.

For me that's not a problem at all because coop play assume that players play fair wich each other.
If try to realise handling situations like above I suggest to grant some control functions over foreign trains on own tracks such as start/stop, skip current order, etc. Or add special order that enabled only for train on not train owner tracks e.g. "Leave foreign line" or so...

I like all the new features in 1.2, so I bumped this to trunk.
It seems to work for me, no guarantees though - any bugs are probably due to me, rather than the author.

EDIT: Removed-found bug.
Will post replacement

EDIT: Replacement posted - GNU 'patch' left the last line off one file for some reason

FLHerne wrote:I like all the new features in 1.2, so I bumped this to trunk.
It seems to work for me, no guarantees though - any bugs are probably due to me, rather than the author.

btw what is new features?

For some reason, adding "//Comment to stop previous line being left off" works

rsdworker: I was thinking of changes in trunk since r22731 (last version this patch was updated for)

NOTE: dadymax posted an improved version below, with a few fixes (Thanks ). It would be a good idea to use that instead .

Did you test this or just compile?
I ask because I also just made some changes in diff from build 22731 to compile IS2 on last trunk but there a problem: some functions (code constructions) becomes obsolete and some change logics.
Did you investigate this?
I.e. this is _playeable_?
Well, tonight I check this (:

P.S. For example of obsolete things look at 1490 string in diff. There a function HaveHangarInOrderList(Aircraft *v) that was removed from trunk on r20474.

P.P.S. I start fom IS 2.1.1 from repo and update chunk by chunk. For today I have IS2.1.1 on OTTD v.1.0.5 stable (r21280)

dadymax wrote: P.P.S. I start fom IS 2.1.1 from repo and update chunk by chunk. For today I have IS2.1.1 on OTTD v.1.0.5 stable (r21280)

Damn, that's a long way to go. I tend to forget how long ago that is. Probably it might be a better idea to get that diff wrt trunk it was written for. And then write it completely anew for current trunk.

Yeah, the Time is running fast

But another reason to do that - I want to look how oTTD was developed For me is funny to look at old pieces writen of C with a lot of #define's and nearby new code on C++ with hard object-code using

I briefly look to that diff and can say that it should work. I made two small fixes on it. Today evening after my own work I will check playeability with friend

upd: delete patch file because of fixed version below.

Did you test this or just compile?
I ask because I also just made some changes in diff from build 22731 to compile IS2 on last trunk but there a problem: some functions (code constructions) becomes obsolete and some change logics.
Did you investigate this?
I.e. this is _playeable_?

I tested it enough to know that:

The game starts.
I can change menu settings etc. without the game crashing/segfaulting/whatever (failed this a few times )
I can start a new game.
I can share infrastructure with AIs in a game.
I can save the game, and reload it successfully.

What I haven't tested fully is sharing in multiplayer (the important bit ). I'll do that today.

I made two small fixes on it.

Thankyou

Well. It looks like work to me
In custom serv on last trunk+this patch I was make two companies and run trains one companies by rails second companies. Money flow, trains runs... All looks fine. Tests will be longer
Need to take a look to some unequal in IS cost and IS income (see screen). Somehow one thing is bigger than other... Also ability to use foreign train depots is not full - I can't buy train in it. But my train can maintenance there. I think that this thing was right and not needed in fix.

Therefore, appologise for my crude words and scepsis.

Going back to the question about income distribution over companies who transfer cargo among map.

Whats wrong now?
Any company get income by "transfer" feature if it just transfer cargo or get income of transport packet from last pickup to dropdown. I don not see anything unfairness.
Opinions?

And let's trace bugs that we found. Last reports on repo is about two years and some fixed but some not.

dadymax wrote:Whats wrong now?
Any company get income by "transfer" feature if it just transfer cargo or get income of transport packet from last pickup to dropdown. I don not see anything unfairness.
Opinions?

what's "wrong" is that this is not at all what happens now. "transfer" does not generate any income. and if it did, it could be abused.

Eddi wrote: what's "wrong" is that this is not at all what happens now. "transfer" does not generate any income. and if it did, it could be abused.

Well, I did not notice that. In game with my friend we use 2 shared stations under one logic name. That is, one station was for "transfer" things and another one was for longrun income trains. On first station trains have income from "transfer" action.
But we engaged in each own cargoes.
Your cheme is "Produce station" -> P1 -> "transfer station" -> P2 -> "final station" and P2 has full income while P1 got nothing. I understood correctly?

dadymax wrote:Your cheme is "Produce station" -> P1 -> "transfer station" -> P2 -> "final station" and P2 has full income while P1 got nothing. I understood correctly?

Yes, IIRC that's what happens.

Yep, that is. Transfer income is displayed on main window and in vehicle view but on finance window and balance has no effect. Learn this mechanism now...

Upd:
Well... Add two conditions and one line in economy.cpp. Short test show that now transfer pays right. Here is fixed version of Infrastructure Sharing patch. Let say that is IS 2.1.2 Please test it and report it.

ok looks good so how i figure to put Diff on game - its very complicated so there is easy way to do it?