Feature #670

Basic version

Added by Hirundo about 10 years ago. Updated almost 10 years ago.

Status:ClosedStart date:2009-12-08
Priority:HighDue date:
Assignee:-% Done:


Target version:-


Instead of trying to prune IS, I suggest working the other way around and create the most basic version of IS possible from the ground up. It should only contain the minimum amount of code needed. I think that boils down to the following:

- 4 boolean settings to enable sharing for rail/road/water/air
- Accessors (IsInfraUsageAllowed) to replace current hard-code calls to IsTileOwner() etc.
- Code to handle changes in sharing settings and bankruptcy.
- Necessary updates to NPF/YAPF

If it's not in this list, it isn't essential and it should thus NOT be included. Examples:
- GUI window.
- Sharing Fees.
- DoCommands
- News messages

We could then focus on maintaining the quality of this smaller patch and thus (hopefully) getting it into trunk more easily. To facilitate this, it has to be created in parts. I suggest using git for this, if possible.

total.diff Magnifier - total patch file (51.9 KB) Hirundo, 2009-12-24 19:09

is-patches.zip - zip file containing all incremental patches (33.5 KB) Hirundo, 2009-12-24 19:09

is-patches.zip (37.5 KB) Hirundo, 2009-12-26 19:30

total.diff Magnifier (57.2 KB) Hirundo, 2009-12-26 19:30

Associated revisions

Revision 14513:53df6537a51d
Added by Hirundo about 10 years ago

[IS] Import patches up to 'signals' from issue #670


#1 Updated by Hirundo about 10 years ago

Attached is a zip file containing a series of patches that implement this. These are created in such a way that more than half of them can be applied without impacting existing behaviour in any way.

How to maintain this in the future (hg patch queue repository?) will have to be discussed on IRC.

Note that they are not yet in a fully completed FS-ready state, further refinement and testing is needed.

#2 Updated by Hirundo about 10 years ago

Just another thought; we could base the 'normal' IS on top of this. It could be split several patch files to be applied on top of these. Else we'd be maintaining these patches and the big IS side by side, thus fixing all bugs twice.

#3 Updated by planetmaker about 10 years ago

As on IRC: these patches definitely make sense as a patch queue on top of a trunk repo. Basing the real thing [TM] on top of these small nearly non-invasive patches, is a sensible idea then, too and makes the whole thing probably quite easy maintainable and easier to commit into trunk in smaller chunks, if there's someone who can be bothered to do so ;-)

Despite its kind funny nature I then propose to create a hg repo of the patches dir for all involved patches - even though the diffs there are then diffs of diffs.

#4 Updated by Hirundo about 10 years ago

#5 Updated by Hirundo almost 10 years ago

  • Status changed from Feedback to Closed

This is exactly what we have now.

Also available in: Atom PDF