Re: JGR's Patch Pack
Posted: 06 Feb 2021 18:34
Build 0.40.1 for macOS
The place to talk about Transport Tycoon
https://www.tt-forums.net/
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.Bernasrebelo11 wrote: ↑03 Feb 2021 01:03Thank you one more questionAuge wrote: ↑02 Feb 2021 22:03 Hello
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.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
Tschö, Auge
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?
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
I will take another look at this. This ought to be technically possible.
Pragmatically speaking, the original model will be maintained in order to keep compatibility with upstream.
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.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?).
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.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:
Any suggestions on how to fix this?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
Thanks in advance!
Unfortunately, that one crashes on my system. This is the crash report I get: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.
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 ***
I will do some investigating to see how this may be able to be resolved.
You may be able to get around this by installing LLVM from homebrew as well.
Code: Select all
brew update
brew install llvm
Code: Select all
export PATH="/usr/local/opt/llvm/bin:$PATH"
This is a suggestion for vincentkoevoets , who compiled it above, right?JGR wrote: ↑07 Feb 2021 22:55You may be able to get around this by installing LLVM from homebrew as well.
Stackoverflow suggests that you can do:Then (temporarily) put the above LLVM installation in your path by means of:Code: Select all
brew update brew install llvm
Then delete the CMakeCache.txt file and try the build again.Code: Select all
export PATH="/usr/local/opt/llvm/bin:$PATH"
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
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?vincentkoevoets wrote: ↑08 Feb 2021 09:55 I'm thinking that maybe it's time to set up a Mac OS building/compiling thread..
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.
This is added now.
This is fixed 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 may be technically possible, but I don't think that it would be an ideal solution from a gameplay point of view.MichalSoldat wrote: ↑10 Feb 2021 22:52 Hello to everyone ,
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
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.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).
It is already a per-save setting.
You can use a conditional on the current time or some other property of the trainMichalSoldat wrote: ↑11 Feb 2021 06:22Yeah 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.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).
It already is? Sorry, I must have missed the change. Nice.
Thanks i used current time feature and it works well!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.
Things which have been implemented but are not in a release yet, issues, PRs, and such are available on Github.MichalSoldat wrote: ↑12 Feb 2021 23:20 BTW do you have some kind of roadmap of future development of patch?