New map features

Forum for technical discussions regarding development. If you have a general suggestion, problem or comment, please use one of the other forums.

Moderator: OpenTTD Developers

User avatar
wallyweb
Tycoon
Tycoon
Posts: 6102
Joined: 27 Nov 2004 15:05
Location: Canada

Re: New map features

Post by wallyweb »

cirdan wrote:I have updated my branch.
:bow:
... and we have the unguaranteed Win32 binary:
OpenTTD-REBASED-r27339-ga12d6691-Win32.7z
Cirdan's New Map Features
(5.46 MiB) Downloaded 74 times
OpenTTD-g9b376707-tracerestrict-cirdan-Win32.7z
JGR's tracerestrict
(5.48 MiB) Downloaded 75 times
Enjoy! :D
Last edited by wallyweb on 05 Oct 2015 11:59, edited 1 time in total.
User avatar
JGR
Tycoon
Tycoon
Posts: 2557
Joined: 08 Aug 2005 13:46
Location: Ipswich

Re: New map features

Post by JGR »

wallyweb wrote:JGR's tracerestrict-cirdan fork awaits JGR's update.
I've pushed an update, though haven't done any testing other than building it.
Ex TTDPatch Coder
Patch Pack, Github
User avatar
wallyweb
Tycoon
Tycoon
Posts: 6102
Joined: 27 Nov 2004 15:05
Location: Canada

Re: New map features

Post by wallyweb »

JGR wrote:I've pushed an update,
:bow:
Compiled and posted above
though haven't done any testing other than building it.
I tested to make sure the game loaded.
Aggressive stress testing will begin later today. 8)
TrueSatan
Transport Coordinator
Transport Coordinator
Posts: 291
Joined: 16 Jul 2003 18:33

Re: New map features

Post by TrueSatan »

JGR wrote:
wallyweb wrote:JGR's tracerestrict-cirdan fork awaits JGR's update.
I've pushed an update, though haven't done any testing other than building it.
Updated my post here
notafrog
Engineer
Engineer
Posts: 14
Joined: 13 May 2014 17:43

Re: New map features

Post by notafrog »

cirdan wrote:I think that the signal should behave as if placed at the end of the platform, unlike normal signals, which are placed at the middle of a tile and make trains stop at the previous tile.
Well if ever you get your teeth into that one I'm sure it's going to be awesome. I'm trying to think where I've already seen something like that.

Oh, I know... :wink:

Image
Hafting
Engineer
Engineer
Posts: 106
Joined: 13 Feb 2014 11:22

Re: New map features

Post by Hafting »

Possible bug in the routing of goods:

I play with cargodist. I don't know if the problem is in cargodist itself or in the nice re-fit system this patch provides. This is what I observe:

A ship picks up grain (or manufacturing supplies)at A. This is brough to a mill at B, the ship refits to food and brings food to C, D and E.
This part works well.

Now, a train comes in and dumps food at A. I planned to have a ship bringing that food directly to E (E is close to A) But I have not bought such a ship yet. (too much other work)
So I expcected that food to be for "any destination" - currently, nothing picks up food at A. Neither ship nor train.

But the food is routed via B to C! That will never happen, so "undeliverable cargo" will pile up. This seems like a cargo problem. There is a ship route that goes A->B->C->D->E, but although it delivers food at C, it never pick up food at A. So how did cargodist get that idea? A bug?

I have seen such oddities before, and they do usually not resolve themselves.

I can salvage this game by allowing the ships to pick up food as well, and buy more ships to cope with the increased shipping demand. But I think the game shouldn't schedule such goods until I actually provide a transport route. There are no conditional orders making things difficult here - only "goto" & "refit to one or two cargo types." The ships are fit for food when they move towards A, but are guaranteed to be empty at that time. Once they reach A they refit to either grain or manufacturing supplies. Food is not an option, and food has never been picked up at A. (well, the train that brings food in might pick it up again, but the train obviously can't cross the ocean to B) No ship ever picked up food at A.
Attachments
cargobug.sav
Updated savegame with the problem. this time, stations are named A,B,C,D,E
(573.59 KiB) Downloaded 61 times
Last edited by Hafting on 23 Oct 2015 12:44, edited 1 time in total.
User avatar
cirdan
Director
Director
Posts: 539
Joined: 07 Apr 2007 18:08

Re: New map features

Post by cirdan »

Which stations and ships in your savegame are those?
Hafting
Engineer
Engineer
Posts: 106
Joined: 13 Feb 2014 11:22

Re: New map features

Post by Hafting »

cirdan wrote:Which stations and ships in your savegame are those?
My mistake, as usual. I renamed the stations to A,B,C,D and E to make it easy. Then I changed the game language to english to verify english cargo names. This apparently re-set all the station names - including those named by me. I did not notice that. I have edited my report and uploaded a savegame with renamed stations. You should find A,B,C, D and E this time.
User avatar
cirdan
Director
Director
Posts: 539
Joined: 07 Apr 2007 18:08

Re: New map features

Post by cirdan »

No worries, I was just a bit confused.

I am looking into your problem and there seem to be two bugs at work here, both of them related to selective autorefit.

The first one is that the link refresher, when processing an autorefit order, would always update the link with the cargo that the vehicle carried before the refit, in addition to any cargoes selected in the autorefit set, even if the previous cargo is not in that set—this is why food dumped at A was routed via B to other places. This is easy enough to fix.

The second bug is that the food would actually be picked up later: If any of the ships stopping at A that were told to refit to either grain or manufacturing supplies found neither of those cargoes, they would remain refitted to food, and proceed to load. This made sense when the previous cargo was implicitly allowed in autorefits because all cargoes were, but not now. Dealing with this is trickier, though. The natural fix would be to refit the vehicle to any cargo in the chosen set (the first one, or a random one) if there is nothing to load at the station, but this can fail if the newgrf disallows the refit. I am leaning towards doing this and then blaming the user if they select a cargo to which the vehicle cannot autorefit, or blaming the newgrf author for not documenting this properly.

As a workaround, you can try duplicating the "goto A" order and making the first one a fixed refit; this will avoid both bugs until there is a proper fix (but note that food already at A may take a long while to be rerouted or disappear).
Hafting
Engineer
Engineer
Posts: 106
Joined: 13 Feb 2014 11:22

Re: New map features

Post by Hafting »

cirdan wrote: The first one is that the link refresher, when processing an autorefit order, would always update the link with the cargo that the vehicle carried before the refit, in addition to any cargoes selected in the autorefit set, even if the previous cargo is not in that set—this is why food dumped at A was routed via B to other places. This is easy enough to fix.
Nice. I believe that is the one usually making problems for me.
cirdan wrote: The second bug is that the food would actually be picked up later: If any of the ships stopping at A that were told to refit to either grain or manufacturing supplies found neither of those cargoes, they would remain refitted to food, and proceed to load. This made sense when the previous cargo was implicitly allowed in autorefits because all cargoes were, but not now. Dealing with this is trickier, though. The natural fix would be to refit the vehicle to any cargo in the chosen set (the first one, or a random one) if there is nothing to load at the station, but this can fail if the newgrf disallows the refit. I am leaning towards doing this and then blaming the user if they select a cargo to which the vehicle cannot autorefit, or blaming the newgrf author for not documenting this properly.
There is also the possibility that the player skips a station. The ship might then come back half-full with undelivered food - and proceed to pick up more food. But that is the player's own fault, I think. Unless we want ships etc. to auto-unload all cargo not in the re-fit set. I would not want that for trains - where a common case is to load more sand/stone/grain/building material if there happen to be any empty ore-type cars. It'd be impractical to also have to specify every cargo I might want the train to bring past that point so they won't toss it out.

Having an empty vehicle re-fit to something in the re-fit set would be enough, I guess. At least, it won't mess up those multi-cargo trains that might be all iron ore or all sand depending on what came in from elsewere. If the vehicle waits for a full load, then it must re-fit to the first acceptable cargo that appear. It'd be a disaster if all the ships on some route come in, all re-fit to one cargo & waits, then the other cargo comes in but nobody ever tries to load it.
User avatar
cirdan
Director
Director
Posts: 539
Joined: 07 Apr 2007 18:08

Re: New map features

Post by cirdan »

I have just pushed an update with (hopefully) a fix for your bug. Thanks for your report!
Hafting wrote:There is also the possibility that the player skips a station. The ship might then come back half-full with undelivered food - and proceed to pick up more food. But that is the player's own fault, I think. Unless we want ships etc. to auto-unload all cargo not in the re-fit set. I would not want that for trains - where a common case is to load more sand/stone/grain/building material if there happen to be any empty ore-type cars. It'd be impractical to also have to specify every cargo I might want the train to bring past that point so they won't toss it out.
A vehicle that arrives half-full to a station should not load any cargo anyway unless that cargo is already routed through that link, which should not happen now that the previous bug is fixed.
Hafting wrote:Having an empty vehicle re-fit to something in the re-fit set would be enough, I guess. At least, it won't mess up those multi-cargo trains that might be all iron ore or all sand depending on what came in from elsewere. If the vehicle waits for a full load, then it must re-fit to the first acceptable cargo that appear. It'd be a disaster if all the ships on some route come in, all re-fit to one cargo & waits, then the other cargo comes in but nobody ever tries to load it.
The new code should try to do precisely this, so please report back if it does not.
TrueSatan
Transport Coordinator
Transport Coordinator
Posts: 291
Joined: 16 Jul 2003 18:33

Re: New map features

Post by TrueSatan »

Code: Select all

[SRC] Compiling blitter/blitter.cpp
In file included from /home/computeradvisor/nmf/src/blitter/sse3.h:13:0,
                 from /home/computeradvisor/nmf/src/blitter/32bpp_ssse3.hpp:17,
                 from /home/computeradvisor/nmf/src/blitter/blitter.cpp:28:
/usr/lib/gcc/x86_64-linux-gnu/4.8/include/tmmintrin.h:31:3: error: #error "SSSE3 instruction set not enabled"
 # error "SSSE3 instruction set not enabled"
   ^
In file included from /home/computeradvisor/nmf/src/blitter/sse4.h:13:0,
                 from /home/computeradvisor/nmf/src/blitter/32bpp_sse4.hpp:17,
                 from /home/computeradvisor/nmf/src/blitter/blitter.cpp:29:
/usr/lib/gcc/x86_64-linux-gnu/4.8/include/smmintrin.h:31:3: error: #error "SSE4.1 instruction set not enabled"
 # error "SSE4.1 instruction set not enabled"
   ^
In file included from /home/computeradvisor/nmf/src/blitter/32bpp_ssse3.hpp:17:0,
                 from /home/computeradvisor/nmf/src/blitter/blitter.cpp:28:
/home/computeradvisor/nmf/src/blitter/sse3.h: In static member function ‘static __m128i SSE3::pack_unsaturated(__m128i, __m128i)’:
/home/computeradvisor/nmf/src/blitter/sse3.h:21:38: error: ‘_mm_shuffle_epi8’ was not declared in this scope
   return _mm_shuffle_epi8 (from, mask);
                                      ^
/home/computeradvisor/nmf/src/blitter/sse3.h: In static member function ‘static __m128i SSE3::distribute_alpha(__m128i, __m128i)’:
/home/computeradvisor/nmf/src/blitter/sse3.h:26:38: error: ‘_mm_shuffle_epi8’ was not declared in this scope
   return _mm_shuffle_epi8 (from, mask);
                                      ^
/home/computeradvisor/nmf/src/blitter/sse3.h: In static member function ‘static __m128i SSE3::shuffle_epi8(__m128i, __m128i)’:
/home/computeradvisor/nmf/src/blitter/sse3.h:31:32: error: ‘_mm_shuffle_epi8’ was not declared in this scope
   return _mm_shuffle_epi8 (x, y);
                                ^
/home/computeradvisor/nmf/src/blitter/sse3.h: In static member function ‘static __m128i SSE3::hadd_epi16(__m128i, __m128i)’:
/home/computeradvisor/nmf/src/blitter/sse3.h:36:30: error: ‘_mm_hadd_epi16’ was not declared in this scope
   return _mm_hadd_epi16 (x, y);
                              ^
/home/computeradvisor/nmf/src/blitter/sse3.h: In static member function ‘static __m128i SSE3::pack_unsaturated(__m128i, __m128i)’:
/home/computeradvisor/nmf/src/blitter/sse3.h:22:2: warning: control reaches end of non-void function [-Wreturn-type]
  }
  ^
/home/computeradvisor/nmf/src/blitter/sse3.h: In static member function ‘static __m128i SSE3::distribute_alpha(__m128i, __m128i)’:
/home/computeradvisor/nmf/src/blitter/sse3.h:27:2: warning: control reaches end of non-void function [-Wreturn-type]
  }
  ^
/home/computeradvisor/nmf/src/blitter/sse3.h: In static member function ‘static __m128i SSE3::shuffle_epi8(__m128i, __m128i)’:
/home/computeradvisor/nmf/src/blitter/sse3.h:32:2: warning: control reaches end of non-void function [-Wreturn-type]
  }
  ^
/home/computeradvisor/nmf/src/blitter/sse3.h: In static member function ‘static __m128i SSE3::hadd_epi16(__m128i, __m128i)’:
/home/computeradvisor/nmf/src/blitter/sse3.h:37:2: warning: control reaches end of non-void function [-Wreturn-type]
  }
  ^
make[1]: *** [blitter/blitter.o] Fehler 1
make[1]: Verzeichnis »/home/computeradvisor/nmf/objs/release« wird verlassen
make: *** [all] Fehler 1
Hey Cirdan, got some nasty compiler errors with the latest update of your repo.
Cheers
User avatar
cirdan
Director
Director
Posts: 539
Joined: 07 Apr 2007 18:08

Re: New map features

Post by cirdan »

Oops, sorry about that. I made some changes to the blitters and it seems that I left a couple of includes at the wrong places. Could you test if the attached patch fixes the build for you?
Attachments
sse-fix.diff
(1.69 KiB) Downloaded 64 times
TrueSatan
Transport Coordinator
Transport Coordinator
Posts: 291
Joined: 16 Jul 2003 18:33

Re: New map features

Post by TrueSatan »

cirdan wrote:Oops, sorry about that. I made some changes to the blitters and it seems that I left a couple of includes at the wrong places. Could you test if the attached patch fixes the build for you?
No Problem, I am here to find out and point it out :D
So I started make again and...
See attached :D Answer enough i guess hehe

Thanks again for your efforts Cirdan :)

Cheers
Attachments
openttd-custom-g4360633fM-UNIX.tar.xz
Version: g4360633fM
Ubuntu 14.04
don't mind the M its because of the applied diff
(4.62 MiB) Downloaded 56 times
User avatar
cirdan
Director
Director
Posts: 539
Joined: 07 Apr 2007 18:08

Re: New map features

Post by cirdan »

Thanks for testing. I have pushed the fix to the repository.
User avatar
wallyweb
Tycoon
Tycoon
Posts: 6102
Joined: 27 Nov 2004 15:05
Location: Canada

Re: New map features

Post by wallyweb »

cirdan wrote:I have pushed the fix to the repository.
We have some compile errors. (MinGW/msys - Windows 32 bit) :

Code: Select all

In file included from C:/MinGW/msys/1.0/home/Adminguy/fttd/src/blitter/sse2.h:13
:0,
                 from C:/MinGW/msys/1.0/home/Adminguy/fttd/src/blitter/32bpp_sse
2.hpp:19,
                 from C:/MinGW/msys/1.0/home/Adminguy/fttd/src/blitter/blitter.c
pp:27:
c:\mingw\lib\gcc\mingw32\4.8.1\include\emmintrin.h:31:3: error: #error "SSE2 ins
truction set not enabled"
 # error "SSE2 instruction set not enabled"
   ^
In file included from C:/MinGW/msys/1.0/home/Adminguy/fttd/src/blitter/32bpp_sse
2.hpp:19:0,
                 from C:/MinGW/msys/1.0/home/Adminguy/fttd/src/blitter/blitter.c
pp:27:
C:/MinGW/msys/1.0/home/Adminguy/fttd/src/blitter/sse2.h:22:2: error: '__m128i' d
oes not name a type
  __m128i m128i;
  ^
C:/MinGW/msys/1.0/home/Adminguy/fttd/src/blitter/sse2.h:31:38: error: '__m128i'
has not been declared
  static void load_u64 (uint64 value, __m128i &into)
                                      ^
C:/MinGW/msys/1.0/home/Adminguy/fttd/src/blitter/sse2.h:40:9: error: '__m128i' d
oes not name a type
  static __m128i pack_unsaturated (__m128i from, __m128i mask)
         ^
C:/MinGW/msys/1.0/home/Adminguy/fttd/src/blitter/sse2.h:46:9: error: '__m128i' d
oes not name a type
  static __m128i distribute_alpha (__m128i from, __m128i mask)
         ^
In file included from C:/MinGW/msys/1.0/home/Adminguy/fttd/src/blitter/32bpp_sse
2.hpp:22:0,
                 from C:/MinGW/msys/1.0/home/Adminguy/fttd/src/blitter/blitter.c
pp:27:
C:/MinGW/msys/1.0/home/Adminguy/fttd/src/blitter/32bpp_sse_common.h:29:15: error
: '__m128i' does not name a type
 static inline __m128i AlphaBlendTwoPixels(__m128i src, __m128i dst, const __m12
8i &distribution_mask, const __m128i &pack_mask)
               ^
C:/MinGW/msys/1.0/home/Adminguy/fttd/src/blitter/32bpp_sse_common.h:50:15: error
: '__m128i' does not name a type
 static inline __m128i DarkenTwoPixels(__m128i src, __m128i dst, const __m128i &
distribution_mask, const __m128i &tr_nom_base)
               ^
C:/MinGW/msys/1.0/home/Adminguy/fttd/src/blitter/32bpp_sse_common.h: In function
 'Colour ReallyAdjustBrightness(Colour, uint8)':
C:/MinGW/msys/1.0/home/Adminguy/fttd/src/blitter/32bpp_sse_common.h:77:2: error:
 '__m128i' was not declared in this scope
  __m128i ret;
  ^
C:/MinGW/msys/1.0/home/Adminguy/fttd/src/blitter/32bpp_sse_common.h:77:10: error
: expected ';' before 'ret'
  __m128i ret;
          ^
C:/MinGW/msys/1.0/home/Adminguy/fttd/src/blitter/32bpp_sse_common.h:78:20: error
: 'ret' was not declared in this scope
  T::load_u64 (c16, ret);
                    ^
C:/MinGW/msys/1.0/home/Adminguy/fttd/src/blitter/32bpp_sse_common.h:80:11: error
: expected ';' before 'ob128'
   __m128i ob128 = _mm_cvtsi32_si128(ob);
           ^
C:/MinGW/msys/1.0/home/Adminguy/fttd/src/blitter/32bpp_sse_common.h:81:3: error:
 'ob128' was not declared in this scope
   ob128 = _mm_shufflelo_epi16(ob128, 0xC0);
   ^
C:/MinGW/msys/1.0/home/Adminguy/fttd/src/blitter/32bpp_sse_common.h:81:42: error
: there are no arguments to '_mm_shufflelo_epi16' that depend on a template para
meter, so a declaration of '_mm_shufflelo_epi16' must be available [-fpermissive
]
   ob128 = _mm_shufflelo_epi16(ob128, 0xC0);
                                          ^
C:/MinGW/msys/1.0/home/Adminguy/fttd/src/blitter/32bpp_sse_common.h:81:42: note:
 (if you use '-fpermissive', G++ will accept your code, but allowing the use of
an undeclared name is deprecated)
C:/MinGW/msys/1.0/home/Adminguy/fttd/src/blitter/32bpp_sse_common.h:82:11: error
: expected ';' before 'white'
   __m128i white = OVERBRIGHT_VALUE_MASK;
           ^
C:/MinGW/msys/1.0/home/Adminguy/fttd/src/blitter/32bpp_sse_common.h:83:11: error
: expected ';' before 'c128'
   __m128i c128 = ret;
           ^
C:/MinGW/msys/1.0/home/Adminguy/fttd/src/blitter/32bpp_sse_common.h:84:24: error
: 'white' was not declared in this scope
   ret = _mm_subs_epu16(white, c128); // PSUBUSW,   (255 - rgb)
                        ^
C:/MinGW/msys/1.0/home/Adminguy/fttd/src/blitter/32bpp_sse_common.h:84:31: error
: 'c128' was not declared in this scope
   ret = _mm_subs_epu16(white, c128); // PSUBUSW,   (255 - rgb)
                               ^
C:/MinGW/msys/1.0/home/Adminguy/fttd/src/blitter/32bpp_sse_common.h:84:35: error
: there are no arguments to '_mm_subs_epu16' that depend on a template parameter
, so a declaration of '_mm_subs_epu16' must be available [-fpermissive]
   ret = _mm_subs_epu16(white, c128); // PSUBUSW,   (255 - rgb)
                                   ^
C:/MinGW/msys/1.0/home/Adminguy/fttd/src/blitter/32bpp_sse_common.h:85:35: error
: there are no arguments to '_mm_mullo_epi16' that depend on a template paramete
r, so a declaration of '_mm_mullo_epi16' must be available [-fpermissive]
   ret = _mm_mullo_epi16(ret, ob128); // PMULLW, ob*(255 - rgb)
                                   ^
C:/MinGW/msys/1.0/home/Adminguy/fttd/src/blitter/32bpp_sse_common.h:86:30: error
: there are no arguments to '_mm_srli_epi16' that depend on a template parameter
, so a declaration of '_mm_srli_epi16' must be available [-fpermissive]
   ret = _mm_srli_epi16(ret, 8);      // PSRLW,  ob*(255 - rgb)/256
                              ^
C:/MinGW/msys/1.0/home/Adminguy/fttd/src/blitter/32bpp_sse_common.h:87:32: error
: there are no arguments to '_mm_add_epi16' that depend on a template parameter,
 so a declaration of '_mm_add_epi16' must be available [-fpermissive]
   ret = _mm_add_epi16(ret, c128);    // PADDW,  ob*(255 - rgb)/256 + rgb
                                ^
C:/MinGW/msys/1.0/home/Adminguy/fttd/src/blitter/32bpp_sse_common.h:90:33: error
: there are no arguments to '_mm_packus_epi16' that depend on a template paramet
er, so a declaration of '_mm_packus_epi16' must be available [-fpermissive]
  ret = _mm_packus_epi16(ret, ret);      // PACKUSWB, saturate and pack.
                                 ^
C:/MinGW/msys/1.0/home/Adminguy/fttd/src/blitter/32bpp_sse_common.h:91:40: error
: there are no arguments to '_mm_cvtsi128_si32' that depend on a template parame
ter, so a declaration of '_mm_cvtsi128_si32' must be available [-fpermissive]
  return alpha32 | _mm_cvtsi128_si32(ret);
                                        ^
C:/MinGW/msys/1.0/home/Adminguy/fttd/src/blitter/32bpp_sse_common.h: At global s
cope:
C:/MinGW/msys/1.0/home/Adminguy/fttd/src/blitter/32bpp_sse_common.h:108:15: erro
r: '__m128i' does not name a type
 static inline __m128i AdjustBrightnessOfTwoPixels(__m128i from, uint32 brightne
ss)
               ^
make[1]: *** [blitter/blitter.o] Error 1
make[1]: Leaving directory `/usr/home/Adminguy/fttd/objs/release'
make: *** [all] Error 1
User avatar
cirdan
Director
Director
Posts: 539
Joined: 07 Apr 2007 18:08

Re: New map features

Post by cirdan »

wallyweb wrote:
cirdan wrote:I have pushed the fix to the repository.
We have some compile errors. (MinGW/msys - Windows 32 bit) :
Sorry, the fix was incomplete. There is a new fix in the repository now. Thanks for reporting.
User avatar
wallyweb
Tycoon
Tycoon
Posts: 6102
Joined: 27 Nov 2004 15:05
Location: Canada

Re: New map features

Post by wallyweb »

cirdan wrote:Sorry, the fix was incomplete. There is a new fix in the repository now. Thanks for reporting.
:bow: :D
... and we have the unguaranteed Win32 binary:
OpenTTD-REBASED-r27339-g478eec70-Win32.7z
Cirdan's New Map Features
(5.45 MiB) Downloaded 73 times
OpenTTD-g869c939f-tracerestrict-cirdan-Win32.7z
JGR's tracerestrict
(5.47 MiB) Downloaded 63 times
Enjoy! :D
Last edited by wallyweb on 29 Oct 2015 20:41, edited 1 time in total.
User avatar
JGR
Tycoon
Tycoon
Posts: 2557
Joined: 08 Aug 2005 13:46
Location: Ipswich

Re: New map features

Post by JGR »

wallyweb wrote:JGR's tracerestrict version will be added when available.
I've bumped the branch on github now.
Ex TTDPatch Coder
Patch Pack, Github
User avatar
wallyweb
Tycoon
Tycoon
Posts: 6102
Joined: 27 Nov 2004 15:05
Location: Canada

Re: New map features

Post by wallyweb »

JGR wrote:I've bumped the branch on github now.
:bow:
The Windows 32 bit binary has been posted here. :D
Post Reply

Return to “OpenTTD Development”

Who is online

Users browsing this forum: No registered users and 14 guests