Times are UTC Toggle Colours
00:00:21 *** nielsm has quit IRC 00:00:29 <LordAro> wouldn't normally have that affect 00:00:56 <glx> nice a segfault when rendering the docs 00:01:48 <glx> (graphviz crash I guess) 00:02:59 <glx> let's uninstall graphviz then 00:05:21 <glx> better without graphviz :) 00:06:05 <glx> language warnings and finally nmlc ERROR: "generated/firs.nml", line 7342: Syntax error, unexpected token "waiting_cargo_1" 00:06:23 <glx> so firs is broken :) 00:07:18 <glx> needs older nmlc I guess 00:07:28 *** Smedles has quit IRC 00:08:47 <glx> anyway for docs I needed to install python3-markdown 00:09:44 <glx> so using mingw it 'works' 00:10:06 <Flo> oh god...im so dumb...i just noticed i installed setuptools and cameleon but forgot markdowns... 00:10:13 <glx> nmlc errors, but makefile just works 00:11:35 <glx> with mingw it's often easier to install python module via pacboy (pip should work but sometimes fails if there's a module to compile) 00:12:11 <glx> anyway if pip works it's ok too 00:12:31 <glx> I think it failed for pillow 00:13:25 <Flo> there added markdown now :) i though ive put the 3...but ive only put 2... 00:14:52 <Flo> ugh... 00:14:58 <Flo> same still happening 00:15:03 *** Flygon has joined #openttd 00:15:25 <glx> oh of course it needs python3 exe 00:15:37 <glx> try "pacboy -S python3" 00:15:52 <Flo> pacboy -S python3 00:16:01 <Flo> sh: pacboy: command not found 00:16:21 <glx> oh you're on the old mingw 00:16:39 <glx> ie mingw32 00:16:44 <Flo> yes 00:16:54 <glx> you should move to mingw-w64 00:16:57 *** Smedles has joined #openttd 00:17:03 <glx> mingw32 is outdated 00:17:12 <Flo> oh 00:17:24 <LordAro> i'm surprised you managed to get as far as you did 00:17:42 <LordAro> especially python3.8 00:18:14 <glx> it's using the windows installed python 00:18:37 <LordAro> ah, that makes sense 00:19:31 *** supermop_work_ has quit IRC 00:19:47 <glx> hmm typing python3 doesn't error in powershell, but it does nothing it seems 00:21:10 <glx> haha in cmd it opens windows store 00:21:11 <Flo> im installing the new mingw now 00:21:19 <Flo> oh wow 00:22:26 <Flo> buy python3, starting from only 199,99$. only available for windows proffesional 00:23:45 <LordAro> ? 00:23:54 <Flo> it was a joke 00:24:05 <Flo> when he said cmd took him to windows store 00:24:24 <LordAro> oh lol 00:24:24 <glx> yeah it's free, but it can be annoying :) 00:24:50 *** supermop_work_ has joined #openttd 00:25:03 <glx> https://www.microsoft.com/en-us/p/python-37/9nj46sx7x90p?activetab=pivot:overviewtab 00:25:07 <glx> that's the page 00:25:59 <glx> it's a shortcut they added in the last major update IIRC 00:27:44 <Flo> there :) added new mingw 00:34:18 <glx> follow initial pacman -Syu steps ? 00:35:16 <Flo> yes i did that 00:35:43 <glx> you can close msys2 and open mingw 00:36:39 <glx> you'll need to do "pacboy -S python3" 00:38:06 <glx> and some other packages are needed too 00:38:47 <Flo> its doing python3 right now :) 00:39:06 <Flo> thx for the help btw 00:39:11 <Flo> its really apreciated 00:40:00 <glx> probably "pacboy -S make" too 00:41:16 <glx> that should be a good start 00:41:40 <glx> of course you'll need to install required python modules too 00:42:11 <Flo> i guess :) 00:42:19 <glx> via "pip install" or "pacboy -S python3-<module>" if pip fails 00:42:57 <LordAro> i'd start with the latter 00:43:24 <Flo> there, python3 and make added :) 00:45:18 <Flo> python3 command works but not make 00:45:45 <glx> what does it say ? 00:46:14 <Flo> $ make 00:46:15 <Flo> -bash: make: command not found 00:47:39 <glx> but it should be installed 00:47:44 <Flo> ik... 00:49:52 *** Progman has quit IRC 00:52:09 <Flo> it is there 00:52:11 <Flo> C:\msys64\var\lib\pacman\local\mingw-w64-x86_64-make-4.2.1-4 00:55:04 *** supermop_work_ has quit IRC 00:56:00 <glx> pacboy packages | grep install | grep make 00:56:08 <glx> you should see it there too 00:57:22 <DorpsGek_III> [OpenTTD/OpenTTD] MingweiSamuel dismissed a review for pull request #7595: Possible fix for #7430: when train visits station, only reset time_since_pickup if has room to load https://git.io/Jeiuh 00:57:23 <DorpsGek_III> [OpenTTD/OpenTTD] MingweiSamuel updated pull request #7595: Possible fix for #7430: when train visits station, only reset time_since_pickup if has room to load https://git.io/fjlA7 00:58:45 <glx> I can see I have the 3 variants installed mingw32 mingw64 and msys 01:00:04 *** supermop_work_ has joined #openttd 01:00:29 <Flo> theres nothing in C:\msys64\var\cache\pacboy 01:01:15 <Flo> idk how to check pacboy packages | grep install | grep make 01:01:30 <glx> just type it in mingw shell 01:02:08 <Flo> oh wait i found it 01:02:11 <Flo> oh sorry 01:03:07 <glx> my output for this command contains: 01:03:07 <glx> mingw32 mingw-w64-i686-make 4.2.1-4 [installé] 01:03:07 <glx> mingw64 mingw-w64-x86_64-make 4.2.1-4 [installé] 01:03:07 <glx> msys make 4.2.1-1 [installé] 01:03:53 <glx> (and cmake and many automake but that's useless for you) 01:05:07 <Flo> pacboy packages | grep install | grep make 01:05:07 <Flo> mingw32 mingw-w64-i686-make 4.2.1-4 [installed] 01:05:07 <Flo> mingw64 mingw-w64-x86_64-make 4.2.1-4 [installed] 01:05:17 <Flo> msysmake not there 01:05:35 <glx> so it's installed for mingw 01:06:26 <glx> I guess "which make" fails 01:06:49 <Flo> yes 01:07:44 *** WormnestAndroid has quit IRC 01:07:57 <Flo> there 01:08:02 <Flo> i added it for msys 01:08:06 <Flo> now the 3 are there :) 01:08:30 <glx> yeah it seems it's using msys one on my system 01:08:39 *** WormnestAndroid has joined #openttd 01:09:20 <Flo> yeah i added the msys one and now make is available 01:09:20 <glx> of I know why 01:09:48 <glx> it's because mingw make are called mingw64-make and mingw32-make 01:09:56 <Flo> oh 01:11:37 <glx> a bit silly but ok :) 01:12:02 <glx> so now you have make and python3 01:12:13 <Flo> yes :) 01:14:24 <glx> I don't know if pip is installed via python3 01:15:56 <glx> but it's easy to "pacboy -S python3-pip" if it's not 01:18:28 <Flo> installing pip 01:18:47 <glx> usual python modules are also available in packages 01:19:02 <Flo> installed 01:19:55 <Flo> there 01:20:02 <Flo> pip is now available 01:20:56 <glx> hmm first try "pacboy -S python3-<module>", I know pillow install fails with pip 01:22:20 <Flo> pacboy -S python3-<module> 01:22:21 <DorpsGek_III> [OpenTTD/OpenTTD] MingweiSamuel commented on pull request #7595: Possible fix for #7430: when train visits station, only reset time_since_pickup if has room to load https://git.io/Je1wQ 01:22:43 <Flo> $ pacboy -S python3-<module> 01:22:43 <Flo> -bash: syntax error near unexpected token `newline' 01:22:51 <glx> replace <module> with its name 01:22:56 <Flo> oh sorry 01:23:17 <glx> pacboy -S python3-ply python-pillow 01:23:38 <glx> *python3-pillow sorry 01:23:49 <glx> python3-markdown exists too 01:24:27 <glx> I think you'll need pip only for nml 01:24:50 <Flo> $ pacboy -S python3-pillow 01:24:50 <Flo> error: target not found: python3-pillow 01:26:11 <Flo> same with python3-markdown 01:27:13 <glx> but I have them 01:27:24 <glx> pacboy find pillow 01:27:41 <glx> it should show them (even uninstalled) 01:27:49 <Flo> oh I see why 01:27:58 <Flo> I was in msys 01:28:00 <glx> hehe 01:29:13 <Flo> there they added :) 01:29:32 <glx> if you want to install something for msys you can do it from mingw by just adding :m to the package name (pacboy -S make:m) 01:29:50 <Flo> oh thats cool to know :) 01:29:53 <Flo> thx for the info 01:30:18 *** supermop_work_ has quit IRC 01:31:27 *** supermop_work_ has joined #openttd 01:33:54 <glx> oh no sorry I miss read the help 01:34:16 <glx> For 64-bit MSYS2, name:i means i686-only 01:34:16 <glx> For 64-bit MSYS2, name:x means x86_64-only 01:34:16 <glx> For MSYS shell, name:m means mingw-w64 01:34:42 <glx> so to install stuff in msys you need to be in msys 01:35:03 <Flo> oh 01:35:04 <glx> but from msys you can install in mingw using :m 01:35:04 <Flo> ok 01:35:07 <Flo> oh 01:35:32 <glx> use "pacman help" to see more details 01:36:09 <glx> anyway you rarely need to install stuff in msys 01:36:14 <Flo> oh 01:36:54 <glx> unless like make it doesn't work as expected 01:37:10 <Flo> right 01:37:15 <Flo> I still get this though: 01:37:17 <Flo> which: no dot in (/mingw64/bin:/usr/local/bin:/usr/bin:/bin:/c/Windows/System32:/c/Windows:/c/Windows/System32/Wbem:/c/Windows/System32/WindowsPowerShell/v1.0/) 01:37:43 <glx> yeah, it's graphviz, ignore ite 01:37:45 <glx> *it 01:38:11 <Flo> oh ok 01:38:18 <glx> doc generation crashed for me when I installed graphviz ;) 01:38:37 <glx> it's optionnal anyway 01:38:41 <Flo> Oh 01:38:42 <Flo> Yeah 01:38:55 <Flo> Well then the last thing I get seems to be ModuleNotFoundError: No module named 'chameleon' 01:38:55 <Flo> make: *** [Makefile:75: generated/lang] Error 1 01:39:06 <Flo> But U got cameloan in my python... I think? 01:39:08 <Flo> I* 01:40:29 <Flo> Its in my python folder, but idk if it has to be in mingw 01:40:44 <glx> it's not the same python install 01:41:14 <Flo> oh 01:41:15 <glx> and it's not available as a mingw package, so pip install chameleon 01:41:34 <Flo> ok. how do I do pip install eacly? 01:41:57 <Flo> oh 01:41:59 <Flo> found it 01:45:35 <Flo> ok so I did pip install chameleon 01:45:44 <Flo> I still get no module called chameleon 01:45:45 <glx> usually for a missing python module you do "pacboy -S python3-<modulename>", and if it fails "pip install <modulename>" 01:46:28 <Flo> it said it installed chameleon with pip 01:46:41 <Flo> but I still get the module missing thing with make 01:46:52 <glx> installed in mingw ? 01:47:19 <glx> "pip list" should show all installed modules 01:47:58 <Flo> its in the list 01:49:30 <Flo> ModuleNotFoundError: No module named 'chameleon' 01:49:30 <Flo> make: *** [Makefile:78: docs] Error 1 01:49:30 <Flo> Florence@Flo-s-Laptop MINGW64 /c/Users/Florence/Downloads/firs-masterf/firs-master2 01:49:30 <Flo> $ pip list 01:49:30 <Flo> Package Version 01:49:32 <Flo> ---------- --------------------- 01:49:32 <Flo> appdirs 1.4.3 01:49:34 <Flo> attrs 19.3.0 01:49:34 <Flo> Chameleon 3.6.2 01:49:38 <Flo> maybe the capital C? 01:49:50 <glx> no it's ok 01:49:55 <glx> it's installed 01:50:15 <Flo> oh... 01:50:41 <glx> hmm and ugrading my msys/mingw install removed nml 01:51:20 <glx> oh it remove all stuff I previously installed via pip 01:51:54 <Flo> wow... 01:52:25 <glx> so yeah using pacboy for python modules is a good idea :) 01:52:54 <glx> oh of course it upgrade python 01:53:05 <glx> I was on 3.7.4 and now it's 3.8 01:53:08 <glx> makes sense 01:53:37 <Flo> oh... 01:54:04 <Flo> so whats wrong with my chameleon? 01:54:56 <glx> reinstalling my local nmlc 01:55:14 <Flo> oh 01:55:46 <glx> and it works fine for me 01:56:05 <Flo> the chameleon? 01:58:53 <glx> I now get SyntaxWarnings during docs rendering (because python 3.8) but it works 01:59:05 <Flo> oh 02:01:36 *** supermop_work_ has quit IRC 02:08:04 <Flo> um 02:08:08 <Flo> maybe because C:\msys64\usr\lib\python3.7? 02:08:17 <Flo> chameleon location is in there 02:08:22 <Flo> but I use 3.8 02:15:09 <Flo> yes I found why 02:15:10 <glx> for mingw it should be in C:\msys64\mingw64\lib\python3.8 02:15:17 <Flo> oh 02:15:19 <Flo> thx 02:15:32 <glx> but pip installs it there 02:15:56 *** Thedarkb-X40 has joined #openttd 02:16:41 <glx> you ran "pip install" in mingw ? 02:16:51 <Flo> yes 02:18:51 <Flo> it puts it into msys 02:18:52 <Flo> Florence@Flo-s-Laptop MINGW64 ~ 02:18:52 <Flo> $ pip install chameleon 02:18:52 <Flo> Requirement already satisfied: chameleon in /usr/lib/python3.7/site-packages (3.6.2) 02:19:34 <glx> oh it's the wrong pip 02:19:39 <Flo> oh... 02:20:43 <Flo> whats the right pip? 02:20:48 *** supermop_work_ has joined #openttd 02:21:16 <glx> pacboy find pip | grep install 02:21:48 <glx> I guess you have a pip in msys 02:22:08 <Flo> yeah your right 02:22:27 <glx> and none in mingw 02:22:48 <Flo> yep 02:22:49 <Flo> $ pacboy find pip | grep install 02:22:50 <Flo> An easy_install replacement for installing pypi python packages (mingw-w64) 02:22:50 <Flo> An easy_install replacement for installing pypi python packages (mingw-w64) 02:22:50 <Flo> An easy_install replacement for installing pypi python packages (mingw-w64) 02:22:50 <Flo> An easy_install replacement for installing pypi python packages (mingw-w64) 02:22:50 <Flo> The PyPA recommended tool for installing Python packages 02:22:52 <Flo> msys/python3-pip 19.3.1-1 [installed] 02:22:52 <Flo> The PyPA recommended tool for installing Python packages 02:23:33 <glx> pacboy -S python3-pip was done in the msys shell and not mingw shell :) 02:24:04 <Flo> yeah 02:24:09 <Flo> im very bad at this sorry 02:25:03 <Flo> Atleast after that ill be able compile my firs fork as many times as I want :D 02:25:58 <glx> well the clean firs doesn't compile for me, but I use the dev version of nmlc 02:26:10 <Flo> oh 02:29:26 <glx> ah yes it's because 16 input/output cargo 02:29:45 <Flo> oh... 02:30:01 <glx> my nmlc is too recent :) 02:31:07 <Flo> oof 02:31:10 <Flo> I get make: nmlc: Command not found 02:31:10 <Flo> make: *** [Makefile:93: generated/firs.grf] Error 127 02:31:18 <glx> pip install nml 02:31:29 <Flo> thx 02:32:22 <Flo> Running setup.py install for nml ... error 02:32:22 <Flo> ERROR: Command errored out with exit status 1: 02:33:17 <glx> I like when tools give very explicit messages :) 02:34:02 <Flo> ikr... 02:34:07 <glx> pip install -v nml 02:34:32 <glx> but I think I know why it fails 02:36:05 <Flo> ERROR: Command errored out with exit status 1: C:/msys64/mingw64/bin/python3.exe -u -c 'import sys, setuptools, tokenize; sys.argv[0] = '"'"'C:/Users/Florence/AppData/Local/Temp/pip-install-dn_tymp4/nml/setup.py'"'"'; __file__='"'"'C:/Users/Florence/AppData/Local/Temp/pip-install-dn_tymp4/nml/setup.py'"'"';f=getattr(tokenize, '"'"'open'"'"', open)(__file__);code=f.read().replace('"'"'\r\n'"'"', 02:36:05 <Flo> '"'"'\n'"'"');f.close();exec(compile(code, __file__, '"'"'exec'"'"'))' install --record C:/Users/Florence/AppData/Local/Temp/pip-record-ho7uyo_v/install-record.txt --single-version-externally-managed --compile Check the logs for full command output. 02:36:07 <Flo> Oh? 02:37:30 <Flo> Exception information: 02:37:30 <Flo> Traceback (most recent call last): 02:37:30 <Flo> File "C:/msys64/mingw64/lib/python3.8/site-packages\pip\_internal\cli\base_command.py", line 153, in _main 02:37:30 <Flo> status = self.run(options, args) 02:37:30 <Flo> File "C:/msys64/mingw64/lib/python3.8/site-packages\pip\_internal\commands\install.py", line 446, in run 02:37:30 <Flo> installed = install_given_reqs( 02:37:30 <Flo> File "C:/msys64/mingw64/lib/python3.8/site-packages\pip\_internal\req\__init__.py", line 58, in install_given_reqs 02:37:32 <Flo> requirement.install( 02:37:32 <Flo> File "C:/msys64/mingw64/lib/python3.8/site-packages\pip\_internal\req\req_install.py", line 886, in install 02:37:34 <Flo> runner( 02:37:34 <Flo> File "C:/msys64/mingw64/lib/python3.8/site-packages\pip\_internal\utils\subprocess.py", line 271, in runner 02:37:36 <Flo> call_subprocess( 02:37:36 <Flo> File "C:/msys64/mingw64/lib/python3.8/site-packages\pip\_internal\utils\subprocess.py", line 242, in call_subprocess 02:37:38 <Flo> raise InstallationError(exc_msg) 02:38:12 <glx> for big copy/paste use https://paste.openttdcoop.org/ ;) 02:38:39 <Flo> oh ok 02:38:41 <Flo> sorry 02:38:42 <glx> but I think "pacboy -S gcc" should do 02:39:34 <Flo> alright 02:40:41 <glx> it needs a compiler to build a lib 02:42:04 <Flo> oh 02:42:07 <glx> ahah and of course using this nml version fails too 02:42:09 <Flo> it worked :) 02:42:19 <glx> because pillow is too recent 02:42:34 <glx> and that's fixed in dev version 02:42:41 <Flo> oh 02:44:47 <Flo> oh oof I had ModuleNotFoundError: No module named 'ply' 02:45:04 <Flo> installing it 02:45:13 <Flo> there ;) 02:45:13 <glx> via pacboy ;) 02:45:20 <Flo> Oh I did with pip 02:45:43 <glx> works too 02:47:24 <Flo> um... 02:47:41 <Flo> I had Error: (AttributeError) "module 'PIL.Image' has no attribute 'VERSION'". 02:47:57 <glx> yes pillow is too recent 02:48:15 <Flo> oh... 02:48:17 <Flo> welp 02:48:26 <Flo> how do I get an older pillow? 02:49:19 <Flo> or the version of firs that was fixed? 02:50:01 <glx> dev version of nmlc works with current pillow, but firs is not compatible with it 02:50:25 <Flo> oh... 02:50:41 <Flo> So what do I have to do? 02:51:00 *** supermop_work_ has quit IRC 02:51:37 <Flo> should I just get an older pillow? 02:53:40 *** supermop_work_ has joined #openttd 02:55:08 *** Wormnest_ has joined #openttd 02:57:24 <Flo> what version is compatible with it? 02:58:17 <glx> only dev version is compatible with pillow >6.0 02:59:21 <Flo> ill install pillow earlier than 6.0 02:59:27 <Flo> would that work? 02:59:35 <glx> I'm trying it 03:00:11 <Flo> ill put 5.4.1 03:00:33 <glx> I'm trying "pip install pillow\<6.0" 03:01:09 <Flo> oh 03:01:12 <glx> it's installing 5.4.1 03:02:27 <glx> and it failed 03:02:54 <Flo> same 03:03:01 <Flo> it failed to install it 03:03:32 <Flo> does not yet support python 3.7 03:03:35 <Flo> 3.8* 03:04:29 <glx> it fails to compile some stuff but I don't know why 03:05:03 <glx> same happens with >6.0 03:05:26 <glx> but the package is ok 03:05:52 <Flo> oh you got it installed on 3.8? 03:06:21 <glx> I mean 6.2.1 package, the one from pacboy 03:06:28 <Flo> oh 03:07:11 <Flo> seems like we would need to use python 3.7 03:08:31 <glx> ah yes I use python 3.7 on windows for that reason, because there a precompiled pillow package compatible 03:08:43 <Flo> oh 03:09:06 <Flo> well then I guess ill do everything again but in python 3.7 03:09:17 <Flo> atleast now i should be able do most of it alone 03:09:26 <glx> it's hard to change version on mingw 03:09:35 <Flo> oh? 03:10:16 <Flo> i mean, ill prob have to reinstall the packages 03:10:45 <glx> but without the pacman -Syu steps 03:11:08 <Flo> wym? 03:11:34 *** tokai has joined #openttd 03:11:34 *** ChanServ sets mode: +v tokai 03:11:43 <glx> because pacman -Syu upgrades the package list 03:12:07 <glx> but you could also use current nml 03:12:19 <Flo> oh? 03:14:01 <Flo> ill get 3.7 python to start with, and try put all dependencies 03:14:15 <Flo> unless theres a way to do it in 3.8... 03:14:38 <glx> you can get it with "git clone https://github.com/openttd/nml.git" 03:16:29 <Flo> can it compile firs? 03:17:03 <glx> not yet, and I think it's a bug 03:17:10 <Flo> oh... 03:17:53 <Flo> it can be solved? 03:22:37 *** debdog has joined #openttd 03:23:50 *** supermop_work_ has quit IRC 03:25:57 *** D-HUND has quit IRC 03:29:00 *** supermop_work_ has joined #openttd 03:32:54 <glx> hmm will be easier to fix FIRS 03:33:34 <Flo> nice 03:34:05 <Flo> still trying to figure out how to install nml from that github 03:34:41 <glx> just git clone and "pip install ." 03:34:48 <Flo> oh 03:35:10 <glx> or better "pip install -e ." 03:37:57 <Flo> $ pip install -e https://github.com/OpenTTD/nml.git ? 03:40:33 <glx> pip install git+https://github.com/OpenTTD/nml.git 03:44:10 *** HerzogDeXtEr has quit IRC 03:45:18 <glx> hmm and that fails 03:47:04 <Flo> i installed the nml 03:49:44 <Flo> yeah, failed for me to... 03:49:57 <Flo> as you said, it does seems like a firs issue: nmlc ERROR: "generated/firs.nml", line 7342: Syntax error, unexpected token "waiting_cargo_1" 03:50:29 <glx> yes major change between nml 0.4 and 0.5 03:50:40 <Flo> right 03:50:56 <glx> but that's fixable in firs 03:51:01 *** Thedarkb-X40 has quit IRC 03:51:21 <Flo> yeah, seems more like a syntax thing...some rewriting could possibly fix that 03:51:40 <glx> just the doc is not fully updated ;) 03:51:51 <Flo> oof 03:52:04 <Flo> wait you updating the firs right now 03:52:05 <Flo> ? 03:52:26 <glx> no I'm not touching firs 03:52:44 <Flo> oh 03:52:49 <glx> in https://newgrf-specs.tt-wiki.net/wiki/NML:Industries Industry properties section is updated 03:52:56 <Flo> oh 03:53:00 <Flo> a fixed version 03:53:12 <glx> but Industry variables is not 03:53:27 <Flo> sad 03:54:22 <Flo> if you manage to get a working firs, let me know :) 03:54:32 <glx> https://github.com/OpenTTD/nml/blob/master/examples/industry/example_industry.nml should help 03:59:14 *** supermop_work_ has quit IRC 04:02:09 *** supermop_work_ has joined #openttd 04:02:59 *** Wormnest_ has quit IRC 04:08:48 *** Smedles has quit IRC 04:25:37 *** snail_UES_ has quit IRC 04:31:26 *** Smedles has joined #openttd 04:32:20 *** supermop_work_ has quit IRC 04:33:09 *** supermop_work_ has joined #openttd 05:03:23 *** supermop_work_ has quit IRC 05:04:59 *** glx has quit IRC 05:08:27 *** supermop_work_ has joined #openttd 05:38:34 *** supermop_work_ has quit IRC 05:40:44 *** supermop_work_ has joined #openttd 05:58:37 *** Flo has quit IRC 06:10:57 *** supermop_work_ has quit IRC 06:17:20 *** supermop_work_ has joined #openttd 06:43:26 *** sla_ro|master has joined #openttd 06:47:33 *** supermop_work_ has quit IRC 06:51:19 *** supermop_work_ has joined #openttd 07:03:28 *** Progman has joined #openttd 07:15:05 *** andythenorth has joined #openttd 07:21:31 *** supermop_work_ has quit IRC 07:24:09 *** supermop_work_ has joined #openttd 07:55:21 *** supermop_work_ has quit IRC 08:01:37 *** supermop_work_ has joined #openttd 08:01:39 <andythenorth> hmm 08:01:48 <andythenorth> why is python import perfomance so poor? 08:01:56 <andythenorth> and what can I do about it ? :P 08:02:11 <andythenorth> is using modules wrong? 08:02:30 <andythenorth> I could just write everything in one python file 08:03:20 *** dude[m] has quit IRC 08:03:55 <Eddi|zuHause> andythenorth: it depends on loads of things, like what kinds of initialisations the module does 08:04:05 <Eddi|zuHause> or whether it needs to be converted to .pyc first 08:04:20 <andythenorth> it scales horribly 08:04:32 <andythenorth> there are some core modules that I import hundreds of times 08:04:46 <andythenorth> they're only 0.02s or such 08:04:55 <andythenorth> but they scale up to delays of seconds 08:05:12 <andythenorth> then I use a multiprocessing pool, and every pool instance scales that delay 08:05:13 <Eddi|zuHause> im sure there are import optimizers :) 08:05:29 <andythenorth> it's interestingly a new problem in 3.7 or 3.8 08:05:41 <andythenorth> 3.5 does not show this behaviour 08:05:55 <Eddi|zuHause> "pool instance" sounds like loads of initialisation code 08:06:05 <andythenorth> it is, and there's a known problem of overhead 08:07:39 <andythenorth> this file takes 0.2s to run (python src/iron_horse.py) https://github.com/andythenorth/iron-horse/blob/master/src/iron_horse.py 08:07:48 <andythenorth> or 1.1s to import (import iron_horse) 08:08:32 <andythenorth> at least one problem appears to be that chameleon's PageTemplateLoader class is incredibly slow to import 08:09:03 <andythenorth> so I'll find a way around that :P 08:09:09 <Eddi|zuHause> i don't think i can help you here 08:09:15 <andythenorth> no, this is my mess 08:09:25 <andythenorth> but the 3.5 vs 3.8 degradation was shocking 08:09:31 <andythenorth> it's probably because 3.8 is faster 08:09:59 <andythenorth> so something in the implementation has changed, and is no longer caching modules or similar 08:14:24 <Eddi|zuHause> likely a side effect of some other fix 08:15:42 <andythenorth> 3.8 is generally faster for the cases I have, about 10%-20% 08:17:05 <andythenorth> also I learn some things this way :P 08:17:08 <andythenorth> mostly regrets 08:17:45 <planetmaker> moin, is it possibly worth reporting that as regression back to python? With the example as-is? 08:20:11 <andythenorth> not in the current form 08:20:20 <andythenorth> I'm using terrible python practices, like no main() 08:20:53 <andythenorth> I'll find out if the regression is legitimate, or just my bad style, then see :) 08:21:08 <andythenorth> shall we place a bet on who is more likely wrong? :P 08:26:09 <andythenorth> 3.8 vs 3.5 is measurably faster for nmlc 08:28:29 <Eddi|zuHause> andythenorth: step 1: make two test environments with 3.5 and 3.8 )and possibly some inbetween versions) to test whether the slowdown is real 08:28:38 <andythenorth> done 08:28:45 <Eddi|zuHause> 2a) comment out code, until the difference disappears 08:28:47 <andythenorth> yes 08:29:16 <Eddi|zuHause> 2b) work through the changelog which changes would be likely to cause a slowdown 08:29:34 <andythenorth> that's not done yet :P 08:30:10 <andythenorth> I've fixed some self-inflicted problems, and now have parity for total run time between 3.5 and 3.8 08:30:25 <andythenorth> but as 3.8 is generally faster, that masks some things that are slower :) 08:31:24 <andythenorth> general observation, Iron Horse nmlc run time is about 28s for py3.8 vs 35s for py3.5 08:31:48 *** supermop_work_ has quit IRC 08:32:07 <andythenorth> oh if I let the caches prime, my total 3.8 run time is now a few seconds less than 3.5 08:32:07 <Eddi|zuHause> so 20% faster 08:32:13 <andythenorth> yes 08:33:10 <andythenorth> the remaining interesting problem 08:33:20 <andythenorth> is why a specific module takes 0.2s to just run 08:33:23 <andythenorth> and 1.1s to import 08:33:47 *** supermop_work_ has joined #openttd 08:34:01 *** arikover has joined #openttd 08:36:04 <andythenorth> hmm, that's same behaviour on 3.5 also, but after the first import, it's cached 08:36:18 <andythenorth> whereas 3.8 seems to incur the 1.1s every time the module is imported 08:41:13 <andythenorth> very interesting :P 08:41:19 <andythenorth> where's that xkcd on time saved? :P 08:52:35 <andythenorth> https://paste.openttdcoop.org/projijyrr/hxy91u/raw 08:53:07 <andythenorth> python3.5 doesn't trigger multiple imports when Pool is used, python3.8 does 08:53:47 <andythenorth> (I knew this already, I just added timings to verify it) 09:01:36 <planetmaker> at your service ;) https://xkcd.com/1205/ 09:02:13 <andythenorth> thx 09:03:22 <andythenorth> ok found it https://github.com/python/cpython/pull/13603 09:03:47 <andythenorth> python mp fork inherits from parent, mp spawn initialises clean 09:03:59 *** supermop_work_ has quit IRC 09:04:12 <andythenorth> fork is unreliable, changed on macos, consensus couldn't be achieved to change it on *nix for 3.8 09:04:30 <andythenorth> may be changed for *nix in 3.9 09:04:37 <andythenorth> super :) 09:05:27 *** supermop_work_ has joined #openttd 09:06:31 <andythenorth> https://news.ycombinator.com/item?id=5191495 09:07:52 <planetmaker> I hoped you were joking :D 09:08:56 <andythenorth> joke multithreading not do about I 09:19:18 <peter1138> "I didn't test my PR." 09:20:12 <peter1138> Is that how other developers do things? 09:20:26 <andythenorth> somewhat 09:20:48 <andythenorth> on certain days I think OpenTTD is well above the average on quality 09:29:35 * andythenorth duty calls :P 09:29:36 *** andythenorth has quit IRC 09:35:39 *** supermop_work_ has quit IRC 09:38:52 *** nielsm has joined #openttd 09:40:49 *** supermop_work_ has joined #openttd 10:06:59 *** arikover has quit IRC 10:11:01 *** supermop_work_ has quit IRC 10:12:06 *** Samu has joined #openttd 10:19:28 *** supermop_work_ has joined #openttd 10:49:42 *** supermop_work_ has quit IRC 10:58:40 *** HerzogDeXtEr has joined #openttd 11:02:01 *** supermop_work_ has joined #openttd 11:32:11 *** supermop_work_ has quit IRC 11:33:33 <nielsm> https://www.tt-forums.net/viewtopic.php?p=1227166#p1227166 <-- why doesn't it print the (full path) name of the log file it fails to open? 11:33:38 <nielsm> that would make diagnostics easier 11:34:40 *** supermop_work_ has joined #openttd 11:37:14 <DorpsGek_III> [OpenTTD/OpenTTD] nielsmh closed issue #7848: Cannot scroll when building on Android https://git.io/Je12F 11:37:14 <DorpsGek_III> [OpenTTD/OpenTTD] nielsmh commented on issue #7848: Cannot scroll when building on Android https://git.io/Je12F 11:42:36 *** freu[m] has quit IRC 11:44:43 *** nielsm has quit IRC 11:52:52 <Samu> I'm so tempted to buy this https://www.pcdiga.com/processador-amd-ryzen-7-2700-octa-core-3-2ghz-c-turbo-4-1ghz-20mb-sktam4 11:53:04 <Samu> at that price 11:53:23 <Samu> but it's last gen :( and next year, new stuff is coming out 11:57:17 <Samu> with about €370 i can upgrade cpu, mb, ram and still add a 1 TB SSD 11:57:31 <Samu> and a tower 11:57:47 <Samu> so undecided 12:04:53 *** supermop_work_ has quit IRC 12:05:20 *** supermop_work_ has joined #openttd 12:35:33 *** supermop_work_ has quit IRC 12:35:34 *** Wolf01 has joined #openttd 12:39:32 *** andythenorth has joined #openttd 12:40:15 <andythenorth> well 12:41:13 *** supermop_work_ has joined #openttd 12:49:26 <andythenorth> so why am I tickling "[Errno 24] Too many open files" 12:51:37 <andythenorth> ulimit reports 'unlimited' 12:51:37 <Wolf01> Close a file handler when you finish to use it? 12:51:56 <andythenorth> yes, I wonder where it is though 12:52:12 <andythenorth> and why this triggers with pypy but not python3 12:53:05 <Wolf01> I think that "unlimited" is like "free! (with a 4.99€ purchase)" or "you get unlimited call time (up to 200 minutes/month)" 12:53:49 <Wolf01> Maybe it depends on other things, like OS, ram, whatever 12:54:24 <Wolf01> " 12:54:24 <Wolf01> "Too many open files" errors are always tricky – you not only have to twiddle with ulimit, but you also have to check system-wide limits and OSX-specifics" 12:55:26 <andythenorth> ulimit -n 4096 solves it 12:55:40 <andythenorth> but I wonder if I should be closing files 12:56:51 <Wolf01> ^ 12:58:07 <andythenorth> well I wonder where, to be more accurate :P 13:00:15 <Wolf01> Just after you finished to write/read it 13:00:22 *** andythenorth has quit IRC 13:03:42 *** andythenorth has joined #openttd 13:10:28 *** nielsm has joined #openttd 13:11:27 *** supermop_work_ has quit IRC 13:13:19 *** supermop_work_ has joined #openttd 13:16:18 *** Progman has quit IRC 13:21:20 <supermop_Home> can an industry distribute cargo to only 2 stations, or is it 2 station per cargo? 13:22:49 <nielsm> two per cargo 13:23:28 <nielsm> when a cargo packet is about to be distributed it searches for all stations in catchment and sorts them by rating for that cargo, then picks the top two 13:23:52 <supermop_Home> ah ok 13:24:25 <supermop_Home> with cdist i usually keep two stations, one for far destination and one for near 13:25:04 <supermop_Home> but in this case i think i want separate trains taking the vehicles vs the engineering supplies 13:32:34 *** Flygon has quit IRC 13:42:20 * andythenorth closes some file handles :P 13:43:30 *** supermop_work_ has quit IRC 13:44:36 <andythenorth> hmm 13:44:43 <andythenorth> closing file handles seems to have made the compile faster :P 13:44:56 <Wolf01> Ahahaha 13:45:30 <andythenorth> not sure why that would be 13:46:12 <andythenorth> plenty of RAM :P 13:48:09 *** supermop_work_ has joined #openttd 13:48:36 *** HerzogDeXtEr has quit IRC 13:50:00 *** HerzogDeXtEr has joined #openttd 14:00:36 <andythenorth> oh lol 14:00:52 <andythenorth> the py3.8 syntax errors were me not nml 14:00:57 <andythenorth> but the file handles are nml :P 14:04:55 <supermop_Home> hmm this GS wants 'raw energy' once a town is bigger than 10k 14:05:19 <supermop_Home> but in steeltown that only means coal, which means a coke oven 14:05:30 <andythenorth> oof 14:05:31 <andythenorth> which GS? 14:06:09 <supermop_Home> and the only coal mine, oven, and steelmill are conveniently all near eachother in the far corner of the map 14:06:43 <supermop_Home> so setting up a new oven in the middle of my big city makes no sense 14:06:58 <supermop_Home> think globally act locally 14:07:00 <andythenorth> rage quit! 14:07:06 <andythenorth> only solution ^ 14:08:26 <supermop_Home> nothing makes me want to move to a new city like huge trains of coal being hauled in to be baked in town, just to be carried back out to where they came from 14:08:44 <andythenorth> I am trying Migrations GS 14:08:57 <andythenorth> when you serve an industry, it spams a new town and houses round it 14:09:19 <andythenorth> neat concept, probably not going to be a keeper for me :) 14:09:26 <supermop_Home> oooh 14:09:27 <supermop_Home> cool 14:10:26 <supermop_Home> i accidentally started this steeltown game in tropic, so now im setting up complex systems to serve vehicles to all towns to let them grow 14:10:45 <supermop_Home> because all but one town spawned in the desert 14:14:29 <andythenorth> oops 14:18:22 *** supermop_work_ has quit IRC 14:23:31 *** supermop_work_ has joined #openttd 14:41:30 * andythenorth wonders what happens to an open Image file when copy is called on it :P 14:41:34 <andythenorth> do I also need to close the copy? 14:53:42 *** supermop_work_ has quit IRC 14:55:32 *** supermop_work_ has joined #openttd 14:59:25 *** Progman has joined #openttd 15:02:42 *** WormnestAndroid has quit IRC 15:02:55 *** WormnestAndroid has joined #openttd 15:09:34 <andythenorth> hmmm when things work... 15:25:45 *** supermop_work_ has quit IRC 15:27:37 *** supermop_work_ has joined #openttd 15:27:42 *** gandi[m] has quit IRC 15:31:13 *** snail_UES_ has joined #openttd 15:39:04 <andythenorth> ho ho 15:39:29 <andythenorth> Iron Horse compile is reliably ~10 seconds faster with python 3.8 compared to a week ago with python 3.5 15:39:56 <andythenorth> BUT some of the gain is due to me removing broken/slow things that worked under 3.5 and don't in 3.8 :P 15:41:10 <andythenorth> @calc 55/68 15:41:11 <DorpsGek> andythenorth: 0.808823529412 15:57:50 *** supermop_work_ has quit IRC 15:59:43 *** supermop_work_ has joined #openttd 16:25:58 <Samu> it's 1958 in the debug test, 3 years away from the crash 16:26:33 <Samu> enabling autosaves 16:29:11 <FLHerne> andythenorth: PyPy doesn't use reference-counted GC 16:29:53 <FLHerne> So file handles are only closed whenever the GC feels like it, whereas in CPython they're usually closed when leaving their scope 16:29:54 *** supermop_work_ has quit IRC 16:30:23 <FLHerne> (or, of course, when actually closing them like the spec says to :P) 16:30:25 <andythenorth> oic :) 16:30:31 <andythenorth> that makes sense 16:30:42 <andythenorth> nmlc might want to Image.close() 16:30:45 <andythenorth> I didn't look where 16:31:08 <andythenorth> it's possibly a cause of reported RAM bloat as well, but dunno 16:31:18 <andythenorth> not sure the 2 are connected? 16:34:12 *** supermop_work_ has joined #openttd 16:34:28 <FLHerne> Might well be 16:36:05 <Eddi|zuHause> i wouldn't count "GC can free it" under "bloat" 16:36:43 <Eddi|zuHause> however, "GC can't figure out that it can be freed" is different 16:38:09 *** Wormnest_ has joined #openttd 16:43:47 <andythenorth> I stopped testing with pypy, it's faster for some cases, but slower than others 16:49:00 <andythenorth> hmm overall faster with pypy though 16:55:10 <andythenorth> 48s vs 55s 16:57:31 <andythenorth> if I could switch py38 and pypy I could save another 8 seconds :P 16:57:58 <andythenorth> but 'source' to swtich virtualenv doesn't seem to work from a makefile 16:59:39 <Eddi|zuHause> i've no clue what you're saying 17:00:31 *** lastmikoi_ has joined #openttd 17:01:31 *** lastmikoi has quit IRC 17:01:31 *** lastmikoi_ is now known as lastmikoi 17:02:20 <andythenorth> some python interpreters are faster than others 17:02:29 <andythenorth> which one is fastest depends on the code being run 17:02:58 <andythenorth> the compile is made up of discrete steps 17:03:14 <andythenorth> I could switch to the fastest interpreter for each step 17:03:26 <andythenorth> but it's unwise, and I can't get it to trivially work anyway 17:04:11 <snail_UES_> andythenorth: I just read your past messages… just curious, how long does it take to compile IH? 17:04:26 *** supermop_work_ has quit IRC 17:04:31 <andythenorth> roughly 1 minute 17:04:43 <andythenorth> it's very slow 17:05:00 <snail_UES_> right… my set with m4nfo is much quicker 17:05:25 <Eddi|zuHause> CETS spends 1 minute in grfcodec alone 17:06:19 <DorpsGek_III> [OpenTTD/OpenTTD] nielsmh updated pull request #7353: Feature: Measure vehicle capacity utilisation efficiency https://git.io/fhho4 17:06:40 <DorpsGek_III> [OpenTTD/OpenTTD] nielsmh commented on pull request #7353: Feature: Measure vehicle capacity utilisation efficiency https://git.io/Je1QY 17:07:00 <andythenorth> I did consider switching to m4nfo 17:07:00 <Eddi|zuHause> it's about 300k lines of NFO 17:07:23 <Eddi|zuHause> and grfcodec cannot be parallelized 17:07:54 <Eddi|zuHause> so while it's only 20% of the work, it's 50% of the time 17:08:05 <snail_UES_> mine just compiled in 28 seconds, including something like A5F recoloring tables 17:08:11 <snail_UES_> without those, it’d take like 10 secs 17:08:39 *** supermop_work_ has joined #openttd 17:08:40 <andythenorth> how long does it take you to generate the m4nfo? 17:09:07 <snail_UES_> you mean, within those 28 seconds? 17:09:10 <snail_UES_> let me see 17:09:55 <andythenorth> no, I mean to get the input file? 17:10:08 <andythenorth> or you wrote it all by hand? 17:10:39 <snail_UES_> I wrote my code by hand… well, with lots of copy and paste :p 17:10:50 <snail_UES_> but all of the logic is done by hand 17:11:33 <andythenorth> @calc 38/55 17:11:33 <DorpsGek> andythenorth: 0.690909090909 17:11:54 <andythenorth> ok so about 30% of the Horse compile is code generation, graphics generation, docs generation, overhead 17:12:01 <Eddi|zuHause> andythenorth: my generate.py takes 6 seconds 17:12:37 <andythenorth> you should have parellelised it :P 17:12:50 <andythenorth> use 16 processes, it would be done in 5 seconds 17:13:10 <snail_UES_> you mean you don’t write your nml code by hand? then how do you do it? 17:13:15 <LordAro> andythenorth: what bit of it is being parallelised? 17:13:55 <andythenorth> snail_UES_: I don't even know how to write nml :) 17:13:59 <andythenorth> I have to look it up every time 17:14:06 <Eddi|zuHause> andythenorth: how would you parallelize reading a giant table? from a single file? :p 17:14:08 <andythenorth> LordAro: just graphics generation 17:14:23 <andythenorth> Eddi|zuHause: divide it into 16 chunks :P 17:14:30 <andythenorth> map reduce 17:14:35 <andythenorth> the overhead will kill you :P 17:14:53 <snail_UES_> andythenorth: so how are you coding your set? :p 17:14:59 <andythenorth> python 17:15:14 <LordAro> personally i'd like make deal with parallelising for me 17:15:23 <LordAro> s/like/let/ 17:15:32 <snail_UES_> you write in python, then python generates nml, and then from nml you compile the newgrf? 17:15:35 <andythenorth> yes 17:15:44 <snail_UES_> alright… sounds a bit convoluted to me :) 17:16:08 <andythenorth> I really don't like nml 17:16:21 <andythenorth> if I could template nfo, I would, but I'm not smart enough 17:16:41 <andythenorth> the nml is actually compiled to nfo 17:16:45 <andythenorth> then grfcodec is used 17:16:49 <snail_UES_> omg... 17:16:51 <andythenorth> it's faster 17:17:00 <snail_UES_> python —> nml —> nfo —> newgrf? :D 17:17:12 <Eddi|zuHause> snail_UES_: it probably is convoluted in andy's case, but if you have any kind of theoretical background it's pretty clean and straightforward to generate code. 17:17:39 <Eddi|zuHause> snail_UES_: basically, you write one vehicle, and it does all the copy-paste for you 17:18:02 <snail_UES_> yes, but each vehicle has its own quirks... 17:18:10 <andythenorth> that's why it gets convoluted 17:18:19 <andythenorth> and that's why Iron Horse vehicles are all pretty much the same 17:18:20 <snail_UES_> it’s rare that 2 vehicles are coded exactly the same in any trainset 17:20:07 <snail_UES_> right… well, if your trains are coded the same, it would be easy to create templates in nfo 17:20:21 <Eddi|zuHause> snail_UES_: there are ways out of that dilemma. like you can extend the system to handle all these tiny differences, or you can restrucure them to minimize the differences 17:20:50 <snail_UES_> Eddi|zuHause: yeah, like bringing some degree of standardization 17:20:58 <snail_UES_> I will totally do it for my next sets... 17:21:09 <snail_UES_> the narrow gauge one was my first, so I had crazy ideas 17:21:16 <andythenorth> I did that for HEQS :P 17:21:32 <andythenorth> Iron Horse is probably my 8th or 9th attempt at templating 17:21:56 *** gelignite has joined #openttd 17:22:02 <snail_UES_> templating helps, but then the result might lack variety... 17:22:17 <Eddi|zuHause> i found templates to be too restrictive 17:22:48 <Eddi|zuHause> that's where the code generation comes in, you have more ways to fit in the variations 17:22:53 <snail_UES_> you need to find a compromise between standardization and diversity 17:23:11 <andythenorth> there's a gameplay aspect as well 17:23:34 <Eddi|zuHause> code generation is essentially just fancy templates 17:23:35 <andythenorth> too much variation is bad for e.g. AIs, coop etc 17:23:44 <andythenorth> not enough variation is dull as hell 17:24:02 <snail_UES_> what do you mean by "coop"? 17:24:10 <andythenorth> coop style gameplay 17:24:20 <snail_UES_> in multiplayer? 17:24:36 <andythenorth> anywhere 17:24:47 <andythenorth> they like all trains to have same performance 17:25:02 <andythenorth> or so 17:25:08 <snail_UES_> all trains to have the same performance?? 17:25:14 <snail_UES_> then just buy the same model :p 17:25:19 <nielsm> can any language lawyers give a quick opinion on this? :) https://github.com/OpenTTD/OpenTTD/pull/7353#discussion_r337248135 17:25:52 <andythenorth> it it tonne-miles? 17:26:07 <nielsm> yes 17:26:20 <andythenorth> many 17:26:22 <nielsm> ok 17:26:56 * andythenorth wonders whether to try and make Iron Horse compile faster 17:27:07 <LordAro> much vs many is the same as less vs fewer 17:27:44 <Eddi|zuHause> LordAro: the problem is, if your native language uses the same word for both cases 17:28:16 <LordAro> Eddi|zuHause: true :) 17:28:18 <Eddi|zuHause> ... then you might lack the ability to distinguish these cases 17:28:36 <andythenorth> nmlc is so much faster under pypy 17:28:47 <andythenorth> maybe I do need to switch interpreter in the makefile 17:28:58 <LordAro> uncountable vs countable - how much water, there is less water. how many people, there are fewer people 17:29:01 <LordAro> e.g. 17:30:04 <Eddi|zuHause> LordAro: that may seem logical to you... 17:30:10 <snail_UES_> LordAro: this might look a bit complicated to anyone who wasn’t born English ;) 17:30:35 <snail_UES_> even lots of native-born Americans have an incredible trouble with that 17:30:46 <LordAro> quite a lot of British people too :p 17:30:48 <andythenorth> lego or legos :P 17:30:48 <Eddi|zuHause> LordAro: it's like a japanese person confusing "r" and "l", or a french person randomly sprinking "h" into a word 17:31:19 <snail_UES_> what pisses me off is native-born speakers who confuse “it’s” with “its” 17:31:22 <snail_UES_> you see that all the time... 17:31:29 <andythenorth> I do that all the time :) 17:31:33 <snail_UES_> :p 17:31:34 <andythenorth> it's really hard to not get wrong 17:31:57 <LordAro> "[wsc]ould of" gets me 17:31:58 <nielsm> and classic their/they're/there 17:32:02 <nielsm> that too 17:32:03 <andythenorth> that's classic 17:32:06 <Eddi|zuHause> that's the reverse case, because in most foreign languages there is no way to confuse these two things 17:32:06 <snail_UES_> that too... 17:32:12 <LordAro> "off of" particularly gets me 17:32:15 <andythenorth> I know all the rules, but I still make the mistakes 17:32:17 <Eddi|zuHause> so non-native speakers are less likely to make that mistake 17:32:19 <andythenorth> the language is stupid 17:32:31 <andythenorth> but flexible 17:32:59 <Eddi|zuHause> what i never could wrap my head around was peopple using "of" instead of "have"... what?? why? 17:33:10 <andythenorth> nmlc run time Iron Horse: py38 39s; pypy 20s 17:33:16 <andythenorth> ^ substantial saving 17:33:53 <nielsm> heh, Aircraft::GetCurrentMaxSpeed() is not used anywhere at all 17:33:59 <andythenorth> :P 17:34:03 *** glx has joined #openttd 17:34:03 *** ChanServ sets mode: +v glx 17:34:10 <andythenorth> so how do I change virtualenv in a makefile :P 17:34:11 <nielsm> and the point of GetSpeedOldUnits() is not explained anywhere as far as I can tell 17:34:12 * andythenorth wonderw 17:34:29 <LordAro> andythenorth: you really don't 17:34:58 <LordAro> Eddi|zuHause: probably due to contractions - "should've" -> "should of" 17:35:49 <andythenorth> LordAro: the speed though :P 17:35:55 <nielsm> "shuddef" 17:36:30 <LordAro> andythenorth: sure, but switching dev environments from within a makefile? ew ew ew 17:36:40 <Eddi|zuHause> andythenorth: excuse my ignorance, but the point of a virtualenv is that the program being run doesn't know about it? 17:36:47 <andythenorth> it's just an interpreter LordAro 17:36:58 <andythenorth> I used to have a mixed python3 / python2.7 compile :P 17:36:59 <LordAro> i'm guessing nml itself can't cope with pypy? 17:37:14 <andythenorth> Eddi|zuHause: somewhat yes 17:37:38 <LordAro> then call pypy as "pypy" ? why is the virtualenv a factor? 17:38:15 <nielsm> aircraft movement speed is deep magic 17:38:15 <andythenorth> I don't use system-wide python 17:38:21 <andythenorth> it's very fragile 17:38:28 <LordAro> sure, but your build system doesn't need to know that 17:38:36 <andythenorth> Makefile.local maybe 17:38:40 <LordAro> virtualenv sets up your environment 17:38:40 <Eddi|zuHause> yeah, i don't understand what the virtualenv has to do with it. you need a virtualenv with both interpreters in it 17:38:47 <nielsm> the virtualenv should have the python version used encoded in it 17:38:47 <LordAro> make runs in that environment 17:38:48 <LordAro> end of 17:38:52 *** supermop_work_ has quit IRC 17:39:00 <Eddi|zuHause> and then just call the interpreter in the makefile 17:39:10 <nielsm> by having an appropriate symlink from the venv's bin directory to the intended interpreter 17:39:19 <andythenorth> what nielsm said 17:39:45 <Eddi|zuHause> one virtualenv, two interpreters. 17:39:50 <andythenorth> that's not how it's done 17:40:01 <Eddi|zuHause> but that's the only way to do it 17:40:03 <andythenorth> that's just a particularly inventive way to break things 17:40:26 <nielsm> this is one good line: v->subspeed = (t = v->subspeed) + (byte)spd; 17:40:29 *** supermop_work_ has joined #openttd 17:40:41 <andythenorth> actually one virtualenv, two interpreters might be the best way to break things so far :) 17:40:44 <andythenorth> it's so subtle 17:40:52 <andythenorth> it would take ages to figure it out :) 17:41:20 <Eddi|zuHause> nielsm: if i were to work in QA, i'd immeddiately ban = in expressions 17:41:40 <Eddi|zuHause> nielsm: so many ways for it to go wrong 17:42:02 <LordAro> there are certain cases where it's acceptable 17:42:08 <Eddi|zuHause> and "t = subspeed; subspeed += spd" isn't even any longer 17:42:08 <LordAro> but those are vanishingly rare 17:42:36 <LordAro> e.g. while((foo = read())) {...} 17:42:51 <Eddi|zuHause> LordAro: iterator. 17:43:16 <Eddi|zuHause> LordAro: that's a for-loop 17:43:19 <nielsm> static void MaybeCrashAirplane(Aircraft *v); 17:43:22 <nielsm> yeah 17:45:06 <Eddi|zuHause> nielsm: there's a good chance you can trace these kinds of expressions back to the original decompile 17:45:12 <glx> andythenorth: you can have many venv, but you can have only one enabled per session 17:45:34 <andythenorth> yes 17:45:38 <andythenorth> one has to switch 17:45:49 <glx> that's the main use of venv 17:45:51 <andythenorth> yes 17:46:00 <andythenorth> doing that in the Makefile might be considered unwise :P 17:46:22 <glx> Makefile doesn't have to know about venv 17:46:32 <glx> it's the responsability of the user 17:46:54 <andythenorth> rock, hard place 17:47:03 <andythenorth> that game-overs switching interpreter 17:47:06 <Eddi|zuHause> Makefile MUST NOT know about virtualenv 17:47:41 <andythenorth> we have a work Makefile that actually creates virtualenvs 17:47:52 <Eddi|zuHause> that's different 17:47:53 <andythenorth> but it's for creating a build environment, not for the compile 17:48:11 <Eddi|zuHause> that makefile lives on a meta-environment 17:48:13 <andythenorth> yes 17:48:24 <glx> projects themself don't care 17:48:35 <nielsm> @todo De-mystify the cur_speed values for helicopter rotors. <- yeah that too 17:49:06 <andythenorth> well I could just install all the deps in system-wide pypy 17:49:19 <glx> you can use --user 17:49:19 <andythenorth> but I hate system-wide python installs, they break at no-notice 17:49:41 <glx> or use venv from the global install 17:50:25 <glx> on windows I can't install modules system wide if not in an admin shell 17:50:33 <Eddi|zuHause> i stand by my opinion that the only way to do what you want is to have both interpreters in the same virtualenv 17:50:45 <glx> but pip supports that easily 17:51:01 <andythenorth> Eddi|zuHause: that might work because pypy is tracking py3 17:51:06 <andythenorth> but it's very prone to breaking 17:51:26 <andythenorth> which package should be installed in the env for which interpreter? 17:51:38 <andythenorth> it defeats the point of the env 17:51:39 <glx> pip takes care of that 17:52:07 <andythenorth> are there interpreter-specific packages? 17:52:13 <glx> venv/bin is put in front of the path 17:52:24 <andythenorth> I'm confused now 17:52:59 <glx> so if you use python2 -m pip you install for python2, and python3 -m pip to install python3 17:53:54 <andythenorth> well I could try it 17:54:03 <andythenorth> I can always just delete the env if it breaks 17:54:36 <glx> venv/bin/pip on the other hand will use the latest interpreter added to the venv 17:55:33 * andythenorth looks what's in bin/activate 17:55:48 <glx> bin/activate just adds the path IIRC 17:55:59 <glx> basically 17:56:41 <andythenorth> so with two interpreters, I'm curious how it will know which one to activate 17:58:24 <glx> anyway it's probably easier to just do python2 -m venv venv2 and python3 -m venv venv3 17:59:01 <andythenorth> that results in 2 venvs though 17:59:13 <glx> but only one used at a time 17:59:21 <andythenorth> hmm 17:59:25 * andythenorth still confused 17:59:50 <andythenorth> the only solution seems to be system-wide install 18:00:06 <andythenorth> not doing that 18:02:32 <Samu> {type=VKI_STATION (0) id={station=1746 town=1746 sign=1746 } center=-48128 ...} 18:02:36 <andythenorth> is there a convention for naming pypy? 18:02:49 <Samu> the id being equal to station, town and sign, is that the way it works? 18:03:18 <andythenorth> probably the makefile needs to test if pypy exists? 18:06:40 <DorpsGek_III> [OpenTTD/OpenTTD] SamuXarick commented on issue #7847: Crash - Assertion failed at line 213 of src\core\kdtree.hpp: next != INVALID_NODE https://git.io/Je1Eh 18:07:45 <nielsm> Samu: the id there is a union, not a struct, so it's only the id for the appropriate item type 18:08:19 <nielsm> (it's not a StationID, TownID, SignID all at the same time, only the one type given by VKI_STATION/etc.) 18:08:24 <Samu> btw, it also crashed on master version 18:08:41 <Samu> ah, i see 18:08:48 <glx> of course, 1.10 is master ;) 18:09:24 <glx> not the more recent master, but still master 18:09:41 <Samu> master-gd865916a07 18:09:58 <glx> and no changes happened in this area since beta release 18:10:47 *** supermop_work_ has quit IRC 18:10:57 <glx> still no fast way to reproduce ? 18:11:12 <andythenorth> hmm maybe I can rewrite to be faster for pypy 18:11:14 <Samu> _viewport_sign_kdtree.Remove(ViewportSignKdtreeItem::MakeStation(this->index)); 18:11:19 <andythenorth> seems that it needs code written for it 18:11:34 <andythenorth> or I could maybe switch template language 18:11:38 <Samu> it enters this part, and tries to find something, and reaches invalid_node 18:11:47 <glx> Samu: yes I know where the crash is, I posted the log in the issue ;) 18:12:27 <glx> at some point it takes the wrong branch of the tree I think 18:12:38 *** supermop_work_ has joined #openttd 18:13:05 <glx> now the question is why ? 18:13:48 <DorpsGek_III> [OpenTTD/OpenTTD] nielsmh updated pull request #7353: Feature: Measure vehicle capacity utilisation efficiency https://git.io/fhho4 18:14:19 <Samu> is there anything I can do to brute force a search? 18:14:27 <Samu> branch stuff 18:15:13 <andythenorth> hmm 18:15:14 <andythenorth> FIRS 18:15:34 <Samu> or maybe a failsafe when it fails to find, have it make some slower search 18:15:37 <andythenorth> py35: 59s; py38: 47s; pypy: 31s 18:15:56 <DorpsGek_III> [OpenTTD/OpenTTD] nielsmh commented on pull request #7353: Feature: Measure vehicle capacity utilisation efficiency https://git.io/Je17r 18:16:11 <glx> FIRS (at least the one on github) needs a big update for current nmlc 18:16:24 <andythenorth> there's a branch 18:16:29 <andythenorth> v4-development or something 18:16:43 <andythenorth> main reason I switched it to git :) 18:16:53 <glx> luckily as you did it only one file needs changes ;) 18:17:17 <andythenorth> has something else changed? :P 18:20:32 <DorpsGek_III> [OpenTTD/OpenTTD] nielsmh updated pull request #7353: Feature: Measure vehicle capacity utilisation efficiency https://git.io/fhho4 18:22:03 <glx> ha yes v4-development-track compiles 18:22:16 <glx> I forgot to check branches last night 18:22:35 <andythenorth> I wonder if FIRS is suitable for stored procedures :P 18:23:09 <andythenorth> there are some truly horrible things for drawing the correct ground tile: snow, slope etc 18:23:15 <andythenorth> they are endlessly repetitive 18:23:18 <glx> it is if switches are based on the same calculations 18:23:42 <andythenorth> I am hoping that stored procedures might work for Iron Horse 18:23:58 <andythenorth> optimistically, I might remove 20k lines of 170k total 18:25:01 <andythenorth> FIRS :P https://github.com/andythenorth/firs/blob/master/src/templates/spritelayouts_groundaware.pynml#L62 18:25:14 <andythenorth> I don't know if childsprite can use a stored procedure result 18:27:22 <andythenorth> that would be a trip deep into nml :P 18:27:25 <andythenorth> https://newgrf-specs.tt-wiki.net/wiki/Action2/Sprite_Layout#Extended_format_using_multiple_combined_sprites 18:27:43 <andythenorth> there's also an advanced format using registers :P 18:29:44 <andythenorth> this check is super, I wonder what it expands to in the final varaction 2 :P https://github.com/andythenorth/firs/blob/master/src/templates/spritelayouts.pynml#L34 18:32:35 <glx> I think childsprite can use a stored procedure result 18:32:59 <glx> I guesse the stuff is converted to a varact2 by nmlc 18:33:34 <andythenorth> maybe nml could consolidate them for me :P 18:34:06 <glx> it should be possible to use [STORE_TEMP(), procedure()] 18:34:54 <glx> and in the procedure you use LOAD_TEMP() to get the parameter 18:35:24 <andythenorth> :) 18:36:18 * andythenorth wonders how compilers optimise 18:37:15 <andythenorth> this expression is all keywords 18:37:20 <andythenorth> (climate != CLIMATE_TROPIC) || ((climate == CLIMATE_TROPIC) && (nearby_tile_terrain_type(0, 0) == TILETYPE_DESERT)) || ((climate == CLIMATE_TROPIC) && (nearby_tile_terrain_type(0, 0) == TILETYPE_NORMAL) && ((nearby_tile_terrain_type( 1, 0) != TILETYPE_DESERT) && (nearby_tile_terrain_type(-1, 0) != TILETYPE_DESERT) && (nearby_tile_terrain_type( 0, 1) != TILETYPE_DESERT) && (nearby_tile_terrain_type( 0,-1) != 18:37:20 <andythenorth> TILETYPE_DESERT) ) ) 18:37:26 <glx> and we could probably add something like function name(args..) { return <calculation>; } to let nmlc generate the varact2 18:37:31 <andythenorth> so presumably all instances of it could be resolved to one instance 18:37:36 <andythenorth> automatically :P 18:37:56 <andythenorth> do compilers construct tables of recurring patterns? 18:38:14 <glx> I don't think nmlc does :) 18:39:34 <andythenorth> :) 18:40:27 <Samu> it exists 18:40:40 <Samu> + [2595] {element={type=VKI_STATION (0) id={station=1746 town=1746 sign=1746 } center=-48128 ...} left=2597 right=...} Kdtree<ViewportSignKdtreeItem,int (__cdecl*)(ViewportSignKdtreeItem const &,int),int,int>::node 18:40:49 <Samu> it's in the list of nodes 18:40:55 <Samu> it just fails to find it 18:41:24 <nielsm> does the cached position match the expected? 18:41:40 <nielsm> (cached position = the position stored in the tree) 18:42:02 <Samu> center, left and right? 18:42:05 <nielsm> yes 18:42:16 <Samu> not sure how to check, but let me try 18:42:51 *** supermop_work_ has quit IRC 18:44:00 <Samu> https://imgur.com/qmWN94d 18:44:29 *** supermop_work_ has joined #openttd 18:44:53 <Samu> nop, doesn't seem to match 18:45:07 <Samu> sec, i take another screenshot 18:45:18 <DorpsGek_III> [OpenTTD/OpenTTD] nielsmh commented on pull request #7353: Feature: Measure vehicle capacity utilisation efficiency https://git.io/Je15f 18:46:09 <Samu> https://imgur.com/a/glwkJej 18:46:16 <Samu> 2 screenshots 18:46:52 <Samu> the top for one is 43872, the top for the other is 43904 18:46:59 <Samu> they should have the same value, right? 18:47:09 <glx> I think I know what happened 18:47:35 <glx> dock removed, land raised, sign moved 18:47:44 <nielsm> ah yeah 18:48:06 <nielsm> so changing land height below a ghost station sign can trigger bugs 18:48:08 <nielsm> ugh 18:48:53 <DorpsGek_III> [OpenTTD/OpenTTD] nielsmh updated pull request #7353: Feature: Measure vehicle capacity utilisation efficiency https://git.io/fhho4 18:48:59 <glx> let see if I can reproduce using these simple steps 18:49:06 <Samu> land lowered, it seems 18:49:35 <glx> whatever the sign moved 18:49:41 <andythenorth> maybe I can speed up PIL :P 18:50:06 <DorpsGek_III> [OpenTTD/OpenTTD] nielsmh commented on pull request #7353: Feature: Measure vehicle capacity utilisation efficiency https://git.io/Je15T 18:50:40 <glx> it's annoying to not be able the batch replies to reviews ;) 19:11:13 <peter1138> Yeah 19:11:38 *** snail_UES_ has quit IRC 19:12:41 <nielsm> glx: you can if you go to the Files Changed tab first 19:14:43 *** supermop_work_ has quit IRC 19:20:06 *** supermop_work_ has joined #openttd 19:43:31 <glx> and write a new review ? 19:44:21 <Samu> i can't reproduce the crash glx 19:44:39 <Samu> raised land, lowered land, nothing seems to make it crash 19:50:19 *** supermop_work_ has quit IRC 19:51:31 *** supermop_work_ has joined #openttd 20:04:25 <Samu> strange, when I load an autosave from a month earlier 20:04:46 <Samu> i get top = 43904, and it's now node 171, instead of 2595 20:05:07 <nielsm> is the station already demolished at that time? 20:05:11 <Samu> yes 20:05:17 <nielsm> yeah 20:05:22 <glx> node changes when something is added removed, ignore the nod ;) 20:05:29 <nielsm> the tree is recalculated when the save is loaded 20:05:30 <glx> *node index 20:05:51 <Samu> so, gonna try load when the station is not yet demolished 20:06:06 <nielsm> so if you save and reload while the tree is in an inconsistent state, the state will be rebuilt to be consistent 20:06:13 <glx> the main issue is to find why the sign "moved" 20:06:49 <glx> or how we can move it without updating the tree 20:10:59 <Samu> top = 43872 with the station yet built 20:11:42 <Samu> if i delete the station, will i get the crash now? 20:11:43 <nielsm> how does the map look with the station in place? 20:11:59 <nielsm> compared to how it looks after it was deleted 20:12:10 <nielsm> sorry, demolished not deleted 20:12:48 <Samu> https://imgur.com/1SAlRbV looks like this 20:13:42 <nielsm> so the AI demolishes the dock and also lower the land piece it sits on 20:13:59 <Samu> yes, but he's not demolishing now :( 20:14:18 <Samu> ais after load tend to do different than a straight run 20:14:41 <nielsm> yes they use the interactive random, not a game state random 20:21:42 *** supermop_work_ has quit IRC 20:24:56 *** supermop_work_ has joined #openttd 20:26:20 <Samu> yay, i think i found a more reproducible way to crash it 20:26:41 <Samu> gonna try again to confirm 20:29:02 <Samu> yes! it crashed 20:29:03 <Samu> gonna post 20:31:55 <DorpsGek_III> [OpenTTD/OpenTTD] SamuXarick commented on issue #7847: Crash - Assertion failed at line 213 of src\core\kdtree.hpp: next != INVALID_NODE https://git.io/Je1Eh 20:34:23 <Samu> in autosave11 the top value is different than that in autosave12, because the dock still exists in 11, but not in 12 20:34:57 <Samu> if i load the autosave12 it won't crash 20:36:23 <Samu> do you want autosave12? 20:37:08 <nielsm> I wonder what the trigger for the sign moving it though 20:37:43 <Samu> if you don't lower the land after demolishing the docks, autosave11 won't crash either 20:37:50 <Samu> so it's something related to lowering land 20:38:07 * andythenorth wonders if grfcodec could be faster 20:38:08 <nielsm> normally ghost station signs don't move after modifying the land below them 20:38:28 <glx> the sign moves when the dock is removed but doesn't cause crash 20:39:37 <glx> and it moves because content changes 20:41:40 <glx> waiting for the sign to disappear at 7fps takes time :) 20:41:52 <nielsm> yeah... 20:41:57 <nielsm> but I reproduce it too with that save 20:42:11 <DorpsGek_III> [OpenTTD/OpenTTD] nielsmh commented on issue #7847: Crash - Assertion failed at line 213 of src\core\kdtree.hpp: next != INVALID_NODE https://git.io/Je1Eh 20:43:20 *** snail_UES_ has joined #openttd 20:48:04 <andythenorth> hmm 20:48:14 <andythenorth> I need to save 5s on generating the nml 20:49:20 <andythenorth> the overhead of starting the template engine is 1s 20:49:37 <andythenorth> so I don't think parallelising will help :( 20:55:09 *** supermop_work_ has quit IRC 20:57:33 <nielsm> okay the bug seems to occur already in demolishing the station 20:57:39 <nielsm> lowering the land is not required 20:58:44 *** supermop_work_ has joined #openttd 21:04:17 <glx> I tried building something similar but that doesn't trigger 21:04:32 <nielsm> yeah it depends on the rest of the map and signs 21:05:03 <nielsm> it has to be sufficiently large and positioned "correctly" so the station sign that moves ends up in a different position in the tree 21:05:24 <glx> ah yes it's the only station I have when I try 21:05:33 <DorpsGek_III> [OpenTTD/OpenTTD] nielsmh commented on issue #7847: Crash - Assertion failed at line 213 of src\core\kdtree.hpp: next != INVALID_NODE https://git.io/Je1Eh 21:09:53 <DorpsGek_III> [OpenTTD/OpenTTD] nielsmh commented on issue #7847: Crash - Assertion failed at line 213 of src\core\kdtree.hpp: next != INVALID_NODE https://git.io/Je1Eh 21:11:20 <nielsm> if you want to trace it, breakpoint in ClearTile_Station() and follow it into RemoveDock() 21:12:12 <nielsm> and stuff happens with the st->rect.AfterRemoveTile() until st->AfterStationTileSetChange() calls 21:15:11 <nielsm> the reason the sign moves is not because it gets moved, or the tile height changes, but because the way the tile z coordinate is calculated changes when the tile changes from a station tile to a clear tile 21:16:05 <glx> because it's a slope 21:16:49 <nielsm> yeah 21:26:56 <andythenorth> oof can't commit this to a public repo eh :D 21:26:58 <andythenorth> ../../pypy3/bin/nmlc -l generated/lang --verbosity=4 --nfo=generated/iron-horse.nfo generated/iron-horse.nml 21:27:42 <glx> hardcoded path to an exe ? 21:27:50 <andythenorth> :( 21:28:09 <andythenorth> 39s vs 55s 21:28:58 *** supermop_work_ has quit IRC 21:30:48 *** supermop_work_ has joined #openttd 21:36:53 <andythenorth> Makefile.local and gitignore it? :P 21:43:56 <andythenorth> that seems to work fine 21:44:20 <andythenorth> @calc 39/68 21:44:20 <DorpsGek> andythenorth: 0.573529411765 21:44:28 <andythenorth> not a bad speed up 21:44:37 <andythenorth> overall 21:56:04 <Samu> Point pt = RemapCoords2(TileX(this->xy) * TILE_SIZE, TileY(this->xy) * TILE_SIZE); 21:56:16 <Samu> Point pt = RemapCoords(TileX(st->xy) * TILE_SIZE, TileY(st->xy) * TILE_SIZE, GetTileMaxZ(st->xy) * TILE_HEIGHT); 21:56:27 <Samu> could this be the issue? 21:56:51 <nielsm> no 21:56:56 <nielsm> I'm fixing that too, but it isn't 21:57:00 <nielsm> I know exactly what's going wrong 21:57:02 <Samu> oh, cool 21:57:04 <nielsm> and it's annoying to fix 21:58:01 <glx> I think it could be done in ViewportSign::UpdatePosition() 21:58:10 <supermop_Home> andythenorth: why do sliding wagons cost more than curtain sided? 21:58:25 <nielsm> glx yes and no 21:59:54 <glx> but it first needs to check it's already in the tree before maybe remove 22:01:01 *** supermop_work_ has quit IRC 22:03:38 <andythenorth> supermop_Home: not sure :D cost in code is the same for both 22:05:07 <supermop_Home> i mean at this point i can afford the sliding side wagon, running cost is the same 22:05:26 <supermop_Home> i figure it might look better for shipping vehicles 22:06:33 *** supermop_work_ has joined #openttd 22:08:09 <supermop_Home> its like 27 vs 51 for the large wagon 22:10:33 <andythenorth> mine all cost same :) 22:11:09 <andythenorth> oh the tarp wagon is cheaper 22:12:15 <supermop_Home> well the metal sided looks more like a car carrier 22:12:31 <supermop_Home> so im paying the premium for it 22:13:58 <andythenorth> I should finish the vehicle wagons :P 22:14:01 *** snail_UES_ has quit IRC 22:14:17 <andythenorth> https://dev.openttdcoop.org/attachments/download/9482/vehicles_cars_trucks_5.png 22:14:39 <nielsm> glx no doesn't fix it, I suspected that 22:15:06 <supermop_Home> if im dropping a town effect cargo off on the outskirts of town (at a black hole industry) does the TE go to the town with the station name, or closest by mht distance? 22:15:13 <nielsm> thing is the expected position of the sign changes behind the station code when the tile is modified after it stops being a station tile 22:16:07 <nielsm> really ViewportSignKdtreeItem::MakeStation() ought to use BaseStation::sign.top and .center for the position 22:16:18 <nielsm> but those aren't always valid when it gets called first, I think 22:18:41 <glx> ah yes ViewportSign::UpdatePosition() can't know the object containing it 22:21:06 <nielsm> I think I need to make a StationViewportSign inheriting ViewportSign and keeping track of its kdtree state 22:35:57 <supermop_Home> how many tiles away until luxury passenger car makes sense? 22:37:15 *** supermop_work_ has quit IRC 22:38:28 <nielsm> depends on train speed too I think 22:39:06 <nielsm> since the effect of luxury passenger cars is to make the trip "feel shorter" 22:39:39 <nielsm> if it's sufficiently long (too slow) then you'll hit the max cap I think exists 22:39:51 <supermop_Home> 185 kph… still haven't figured out all the livery easter eggs in IH 22:41:27 <andythenorth> in tests it's about 64 tiles or so 22:42:05 <andythenorth> the luxury pax cars actually do ~nothing 22:42:16 <andythenorth> the standard pax cars have to have a nerf 22:42:38 <supermop_Home> luxury in HST? 22:42:44 <andythenorth> the decay rate modifier is mostly useless 22:43:15 <supermop_Home> these are just 4 tile push-pulls with a fury on the back 22:43:24 <supermop_Home> and mail emu up front 22:43:35 <supermop_Home> look nice 22:44:54 <andythenorth> :) 22:46:39 *** supermop_work_ has joined #openttd 22:49:14 *** Progman has quit IRC 23:03:13 <DorpsGek_III> [OpenTTD/OpenTTD] nielsmh opened pull request #7849: Fix #7847: Use ViewportSign coordinates for sign Kdtree coordinates for stations https://git.io/Je1bx 23:03:51 <nielsm> Samu: test that :) 23:13:42 <Samu> ok 23:15:55 <Samu> uhm, i forgot what was the command 23:16:03 <Samu> glx, to create a PR 23:16:13 <glx> git pr <number> 23:16:24 <glx> easy to remember :) 23:16:52 *** supermop_work_ has quit IRC 23:21:07 <Samu> waiting for sign to disappear 23:21:25 <Samu> is this the right way to test? load the savegame with the station? 23:21:34 <nielsm> yes 23:21:41 <Samu> remove it, and lower terrain 23:21:42 <Samu> ok 23:21:47 <nielsm> also it helped me to test by getting rid of all installed AIs 23:23:53 <Samu> yep, sign poof, no crash 23:24:00 <glx> code looks good and simplifies a lot of corner cases 23:24:19 *** supermop_work_ has joined #openttd 23:25:26 <Samu> gonna try restarting the world 23:25:34 <Samu> see if it passes 1961 23:25:42 <Samu> starting at 1935 23:25:47 *** Progman has joined #openttd 23:27:30 *** snail_UES_ has joined #openttd 23:27:41 <nielsm> glx: indeed after getting the idea it's quite a "why didn't I do that from the beginning" moment 23:27:55 <glx> I know the feeling 23:29:23 <Samu> i should be in bed, they don't let me stay up this late 23:30:05 <glx> then go to be, you can test tomorrow :) 23:30:12 <glx> *bed 23:30:30 <Samu> ok, take care 23:32:29 <Samu> 1940, come on, faster!! 23:32:35 *** Wolf01 has quit IRC 23:33:35 <Samu> meh, better go 23:33:37 <Samu> bye 23:36:12 <DorpsGek_III> [OpenTTD/nml] glx22 opened pull request #67: Minor changes in regression Makefile and .gitignore https://git.io/Je1N2 23:38:02 <nielsm> and me too, gn 23:38:30 <andythenorth> bed 23:38:31 *** andythenorth has left #openttd 23:41:42 *** Samu has quit IRC 23:46:16 *** nielsm has quit IRC 23:51:03 <DorpsGek_III> [OpenTTD/nml] glx22 updated pull request #67: Minor changes in regression Makefile and .gitignore https://git.io/Je1N2 23:54:32 *** supermop_work_ has quit IRC 23:55:26 *** supermop_work_ has joined #openttd