IRC logs for #openttd on OFTC at 2019-09-18
⏴ go to previous day
00:02:17 <Eddi|zuHause> we've had special code for 3x3 grid fillings for ages, the corner thing is new
00:47:40 *** WormnestAndroid has quit IRC
00:54:49 *** WormnestAndroid has joined #openttd
01:11:04 *** WormnestAndroid has quit IRC
01:12:17 *** WormnestAndroid has joined #openttd
01:14:06 *** Thedarkb-X40 has joined #openttd
03:24:32 *** ChanServ sets mode: +v tokai
06:01:24 *** tokai|noir has joined #openttd
06:01:24 *** ChanServ sets mode: +v tokai|noir
06:50:13 *** sla_ro|master has joined #openttd
06:54:41 *** Eddi|zuHause2 has joined #openttd
07:01:15 *** Eddi|zuHause2 is now known as Eddi|zuHause
07:01:49 *** WormnestAndroid has quit IRC
07:21:55 *** WormnestAndroid has joined #openttd
07:39:30 *** ChanServ sets mode: +v tokai
08:01:50 *** WormnestAndroid has quit IRC
08:06:46 <DorpsGek_III> [OpenTTD/OpenTTD] andythenorth commented on pull request #7745: Feature: setting for more flexible town spacing https://git.io/JeOdw
08:25:58 *** WormnestAndroid has joined #openttd
08:58:28 *** andythenorth has joined #openttd
09:30:51 *** tokai|noir has joined #openttd
09:30:51 *** ChanServ sets mode: +v tokai|noir
11:03:28 *** andythenorth has joined #openttd
11:18:22 * andythenorth resists making lunch.grf
11:19:27 <peter1138> How did you know I have salad today?
11:19:50 <andythenorth> whichever you believe in more
11:20:02 <peter1138> Remember the days when I use to walk down to the Co-op and buy a lunch deal. Every day?
11:20:21 <peter1138> Somehow I suspect that was cheaper, heh.
11:56:08 <Etua> What is more common: if a creators of NewGRFs create necessary art themselves or do they hire someone from the community for that task if they don't feel competent enough?
11:57:17 <andythenorth> by about 99.9:0.1
12:01:02 <Etua> Thanks and is there a clever way to avoid conflicts for example when someone is using massive GRF adding multiple categories of stuff but would like to install another one that handles one specific thing with more detail? What about 32-bit graphics? Should I use it, the default one or prepare for both? I would like to develop some GRF but I need to know these thing beforehand so I would not waste my time creating something incompatible with the rest of th
12:01:11 *** Eddi|zuHause2 has joined #openttd
12:01:31 <andythenorth> 32 bit graphics is your choice
12:01:58 <andythenorth> I have a strong opinion against them, so my advice is not balanced on 32bpp
12:02:15 <andythenorth> grf with multiple categories, your choices are
12:02:20 <andythenorth> - split it up into smaller grfs
12:02:27 <andythenorth> - detect known incompatible grfs when loading
12:04:04 <andythenorth> and I add more when people report conflicts
12:04:39 <Etua> I meant that I would like to create that more detailed GRF but at the same time I would not expect someone to drop their multi-category GRF like FIRS just to install mine.
12:05:05 <andythenorth> you can disable some features
12:05:14 <andythenorth> either automatically, or with user parameters
12:07:45 *** ChanServ sets mode: +v tokai
12:09:12 <Etua> Within my GRF or the bigger one? If my mod evolves around transferring and processing one type of cargo which happens to also exist in other GRF then disabling the features in my mod that are connected with that cargo would essentially disable the GRF completely or can it be done differently like automatically that some type of cargo is decared by other GRF so I would add new types of buildings etc. while avoiding doubling the same cargo within the game?
12:10:07 <Etua> In the last part I mean that instead of creating a new cargo I reuse the existing one with new features, I should have formulated it differently.
12:10:39 <andythenorth> general advice: only one industry + cargo grf should be active
12:11:25 <andythenorth> multiple industry + cargo grfs causes unexpected results, unless they're deliberately designed to work together
12:15:58 <DorpsGek_III> [OpenTTD/OpenTTD] Eddi-z commented on pull request #7745: Feature: setting for more flexible town spacing https://git.io/JeONV
12:20:52 *** Eddi|zuHause2 is now known as Eddi|zuHause
12:21:52 <Etua> I had an idea for the GRF about processing trash which would be generated in the cities like the mail with specialised vehicles for transporting it everything could evolve over time so you would have only dump sites in the beginning, then you could burn it and in the end you would get the ability to recycle with profitability working like 3>2>1. Do you think that I could make it to work in a manner that the first two sites would be dead ends and the third
12:21:54 <Etua> one would alter depending on whether FIRS is present with my trash cargo turning into recyclables cargo in the FIRS recycling depot and then being processed by FIRS or if FIRS is not present building my GRF's own processing plant which would create some standard goods for simplicity? Do you think that such hybrid solution would be feasible?
12:25:17 <andythenorth> FIRS used to have trash
12:26:56 <andythenorth> making a grf that tries to modify or replace FIRS industries is unlikely to work well
12:27:26 <andythenorth> making an add-on that complements FIRS but doesn't need to change it would work
12:27:33 <andythenorth> did someone make trash chain?
12:30:51 *** tokai|noir has joined #openttd
12:30:51 *** ChanServ sets mode: +v tokai|noir
12:43:53 <Etua> I came up with the idea last year and FIRS was the only GRF that I could find which actually implemented it but because I felt that my idea greatly extends it's behaviour I decided that I could do it anyway. My only problems were images for vehicles and buildings and possible problems with compatibility. I the scheme I described in the last message my GRF would operate on the other type of cargo up until conversion into recyclables and that's where I see
12:43:55 <Etua> a potential source of problems because 1. I would need to check whether FIRS is installed and convert my trash cargo to recyclables from FIRS somewhere, ideally in the recycling depot 2. If I could not change the behaviour of recycling depot the rest of the GRF would not make sense because why would you want to get trash from the city when you would have more valuable recyclables popping out of thin air in the recycling depot?
12:48:50 <Etua> Is the limit of city buildings producing maximum two types of cargo still valid? I remember that I have done some research on the topic last year but I forgot what was the conclusion.
12:49:10 <andythenorth> you could fork FIRS
12:50:31 <Etua> I could but if the limit of two types of cargo per building is still in place then most of my concept can go to trash.
12:57:56 <Etua> Great, does FIRS specify requirements for transport vehicles? Like can you transport everything introduced in FIRS with standard means or does it introduce it's own?
12:59:26 <andythenorth> the convention is to keep industry grfs separate from vehicle grfs
12:59:33 <andythenorth> so FIRS doesn't touch vehicles at all
12:59:57 <andythenorth> this means user has to find newgrfs that support the new cargos :|
13:00:13 <andythenorth> but it's more correct
13:00:35 <andythenorth> hmm possibly FIRS should mod the default vehicles :P
13:00:40 * andythenorth never considered that
13:01:50 <Etua> Wouldn't that introduce possible conflicts with vehicle GRFs that support cargo from FIRS?
13:03:47 <andythenorth> it might be possible to modify default vehicle properties
13:03:53 <andythenorth> I haven't really looked
13:04:05 <andythenorth> really the default vehicles should be fixed permanently in openttd :P
13:04:46 <Etua> You mean that they should not be editable nor removable or that there should not be vehicle GRFs?
13:10:07 <andythenorth> the default vehicles should support refitting to cargos in industry grfs, using cargo classes
13:43:23 *** WormnestAndroid has quit IRC
13:43:37 *** WormnestAndroid has joined #openttd
13:59:49 *** dihedral has joined #openttd
15:15:03 *** supermop_work has joined #openttd
15:45:06 <DorpsGek_III> [OpenTTD/OpenTTD] nielsmh commented on pull request #7745: Feature: setting for more flexible town spacing https://git.io/JeOpW
15:55:18 <DorpsGek_III> [OpenTTD/OpenTTD] sirkoz commented on pull request #7736: Fix: Avoid using stat to retrieve file modification times on Windows (#7731) https://git.io/JeOpo
15:58:13 <DorpsGek_III> [OpenTTD/OpenTTD] andythenorth commented on pull request #7745: Feature: setting for more flexible town spacing https://git.io/JeOpP
16:22:26 <DorpsGek_III> [OpenTTD/OpenTTD] LordAro commented on pull request #7736: Fix: Avoid using stat to retrieve file modification times on Windows (#7731) https://git.io/JeOhL
16:56:05 *** Wormnest_ has joined #openttd
17:20:06 <Samu> comes stronger out of it, for some reason
17:27:45 <Samu> civilai enjoyed first place for 1 year
17:28:13 <Samu> didn't suffer much from the recession
18:37:40 <Samu> when did the downfall of my life start
18:37:45 *** frosch123 has joined #openttd
18:45:02 *** HerzogDeXtEr has joined #openttd
18:46:32 <Samu> I'm gonna be surprised if CivilAI ends 2050 in first place
18:47:01 <Samu> the 3 first are so close in profits to each other
18:52:29 *** Progman has joined #openttd
19:10:59 <Samu> btw guys, fix the pathfinder cache issue
19:11:20 <Samu> for 1.10 or 1.9.4 or somethin
19:20:07 <andythenorth> I wonder which issue he has reported it in
19:26:27 <andythenorth> ouch slow visual diff is slow
19:27:29 <andythenorth> also, css is now witchcraft
19:27:36 <andythenorth> and it actually works!
19:27:43 <andythenorth> there is a vh unit for viewport height
19:27:46 <andythenorth> and it actually works!
19:45:49 <DorpsGek_III> - Update: Translations from eints (by translators)
20:11:37 <DorpsGek_III> [OpenTTD/OpenTTD] Eddi-z commented on pull request #7745: Feature: setting for more flexible town spacing https://git.io/Je3JA
20:19:02 <andythenorth> so how to build longer town bridges then?
20:22:49 <Eddi|zuHause> <andythenorth> hmm possibly FIRS should mod the default vehicles :P <-- that sounds like a horrible idea. we'll get endless complaints about "i use X vehicle GRF, how can i disable the default vehicles?!"
20:23:14 <andythenorth> presumably modding them stops them being disabled?
20:23:55 <Eddi|zuHause> it introduces a copy of the default vehicles, that other grfs cannot disable
20:25:36 <Eddi|zuHause> ... and nobody would think this is the fault of an industry grf
20:25:47 <Eddi|zuHause> so making that a parameter won't help either
20:27:32 <andythenorth> refittability for default vehicles? :P
20:37:14 <TrueBrain> so how difficult would it be to rewrite the MasterServer in Python .. hmm ..
20:37:23 <TrueBrain> I need to recompile an OpenTTD client ..
20:38:13 *** sla_ro|master has joined #openttd
20:38:19 <Eddi|zuHause> that sounds like an insurmountable task.
20:41:39 <TrueBrain> VS2019 license expired, strike 1
20:41:48 <TrueBrain> sln project file tells me weird shit, strike 2
20:42:28 <Eddi|zuHause> tbh, i hate setting up compilers...
20:43:57 <TrueBrain> yeah ... I needed to crosscompile for MIPS and ARMs and others lately ..
20:45:03 <nielsm> okay so there's two ways to handle this "game length" setting together with a "game end year" setting: either entirely ignore the "game end year" setting if the game length is set, and just compare current year to starting year + game length, or when the game is started modify the end year to be start year + game length
20:46:05 <Eddi|zuHause> nielsm: might be easier to just drop the end year and just use game length
20:46:16 <TrueBrain> b'\x05\x00\x06\x02\x02'
20:46:16 <TrueBrain> b'\x1e\x00\x04OpenTTDRegister\x00\x02\x8b\x0f\x00\x00\x00\x00\x00\x00\x00\x00'
20:46:36 <TrueBrain> Servers nicely have a banner, Clients do not .. owh joy .. who designed this protocol?
20:47:13 <andythenorth> towns have do-while checking water tiles and crap
20:47:16 <Eddi|zuHause> TrueBrain: must have been a total idiot.
20:47:29 <TrueBrain> don't know who it was, but pfft
20:47:32 <andythenorth> and I want it to then continue 1 extra tile
20:47:36 <TrueBrain> I hope his commit rights are revoked by now
20:47:42 * andythenorth is well out of depth
20:47:48 <andythenorth> this is actual programming :P
20:51:18 <Eddi|zuHause> andythenorth: i haven't looked at the code, but the bigger problem should be starting 1 tile early
20:51:30 <andythenorth> I made that happen by accident
20:52:45 * andythenorth wonders about more permissive town building
20:52:56 <andythenorth> IRL I can knock a town bridge down and build a new one
20:57:25 <TrueBrain> wuth, the UDP protocol is LE? Holy crap ...
20:58:31 <TrueBrain> what have we been smocking back then ..
21:06:21 <Samu> out of curiosity, gonna keep this running
21:06:42 <nnyby> does your ai work on squirrel 3? i keep forgetting to try that. maybe ill do that tonight.
21:07:19 <Samu> i haven't uploaded the new version yet
21:07:35 <Samu> i'm not sure how i will upload
21:08:02 <Samu> i can't create .tar files here
21:09:49 <Samu> nop, i dont have github desktop here
21:10:15 <Samu> gonna try upload something, but the change log is missing
21:10:58 <milek7> TrueBrain: what's wrong with LE?
21:11:33 <TrueBrain> milek7: network protocols .... LE ....
21:11:52 <TrueBrain> network byte order realllllyyyyy should always be BE
21:11:56 <milek7> i think usage of BE in most protocols is just historial artifact?
21:12:14 <TrueBrain> every sane protocol uses BE
21:12:18 <TrueBrain> as that removes the 'guessing' ;)
21:13:21 <TrueBrain> it is just annoying as fuck if protocol don't do it like that
21:13:29 <TrueBrain> sadly ......... I can only hit myself in the head, as I wrote this darn thing :(
21:13:37 <TrueBrain> so I feel stupid for the ... 20-year-old-me?
21:14:31 <Samu> nnyby: uploaded to github, can you try it
21:15:25 <Samu> actually this github diff viewers will help me with the changelog
21:15:31 <milek7> and < is LE... so what problem does it create?
21:15:41 <andythenorth> TrueBrain: you have to develop forgiveness for former us
21:15:46 <andythenorth> former us are thick as bricks
21:16:32 <TrueBrain> so how to explain this clearly ..... this is a network protocol ... so you expect it to be in BE, as .. every protocol should be ... it isn't ... so I spend at least 5 minutes double checking what endianess this freaking protcol has .. so yeah ... problem created by 20-year-old-me, tnx dude
21:17:30 <TrueBrain> also means I have to take care with htons .. oops ..
21:17:39 <TrueBrain> *mental note added to list ... stack corruption .. shit*
21:20:10 *** gelignite has joined #openttd
21:20:37 <nielsm> I wonder if there's a way in afterload.cpp to know whether this is a scenario being loaded as a new game
21:24:22 <TrueBrain> /* If Load Scenario / New (Scenario) Game is used,
21:24:22 <TrueBrain> * a company does not exist yet. So create one here.
21:25:56 <TrueBrain> PacketInvalidSize: (20, 20) <- pro programmer at work
21:26:32 <nielsm> when starting a game from scenario, should it use the ending year set by the scenario, or by the client's newgame settings
21:28:19 <nielsm> and also, if you load an old scenario in the editor, should it take on the original ending year, or the newgame settings ending year?
21:35:20 <TrueBrain> we support requesting only IPv4 or IPv6 servers, but the client always says AUTODETECT ..
21:39:55 <TrueBrain> funny, if you talk IPv6 with the MasterServer, your server-list is IPv6 servers only, so it seems
21:40:09 <TrueBrain> bit nasty if you are dual-stack, I guess
21:40:24 <TrueBrain> most IPv6 servers also announce on IPv4, but still
21:44:20 <nielsm> Eddi|zuHause: do you have an opinion on ending year handling for scenarios?
21:45:08 <Eddi|zuHause> but my tendency would be "the scenario developer is in control"
21:46:45 <nielsm> yeah that's probably the stronger argument
21:47:11 <nielsm> then it's just, what about when the scenario developer never had a chance of being in control (old scenario started as new game)
21:49:23 <nielsm> "always convert to original ending year on load, regardless of scenario or not" is the easiest so maybe just what should be done
21:56:05 <Eddi|zuHause> "just assume a sane default" seems to be appropriate
21:56:43 <Eddi|zuHause> i don't see how that should be different between old savegames and old scenarios
21:59:15 *** supermop_work has joined #openttd
22:01:21 <milek7> looks like javascript canvas is vsynced
22:01:36 <milek7> so it must run 10% slower, at 30fps
22:02:31 <Eddi|zuHause> milek7: there was always some lingering discussion whether that was the originally intended game speed anyway
22:03:28 <nielsm> isn't SVGA refresh 70 Hz or am I misremembering?
22:03:37 <nielsm> if it is, then 35 fps might be just as reasonable
22:10:01 <Eddi|zuHause> historically, TV screen refresh rate was tied to the power frequency (50Hz in europe, 60Hz in the US), with computer screens, the american 60Hz seems to have established as a standard
22:13:38 <milek7> in last years of CRTs I remember changing refresh rate on people computers from 60hz to 75hz
22:13:44 <milek7> it made so much difference, 60hz was just terribly flickering
22:14:00 <milek7> ..and most said they didn't care
22:14:39 <orudge> Oh yes, I seem to remember 85Hz or so was comfortable for me
22:37:22 <Eddi|zuHause> 75Hz does seem to ring a bell
22:37:56 <Eddi|zuHause> but it was just one of the many options you had with SVGA
22:38:35 <Eddi|zuHause> also, you could have high refreshrate or high resolution, but not both.
22:39:58 <nielsm> classic mode 13h (320x200x8) runs at 70 hz at least
22:40:53 <nielsm> and so do regular 80 and 40 column text modes
22:51:35 <andythenorth> I should try this bridge hack some more
22:51:42 <andythenorth> pls send me the codez
23:09:40 <TrueBrain> sorry, I only have nudes :(
23:12:32 <Eddi|zuHause> awesome, SVGA user's manual: "the above sequence should be familiar to anyone who has ever called the BIOS from assembly code"
23:13:27 <TrueBrain> so nobody under the age of, what, 30? :D
23:13:54 <glx> I think I never called BIOS from assembly
23:14:16 <Eddi|zuHause> this manual is from 1992
23:15:30 <glx> oh and I probably seen some of this calls during opendune first steps :)
23:17:21 <Eddi|zuHause> "* place a O [did they mean 0? they didn't write 0] in register AH to indicate "select mode" function * Place the mode number in register AL * Execute an INT 10h instruction"
23:20:43 <Eddi|zuHause> i've certainly seen INT 10h mentioned before, but i have no clue what it does, or how to invoke it
23:22:15 <Eddi|zuHause> but do modern day graphics card manuals contain that kind of low-level information?
23:22:23 <milek7> it's just instruction causing interrupt
23:23:09 <glx> hmm no, modern graphics card barely tells you how to plug it
23:24:07 <glx> and I think nobody tries to access it directly from code
23:24:16 <glx> unless you're writing a driver
23:29:26 <FLHerne> Eddi|zuHause: AMD publish all that information, but probably not in the user manual :-/
23:30:09 <glx> user doesn't really care about that info anyway
23:30:42 <Eddi|zuHause> glx: but that was probably also true for the SVGA cards from almost 30 years ago
23:32:18 <glx> do you want an cmake branch rebase ?
23:32:47 <TrueBrain> I still think we should merge cmake asap
23:33:01 <andythenorth> merge everything, call it 2.0
23:33:05 <milek7> ISA are usually published
23:33:09 <milek7> but I don't think manuals about initalizing and displaying something on it are available
23:33:29 <glx> yeah we could merge, then let people commenting on the PR submit their changes :)
23:34:00 <TrueBrain> the current comments on the PR don't add anything, really
23:34:08 <TrueBrain> in CMake world, everyone thinks it should be done differently
23:34:11 <TrueBrain> there is no "truth"
23:34:18 <TrueBrain> just ..... different ways of approaching the same problem
23:34:47 <TrueBrain> so yeah ... let them make a PR if they think their way is better .. it possible (even more likely) is
23:34:58 <TrueBrain> but just having people say it should be different, doesn't contribute tbh
23:35:05 <TrueBrain> "This header file should contain a header guard to prevent multiple inclusion." <- lol, this indeed is a bug :D
23:35:37 <TrueBrain> "Comparison is always true because tmp_cidr <= 0 and 32 <= cidr." <- errors with the variable names in them, nice :D
23:36:29 <andythenorth> if it works, it's 'done'
23:37:40 <TrueBrain> "This parameter of type NetworkAddress is 224 bytes - consider passing a const pointer/reference instead." <- oef
23:39:27 <TrueBrain> but I am pretty sure coverity reported more :D
23:40:30 <milek7> there is also PVS-Studio
23:41:45 <glx> "Comments containing 'FIXME' indicate that the code has known bugs." hmm yes
23:41:55 <TrueBrain> not LGTM is part of the GitHub family, you can also enable this for every PR
23:42:25 <TrueBrain> nice baseline of quality-of-control
23:50:36 *** andythenorth has left #openttd
continue to next day ⏵
