build on competitor canal patch

[xarick]

01-03-2015 - Original post

I'm projecting an idea which would allow water based tiles to store Canal owners, to allow the possibility for different companies to build water based structures such as ship depots, docks or oil rigs, on canals owned by other companies.

The idea came to mind when looking at the possibility of building drive-through road stops on roads of different companies. I'm looking now to implement that concept to canals as well, but also add one extra functionality on top of it.

In practice:
1 - Currently when building a Canal tile on a River tile, the River tile is gone for good. I want to preserve the River tile underneath the Canal tile.
2 - Building a structure (for example Ship Depot) from a different owner than the one that built the Canal on top of a Canal (with or without River underneath).
3 - Removing those structures to allow reverting to the previous tile form without losing track of who owned what at a given moment.

[+] Spoiler

I don't know C++ at all, really, not even the basics, but still tried to look at the code and ask for help in irc when necessary, but at this point, I believe my project is too ambitious and is becoming a bit more complex for my own understanding and for me to explain it to others who are not looking at the bigger picture, but who want to help me. I lack the coding knowledge and lingo you guys use, I don't know how to use the right words when trying to express my ideas, but I believe I have a solid idea of what might be needed to achieve the goals.

I learned that I need to store 2 owners for a tile, and also learned that each owner is stored in bits, in some kind of cell called m1. 5 bits are needed to identify one owner. 10 bits would be needed to identify 2 owners from a tile plus 1 other free bit for storing whether the Canal was built on a River or not. One cell wouldn't be enough. 5 bits were already there, at m1, identifying one owner, I needed 6 more bits.

http://hg.openttd.org/openttd/trunk.hg/ ... scape.html
http://hg.openttd.org/openttd/trunk.hg/ ... _grid.html

I've had to search for free, unused bits by looking at the landscape grid documentation. At first, I thought the entire m3 cell was free to be used, but later, when I found out about the Industry tile class, the chances to make this project viable diminished quite rapidly, as the whole m3 was used.

There was 4 bits free, slashed in two parts at m6 cell, bits 76 and 10 positions. Then there's one special bit which is said to be free, at m1 cell, bit 4 position.

That bit 4 at m1 is used by tiles of class Water, Station (and Object?), and they're all used to store the 5th bit of an owner. I quickly discovered that these bits, though in use, are being used for the same purpose of storing owners, and that they could be compatible with each other.

Once I discovered how to run the game in Debug mode and querying tiles to extract information, it turns out that bit 4 at m1 is being written 1 and 0 at some times, when I was expecting them not to be changed, and the cause was when the Oil Rig was being placed. As an Industry tile, I was wondering why would Oil Rigs overwrite new values at that bit position if the information at the grid was telling me that bit was free.

It took me some days to come up with a patch on my own, with the help of devs from irc chat. I ended up with something that prevents the value of that bit 4 at m1 to be altered when Oil Rigs were being born in that place. It took me two attempts to get it right. On the 2nd attempt I also discovered that the value was being modified not once, but twice.

Unaffect MakeIndustry m1 bit 4 attempt 2.patch

(2.14 KiB) Downloaded 353 times

http://bugs.openttd.org/task/6235

With this problem solved out of the way, I could proceed to give some meaning to that bit 4 at m1 cell.

Had to brainstorm some schemathics as to how I'd be able to store 11 bits of information with only 9 bits. I quickly realized that company bits are stored in the 4 last bits while the 5th bit, the one that is making use of bit 4 at m1 is always a 0. When it is 1, then it means that it is no longer owned by any company, and that means it was either owned by water or by none. I also turned to m6 cell and its 4 free bit positions. I learned that when a canal has no owner, the only way I could store that information was to store it as it was owned by town. Town owner doesn't change the value of the 5th bit.

I was lucky to find that Canals don't have more than 16 different owners. I could store all needed information for one owner by using only 4 bits this way. I just don't know if this is possible to do in code, as an exception to the rule, to store owners only using 4 bits for the case of tiles of type water, station, industry (at m6 cell) (and object?) and only if their water class is canal. For all other water classes, this exception doesn't apply.

As for that bit 4 at m1 cell, I will be using it to identify where that canal was built onto, if on a river tile or if on a non-river, such as sea or ground bare land. I don't need to store the owner of a river or sea, because it is always water. When destroying a canal built on a river, restoring back the river tile will always have the owner water. When destroying a canal built on the ground or bare land or sea, the tile becomes of another class and will get it's owners accordingly, which is none or water, respectivelly.

Because this was turning out too complex, I've worked on the schematics for this owner storage on excel and came up with this illustrative spreadsheet:

canal owner bits table.png

(293.7 KiB) Downloaded 14 times

water construction.xlsx

(44.51 KiB) Downloaded 340 times

So where do I stand now?

- I am looking for a way to store owners as 4 bits and not 5, and treat 1111 as owner_none instead of owner_town. This is to be treated as an exception to the rule, given the condiction that the tile class type is either Water, Station, Industry (and Object?), and that their WaterClass is Canal.
- Also I am wondering how do I store canal owners at m6 though that cell it's split in two parts.


23-03-2015 - update

I notice this whole topic is becoming a mess, so I better start organizing my ideas before everyone gets lost, including myself. Here's my current standing on the whole issue:

- As of this day, the idea of storing two owners for canals is on hold, there was no progress regarding this. My last submission about it was the draft post on 05-03-2015: http://www.tt-forums.net/viewtopic.php? ... 1#p1144092

- Since that day, I paused for two weeks, until I returned on 19-03-2015 with fresh ideas. Allthough related with the topic, whatever files you find submitted since that topic are to be treated as separate project from what has been submitted before my pause.
12-09-2016 - update

Here's what I'd like people to test right now:
- Lock Pricing Adjustments - viewtopic.php?p=1145327#p1145327
- Game Setting for Oil Rig, With Better Layout, Dock and Lock on Competitor Canal on Permanent Rivers v2 r27665 - viewtopic.php?p=1176465#p1176465

17-09-2016
Completed! I was able to do it!

1-12-2017
Please test and tell me what you think:
- build on competitor canal v9 r27932 - viewtopic.php?p=1194669#p1194669

[adf88]

I am looking for a way to store owners as 4 bits and not 5, and treat 1111 as owner_none instead of owner_town.

Road owner is stored this way. See GetRoadOwner/SetRoadOwner.

- Also I am wondering how do I store canal owners at m6 though that cell it's split in two parts.

Just use GB/SB functions to read/write certain bits.

So, it could be like:

Code: Select all

static inline Owner GetCanalOwner(TileIndex t)
{
	assert(GetWaterClass(tile) == WATER_CLASS_CANAL);

	if (IsCanal(tile)) return GetTileOwner(tile);

	Owner ret = (Owner)0;
	SB(ret, 0, 2, GB(_me[t].m6, 0, 2));
	SB(ret, 2, 2, GB(_me[t].m6, 6, 2));
	/* Canals don't need OWNER_TOWN, and remapping OWNER_NONE
	 * to OWNER_TOWN makes it use one bit less */
	return ret == OWNER_TOWN ? OWNER_NONE : ret;
}

static inline void SetCanalOwner(TileIndex t, Owner o)
{
	assert(GetWaterClass(tile) == WATER_CLASS_CANAL);

	if (IsCanal(tile)) {
		SetTileOwner(tile, o);
	} else {
		if (o == OWNER_NONE) o = OWNER_TOWN;
		SB(_me[t].m6, 0, 2, GB(o, 0, 2));
		SB(_me[t].m6, 6, 2, GB(o, 2, 2));
	}
}

Remember that companies are not everlasting! See what is happening inside change_tile_owner_proc functions e.g. ChangeTileOwner_Road.

[xarick]

Forgot to update Landscape documentation. I can't attach any more files to the main topic.

[adf88]

Edit html files by hand, keep the encoding. WYSIWYG editors add a lot of garbage, especially yours.
If you will be publishing a patch, include changes to the documentation too.

Inside landscape.html, I would join the two paragraphs "m6 bits 0..2" and "m6 bits 6..7" into a single "m6 bits 0..2, 6..7".

[xarick]

Draft
old behaviour

Code: Select all

WaterClass: WATER_CLASS_SEA, WATER_CLASS_CANAL, WATER_CLASS_RIVER, WATER_CLASS_INVALID
TileType: MP_STATION, MP_WATER, MP_OBJECT              ; m1 = Oaabbbbb ; m6 = OOXXXXOO
TileType: MP_INDUSTRY                                  ; m1 = XaaOXXXX ; m6 = OOXXXXOO

O = not used
X = in use
a = water class
b = tile owner stored in 5 bits

new behaviour

Code: Select all

WaterClass: WATER_CLASS_SEA, WATER_CLASS_RIVER, WATER_CLASS_INVALID
TileType: MP_STATION, MP_WATER, MP_OBJECT              ; m1 = Oaabbbbb ; m6 = OOXXXXOO
TileType: MP_INDUSTRY                                  ; m1 = XaaOXXXX ; m6 = OOXXXXOO

O = not used
X = in use
a = water class (not canal)
b = tile owner stored in 5 bits

WaterClass: WATER_CLASS_CANAL
TileType: MP_STATION, MP_WATER, MP_OBJECT              ; m1 = Oaacbbbb ; m6 = bbXXXXbb
TileType: MP_INDUSTRY                                  ; m1 = XaacXXXX ; m6 = bbXXXXbb

O = not used
X = in use
a = water class (canal)
b = at m1, tile owner stored in 4 bits; at m6, canal owner stored in 4 bits
c = canal on river flag

[xarick]

I wasn't able to do anything about ownership yet, but I did a patch about rivers and canals.

This patch restores rivers when demolishing a canal that has been built on a river tile. Demolishing a 2nd time will actually destroy the river.

Canal on River.patch

(9.39 KiB) Downloaded 353 times

Also note that for this patch, I used a different bit for the canal on river flag. Instead of m1 bit 4, as indicated in the draft, I used m6 bit 0.

Please tell me what you think of it.

[xarick]

Terraforming Rivers test patch.

[xarick]

Permanent Rivers - incomplete patch

Permanent Rivers.patch

(1.54 KiB) Downloaded 302 times

Permanent Rivers mixed with Canal on Rivers

Permanent Rivers and Canal on Rivers.patch

1st version

(10.52 KiB) Downloaded 435 times

Edit:

Permanent Rivers and Canal on Rivers.patch

2nd version

(10.84 KiB) Downloaded 338 times

Improved error message when attempting to terraform a canal that has been built on a river tile.

[xarick]

Permanent Rivers mixed with Canal on Rivers again

Permanent Rivers and Canal on Rivers.patch

4th version

(10.61 KiB) Downloaded 499 times

Canal on Rivers - allows river tiles to be restored when demolishing a canal that has been built on a river tile, but demolishing the same tile a 2nd time would destroy the river.
Permanent Rivers - forbids rivers from being demolished or terraformed, but canals built on river tiles could be destroyed immediately.
The combination of the two patches - prevents rivers from being demolished alltogether and prevents canals built on river tiles from being destroyed immediately.

3rd version (deleted) - This version improves documentation description and fixes some white lines in relation to the 2nd version. No functionality was altered at all.

4th version - Fixing coding style, ident spacing. No functionality was altered at all.


Lock Pricing Adjustments patch

lock pricing adjustments.patch

(4.27 KiB) Downloaded 371 times

Copy pasted from https://bugs.openttd.org/task/6233

This is a patch that attempts to fix two things:

1 - Pricing calculations for building locks on a sloped river tile, without taking into account the cost for clearing a river tile.
2 - Pricing calculations for building and demolishing locks on a sloped bare land tile, taking into account the cost for building, demolishing and maintaining a canal tile. This canal tile isn't actually built or demolished, but its associated costs are simulated, much in the sense to mimic what happens on the upper and lower tiles of a lock. Objective here is to achieve pricing consistency.


Why do I think this patch is needed:

1 - First issue doesn't become apparent when using default prices without the help of a NewGRF. I used BaseCostsMod 5.0 to expose the problem more clearly. The issue becomes apparent when the parameter setting "build canal, also affects 'canal maintenance'" is set to a much lower value. I used 1/8 for my testings.

2 - Second issue is actually more like an "opinionated fix", to maintaining a consistent pricing scheme. If the value for building a canal was instead so blatantly much higher than the cost for building a lock itself, the flaw would become exposed: building several locks in a row would be cheaper than building a single contiguous canal line.

Lock price for when built on sloped river and bare land tiles


Improved Oil Rig Layout patch

improved oil rig layout.patch

(521 Bytes) Downloaded 331 times

This Oil Rig Layout won't block ships docking when an Oil Rig is spawned in front of another Oil Rig.
Also posted here: http://www.tt-forums.net/viewtopic.php?f=33&t=72670

[xarick]

Dock on Competitor Canal Tile patch

dock on competitor canal.patch

1st version

(4.59 KiB) Downloaded 330 times

Allows the watered part of docks to be built on canals owned by another company.

Known bug:
- could place the watered part on top of a ship depot

dock on competitor canal.patch

2nd version

(4.73 KiB) Downloaded 291 times

Fixed the bug found in previous version
edit: still bugged, now I could place the watered part on top of a lock part built on a canal with no owner

dock on competitor canal.patch

3rd version

(4.82 KiB) Downloaded 357 times

Fixed the previously found bug.
Edit: there's a bug, if company A had a canal under the dock water part of company B and company A bankrupts, the canal doesn't become of owner none.

[xarick]

Game setting for lock on competitor canal

game setting for lock on competitor canal.patch

(3.18 KiB) Downloaded 343 times

Allows or forbids building the upper and lower parts of a lock on canals owned by another company. At the moment, the setting is re-using "allow drive-through road stops on roads owned by other companies" though I would prefer to create a different setting on its own in the future.

Game setting for dock and lock on competitor canal

game setting for dock and lock on competitor canal.patch

1st version

(8.12 KiB) Downloaded 334 times

Same as above, but also mixed with dock on competitor canal (3rd version), and including the dock watered part in the setting as well.
Edit: there's a bug, if company A had a canal under the dock water part of company B and company A bankrupts, the canal doesn't become of owner none.

game setting for dock and lock on competitor canal.patch

2nd version

(8.65 KiB) Downloaded 303 times

2nd version: Fixed previous bug (uses 4th version of Dock on competitor canal)

[xarick]

Dock on competitor canal

dock on competitor canal.patch

4th version

(5.35 KiB) Downloaded 329 times

4th version: fixed bug found on the 3rd version

Game Setting for Dock and Lock on Competitor Canal on Permanent Rivers

game setting for dock and lock on competitor canal on permanent rivers v1 r27205.patch

(18.95 KiB) Downloaded 316 times

This is a mix of several patches together tweaked to have better interaction with each other. They are:
- 1) Permanent Rivers and Canal on Rivers (4th version)
- 1.1) Canal on River
- 1.2) Permanent Rivers
- 2) Game Setting for Dock and Lock on Competitor Canal (2nd version)
- 2.1) Dock on Competitor Canal (4th version)
- 2.2) Game Setting for Lock on Competitor Canal



I'd like to have help on making this line more readable in the code.

Code: Select all

MakeStation(t + TileOffsByDiagDir(d), IsWaterTile(t + TileOffsByDiagDir(d)) ? HasTileWaterClass(t + TileOffsByDiagDir(d)) && GetWaterClass(t + TileOffsByDiagDir(d)) == WATER_CLASS_RIVER ? wc == WATER_CLASS_CANAL ? o : GetTileOwner(t + TileOffsByDiagDir(d)) : GetTileOwner(t + TileOffsByDiagDir(d)) : wc == WATER_CLASS_SEA ? OWNER_WATER : o, sid, STATION_DOCK, GFX_DOCK_BASE_WATER_PART + DiagDirToAxis(d), wc);

I know what it's doing, but the line is just too big for me to insert comments explaining. I don't really know what I can do to make it easier.

quick draft explaining what that line is doing:

Draft

if sea:
sea was removed
restore sea, set owner to water
(maintain canal not on river)

if bare land:
self canal was removed
restore canal, set canal to self
(maintain canal not on river)

if river && canal on river:
self canal was removed
restore canal, set canal to self
set canal on river

if river && canal not on river:
(it's a real river)
maintain river, maintain owner
(maintain canal not on river)

if canal && canal not on river:
(it's not our canal)
maintain canal, set canal to its owner
(maintain canal not on river)

if canal && canal on river:
(it's not our canal)
maintain canal, set canal to its owner
(maintain canal on river)

Code: Select all

/**
 * Make the given tile a dock tile.
 * @param t the tile to make a dock
 * @param o the owner of the dock
 * @param sid the station to which this tile belongs
 * @param d the direction of the dock
 * @param wc the type of water on this tile
 */
static inline void MakeDock(TileIndex t, Owner o, StationID sid, DiagDirection d, WaterClass wc)
{
	MakeStation(t, o, sid, STATION_DOCK, d);

	int t2 = t + TileOffsByDiagDir(d);
	MakeStation(t2, // Decide the owner of the water tile placed under a dock.
		/* Make the owner of the dock tile the same as the current owner of the
		 * water tile.
		 * At this point, the information passed by the previous function has
		 * been prepared in a way which permits the Owner and the WaterClass to
		 * be set to their intended values.
		 * 
		 * A canal tile owned by OWNER_NONE has been made sure to have never
		 * been demolished during preparation, as that is needed to retrieve
		 * its respective owner, whenever it finds a river tile.
		 *
		 * If a river tile is found, it can mean either the previous function
		 * demolished own canal and a river was restored, as per the Canal on
		 * River patch's behaviour, or it is indeed a river tile which, albeit
		 * being demolished, it is kept, as per the Permanent Rivers patch
		 * behaviour.
		 * This is not enough to decide on the owner, but the WaterClass of the
		 * original tile can be used to indicate if there was originally a canal.
		 * If it was a canal, it means the canal was ours, and not from another
		 * owner. If it was not a canal, then it was indeed a river.
		 * 
		 * If a bare land tile is found at this stage, then it is known that no
		 * river was ever originally present, but it could have been a canal or
		 * a sea tile. To figure it out, it resorts to checking the original 
		 * WaterClass of the tile even before the clearance test had happen.
		 * If it was sea, then it sets the owner to OWNER_WATER. If it was a
		 * canal then it knows that only own canals could have been demolished
		 * during the clearance check previously, and also that canals
		 * owned by OWNER_NONE are not demolished. 
		 */
			IsWaterTile(t2) ? 
					HasTileWaterClass(t2) && GetWaterClass(t2) == WATER_CLASS_RIVER ?
							wc == WATER_CLASS_CANAL ? o
							: GetTileOwner(t2)
					: GetTileOwner(t2)
			: wc == WATER_CLASS_SEA ? OWNER_WATER :	o,
		sid, STATION_DOCK, GFX_DOCK_BASE_WATER_PART + DiagDirToAxis(d), wc);
}

Is this explanation and code split clear enough? How can I improve it?


----------
Canal on River

Canal on River v2 r27211.patch

(14.61 KiB) Downloaded 293 times

v2:
- behaviour change: Leveling land with rivers or lakes will not immediately demolish them, they must be demolished first.
- improved documentation description.

Todo:
- better error message "Must demolish river or lake first" (but how?)
- (maybe) store canal on river bit flag on m1 bit 7 for convenience, while switching it's current usage to flag completed industry tiles with m1 bit 4 which is currently free.
- better bit field layout description for water tiles.

[xarick]

Canal on River

Canal on River v3 r27212.patch

(14.98 KiB) Downloaded 325 times

Description:
This patch restores rivers when demolishing canals that have been built on river tiles. Demolishing them again will actually clear the river tiles.
Since v2, a behaviour was changed: Leveling land with rivers or lakes will not immediately demolish them, they must be cleared first.

v3:
- A better error message was added to complement the behaviour change in v2.
- Improved the code a little bit, less tab spaces, lines.

To do:
- (maybe) Store canal on river bit flag on m1 bit 7 for convenience, instead of m6 bit 0. All the affected tile types are compatible, except industry tiles. These are currently making use of m1 bit 7 to flag completed industry tiles, but m1 bit 4 is free for them, which means this flagging could use m1 bit 4 instead. Then m1 bit 7 turns out free to be used to flag canal on rivers.
- Improve bit field layout comments for water tiles in water_map.h

Canal on River v4 r27214.patch

(21.71 KiB) Downloaded 307 times

v4:
- No actual functionality has been changed, from v3.
- Moved canal on river bit flag from m6 bit 0 to m1 bit 7.
- Moved completed industry flag from m1 bit 7 to m1 bit 4, and added a conversion for old savegames.
- Updated the documentation regarding these changes.
- Minor code improvements.

To do:
- Improve bit field layout comments for water tiles in water_map.h

[xarick]

Game Setting for Dock and Lock on Competitor Canal on Permanent Rivers

game setting for dock and lock on competitor canal on permanent rivers v3 r27214.patch

(30.65 KiB) Downloaded 315 times

v2: (not posted)

v3:
- Better integration with Scenario Editor and Magic Bulldozer for demolition of River tiles.
- Unified behaviour for Canal placed on River tiles to fix a bug related to Magic Bulldozer which was allowing immediate demolition of canals, regardless if there was a River underneath, causing the water part of a dock tile that were supposed to have been placed on a river tile to get the wrong owner.
- Improved code, simplified some descriptions.
- Moved canal on river bit flag from m6 bit 0 to m1 bit 7.
- Moved completed industry flag from m1 bit 7 to m1 bit 4, and added a conversion for old savegames.
- Updated the documentation regarding these changes.

To do:
- At the moment, the setting is re-using "allow drive-through road stops on roads owned by other companies" though I would prefer to create a different setting on its own in the future.

Code: Select all

MakeStation(t2, wc != WATER_CLASS_CANAL ? OWNER_WATER : wc == WATER_CLASS_CANAL && HasTileWaterClass(t2) && GetWaterClass(t2) == WATER_CLASS_CANAL ? GetTileOwner(t2) : o, sid, STATION_DOCK, GFX_DOCK_BASE_WATER_PART + DiagDirToAxis(d), wc);

Code: Select all

static inline void MakeDock(TileIndex t, Owner o, StationID sid, DiagDirection d, WaterClass wc)
{
	MakeStation(t, o, sid, STATION_DOCK, d);

    int t2 = t + TileOffsByDiagDir(d);

	/* Make the owner of the dock tile placed on water the same as the current
	 * owner of the water tile. In this way, we can reset the owner of the
	 * water to its original state when the dock gets removed. Note that when
	 * this function is called, there may or may not be water currently at the
	 * tile. Extra checks are necessary to set the intended owner.
	 * Old WaterClass | Current Water | Intended Owner
	 * ---------------+---------------+--------------------
	 * Canal          | Canal         | Competitor/None/Self
	 * Canal          | None          | Self
	 * Canal          | River         | Self
	 * River          | None          | Water
	 * River          | River         | Water
	 * Sea            | None          | Water
	 */ 
	MakeStation(t2, // Decide the owner of the water tile placed under a dock.
			wc != WATER_CLASS_CANAL ? OWNER_WATER
					/* Canal owned by OWNER_NONE have not been removed previously. */
					: wc == WATER_CLASS_CANAL && HasTileWaterClass(t2) && GetWaterClass(t2) == WATER_CLASS_CANAL ? GetTileOwner(t2)
							: o, sid, STATION_DOCK, GFX_DOCK_BASE_WATER_PART + DiagDirToAxis(d), wc);
}

game setting for dock and lock on competitor canal on permanent rivers v4 r27218.patch

(32.54 KiB) Downloaded 385 times

v4:
- New game setting "Allow docks and locks on canals owned by competitors" for docks and locks
- No longer re-using "Allow drive-through road stops on roads owned by other companies" setting for this purpose
- Added a conversion for old savegames defaulting this setting to Enabled.

There's a bug, related to Canal on River: I am setting canal on river too early for industries, and that is causing assertion.

[xarick]

Canal on River

v5 (https://bugs.openttd.org/task/6277)
- Documentation clarity.
- There was a problem with v5, I was setting canal on river too early for industries, and that was causing assertion.

v6 (not posted)
- Documentation clarity.

Canal on River v7 r27221.patch

(21.58 KiB) Downloaded 293 times

v7 (https://bugs.openttd.org/task/6277):
- Fixed the bug found on v5.
- No actual functionality has been changed since v3.

To do:
- (maybe) Improve bit field layout comments for water tiles in water_map.h


Game Setting for Oil Rig, With Better Layout, Dock and Lock on Competitor Canal on Permanent Rivers

game setting for oil rig, with better layout, dock and lock on competitor canal on permanent rivers v1 r27221.patch

(34.74 KiB) Downloaded 330 times

This is a mix of several patches together tweaked to have better interaction with each other. They are:
- 1) Game Setting for Dock and Lock on Competitor Canal on Permanent Rivers v4
- 1.1) Game Setting for Dock and Lock on Competitor Canal (2nd version)
- 1.1.1) Dock on Competitor Canal (4th version)
- 1.1.2) Game Setting for Lock on Competitor Canal
- 1.2) Permanent Rivers and Canal on Rivers (4th version)
- 1.2.1) Canal on River v7
- 1.2.2) Permanent Rivers
- 2) Improved Oil Rig Layout

- In addition, Oil Rigs also become part of the same game setting used for docks and locks, and they may be spawned on competitor canals if allowed.

[xarick]

Game Setting for Oil Rig, With Better Layout, Dock and Lock on Competitor Canal on Permanent Rivers

game setting for oil rig, with better layout, dock and lock on competitor canal on permanent rivers v2 r27655.patch

(34.53 KiB) Downloaded 282 times

- updated to resolve conflicts when building on r27655
- still does the same as v1 viewtopic.php?p=1146747#p1146747

[xarick]

build on competitor canal

build on competitor canal v1 r27655.patch

(71.23 KiB) Downloaded 388 times

This is a rework of what I used to call "Game Setting for Oil Rig, With Better Layout, Dock and Lock on Competitor Canal on Permanent Rivers", hopefully with better coding than before, but also complemented with few more things.

Trying to summarize everything it does:
1) Major feature: Canal Owners, it allows everything that is a canal or was built over a canal to have a 'canal owner'. Stuff like Canal, Ship Depot, Dock, Buoy, Lock, Oil Rig, Object, if built on a canal or if it is a canal, will have a 'canal owner'.
- Querying these tiles will display 'Canal owner:' to retrieve the respective owner of that canal.
- Added a game setting allowing or disallowing building over canals of competitors.
- Savegame conversion.

2) Another semi-major feature: Permanent rivers, which mean, rivers are indestructible, unless cheating or in the scenario editor.
- Demolishing a canal that was built on rivers will restore the river.

3) Less relevant stuff:
- improved Oil Rig Layout, to prevent close Oil Rig spaws from blocking ship access to neighbour Oil Rigs.
- improved Lock pricing and infrastructure counting, to achieve better consistency.

build on competitor canal v2 r27655.patch

(71.22 KiB) Downloaded 297 times

v2
- Fixed documentation typos.

[xarick]

build on competitor canal

build on competitor canal v3 r27656.patch

(93.95 KiB) Downloaded 314 times

v3

Added three semi-major features that are aimed to ease water-based construction:
- Auto-Lock: When building a line of Canals crossing compatible inclined slopes, Locks are automatically built on them.
- Auto-Canal: When building Buoys, Docks and Ship Depots on land, Canals are automatically built underneath them. Locks were already doing this.
- Auto-Terraform: When building Buoys, Docks, Ship Depots and Aqueducts on some slopes, the terrain is automatically terraformed to allow placement. Note that some slope combinations may not be automated and placement can fail.

build on competitor canal v4 r27656.patch

(94.8 KiB) Downloaded 311 times

v4

Minor changes:
- Auto-Terraform: Allow Ship Depot placement for one more slope combination.
- Docks: Forbid placing Docks near the edge of the world. Ships would never be able to access it.

build on competitor canal v5 r27656.patch

(97.29 KiB) Downloaded 275 times

v5

Added a game setting for an already existant feature:
- Permanent Rivers: 'Allow removal of rivers' setting added under 'Limitations' in the list of game settings. Can be turned on or off. Loading old savegames will treat it as enabled.

[xarick]

Test build.

Build requires SSE2 capable processor. Couldn't run on Athlon XP 2700+
[00:34] <Samu> everything points out to SSE2 instructions being required to execute it on this system, which this cpu doesn't support
[00:34] <Samu> what's different from the build that are created on openttd.org and the ones created with visual studio?
[00:36] <Samu> is there a way to create non-SSE2 builds with visual studio?
[00:36] <Samu> i dunno how to ask it
[00:45] <+glx> compile farm uses VS2010, and SSE2 is default since VS2012
[00:45] <+glx> https://msdn.microsoft.com/en-us/librar ... .140).aspx
[00:45] <+glx> but you can modify it
[00:51] <Samu> ah, thank you very much, that's what I missed
[00:52] <Samu> also the reason openttd.org 1.6.1 still runs here

[xarick]

build on competitor canal v6 r27816.patch

(97.29 KiB) Downloaded 350 times

v6
- Updated to resolve a conflict when patching after trunk r27785
- Updated savegame version to resolve a conflict when patching after trunk r27778