I just tried to compile your latest version (0.41.0) on my system, which is OS X 10.12 . I could compile versions up to 0.40.5 with no problems, thanks to your previous fix.
Now, at around 60%, I come across the following error:
[ 63%] Building CXX object CMakeFiles/openttd.dir/src/network/network_udp.cpp.o
/roba/OpenTTD-patches-jgrpp-0.41.0/src/network/network_udp.cpp:733:18: error: expected ';' after
expression
std::scoped_lock lock(_udp_client.mutex, _udp_server.mutex, _udp_master.mutex);
^
;
/roba/OpenTTD-patches-jgrpp-0.41.0/src/network/network_udp.cpp:733:7: error: no member named
'scoped_lock' in namespace 'std'; did you mean 'adopt_lock'?
std::scoped_lock lock(_udp_client.mutex, _udp_server.mutex, _udp_master.mutex);
~~~~~^~~~~~~~~~~
adopt_lock
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/__mutex_base:79:25: note:
'adopt_lock' declared here
constexpr adopt_lock_t adopt_lock = adopt_lock_t();
^
/roba/OpenTTD-patches-jgrpp-0.41.0/src/network/network_udp.cpp:733:2: warning: expression result
unused [-Wunused-value]
std::scoped_lock lock(_udp_client.mutex, _udp_server.mutex, _udp_master.mutex);
^~~~~~~~~~~~~~~~
1 warning and 2 errors generated.
make[2]: *** [CMakeFiles/openttd.dir/src/network/network_udp.cpp.o] Error 1
make[1]: *** [CMakeFiles/openttd.dir/all] Error 2
make: *** [all] Error 2
Your Mac OS bin works fine with my system, so my question is more of a curiosity. Would this be an easy error to fix? If so, it'd be great if it could get fixed, since I would still welcome the opportunity of compiling your patchpack myself.
Thanks in advance!
This is from some upstream improvements to networking. I've added a workaround which should enable you to compile it.
EDIT: I may have figured it out - I was playing with OpenTTD 1.11.1 earlier and I had hardware acceleration and vsync enabled. Disabled those, re-launched, loaded fine. Leaving it here for JGR to double-check.
------------------------------------------------------------------
Just tried launching 0.41.0 and I'm hit with this error:
Error! Assertion failed at line 996 of /home/jgr/openttd/jgrpp/src/video/win32_v.cpp: _screen.dst_ptr != nullptr
---- gamelog start ----
Tick 62675: game loaded
Conversion from OTTD savegame without gamelog: version 4, 1
Revision text changed to jgrpp-0.41.0, savegame version 290, not modified, _openttd_newgrf_version = 0x1c006d64
New game mode: 0 landscape: 1
---- gamelog end ----
Hello everyone, I'm trying to compile the Patch Pack from source. Which generally works, however when I launch the game, load a save and zoom out on the map it lags a lot. It generally seems that my compiled version runs a lot slower. Map generation is slower too. I'm building on Windows with Visual Studio Community 2019.
I've tested the same with vanilla OpenTTD and the same issue occurs there too, so it's probably an issue with some settings. Has anyone experienced this and knows a solution?
I've tried changing the configuration from Debug to Release, but that made no difference.
Hey JGR,
I've noticed that in v0.41.0 house IDs have been increased. I wonder if a similar increase could also be done to the current maximum of 64 road types?
Thanks!
mxnp wrote: ↑20 Apr 2021 12:36
I've noticed that in v0.41.0 house IDs have been increased. I wonder if a similar increase could also be done to the current maximum of 64 road types?
Holy s***! What the heck wants one with more than 64 road types? I am a bit overwhelmed with testing my own set in development with currently only 10 types. )
mxnp wrote: ↑20 Apr 2021 12:36
I've noticed that in v0.41.0 house IDs have been increased. I wonder if a similar increase could also be done to the current maximum of 64 road types?
Holy s***! What the heck wants one with more than 64 road types? I am a bit overwhelmed with testing my own set in development with currently only 10 types. )
Tschö, Auge
"640Kb will be enough for everyone"
I'm starting to think that 64 rail types might not be enough but I wouldn't dare to ask our OTTD developers to increase that limit.
The French Narrow Gauge Train Set is now released! Get it here
Auge wrote: ↑20 Apr 2021 13:59
Holy s***! What the heck wants one with more than 64 road types? I am a bit overwhelmed with testing my own set in development with currently only 10 types. )
Snail wrote: ↑20 Apr 2021 14:27
"640Kb will be enough for everyone"
I'm starting to think that 64 rail types might not be enough but I wouldn't dare to ask our OTTD developers to increase that limit.
HAHA I was scared to ask this question. I promise I'm not going insane with all your GRF releases, yet!
Unfortunately you start running out when using the latest U&RaTT with GarryG's AuzRoads—maybe I'll just make my own personal set in the future.
mxnp wrote: ↑20 Apr 2021 12:36
Hey JGR,
I've noticed that in v0.41.0 house IDs have been increased. I wonder if a similar increase could also be done to the current maximum of 64 road types?
Thanks!
I'm not going to be doing that.
64 types is already too many from a UI point of view.
Having more and more types to compensate for the lack of composability of road/tram properties isn't a good approach.
Most sets with large number of types have minuscule differences between most of them.
kamnet wrote: ↑19 Apr 2021 04:34EDIT: I may have figured it out - I was playing with OpenTTD 1.11.1 earlier and I had hardware acceleration and vsync enabled. Disabled those, re-launched, loaded fine. Leaving it here for JGR to double-check.
------------------------------------------------------------------
Just tried launching 0.41.0 and I'm hit with this error:
Error! Assertion failed at line 996 of /home/jgr/openttd/jgrpp/src/video/win32_v.cpp: _screen.dst_ptr != nullptr
---- gamelog start ----
Tick 62675: game loaded
Conversion from OTTD savegame without gamelog: version 4, 1
Revision text changed to jgrpp-0.41.0, savegame version 290, not modified, _openttd_newgrf_version = 0x1c006d64
New game mode: 0 landscape: 1
---- gamelog end ----
Upstream are looking into this. There's not a great deal that I can do other than disabling OpenGL again.
Nrgte wrote: ↑19 Apr 2021 10:55
Hello everyone, I'm trying to compile the Patch Pack from source. Which generally works, however when I launch the game, load a save and zoom out on the map it lags a lot. It generally seems that my compiled version runs a lot slower. Map generation is slower too. I'm building on Windows with Visual Studio Community 2019.
I've tested the same with vanilla OpenTTD and the same issue occurs there too, so it's probably an issue with some settings. Has anyone experienced this and knows a solution?
I've tried changing the configuration from Debug to Release, but that made no difference.
I've not used Visual Studio in quite a few years now, so I can't really help there unfortunately.
Are you going via CMake?
JGR wrote: ↑20 Apr 2021 17:12
I've not used Visual Studio in quite a few years now, so I can't really help there unfortunately.
Are you going via CMake?
Yes, I basically did everything that was listed in the compiling.md doc. Using CMake with vcpkg and then make the exectuble with Visual Studio. According to the documenation this seems to be the default way of building OpenTTD on Windows. The build process works flawlessly, it's just that the built executable is lagging horribly when I zoom out and the map generation takes a lot longer than your pre-built executable as well as the pre-built executable of vanilla OpenTTD.
JGR wrote: ↑20 Apr 2021 17:12
I've not used Visual Studio in quite a few years now, so I can't really help there unfortunately.
Are you going via CMake?
Yes, I basically did everything that was listed in the compiling.md doc. Using CMake with vcpkg and then make the exectuble with Visual Studio. According to the documenation this seems to be the default way of building OpenTTD on Windows. The build process works flawlessly, it's just that the built executable is lagging horribly when I zoom out and the map generation takes a lot longer than your pre-built executable as well as the pre-built executable of vanilla OpenTTD.
Just a thought. It's been a year or two since I compiled. It seems to me that there was an option to compile a debug version which adds a lot of overhead to the binary. Might this be your problem? How big is your product compared to vanilla or jgrpp?
JGR wrote: ↑20 Apr 2021 17:08
I'm not going to be doing that.
64 types is already too many from a UI point of view.
Having more and more types to compensate for the lack of composability of road/tram properties isn't a good approach.
Most sets with large number of types have minuscule differences between most of them.
Yep that's reasonable, as you said, with the current limit the UI already fills the whole screen, and it's probably more the fault of the design approach with road sets, than the actual game. (A little bit annoying that trams and roads share the same limit, but the limit is reasonable.)
I'm going to have to refrain from posting when I'm still half-awake...
mxnp wrote: ↑20 Apr 2021 12:36
Hey JGR,
I've noticed that in v0.41.0 house IDs have been increased. I wonder if a similar increase could also be done to the current maximum of 64 road types?
Thanks!
I'm not going to be doing that.
64 types is already too many from a UI point of view.
Having more and more types to compensate for the lack of composability of road/tram properties isn't a good approach.
Most sets with large number of types have minuscule differences between most of them.
I'll definitely agree with this, as much as I LOVE cramming as much stuff in as possible, there is no reason to play with more than one, maybe two road sets. Most of them have so much stuff that overlaps already. If anything, we need developers to focus on more carefully curating their sets rather than throwing a bunch of sets together.
mxnp wrote: ↑20 Apr 2021 12:36
Hey JGR,
I've noticed that in v0.41.0 house IDs have been increased. I wonder if a similar increase could also be done to the current maximum of 64 road types?
Thanks!
I'm not going to be doing that.
64 types is already too many from a UI point of view.
Having more and more types to compensate for the lack of composability of road/tram properties isn't a good approach.
Most sets with large number of types have minuscule differences between most of them.
I'll definitely agree with this, as much as I LOVE cramming as much stuff in as possible, there is no reason to play with more than one, maybe two road sets. Most of them have so much stuff that overlaps already. If anything, we need developers to focus on more carefully curating their sets rather than throwing a bunch of sets together.
Not sure how deceleration in advanced braking model works, but maybe it would be interesting to take tractive effort of all vehicles into account?
So newgrf maker can easily simulate all these brake-less wagons just by putting TE 0 (usually it is default 0.3 and not used).