New map features

[wallyweb]

I have updated my branch.

... and we have the unguaranteed Win32 binary:

OpenTTD-REBASED-r27339-ga12d6691-Win32.7z

Cirdan's New Map Features

(5.46 MiB) Downloaded 131 times

OpenTTD-g9b376707-tracerestrict-cirdan-Win32.7z

JGR's tracerestrict

(5.48 MiB) Downloaded 126 times

Enjoy!

[JGR]

JGR's tracerestrict-cirdan fork awaits JGR's update.

I've pushed an update, though haven't done any testing other than building it.

[wallyweb]

I've pushed an update,

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.

[TrueSatan]

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]

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...

[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.

[cirdan]

Which stations and ships in your savegame are those?

[Hafting]

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.

[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]

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.

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.

[cirdan]

I have just pushed an update with (hopefully) a fix for your bug. Thanks for your report!

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.

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]

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

[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?

[TrueSatan]

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
So I started make again and...
See attached Answer enough i guess hehe

Thanks again for your efforts Cirdan

Cheers

[cirdan]

Thanks for testing. I have pushed the fix to the repository.

[wallyweb]

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

[cirdan]

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.

[wallyweb]

Sorry, the fix was incomplete. There is a new fix in the repository now. Thanks for reporting.

... and we have the unguaranteed Win32 binary:

OpenTTD-REBASED-r27339-g478eec70-Win32.7z

Cirdan's New Map Features

(5.45 MiB) Downloaded 142 times

OpenTTD-g869c939f-tracerestrict-cirdan-Win32.7z

JGR's tracerestrict

(5.47 MiB) Downloaded 125 times

Enjoy!

[JGR]

JGR's tracerestrict version will be added when available.

I've bumped the branch on github now.

[wallyweb]

I've bumped the branch on github now.

The Windows 32 bit binary has been posted here.