Page 164 of 235

Re: JGR's Patch Pack

Posted: 06 Feb 2021 18:34
by vincentkoevoets
Build 0.40.1 for macOS
openttd-jgrpp-0.40.1-macos.dmg
openttd-jgrpp-0.40.1-macos
(7.61 MiB) Downloaded 167 times

Re: JGR's Patch Pack

Posted: 06 Feb 2021 21:42
by jor[D]1
Bernasrebelo11 wrote: 03 Feb 2021 01:03
Auge wrote: 02 Feb 2021 22:03 Hello
Bernasrebelo11 wrote: 02 Feb 2021 17:33 How do I make a selection of path using signaling
https://prnt.sc/y1lndc
it appears to not be able to select anything YAPF chosen
Mark the word "End" instead of "Start" in the signal restrictions window. If done, you should be able to use the insert-button on the bottom left side of the popup window. Further buttons will get active depending on your choices.

Tschö, Auge
Thank you one more question
https://prnt.sc/y30me7

let's say in the image above the train normally goes bottom left because of its route, how do I make that train after a certain hour go top right or in front
function:
if hour/minute > 20:00:
"turn top right"
return

how do I do that top right or middle?
Conditional order with Time condition could be a really usefull feature for this also. Had the same issue recently. Don't know if it's possible to create such an order with a patch.

Re: JGR's Patch Pack

Posted: 07 Feb 2021 04:58
by Deicide
Now that realistic braking patch is here, can we please be done with nonsense where trains slow down when entering stations and entering/exiting depots, when braking model is original?

Re: JGR's Patch Pack

Posted: 07 Feb 2021 16:48
by Snail
Hi,

I'm trying to compile it on my MacOS X 10.12 using HomeBrew and CMake 3.19.2, and I get the following error:

Code: Select all

[ 38%] Building CXX object src/settingsgen/CMakeFiles/settingsgen.dir/settingsgen.cpp.o
In file included from /roba/OpenTTD-patches-jgrpp040/src/settingsgen/settingsgen.cpp:14:
/roba/OpenTTD-patches-jgrpp040/src/settingsgen/../ini_type.h:15:10: fatal error: 
      'optional' file not found
#include <optional>
         ^~~~~~~~~~
1 error generated.
make[2]: *** [src/settingsgen/CMakeFiles/settingsgen.dir/settingsgen.cpp.o] Error 1
make[1]: *** [src/settingsgen/CMakeFiles/settingsgen.dir/all] Error 2
make: *** [all] Error 2
Any suggestions on how to fix this?

Thanks in advance!

Re: JGR's Patch Pack

Posted: 07 Feb 2021 17:03
by JGR
jor[D]1 wrote: 06 Feb 2021 21:42 Conditional order with Time condition could be a really usefull feature for this also. Had the same issue recently. Don't know if it's possible to create such an order with a patch.
I will take another look at this. This ought to be technically possible.
Deicide wrote: 07 Feb 2021 04:58 Now that realistic braking patch is here, can we please be done with nonsense where trains slow down when entering stations and entering/exiting depots, when braking model is original?
Pragmatically speaking, the original model will be maintained in order to keep compatibility with upstream.
McZapkie wrote: 06 Feb 2021 11:33 @JGR current mechanism of bancruptcy is inherited from vanilla openttd, but it doesn't make sense in case of infrastructure sharing, I mean all these track vanishing including other players trains - handling of track infrastructure should be equivalent to road/canals.
Of course making rails ownerless would lead to cheats like phoney companies founded just to make free for all infrastructure and then go bancrupt.
But in fact these cheats exists in vanilla openttd, but limited to roads/canals.
Thus my second proposal to fix such issues, which is now possible with all these NRT: option to slowly degrade track or road, if located outside city authority:
each stray track or road may be randomly degraded to compatible one but with lowest speed.
Additionally convert tool may change track owner (is in't already implemented for roads?).
Things like auto-changing road types would add a lot of complexity and create opportunities for bugs and undesired behaviour. Road types are not necessarily interchangeable.

Quite likely different server owners would have different opinions about what the correct behaviour should be.
Snail wrote: 07 Feb 2021 16:48 Hi,

I'm trying to compile it on my MacOS X 10.12 using HomeBrew, and I get the following error:

Code: Select all

[ 38%] Building CXX object src/settingsgen/CMakeFiles/settingsgen.dir/settingsgen.cpp.o
In file included from /roba/OpenTTD-patches-jgrpp040/src/settingsgen/settingsgen.cpp:14:
/roba/OpenTTD-patches-jgrpp040/src/settingsgen/../ini_type.h:15:10: fatal error: 
      'optional' file not found
#include <optional>
         ^~~~~~~~~~
1 error generated.
make[2]: *** [src/settingsgen/CMakeFiles/settingsgen.dir/settingsgen.cpp.o] Error 1
make[1]: *** [src/settingsgen/CMakeFiles/settingsgen.dir/all] Error 2
make: *** [all] Error 2
Any suggestions on how to fix this?

Thanks in advance!
Upstream trunk recently raised the minimum C++ requirements to C++17. If you try to compile upstream OpenTTD you would will likely encounter the same problem.
There isn't very much that I can do about Apple-specific problems and it is not pragmatic for me to target a lower version of C++ than upstream trunk.
It may be worth raising this with the upstream devs, as a few of them do use Apple platforms.

Alternatively there is an Apple binary posted a few posts above this one.

Re: JGR's Patch Pack

Posted: 07 Feb 2021 17:16
by Snail
JGR wrote: 07 Feb 2021 17:03Upstream trunk recently raised the minimum C++ requirements to C++17. If you try to compile upstream OpenTTD you would will likely encounter the same problem.
There isn't very much that I can do about Apple-specific problems and it is not pragmatic for me to target a lower version of C++ than upstream trunk.
It may be worth raising this with the upstream devs, as a few of them do use Apple platforms.

Alternatively there is an Apple binary posted a few posts above this one.
Unfortunately, that one crashes on my system. This is the crash report I get:

Code: Select all

*** OpenTTD Crash Report ***

Crash at: Sun Feb  7 17:10:25 2021
In game date: 0-01-01 (0, 0) (DL: 0)

Crash reason:
 Signal:  Abort trap: 6 (6)
          si_code: 0
 Message: <none>

OpenTTD version:
 Version:    jgrpp-0.40.1 (0)
 NewGRF ver: 1b006d64
 Bits:       64
 Endian:     little
 Dedicated:  no
 Build date: Feb  6 2021 10:19:02
 Defines:    NDEBUG WITH_UCONTEXT WITH_BITMATH_BUILTINS WITH_OVERFLOW_BUILTINS WITH_DL WITH_DEMANGLE WITH_SIGACTION WITH_DBG_GDB WITH_UCONTEXT TTD_ENDIAN=TTD_LITTLE_ENDIAN UNIX WITH_PNG WITH_ZLIB WITH_LIBLZMA WITH_LZO WITH_FREETYPE WITH_ICONV WITH_COCOA WITH_PERSONAL_DIR WITH_SHARED_DIR WITH_SSE WITH_ASSERT _SQ64


Stacktrace:
 [00] openttd              0x000000010d274f66 (CrashLog::FillCrashLog(char*, char const*) const + 678)
 [01] openttd              0x000000010d1772d5 (CrashLogOSX::MakeCrashLog() + 69)
 [02] openttd              0x000000010d1771f0 (HandleCrash(int, __siginfo*, void*) + 208)
 [03] libsystem_platform.dylib 0x00007fffacad8b3a (_sigtramp + 26)
 [04] ???                  0x000000011271fb4d
 [05] ???                  0x000000011272a464
 [06] ???                  0x0000000112705793
 [07] ???                  0x000000011270589e
 [08] libdyld.dylib        0x0000000112217282 (dyld_stub_binder + 282)
 [09] libfreetype.6.dylib  0x000000010f48e208 (_dyld_private + 0)
 [10] libfreetype.6.dylib  0x000000010f45c8bf (ft_raster1_render + 472)
 [11] libfreetype.6.dylib  0x000000010f40f391 (FT_Render_Glyph_Internal + 238)
 [12] openttd              0x000000010d2b73ca (FreeTypeFontCache::InternalGetGlyph(unsigned int, bool) + 74)
 [13] openttd              0x000000010d2b6a56 (TrueTypeFontCache::GetGlyphWidth(unsigned int) + 102)
 [14] openttd              0x000000010d2c823f (LoadStringWidthTable(bool) + 143)
 [15] openttd              0x000000010d2be052 (GenerateWorld(GenWorldMode, unsigned int, unsigned int, bool) + 146)
 [16] openttd              0x000000010d3b3c01 (openttd_main(int, char**) + 6689)
 [17] openttd              0x000000010d17b867 (main + 151)
 [18] libdyld.dylib        0x000000011221b235 (start + 1)

LLDB info:
(lldb) process attach --pid 50564
Process 50564 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
    frame #0: 0x000000011225e246 libsystem_kernel.dylib`read + 10
libsystem_kernel.dylib`read:
->  0x11225e246 <+10>: jae    0x11225e250               ; <+20>
    0x11225e248 <+12>: movq   %rax, %rdi
    0x11225e24b <+15>: jmp    0x112255cd4               ; cerror
    0x11225e250 <+20>: retq   
Target 0: (openttd) stopped.

Executable module set to "/Applications/OpenTTD.app/Contents/MacOS/openttd".
Architecture set to: x86_64h-apple-macosx.
(lldb) bt 100
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
  * frame #0: 0x000000011225e246 libsystem_kernel.dylib`read + 10
    frame #1: 0x000000010d178196 openttd`CrashLogOSX::LogLldbInfo(char*, char const*) const + 1926
    frame #2: 0x000000010d177845 openttd`CrashLogOSX::LogRegisters(char*, char const*) const + 21
    frame #3: 0x000000010d274f75 openttd`CrashLog::FillCrashLog(char*, char const*) const + 693
    frame #4: 0x000000010d1772d5 openttd`CrashLogOSX::MakeCrashLog() + 69
    frame #5: 0x000000010d1771f0 openttd`HandleCrash(int, __siginfo*, void*) + 208
    frame #6: 0x00007fffacad8b3a libsystem_platform.dylib`_sigtramp + 26
    frame #7: 0x000000011272a9ef dyld`__abort_with_payload + 11
    frame #8: 0x000000011272a43b dyld`abort_with_payload_wrapper_internal + 90
    frame #9: 0x000000011272a464 dyld`abort_with_payload + 9
    frame #10: 0x0000000112705793 dyld`dyld::halt(char const*) + 361
    frame #11: 0x000000011270589e dyld`dyld::fastBindLazySymbol(ImageLoader**, unsigned long) + 139
    frame #12: 0x0000000112217282 libdyld.dylib`dyld_stub_binder + 282
    frame #13: 0x000000010f48e208 libfreetype.6.dylib
    frame #14: 0x000000010f45c8bf libfreetype.6.dylib`ft_raster1_render + 472
    frame #15: 0x000000010f40f391 libfreetype.6.dylib`FT_Render_Glyph_Internal + 238
    frame #16: 0x000000010d2b73ca openttd`FreeTypeFontCache::InternalGetGlyph(unsigned int, bool) + 74
    frame #17: 0x000000010d2b6a56 openttd`TrueTypeFontCache::GetGlyphWidth(unsigned int) + 102
    frame #18: 0x000000010d2c823f openttd`LoadStringWidthTable(bool) + 143
    frame #19: 0x000000010d2be052 openttd`GenerateWorld(GenWorldMode, unsigned int, unsigned int, bool) + 146
    frame #20: 0x000000010d3b3c01 openttd`openttd_main(int, char**) + 6689
    frame #21: 0x000000010d17b867 openttd`main + 151
    frame #22: 0x000000011221b235 libdyld.dylib`start + 1
    frame #23: 0x000000011221b235 libdyld.dylib`start + 1
(lldb) disassemble -b -F intel -c 1 -s 0x11272a9ee
dyld`__abort_with_payload:
    0x11272a9ee <+10>: 73 08  jae    0x11272a9f8               ; <+20>

Registers:
 rax:        0x2000209 rbx:              0x4 rcx:   0x7fff52bb74f8 rdx:   0x7fff52bb7970
 rsi:              0x4 rdi:              0x6 rbp:   0x7fff52bb7550 rsp:   0x7fff52bb74f8
 r8:    0x7fff52bb7570 r9:                 0 r10:             0x8c r11:            0x246
 r12:             0x8c r13:   0x7fff52bb7970 r14:              0x6 r15:                0
 rip:      0x11272a9ee rflags:    0x246

Operating system:
 Name:     Mac OS X
 Release:  10.12.6
 Machine:  Intel x86-64h Haswell
 Min Ver:  1090
 Max Ver:  110100
 Compiler: clang 12.0.0 (clang-1200.0.32.29) "Apple LLVM 12.0.0 (clang-1200.0.32.29)"

Configuration:
 Blitter:      32bpp-sse2-anim
 Graphics set: original_windows (0)
 Language:     /Applications/OpenTTD.app/Contents/Resources/lang/italian.lng
 Music driver: cocoa
 Music set:    original_windows (1)
 Network:      no
 Sound driver: cocoa
 Sound set:    original_windows (0)
 Video driver: cocoa
 Pathfinder:   - - -

Fonts:
 Small:  sprite
 Medium: sprite
 Large:  Dauphin
 Mono:   sprite

Map size: 0x1000 (64 x 64)

AI Configuration (local: 255) (current: 255):

Libraries:
 FreeType:   2.10.4
 LZMA:       5.0.5
 LZO:        2.10
 PNG:        1.6.37
 Zlib:       1.2.8

---- gamelog start ----
Tick 0: new game started
Revision text changed to jgrpp-0.40.1, savegame version 289, not modified, _openttd_newgrf_version = 0x1b006d64
New game mode: 0 landscape: 0
---- gamelog end ----

Recent news messages (0 of 0):

Command Log:
 Showing most recent 0 of 0 commands

*** End of OpenTTD Crash Report ***

Re: JGR's Patch Pack

Posted: 07 Feb 2021 18:21
by JGR
Snail wrote: 07 Feb 2021 17:16 Unfortunately, that one crashes on my system. This is the crash report I get:
I will do some investigating to see how this may be able to be resolved.

In the meantime, it may be more pragmatic to install a VM (Linux, Windows, or similar), as this should allow compiling, testing and other dev work.

Re: JGR's Patch Pack

Posted: 07 Feb 2021 22:55
by JGR
Snail wrote: 07 Feb 2021 17:16 Unfortunately, that one crashes on my system. This is the crash report I get:
You may be able to get around this by installing LLVM from homebrew as well.

Stackoverflow suggests that you can do:

Code: Select all

brew update
brew install llvm
Then (temporarily) put the above LLVM installation in your path by means of:

Code: Select all

export PATH="/usr/local/opt/llvm/bin:$PATH"
Then delete the CMakeCache.txt file and try the build again.

Re: JGR's Patch Pack

Posted: 08 Feb 2021 03:14
by Snail
JGR wrote: 07 Feb 2021 22:55
Snail wrote: 07 Feb 2021 17:16 Unfortunately, that one crashes on my system. This is the crash report I get:
You may be able to get around this by installing LLVM from homebrew as well.

Stackoverflow suggests that you can do:

Code: Select all

brew update
brew install llvm
Then (temporarily) put the above LLVM installation in your path by means of:

Code: Select all

export PATH="/usr/local/opt/llvm/bin:$PATH"
Then delete the CMakeCache.txt file and try the build again.
This is a suggestion for vincentkoevoets , who compiled it above, right?
I tried to do it myself, and it failed, because it was looking for stuff that's in OSX 10.13:

Code: Select all

Last 15 lines from /Users/jacopocoletto/Library/Logs/Homebrew/tcl-tk/12.make:
2021-02-07 22:09:28 -0500

make
critcl

make: error: unable to find utility "make", not a developer tool or in PATH
xcodebuild: error: SDK "/Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk" cannot be located.
clang: error: unable to find utility "clang", not a developer tool or in PATH
So it seems it needs to be ran in a more recent OS.

Re: JGR's Patch Pack

Posted: 08 Feb 2021 09:55
by vincentkoevoets
I'm thinking that maybe it's time to set up a Mac OS building/compiling thread.. :lol:
But in the meantime, yes my binary is compiled and tested in the latest version of Mac OS (Big Sur 11.3). I'm willing to set up another VM with 10.12, and compile it from there. Maybe you could test that one. All in all it sounds like your building environment might be broken, so I would advise to clean your building environment and start with a fresh Homebrew and Xcode installation.

Re: JGR's Patch Pack

Posted: 08 Feb 2021 15:39
by Snail
vincentkoevoets wrote: 08 Feb 2021 09:55 I'm thinking that maybe it's time to set up a Mac OS building/compiling thread.. :lol:
But in the meantime, yes my binary is compiled and tested in the latest version of Mac OS (Big Sur 11.3). I'm willing to set up another VM with 10.12, and compile it from there. Maybe you could test that one. All in all it sounds like your building environment might be broken, so I would advise to clean your building environment and start with a fresh Homebrew and Xcode installation.
Thank you. For what I can understand, though, the compiler chosen by the OTTD Developers (C++17) is not compatible with 10.12's XCode version. I'm not sure if there is another way to run C++17 on OS 10.12?

And I agree, this might be slightly off-topic in JGR's thread... :oops:

Re: JGR's Patch Pack

Posted: 10 Feb 2021 06:37
by Deicide
When using original braking model, the train starts slowing down immediately upon entering a station and brakes very "aggressively" taking really long to actually arrive. In the base game this isn't the same, as trains start decelerating 4 tiles before the stopping point and do so a lot "faster" allowing trains to arrive earlier.

Long story short: "original braking model" is not the same as "original".

Also, both tests were done with Iron Horse with no speed limits on cars.

Re: JGR's Patch Pack

Posted: 10 Feb 2021 22:52
by MichalSoldat
Hello to everyone 8) ,
would it be possible to add a feature to set as "go to" order a specific signal (and if in the timetable somone sets a valuve to "stay for >0" to stop before signal. So train doesn't reserve furtherway) ?

That would let us build more complex timetables without need of building waypoints. Also u can't build waypoint or station on crosswise tiles, so that would help us to save space.
Thanks for response :bow:

Re: JGR's Patch Pack

Posted: 11 Feb 2021 00:21
by JGR
jor[D]1 wrote: 06 Feb 2021 21:42 Conditional order with Time condition could be a really usefull feature for this also. Had the same issue recently. Don't know if it's possible to create such an order with a patch.
This is added now.
Deicide wrote: 10 Feb 2021 06:37 When using original braking model, the train starts slowing down immediately upon entering a station and brakes very "aggressively" taking really long to actually arrive. In the base game this isn't the same, as trains start decelerating 4 tiles before the stopping point and do so a lot "faster" allowing trains to arrive earlier.

Long story short: "original braking model" is not the same as "original".

Also, both tests were done with Iron Horse with no speed limits on cars.
This is fixed now.
MichalSoldat wrote: 10 Feb 2021 22:52 Hello to everyone 8) ,
would it be possible to add a feature to set as "go to" order a specific signal (and if in the timetable somone sets a valuve to "stay for >0" to stop before signal. So train doesn't reserve furtherway) ?

That would let us build more complex timetables without need of building waypoints. Also u can't build waypoint or station on crosswise tiles, so that would help us to save space.
Thanks for response :bow:
This may be technically possible, but I don't think that it would be an ideal solution from a gameplay point of view.
Order management would be a problem, and eventually you want to move the signal or have more than one equivalent signal to support multiple trains (i.e. shared orders).

Re: JGR's Patch Pack

Posted: 11 Feb 2021 06:14
by ino
Seeing that there are starting to have more features that are tied to wall clock HH:MM, have you considered making the wall clock setting a per-save setting instead of client setting?

Re: JGR's Patch Pack

Posted: 11 Feb 2021 06:22
by MichalSoldat
This may be technically possible, but I don't think that it would be an ideal solution from a gameplay point of view.
Order management would be a problem, and eventually you want to move the signal or have more than one equivalent signal to support multiple trains (i.e. shared orders).
Yeah you a right. I got another idea how to get around this. In route restrictions window for signals is a position called "wait at PBS Signal", if we chose it you can't set amount of time to wait at it (train will wait forever. Or am i something missing?). Adding a possibility to set time together with condition to test program by trains number (also missing) will also do this job.

Re: JGR's Patch Pack

Posted: 11 Feb 2021 11:24
by JGR
ino wrote: 11 Feb 2021 06:14 Seeing that there are starting to have more features that are tied to wall clock HH:MM, have you considered making the wall clock setting a per-save setting instead of client setting?
It is already a per-save setting.
MichalSoldat wrote: 11 Feb 2021 06:22
This may be technically possible, but I don't think that it would be an ideal solution from a gameplay point of view.
Order management would be a problem, and eventually you want to move the signal or have more than one equivalent signal to support multiple trains (i.e. shared orders).
Yeah you a right. I got another idea how to get around this. In route restrictions window for signals is a position called "wait at PBS Signal", if we chose it you can't set amount of time to wait at it (train will wait forever. Or am i something missing?). Adding a possibility to set time together with condition to test program by trains number (also missing) will also do this job.
You can use a conditional on the current time or some other property of the train
You can test the group membership of the train.
You might want to look into slots as they could be useful for your use-case.

Re: JGR's Patch Pack

Posted: 11 Feb 2021 15:53
by ino
JGR wrote: 11 Feb 2021 11:24
ino wrote: 11 Feb 2021 06:14 Seeing that there are starting to have more features that are tied to wall clock HH:MM, have you considered making the wall clock setting a per-save setting instead of client setting?
It is already a per-save setting.
It already is? Sorry, I must have missed the change. Nice.

Re: JGR's Patch Pack

Posted: 12 Feb 2021 23:20
by MichalSoldat
You can use a conditional on the current time or some other property of the train
You can test the group membership of the train.
You might want to look into slots as they could be useful for your use-case.
Thanks i used current time feature and it works well!
BTW do you have some kind of roadmap of future development of patch?

Re: JGR's Patch Pack

Posted: 12 Feb 2021 23:41
by JGR
MichalSoldat wrote: 12 Feb 2021 23:20 BTW do you have some kind of roadmap of future development of patch?
Things which have been implemented but are not in a release yet, issues, PRs, and such are available on Github.
Other than that not really.