You may have desync issues if improved breakdowns is enabled, if that's turned off you'll probably be fine.Mizari wrote:Are there any instabilities with multiplayer to be expected?
I'll likely do another release soonish with that sorted.
Moderator: OpenTTD Developers
You may have desync issues if improved breakdowns is enabled, if that's turned off you'll probably be fine.Mizari wrote:Are there any instabilities with multiplayer to be expected?
Code: Select all
Crash reason:
Signal: Aborted (6)
Message: Assertion failed at line 39 of /home/samira/games/openttd/openttd.jgrpp/src/rail_map.h: IsTileType(t, MP_RAILWAY)
OpenTTD version:
Version: jgrpp-0.5.2-8-gd715b7e (0)
NewGRF ver: 16006b0a
Bits: 32
Endian: little
Dedicated: no
Build date: Sep 30 2015 14:36:00
Stacktrace:
[00] 0x83a32f8 ./openttd CrashLogUnix::LogStacktrace(char*, char const*) const + 0x118
[01] 0x828006e ./openttd CrashLog::FillCrashLog(char*, char const*) const + 0xce
[02] 0x828028b ./openttd CrashLog::MakeCrashLog() const + 0x5b
[03] 0x83a315b ./openttd + 0x35b15b
[04] 0xb76eabbc __kernel_sigreturn + 0x0
[05] 0xb76eabe0 __kernel_vsyscall + 0x10
[06] 0xb572e297 /lib/libc.so.6 gsignal + 0x47
[07] 0xb572fb69 /lib/libc.so.6 abort + 0x149
[08] 0x838f35f ./openttd + 0x34735f
[09] 0x812789f ./openttd + 0xdf89f
[10] 0x83d54f6 ./openttd SignalStateCondition::IsSignalValid() + 0x86
[11] 0x83d5584 ./openttd SignalStateCondition::~SignalStateCondition() + 0x14
[12] 0x83d55ce ./openttd SignalStateCondition::~SignalStateCondition() + 0xe
[13] 0x83d4eb8 ./openttd SignalIf::Remove() + 0x18
[14] 0x83d5399 ./openttd SignalSpecial::Remove() + 0x29
[15] 0x83d6039 ./openttd SignalProgram::~SignalProgram() + 0x19
[16] 0x83d6f30 ./openttd FreeSignalProgram(SignalReference) + 0x50
[17] 0x8422cf8 ./openttd + 0x3dacf8
[18] 0x8420cfc ./openttd + 0x3d8cfc
[19] 0x84217aa ./openttd SaveOrLoad(char const*, int, Subdirectory, bool) + 0x25a
[20] 0x83916d0 ./openttd SwitchToMode(SwitchMode) + 0x370
[21] 0x8392f33 ./openttd GameLoop() + 0x43
[22] 0x850d754 ./openttd VideoDriver_SDL::MainLoop() + 0x224
[23] 0x8390b8f ./openttd openttd_main(int, char**) + 0x14cf
[24] 0x8171d50 ./openttd main + 0x60
[25] 0xb5718e7e /lib/libc.so.6 __libc_start_main + 0xde
[26] 0x81c6c9d ./openttd + 0x17ec9d
Operating system:
Name: Linux
Release: 4.1.6-100.fc21.i686+PAE
Version: #1 SMP Mon Aug 17 22:43:44 UTC 2015
Machine: i686
Compiler: GCC 4.9.2 "4.9.2 20150212 (Red Hat 4.9.2-6)"
Code: Select all
Writing crash savegame...
dbg: [sl] Programmable signal information for (ec0ba, 0) has been leaked!
Error: Assertion failed at line 39 of /home/samira/games/openttd/openttd.jgrpp/src/rail_map.h: IsTileType(t, MP_RAILWAY)
Aborted (core dumped)
I'll certainly consider this for possible future addition.Wipe wrote:Would be nice to have dedicated category in settings, with options not present in trunk only.
Thanks for reporting this.Wipe wrote:There's a crash coming from programmable signals; happened during manual save, when there was no rails built at all yet [just a small ship network].
Oh, i'm too slowJGR wrote: It seems that programmable signal programs are not cleared when initialising a new game, so any signal programs which were in the previous game get carried over and this quite upsets the savegame code when these dangling signal programs now point to tiles which aren't rails/signals. This should be fixed in the next release and on git, shortly.
Code: Select all
[07] 0xb5780b69 /lib/libc.so.6 abort + 0x149
[08] 0x838f35f ./openttd + 0x34735f
[09] 0x846b315 ./openttd + 0x423315
[10] 0x846b4ad ./openttd UpdateSignalsInBuffer() + 0x1d
[11] 0x83d6a05 ./openttd CmdModifySignalInstruction(unsigned int, DoCommandFlag, unsigned int, unsigned int, char const*) + 0x445
[12] 0x826a569 ./openttd DoCommandPInternal(unsigned int, unsigned int, unsigned int, unsigned int, void (*)(CommandCost const&, unsigned int, unsigned int, unsigned int), char const*, bool, bool, unsigned int) + 0x239
[13] 0x826ab77 ./openttd DoCommandP(unsigned int, unsigned int, unsigned int, unsigned int, void (*)(CommandCost const&, unsigned int, unsigned int, unsigned int), char const*, bool, unsigned int) + 0xb7
[14] 0x83d96d6 ./openttd ProgramWindow::OnDropdownSelect(int, int) + 0x196
[15] 0x852ac70 ./openttd DropdownWindow::OnMouseLoop() + 0x200
[16] 0x8530806 ./openttd InputLoop() + 0x2c6
[17] 0x8392fc6 ./openttd GameLoop() + 0xd6
-snip-
dbg: [misc] SignalSegment too complex. Set _globset is full (maximum 128) // spams same message about dozen of times
If possible, could you post a screenshot of what your track layout looks like here, or a savegame?Wipe wrote:Hmm, there also seems that are problems with tracking if signals used in program are still valid... or something.
Here you go. Any attempt to delete psignals A-D in any order leads to crash.JGR wrote:or a savegame?
This should be fixed now. When the target of a signal condition was deleted, or when clearing previous signal programs after creating a new map, the signal condition destructor used a function only valid on rail tiles to check whether the tile was a valid signal.Wipe wrote:Here you go. Any attempt to delete psignals A-D in any order leads to crash.
This is something I looked at for a bit when implementing routing restrictions. If I remember correctly it seemed unexpectedly clunky to implement something like that, so I left it out. At some point in the future I may go and add it.Wipe wrote:PS: goto signal could hilight a tile for a short time [like "you cannot build here" does] aside of centering, would be easier to find what depends on what if you have many signals next to each other.
Stigah wrote:I've been playing 0.4.1 for awhile now, and I just downloaded 0.5.2.
I'm trying to start a new game, but I always get this error message:
"Map generation aborted...
no suitable town locations"
Is this a bug?
I just tried it and got an all water map (or at least as far as I was prepared to scroll).Eddi wrote:try to recreate the map with these settings in the scenario editor. it might be that you get all-water maps.
if you want flat maps, you should probably disable variety distribution.
It seems that this is a bug in the terrain generator when both map edges are longer than 4096. I've fixed this now and it'll be in the next release.Stigah wrote:I found out that 16384x16384 was a little bit too huge, so I changed it to 8192x8192. I changed variety distribution to none, and terrain type to flat.
It's still not working, unfortunately. Do you have any idea what I could do to fix this?
THX, Worked like a Charme out of the Box 2 compile ... lets hope it runs stable ... nice collection of patches, have 2 try them out next days ...JGR wrote:
Alternatively it may be easier for you to clone the repo using:Code: Select all
git clone -b jgrpp https://github.com/JGRennison/OpenTTD-patches.git jgrpp && cd jgrpp
If you can remember, did the crash occur when you pressed the "Buy Vehicle" button, or did it occur when you did something else?ISA wrote:I am not sure what caused the crash. If its not in the patch let me know and I do the proper post where needed
If I am correct I was start buying this highlighted road vehicle in the buy menu. If that's not it then second guess would be that I was starting to give orders to a vehicle, but if I look to the picture I haven't bought any metal road vehicles... so this kinda rules thing out.JGR wrote:If you can remember, did the crash occur when you pressed the "Buy Vehicle" button, or did it occur when you did something else?ISA wrote:I am not sure what caused the crash. If its not in the patch let me know and I do the proper post where needed
From the screenshot I'm guessing it's the buy and refit patch, but I'll have to look in more detail tomorrow.
The problem appears to be that the cost estimation is incorrect for articulated/multi-head vehicles where there is a non-zero cost for refitting the trailing vehicle parts.ISA wrote:If I am correct I was start buying this highlighted road vehicle in the buy menu. If that's not it then second guess would be that I was starting to give orders to a vehicle, but if I look to the picture I haven't bought any metal road vehicles... so this kinda rules thing out.
This is now available in v0.6.0 in the first post, along with some other fixes.JGR wrote:The problem appears to be that the cost estimation is incorrect for articulated/multi-head vehicles where there is a non-zero cost for refitting the trailing vehicle parts.ISA wrote:If I am correct I was start buying this highlighted road vehicle in the buy menu. If that's not it then second guess would be that I was starting to give orders to a vehicle, but if I look to the picture I haven't bought any metal road vehicles... so this kinda rules thing out.
This should be fixed in the next release, thanks for the bug report.
Code: Select all
auge@Desktop:~/OpenTTD/JGR/jgrpp$ make
make[1]: Verzeichnis »/home/auge/OpenTTD/JGR/jgrpp/objs/lang« wird betreten
[LANG] Compiling string.cpp
[LANG] Compiling and Linking strgen
strgen_base.o: In Funktion `StringReader::ParseFile()':
strgen_base.cpp:(.text+0x1b10): Nicht definierter Verweis auf `strecpy(char*, char const*, char const*)'
strgen_base.cpp:(.text+0x1b24): Nicht definierter Verweis auf `strecpy(char*, char const*, char const*)'
strgen_base.cpp:(.text+0x1b38): Nicht definierter Verweis auf `strecpy(char*, char const*, char const*)'
strgen.o: In Funktion `mkpath(char*, char const*, char const*, char const*)':
strgen.cpp:(.text+0x14): Nicht definierter Verweis auf `strecpy(char*, char const*, char const*)'
strgen.cpp:(.text+0x48): Nicht definierter Verweis auf `strecpy(char*, char const*, char const*)'
strgen.o:strgen.cpp:(.text+0xd43): Weitere nicht definierte Verweise auf `strecpy(char*, char const*, char const*)' folgen
collect2: error: ld returned 1 exit status
make[1]: *** [strgen] Fehler 1
make[1]: Verzeichnis »/home/auge/OpenTTD/JGR/jgrpp/objs/lang« wird verlassen
make: *** [all] Fehler 1
auge@Desktop:~/OpenTTD/JGR/jgrpp$
Users browsing this forum: No registered users and 2 guests