Distant-join-stations (in trunk)

[ColdIce]

It doesn`t ! When I release the mouse it just building the station! Firt I build a station without holdin CTRL, then lets say on 5 tiles away I want to build another station I press CRTL, drag the station and instead of that pop-up it just planting the station!

[ColdIce]

Found the problem! Is not CTRL key ! Is ALT key !

[Frostregen]

Yeah, if i remember correctly:
In mini-in, ctrl was for "separate" stations, so you could build 2 stations adjacent.

[MJS]

Frostregen, is the 'distant stations'-part of this patch still in development? Now that the adjacent stations have been taken care of, it'd be nice to see the other half in as well

[Frostregen]

It is finished...
Needs an update to current trunk though...

[MJS]

Finished in the sense that it works as a patch - but not that it will be taken into the trunk, apparently. Which would be nice - although I really appreciate the current rush forward in both Ottd and the Patch, it's always nice if the basic features of the two keep up with one another, so that non-expert users can easily make the switch...

Besides, I believe Kaan's wonderful Ottd-builder allows for only one diff at a time in the process, and I already wanted something else in...

[chrissicom]

Awesome waited for this for a long time there are a few conflicts with r10916 but that's only because other things have been added as well so it shouldn't take too long to resolve those conflicts.

[chrissicom]

Ok, doesn't seem so easy because I get the following error:

In command.h the following is added

Code: Select all

Index: src/command.h
===================================================================
--- src/command.h	(revision 9840)
+++ src/command.h	(working copy)
@@ -200,6 +200,14 @@
 int32 DoCommand(TileIndex tile, uint32 p1, uint32 p2, uint32 flags, uint procc);
 bool DoCommandP(TileIndex tile, uint32 p1, uint32 p2, CommandCallback *callback, uint32 cmd);
 
+typedef struct CommandContainer {
+	TileIndex tile;
+	uint32 p1;
+	uint32 p2;
+	CommandCallback *callback;
+	uint32 cmd;
+};
+
 #ifdef ENABLE_NETWORK

When I try to compile this in MSVC I get:
error C2220: warning treated as error - no 'object' file generated
warning C4091: 'typedef' : ignored on left of 'CommandContainer' when no variable is declared

I also just noticed this error:
2>..\src\station_cmd.cpp(1428) : error C2065: 'distant_join' : undeclared identifier
2>..\src\station_cmd.cpp(1431) : error C2065: 'joinStationIndex' : undeclared identifier

I don't know why I get this error, it seems well defined and there were no errors applying the .diff file with TortoiseSVN.

[DaleStan]

The offending code reads, once all the stuff unrelated to the error is removed

Code: Select all

typedef struct CommandContainer;

Remove the typedef, or use it to define a type.

[chrissicom]

Removing typedef from the line fixes the error but I still have another error which I couldn't resolve yet. As far as I can see it is definded properly with the lines the patch adds.

Code: Select all

2>..\src\station_cmd.cpp(1428) : error C2065: 'distant_join' : undeclared identifier 
2>..\src\station_cmd.cpp(1431) : error C2065: 'joinStationIndex' : undeclared identifier 

[Frostregen]

You may check if the included headers have changed, so it is not visible within this file anymore.
Either include the header in question again, or move the variable declaration to variables.h. (Which should be included anyway)

[BamBam]

Here's an update to work with the current (10230) trunk.

Regards,
BamBam

[chrissicom]

Here's an update to work with the current (10230) trunk.

Regards,
BamBam

Great work, this works perfectly also on 10232 *g*

[MJS]

Now, this wonderful patch is performing splendidly in ChrisIN, I believe (but then again people would never send bug reports to me, so how could I tell if it didn't?). Does anyone know whether the coding style of this patch is up to standard for inclusion in trunk?

[Maedhros]

I think this patch goes about things the wrong way. Building a list, and hoping it will be the same on the client and the server from the time the command is issued to the time it is executed is asking for trouble, imho. (Also comments like "Do not laugh " don't inspire too much confidence .)

The way I would do this would be to pass the selected station ID directly to the command. It'll take some re-ordering of p1 and p2, but I think there's still space for it.

[chrissicom]

Although the patch works usually really well, there are sometimes little bugs (very seldom) that you are asked wether you'd like to join your station with opponents stations (which results in an error message when you click one of the stations).

Also the station catchment area is either painted wrongfully with the righclick show station catchment patch or it is not working properly. See screenshot.

[vanOekelen]

Although the patch works usually really well, there are sometimes little bugs (very seldom) that you are asked wether you'd like to join your station with opponents stations (which results in an error message when you click one of the stations).

Also the station catchment area is either painted wrongfully with the righclick show station catchment patch or it is not working properly. See screenshot.

As far as I know that catchment area is correctly, the station catchment area is only determined by the two most outher station tiles in a rectangle, so the total catchment area should also always be a rectangle.

See also: http://www.tt-forums.net/viewtopic.php?f=33&t=31797

[Maedhros]

Although the patch works usually really well, there are sometimes little bugs (very seldom) that you are asked wether you'd like to join your station with opponents stations (which results in an error message when you click one of the stations).

Which is why building a list and hoping no-one else will change it before it gets used is not a good idea.

[Frostregen]

Although the patch works usually really well, there are sometimes little bugs (very seldom) that you are asked wether you'd like to join your station with opponents stations (which results in an error message when you click one of the stations).

Which is why building a list and hoping no-one else will change it before it gets used is not a good idea.

If i remember right, the only way this list could change while you are viewing it,
is by a coop-player in multiplayer.
Other companies stations should never get into the list,
thus cannot modify the list.
(if opponents stations show up in the list, it is a bug )

btw, if anyone wants to take over, or make a new version, just do it...
i'm busy with keeping copy&paste up to date

[MJS]

Does it currently include a last check after the user has chosen a station with which he wants to join? In coop playing, that would be the moment to check whether the chosen station still exists, and return to the choice screen if it doesn't. Or can anyone confirm the rumour that non-coop opponent's stations appear in the list? Otherwise, this seems a rather likely candidate to go into trunk, seeing how it would increase compatibility with Patch.