IRC logs for #openttd on OFTC at 2023-07-16
01:03:54 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
01:52:32 <DorpsGek> [OpenTTD/OpenTTD] shoter updated pull request #11092: fix: Correct order of messages for admin port company msgs
01:55:43 <DorpsGek> [OpenTTD/OpenTTD] shoter closed pull request #11092: fix: Correct order of messages for admin port company msgs
02:11:26 *** D-HUND has joined #openttd
02:12:03 <DorpsGek> [OpenTTD/OpenTTD] shoter opened pull request #11140: Fix #10983: [AdminPort] Correct order of messages
02:15:05 *** debdog has quit IRC (Ping timeout: 480 seconds)
02:38:27 *** Wormnest has quit IRC (Quit: Leaving)
02:54:32 *** D-HUND is now known as debdog
03:18:09 *** Artea has quit IRC (Ping timeout: 480 seconds)
03:39:37 *** keikoz has joined #openttd
03:45:16 *** olionkey has quit IRC (Remote host closed the connection)
03:45:16 *** robinovitch61 has quit IRC (Remote host closed the connection)
03:45:16 *** talltyler has quit IRC (Remote host closed the connection)
03:45:16 *** peter1138 has quit IRC (Remote host closed the connection)
03:45:16 *** starbud has quit IRC (Remote host closed the connection)
03:45:16 *** locosage has quit IRC (Remote host closed the connection)
03:45:16 *** kamnet has quit IRC (Remote host closed the connection)
03:45:16 *** kuhnovic has quit IRC (Remote host closed the connection)
03:45:16 *** truebrain has quit IRC (Remote host closed the connection)
03:45:16 *** squirejames has quit IRC (Remote host closed the connection)
03:45:16 *** _jgr_ has quit IRC (Remote host closed the connection)
03:45:16 *** belajalilija has quit IRC (Remote host closed the connection)
03:45:16 *** merni has quit IRC (Remote host closed the connection)
03:45:16 *** DorpsGek_v has quit IRC (Remote host closed the connection)
03:45:16 *** ahyangyi has quit IRC (Remote host closed the connection)
03:45:16 *** andythenorth has quit IRC (Remote host closed the connection)
03:45:16 *** alfagamma_0007 has quit IRC (Remote host closed the connection)
03:45:16 *** frosch123 has quit IRC (Remote host closed the connection)
03:45:16 *** _glx_ has quit IRC (Remote host closed the connection)
03:45:16 *** emperorjake has quit IRC (Remote host closed the connection)
03:45:44 *** DorpsGek_v has joined #openttd
06:00:40 *** nielsm has joined #openttd
06:50:02 <DorpsGek> [OpenTTD/OpenTTD] Ananab123 commented on issue #11135: [Crash]:
07:12:57 *** Wolf01 has joined #openttd
07:50:30 *** HerzogDeXtEr has joined #openttd
08:10:08 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 merged pull request #11139: Fix: Integer overflow in LinkGraphOverlay::ShowTooltip for long links
08:15:10 *** gelignite has joined #openttd
08:32:39 *** andythenorth has joined #openttd
08:32:39 <andythenorth> o/
08:41:12 *** frosch123 has joined #openttd
09:10:44 <pickpacket> o/
10:23:05 *** Artea has joined #openttd
10:24:14 *** Kitrana has joined #openttd
10:41:27 <andythenorth> it's impossible for the grf to know whether a GS is present at `newgame` time?
10:41:35 <andythenorth> architecturally?
10:42:05 <andythenorth> I need to ban FIRS if the GS isn't active
10:42:58 <andythenorth> oh maybe I could just set probability of all industries to 0
10:43:01 <andythenorth> then have the GS build them
10:46:19 *** _glx_ has joined #openttd
10:46:19 <_glx_> Funny how you always ask the same question ๐Ÿ™‚
10:46:19 *** gelignite has quit IRC (Remote host closed the connection)
10:47:54 *** gelignite has joined #openttd
10:53:01 <andythenorth>
10:53:01 <andythenorth> I think there's a quote from Buffy the Vampire Slayer
10:57:33 *** kamnet has joined #openttd
10:57:33 <kamnet> Mmmmm ... Buffy. I need to rewatch.
11:02:00 *** squirejames has joined #openttd
11:02:00 <squirejames> Also Einstein I believe
11:02:11 *** truebrain has joined #openttd
11:02:11 <truebrain> pretty sure he didn't talk about murder rehab ๐Ÿ˜›
11:02:16 <squirejames> Probably not
11:02:22 <truebrain> ๐Ÿ˜„
11:02:28 <squirejames> I doubt he used the word "baby" either but hey ๐Ÿ˜„
11:02:43 <truebrain> maybe he was in a romantic mood!
11:04:03 <andythenorth> anyway, it's tricky to move map gen into GS because map gen happens before GS init
11:27:57 *** ahyangyi has joined #openttd
11:27:57 <ahyangyi> Andy, are you trying to implement some advanced industry placement rules that's only possible with gs?
11:31:08 <andythenorth> Kinda
12:10:44 <andythenorth> I need to count the number of connected water tiles for a location
12:10:53 <andythenorth> Can probably be done in grf
12:18:08 * andythenorth lost in algorithms
12:18:19 <andythenorth> Jump Flooding?
13:31:07 <andythenorth> Hmm industry layouts for ports
13:31:42 <andythenorth> Can probably just do one coast orientation, then auto-rotate them in python
13:37:40 *** peter1138 has joined #openttd
13:37:40 <peter1138> See, coupling GS to a specific NewGRF seems like a bad idea.
13:38:08 <peter1138> And, indeed, vice-versa.
13:38:17 <peter1138> Also, salad time.
13:40:41 <ahyangyi> Is coupling salad with salad dressing a good idea?
13:41:13 <peter1138> Yes, but any/any will do.
13:47:16 <andythenorth> peter1138: At least trying it will find out why itโ€™s a bad idea ๐Ÿ˜›
13:48:45 <peter1138> At the expense of a lot of work making the coupling possible in the first place.
13:49:21 <peter1138> WASM NewGRF?
13:50:14 <peter1138> My work project is like Company Shares right now.
13:50:40 <andythenorth> Becauseโ€ฆ? ๐Ÿ˜›
13:52:56 <peter1138> So much code removal ๐Ÿ™‚
13:53:49 <andythenorth> Coupling grf and GS via the grfid wasnโ€™t hard :p
13:54:04 <andythenorth> Nor generating a GS from python
13:54:19 <andythenorth> But itโ€™s a bit of a false summit
13:54:40 <andythenorth> grf has no way to adapt behaviour to the GS
13:55:01 <andythenorth> And GS canโ€™t read grf internals
13:55:37 <andythenorth> And thereโ€™s even less appetite to extend GS than for grf ๐Ÿ˜›
13:56:18 <andythenorth> And thereโ€™s no bundle / packsge format for players to install ๐Ÿ˜›
14:03:28 *** _jgr_ has joined #openttd
14:03:28 <_jgr_> Would it not be easier to add whatever is missing to the GRF spec?
14:04:01 <_jgr_> That way contortions to shoehorn in GSs are not necessary
14:08:50 *** Kitrana has quit IRC (Quit: Leaving.)
14:13:10 *** Kitrana has joined #openttd
14:22:05 <andythenorth> Maybe
14:26:19 <andythenorth> Writing a monthly loop per town is extremely convoluted in grf though
14:26:57 <andythenorth> It requires using industry loop, and using registers for comms
14:27:11 <andythenorth> I had it working in a branch but it was ugly
14:30:37 <ahyangyi> Yeah, but "adding a way to inject squirrel code into newGRF" is a solution as well
14:32:16 <ahyangyi> And somehow that might still be preferable to making GS and newGRF interact with each other...?
14:33:26 <andythenorth> Explore that idea further?
14:35:17 <andythenorth> So grf could make calls against the GS API?
14:41:33 *** brickblock19280 has joined #openttd
14:41:33 <brickblock19280> ahyangyi: that seems really really hard
14:44:25 <andythenorth> Probably fine
14:45:03 <andythenorth> Just expose a special var for โ€œGS methodโ€ with params in registers
14:45:13 <andythenorth> Like 0x61, but for GS
14:45:36 <andythenorth> Give them all numbers, let nml substitute constants
14:46:15 <andythenorth> Can it desync though?
14:57:32 <peter1138> Hmm, everything is broken ๐Ÿ˜„
15:02:03 *** esselfe has joined #openttd
15:02:13 <ahyangyi> Delete everything
15:03:28 <_glx_> Let me remind Andy about the fact GS runs on server only
15:04:04 <_glx_> While GRF run on both
15:05:20 <_glx_> And clients know nothing about GS
15:07:39 <andythenorth> But the API is there?
15:08:34 <andythenorth> the idea is to give grf access to GS methods, but without a GS
15:08:44 * andythenorth not sure what problem that solves at all
15:21:40 *** merni has joined #openttd
15:21:40 <merni> andythenorth: oh geez why
15:21:51 <merni> that means people can't play FIRS with any other GS
15:22:32 <andythenorth> well then it won't be FIRS ๐Ÿ™‚
15:22:52 <andythenorth> FIRS now depends on GS
15:24:18 <merni> andythenorth: well yeah I guess people could make forks
15:25:12 <ahyangyi> Or use existing FIRS versions
15:25:44 <merni> yeah I remember someone popped up in the help channel using FIRS 1 recently
15:26:02 <merni> they are available in bananas still so I guess easy mistake?
15:26:02 <andythenorth> software version numbers massively confuse the reddit audience
15:26:17 *** alfagamma_0007 has joined #openttd
15:26:17 <alfagamma_0007> Reddit pssst
15:26:29 <alfagamma_0007> Who cares about reddit
15:26:40 <andythenorth> I guess Iron Man 3 comes before Iron Man though
15:26:45 <andythenorth> in the movie world
15:27:09 <ahyangyi> Make FIRS 0 after FIRS 4
15:27:45 <andythenorth> prequel?
15:27:50 <merni> integer rollover
15:27:52 <LordAro> andythenorth: uwot
15:27:57 <pickpacket> andythenorth: whaaaaat? Iron Man is before Iron Man 3
15:28:11 <andythenorth> not a concept familiar to the reddit audience
15:28:12 <merni> lol you just angered all the iron man fans
15:28:13 <andythenorth> counting upwards
15:28:21 <LordAro> lol
15:28:24 <andythenorth> I didn't use the irony font
15:28:31 <andythenorth> I should have
15:28:53 <LordAro> honestly
15:29:03 <andythenorth> so how do we even policy here these days?
15:29:23 <andythenorth> the prevailing policy is that GS is for map-global stuff, and grf is for 'local' items
15:29:29 <andythenorth> but that dates to 2012
15:29:55 <andythenorth> and there are as many opinions as posters
15:29:57 <andythenorth> (of course)
15:29:59 <pickpacket> andythenorth: I genuinely thought you were either confused or talking about some other measurement of "before", like money at the box office or whatever ๐Ÿ˜‚
15:30:30 <andythenorth> I am sure I could find a reddit post asking which Iron Man movie came first
15:30:34 <merni> I don't see that tying a GRF to a particular GS is a good thing, since that would basically mean that GRF is incompatible with every GS and every other GRF that is tied to a GS
15:31:34 <merni> because you can only have one GS per game
15:33:10 <andythenorth> well it's an impasse ๐Ÿ™‚
15:33:23 <andythenorth> the circle cannot be squared
15:34:13 <andythenorth> anyway FIRS 5 is broken without the GS
15:34:22 <andythenorth> the behaviour will be .... strange
15:36:15 <FLHerne> merni: I think this is a classic case of andy forcing the devs to implement a better way to do it, just to stop him doing it the horrible way :p
15:36:46 <andythenorth> not sure it is ๐Ÿ˜›
15:36:55 <andythenorth> I think we're actually boxed into a dead end on the content API
15:36:58 <andythenorth> and there's no way out
15:37:04 <merni> why?
15:37:32 <andythenorth> because in 2012 it was decided that GS would supercede planned grf features
15:37:41 <andythenorth> as policy
15:37:52 <FLHerne> well, that clearly hasn't happened because people keep adding them
15:37:56 <andythenorth> and since then we've nerfed grf in favour of GS
15:38:05 <andythenorth> now we have GS in the wild
15:38:06 <_jgr_> Decided by whom, exactly?
15:38:16 <Eddi|zuHause> i don't remember that decision either
15:38:23 <andythenorth> it was in irc
15:38:32 <andythenorth> it was a long argument between me, planetmaker and pikka
15:38:39 <andythenorth> and 2 of us did not cover ourselves in glory
15:38:49 <andythenorth> but planetmaker won by default due to having commit rights
15:39:36 <andythenorth> it wasn't a fine moment in the project
15:39:44 <FLHerne> that doesn't sound like a decision that has to bind OTTD a decade later
15:39:51 <andythenorth> well it's moot at this point
15:40:00 <andythenorth> GS exists
15:40:13 <andythenorth> so grf cannot be extended in certain directions
15:40:13 <FLHerne> although a lot of what you're trying to do does sound more reasonable as scripting than ever-more-insane grf switches
15:40:13 *** Flygon has quit IRC (Quit: A toaster's basically a soldering iron designed to toast bread)
15:40:50 <_jgr_> Not everything in GRF has to be implemented using callback switches
15:41:24 <Eddi|zuHause> well. we also had discussions about hybrid approaches, but nothing ever came of them
15:41:27 <_jgr_> A lot of stuff would likely be better off as declarative policy which is perfectly sensible to do from within a GRF
15:42:48 <andythenorth> hmm
15:43:41 <andythenorth> anyway, if I add GS methods in a PR, do I need to write tests?
15:43:49 <andythenorth> we have some regressions AI thing?
15:44:14 <andythenorth> 99 out of 100 people here are confident that GS and grf cannot and should not work together
15:44:17 <andythenorth> but I have it running
15:44:19 <andythenorth> so eh
15:44:33 <andythenorth> might as well just keep extending it
15:44:41 <Eddi|zuHause> that was never what i actually said
15:44:45 <_jgr_> They can work together, but meaking your GRF stop working when the right GS isn't loaded will just be annoying to users
15:45:46 <_jgr_> Configuration of GRFs is already baffling enough for users without making it deliberately harder
15:48:57 <andythenorth>
15:49:22 <andythenorth>
15:50:35 <andythenorth> _jgr_: well it's already broken without GS
15:50:45 <andythenorth> as we have decided that grf cannot set the GS flags
15:50:58 <andythenorth> so behaviour that depends on them doesn't work
15:51:22 <andythenorth> although this might be a logic problem that complies with PEBKAC
15:51:42 <andythenorth> obvs grf cannot set the GS flags as that will break GS
15:51:50 <andythenorth> but grf has no way to know if there is a GS
15:51:56 <andythenorth> and that's architecturally impossible
15:52:03 <andythenorth> so this seems broken by design
15:54:02 <andythenorth> oh maybe we just need more flags?
15:54:22 <andythenorth> INDCTL_GS_PRESENT?
15:55:26 <andythenorth> or maybe inverted complements to the existing flags?
15:56:13 <_jgr_> At the risk of dรฉjร  vu, using flags as a comms channel will just lead to tears
15:57:04 <andythenorth> it seems odd that we added them in that case
15:57:22 <merni> andythenorth: or maybe don't make your grf dependent on gs-only features? :p
15:57:48 <_jgr_> If a specific thing is missing from the GRF spec, it could just be added?
15:58:27 <andythenorth> previously the conclusion was 'no'
15:58:29 <andythenorth> every time
15:58:32 <andythenorth> because GS exists
15:58:49 <andythenorth> so anything that GS currently has a setter for is now out of scope for grf
15:59:05 <andythenorth> although the policy has exceptions of course
15:59:20 <andythenorth> so grf will never be allowed to write to the town window
15:59:28 <andythenorth> but GS can write to the industry window, as can grf
15:59:50 <andythenorth> obvs 'policy' in an open source community is a bit of misnomer ๐Ÿ™‚
16:01:25 <_jgr_> Adding per-town GRF callbacks would not be difficult
16:01:36 <_jgr_> I have one in my branch already
16:01:56 <andythenorth> how does that not fail the GS / grf conflict test?
16:02:33 <_jgr_> GS doesn't support the particular things that this callback is fo
16:02:40 <andythenorth> ok
16:02:49 <_jgr_> But in general I don't really care if I violate some arbitrary policy
16:03:38 *** talltyler has joined #openttd
16:03:38 <talltyler> I think a spec proposal would help this conversation much more than complaints that we can never change anything. Thatโ€™s only true if we donโ€™t know what change is even desired.
16:03:54 <andythenorth> truebrain proposed a spec, but it was shot down ๐Ÿ™‚
16:04:13 <talltyler> Where can we read it?
16:04:32 <andythenorth> I'll find it
16:05:51 <andythenorth>
16:05:56 <andythenorth> can't find the spec proposal
16:09:10 <talltyler> GS in Python?
16:10:59 <andythenorth> python was just an example compile format
16:11:10 <andythenorth> wouldn't be embedded python in OpenTTD
16:11:13 <andythenorth> discussion:
16:11:19 <andythenorth> and probably the day before or so also
16:18:38 <andythenorth> any spec involves letting go of current grf and GS assumptions
16:18:49 <andythenorth> and compatibility with the current content
16:20:27 <FLHerne> might be relevant here
16:20:57 <FLHerne> I'm not sure the close reason makes sense
16:22:16 *** Wormnest has joined #openttd
16:22:19 <FLHerne> AoT would risk locking OpenTTD into a particular wasm interpreter forever, and repeating the Squirrel 2 thing would be a shame
16:26:34 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 updated pull request #11094: Codechange: use Textbuf directly, instead via several virtual functions in Window
16:26:37 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 updated pull request #10733: Codechange: use standard int types
16:30:12 <andythenorth> so do I abandon my GS PR ๐Ÿ˜›
16:30:13 <andythenorth>
16:30:16 <Rubidium> yeah, I think we should rewrite OpenTTD in Java or something similar. Then everything can just be loaded as runtime jar-files with resources :D
16:31:21 <Rubidium> that would remove the need for custom file formats, and anything that can be compiled into java class files should do the trick :D (or Microsoft's intermediate language)
16:31:48 <alfagamma_0007> Rubidium: Sounds like freecol all over again
16:32:05 <alfagamma_0007> doesn't work on my laptop for some reason
16:35:13 <ahyangyi> What, freecol reached 1.0? ๐Ÿ˜ฎ
16:35:21 <ahyangyi> I just checked and saw the news
16:36:13 <peter1138> What's the news?
16:37:00 <andythenorth>
16:37:01 <ahyangyi> Uh, "freecol reached 1.0 in 2023"
16:40:16 <andythenorth> so we won't be writing mods directly in WASM? ๐Ÿ˜›
16:40:26 <peter1138> Oh, not actual news.
16:40:33 <andythenorth> we'll have some interpreted format?
16:41:01 <peter1138> Does JGRPP implement anything to allow NIFeature's NIProperty properties member to be dynamic?
16:41:17 <peter1138> Seems a bit rigid right now ๐Ÿ˜„
16:41:31 <_jgr_> Do you just mean in the debug window, or the actual GRF loader?
16:41:53 <peter1138> I suppose the general idea is that properties would be fixed anyway, but this particular thing is only used for industry produced/accepted stuff.
16:41:55 <peter1138> debug window.
16:42:34 <peter1138> It all seems very generic, but in a C-style way, rather than C++.
16:43:28 <_jgr_> I haven't done anything with NIProperty at all
16:43:40 <_jgr_> If I want to show more stuff in the window I just add it directly
16:44:52 <_jgr_> I have various extra virtual methods in NIHelper
16:45:14 <andythenorth> lol, I have made poor choices
16:45:27 <andythenorth> the FIRS 5 dev branch is also the "add GS" branch
16:45:41 <andythenorth> as the GS requires the grf part modified accordingly
16:45:51 <andythenorth> so I've gone down a dead end ๐Ÿ™‚
16:46:25 <andythenorth> guess I manually pick it out ๐Ÿ™‚
16:47:16 <andythenorth>
16:47:25 <andythenorth>
16:48:52 <andythenorth> I already manually picked out the attempt to control towns in grf
16:49:11 <andythenorth> fool me twice, fool on me?
16:58:08 <andythenorth> nah I ain't giving up
16:58:13 <andythenorth> there must be side channels I can abuse
16:58:37 <andythenorth> can I string parse industry names in GS?
17:00:30 <andythenorth> seems like I could
17:00:58 <andythenorth> do we have a string control code for "don't print the following characters to screen"?
17:01:12 <andythenorth> that would mean I could encode grf information in the industry name
17:02:02 <andythenorth> ach FIRS already breaks GS though
17:02:23 <andythenorth> curently released FIRS ignores IndustryControlFlags
17:02:38 <andythenorth> oof ๐Ÿ˜ฆ
17:03:07 <andythenorth>
17:03:20 <andythenorth> if INDCTL_NO_PRODUCTION_INCREASE is set, FIRS should disable supplies
17:10:01 <ahyangyi> But if INDCTL_NO_PRODUCTION_DECREASE is set, should you gung-ho everything?
17:10:32 <andythenorth> no, that's not implied by the name
17:10:56 <andythenorth> INDCTL_NO_CLOSURE is puzzling
17:11:00 <andythenorth> because FIRS already doesn't close
17:11:04 <andythenorth> 'probably fine'?
17:11:25 <andythenorth> but the flag isn't set
17:11:29 <andythenorth> ach
17:11:41 <andythenorth> actually that's a bit fucked
17:11:47 <andythenorth> because FIRS can't set the flag to tell GS
17:13:17 <ahyangyi> Anyways, "production increase" has nothing to do with supplies and gung-ho...
17:13:29 <andythenorth> well logically it does
17:13:33 <andythenorth> by definition of the name
17:14:11 <ahyangyi> production increase is a permanent change of the state of the industry. supplies and gung-ho only last for 3 months
17:14:23 <ahyangyi> It's like INDCTL_NO_PRODUCTION_DECREASE has nothing to do with depressions
17:14:43 <ahyangyi> because a depression is not production decrease, despite it decreases the production ๐Ÿ˜„
17:14:57 <andythenorth> "GameScript can optionally set a property that to indicate that production should not increase at this industry. "
17:15:02 <andythenorth> from the nml spec
17:15:13 <andythenorth> although these vars seem to be missing from the nfo spec
17:15:18 <andythenorth> and nml spec is never reliable
17:15:21 <ahyangyi> "When industry production change is evaluated, rolls to increase are ignored."
17:15:35 <ahyangyi> Obviously it means the kind of "rolling to increase production"
17:15:51 <andythenorth> nml spec implies differently, as does the name
17:15:55 <ahyangyi> not any other types of production change
17:16:33 <_jgr_> You'll probably have better luck reading the actual code instead of trying to divine things from word choices on the wiki
17:18:57 <ahyangyi> Andy, are you trying to use IndustryControlFlags as a serial port ๐Ÿ™ˆ
17:20:22 <andythenorth> not currently
17:20:27 <andythenorth> I have seriously considered it
17:20:31 <andythenorth> there are 3 bits there
17:20:47 <andythenorth> which would give me 8 values for comms
17:20:56 <andythenorth> currently I am just trying to use them according to spec
17:20:59 <_glx_> var 47 is in NFO spec
17:21:28 <_glx_> translated into gs_disallows_XXX in NML
17:21:54 <andythenorth> thanks, I was searching 'flag' in the nfo vars page ๐Ÿ™‚
17:21:59 <andythenorth> I will make a small edit :
17:23:39 <andythenorth> can anyone think of a side channel that would let me expose i->prod_level to GS?
17:23:54 <andythenorth> I can't put it in the industry name as that's a prop in grf, not a callback
17:25:31 <andythenorth> hmm I could use the cargo stockpile for signalling
17:25:49 <andythenorth> currently FIRS consumes all cargo when delivered
17:26:10 <andythenorth> can I put things on the stockpile without a delivery?
17:26:12 <andythenorth> maybe I can
17:26:34 <_glx_> why not add a function to the API ?
17:27:26 <andythenorth> because it's unlikely to be merged?
17:28:02 <andythenorth> wonder if consume_cargo can be negative in the produce-block
17:28:29 <ahyangyi> What was the original problem you want to solve anyways
17:28:36 <ahyangyi> get water region area?
17:28:59 <ahyangyi> place industries with complex restrictions, such as water region size?
17:31:25 <andythenorth> that's one of several, but that can probably be done in grf
17:31:43 <andythenorth> the more interesting problem is changing industry production
17:34:54 <andythenorth> GS won't be allowed to modify industry directly because grf
17:35:00 <andythenorth> so it has to signal via flags
17:35:42 <andythenorth> so FIRS grf will now increase prod_level every month, unless FIRS GS has set INDCTL_NO_PRODUCTION_INCREASE,
17:35:52 <andythenorth> the GS sets this for all industries at init
17:36:08 <andythenorth> and resets it monthly
17:36:31 <andythenorth> when the GS wants to increase prod_level, it clears INDCTL_NO_PRODUCTION_INCREASE flag
17:36:40 <andythenorth> this means the grf is broken without the GS
17:36:50 <andythenorth> as it will constantly increase production
17:40:35 <andythenorth> also the amount of increase is capped by the grf
17:40:49 <andythenorth> but the GS doesn't know that, so will continue trying
17:40:59 <andythenorth> oh
17:41:20 <andythenorth> if GS could read current prod_level that would be solvable
17:41:24 *** Kitrana1 has joined #openttd
17:41:31 <andythenorth> hmm
17:41:49 <andythenorth> GS could simulate the grf production, then reverse engineer current prod_level from that maybe
17:42:29 <andythenorth> industry has double production or something in first month, yes?
17:42:31 <andythenorth> for reasons?
17:42:43 <andythenorth> maybe I can store the first month, and the amount of supplies delivered
17:42:54 <andythenorth> then use that to infer the original prod_multiplier per cargo
17:43:05 <andythenorth> then I can reverse engineer current prod_level from that
17:43:16 <andythenorth> will need to account for months with 8 production cycles and months with 9
17:47:43 *** Kitrana has quit IRC (Ping timeout: 480 seconds)
17:49:19 <andythenorth> wonder if I could add a special cargo
17:49:21 <andythenorth> 'signalling'
17:49:54 <alfagamma_0007> Interesting
17:50:03 <alfagamma_0007> How would that work
17:51:39 <andythenorth> I think grf industry stockpile has 65536 possible values
17:51:51 <andythenorth> and I think grf can arbitrarily add / remove stuff to the stockpile
17:52:17 <andythenorth> GS has GetStockpiledCargo()
17:52:31 <andythenorth> so I could signal via a bitmask
17:52:43 <brickblock19280> me about to transport signaling
17:52:47 <andythenorth> 'comms'
17:53:25 <alfagamma_0007> Add Aeroplane parts and shipbuilding as well */s*
17:55:44 <ahyangyi> andythenorth: Well, this isn't the original problem. The original problem sounds like you are trying to change industry production in a way currently impossible in GRF?
17:56:09 <andythenorth> might be a more accurate statement
17:56:16 <andythenorth> well no
17:56:29 <andythenorth> "The original problem sounds like you are trying to change industry production in a way currently impossible in GS" is more accurate
17:56:58 <ahyangyi> Well, I want to understand why must GS be involved here
18:01:55 <andythenorth> oh yes ok
18:02:17 <andythenorth> there are a combination of factors
18:02:27 <andythenorth> grf is not allowed a monthly town callback
18:02:34 <andythenorth> grf is not allowed to write to town window
18:02:38 <andythenorth> grf has no story book
18:02:49 <andythenorth> grf is not allowed a global view of the map
18:03:11 <andythenorth> town would have no way in grf to nominate one industry to increase production
18:03:19 <alfagamma_0007> I see
18:03:38 <alfagamma_0007> So this helps in realistic industry placement, right?
18:03:45 <peter1138> What does "not allowed" mean?
18:04:01 <andythenorth> "you should not be trying to do this in grf, this is what GS is for"
18:04:23 <andythenorth> I mean it's open opinions vary ๐Ÿ™‚
18:04:54 <peter1138> What does it say it is not allowed?
18:04:57 <peter1138> .,..,
18:05:04 <peter1138> WHERE does it say it is not allowed?
18:08:10 <andythenorth> in logs of various people with varying opinions ๐Ÿ™‚
18:08:19 <andythenorth> depending on the day and whether it has a y in the name
18:08:42 <andythenorth> but giving grf a monthly callback and ability to set town growth.....will inevitably conflict with GS
18:11:12 <peter1138> Okay, so.
18:11:17 <peter1138> What would a monthly town callback DO?
18:11:35 <peter1138> If FIRS is an industry GRF, then it has no business touching towns.
18:11:42 <peter1138> If it's a houses GRF, then yes...
18:11:58 <andythenorth> it would decide if the town is happy or not
18:12:16 <ahyangyi> But industries *are* associated with towns ๐Ÿค”
18:12:21 <andythenorth> in happy towns, industry primary production has a chance to increase
18:12:45 <andythenorth> ^ this can actually be done in grf, I have a branch where it works
18:12:52 <peter1138> Is "town happiness" a thing currently?
18:12:55 <andythenorth> nah
18:13:00 <andythenorth> but I asked if I could have grf writing to town window, and was told no
18:13:09 <andythenorth> so I added a 'town notice board' industry, but it was weird
18:13:17 <andythenorth> so I deleted all that and made a GS
18:13:44 <andythenorth> a town monthly callback can be faked by industry loop, using town registers
18:16:19 <peter1138> Is What you're really asking for is a way to hint that an industry should
18:17:08 <talltyler> What keeps track of if the town is happy? A receiving industry like a Hotel? Houses? A GS?
18:17:11 <peter1138> (Rather than throwing around buzzwords like "goes it improve GS")
18:17:33 <peter1138> "town is happy" isn't a thing, so adding it for a monthly callback is weird.
18:18:08 <andythenorth> talltyler: in GS, cargo monitors on the town
18:18:33 <andythenorth> it's complicated, because some industries have to be excluded, e.g. deliverying food to shops is valid, delivering food to port isn't
18:18:38 <andythenorth> but GS supports this
18:18:46 <peter1138> ChangeIndustryProduction does have callbacks, but I don't know what issues cause that to be unsuitable here.
18:18:47 <FLHerne> does "happy" mean growth? rating? fun GS consequences?
18:19:27 <ahyangyi> I think the idea is that many factors contribute to a per-town variable called "happyness", which then in turn affect many things
18:19:31 <andythenorth> yes
18:19:45 <andythenorth> I'm probably going to copy the base growth algorithm into GS, and modify it slightly
18:19:52 <peter1138> (There is a monthly production change callback for industries... and you want a monthly callback, so...)
18:21:58 <andythenorth> yes
18:22:29 <andythenorth> the current implementation is to set INDCTL_NO_PRODUCTION_INCREASE for every grf from GS
18:22:41 <andythenorth> then clear it for selected industries, then reset it next month
18:22:50 <andythenorth> this means the grf is broken without GS
18:22:58 <andythenorth> as the production will increase every month
18:23:27 <peter1138> If industries can control production, why do you need to do all that?
18:25:21 *** tokai|noir has joined #openttd
18:25:21 *** ChanServ sets mode: +v tokai|noir
18:26:25 <andythenorth> the decision to increase is made by GS in this (the second) implementation
18:28:46 <andythenorth> the INDCTL flag is used to signal that an increase is required
18:29:35 <talltyler> But there are three flags? I don't see the problem
18:29:50 <talltyler>
18:29:52 <andythenorth> imagine the grf is running without the GS?
18:29:56 <andythenorth> what happens?
18:30:19 <talltyler> No flags are set, so it knows the GS isn't running?
18:30:26 <peter1138> I think the problem is andy is stuck thinking about GS, instead of thinking or describing what the actual intention of everything is...
18:30:28 <talltyler> And does its own production handling?
18:32:27 *** tokai has quit IRC (Ping timeout: 480 seconds)
18:33:29 <andythenorth> talltyler: there's no INDCTL_PRODUCTION_INCREASE flag
18:33:54 <andythenorth> oh I see
18:34:03 <andythenorth> I could store the flag state in a permanent register
18:34:15 <andythenorth> and if it's *never* been set, don't handle the GS behaviour
18:34:17 <andythenorth> yes
18:34:18 <andythenorth> thanks
18:34:41 <talltyler> Okay, so what are the states you need?
18:34:41 <talltyler> - GS not loaded
18:34:41 <talltyler> - Town is happy
18:34:41 <talltyler> Can the town be so unhappy it decreases production?
18:35:12 <talltyler> Also keep in mind you can combine flags, right? So you have 9 states (I think) to play with
18:35:34 <andythenorth> no
18:35:44 <andythenorth> can't abuse the flags as bits
18:35:48 <andythenorth> because GS might use them
18:35:55 <andythenorth> (non-FIRS GS)
18:36:03 <andythenorth> I already considered and rejected this ๐Ÿ˜›
18:36:29 <talltyler> It might, yeah
18:36:34 <andythenorth> much as I want to
18:37:03 <peter1138> FIRS-GS is such a bad idea anyway
18:37:20 <andythenorth> well it was my 2nd choice ๐Ÿ˜›
18:37:21 <andythenorth> not 1st
18:37:26 <andythenorth> I tried the grf route
18:37:43 <andythenorth> nobody will ever know to install the GS
18:37:51 <andythenorth> and there will be constant bugs due to version mismatch
18:39:40 <talltyler> Can we just bundle a GS with a GRF? Is it time to discuss that?
18:39:53 <DorpsGek> [OpenTTD/OpenTTD] eints-sync[bot] pushed 1 commits to master
18:39:54 <DorpsGek> - Update: Translations from eints (by translators)
18:41:51 <andythenorth> talltyler: depends how viable we think it is to replace the content API with a WASM thing
18:41:59 <andythenorth> I guess they're not mutually exclusive
18:42:05 <andythenorth> but GS seems like a dead end
18:42:21 <andythenorth> at least it's fast now ๐Ÿ˜›
18:44:03 <peter1138> If we ever support multiple GS running at the same time, I would not think a FIRS-GS is such a bad idea.
18:44:07 <peter1138> But we don't, so I do.
18:45:07 <andythenorth> I think it's a bad idea currently
18:45:15 <andythenorth> but I'm knee deep in it ๐Ÿ˜›
18:46:16 *** michi_cc[d] has joined #openttd
18:46:16 <michi_cc[d]> There's still one step to unravel here IMHO. What is town happiness actually supposed to do, i.e. what is the actual mechanic you want FIRS to have?
18:47:27 <peter1138> ^
18:47:39 <michi_cc[d]> Is it just about industry production of multiple indistries being interdependent?
18:48:23 <pickpacket> What FIRS needs is a stock market
18:48:23 <michi_cc[d]> Or is it supposed to be a story-driven thing?
18:48:34 <andythenorth> it's just about a way to increase production
18:48:51 <andythenorth> but when I propose specific gameplay features I'm always asked to describe a more general case
18:48:53 <andythenorth> etc etc ๐Ÿ™‚
18:49:04 <peter1138> Production increases happen automatically anyway.
18:49:11 <andythenorth> and if I propose a general case I'm asked to remember the implementation details ๐Ÿ™‚
18:49:23 <talltyler> So do both ๐Ÿ™‚
18:49:29 <pickpacket> peter1138: maybe differently than andythenorth wants to do it?
18:49:39 <peter1138> And with the callback, GRFs can also impact production.
18:50:02 <peter1138> That is obviously not enough, but so far I don't know why, only that it has to be done via a special GS.
18:52:02 <michi_cc[d]> Maybe I'm asking about the user story (or whatever modern people call it nowadays ๐Ÿ˜„) for this thing. So assuming the implementation magically just works, what's the user-visible gameplay impact and what is the player supposed to do about it?
18:52:30 <andythenorth> player makes town happy, industries in the town have a (dice roll) chance of production increase
18:52:51 <talltyler> Town happy = luxury goods delivered?
18:52:55 <michi_cc[d]> And town happiness can be achived how?
18:53:30 <andythenorth> meet arbitrary goals: deliver specific cargos, provide good transport
18:53:33 <andythenorth> maybe build statues ๐Ÿ˜›
18:54:15 <talltyler> Specific cargos would be GS territory, I guess
18:54:48 <andythenorth> the player learns about the goals from a text window related to the town
18:54:53 <michi_cc[d]> Sounds like story-driven gameplay to me. Which in the magical unicorn world is supposed to be the thing GS was invented for.
18:55:22 <michi_cc[d]> Of course, whether GS as actually existing does that is very much up for debate.
18:55:38 <andythenorth> it sort of does
18:57:14 <peter1138> That's a reasonable idea for a GS, but I don't then understand why it has to be FIRS specific, and why FIRS needs to depend on the GS
18:57:42 <michi_cc[d]> So IMHO, it doesn't really makes sense to give something like this to GRF, unless we'd just decide that GS was a bad idea anyway and let it rest.
18:57:48 <andythenorth> talltyler: has solved the FIRS dependency I think
18:58:38 <peter1138> Not really, the fact you want to do something different in the GRF depending on what a GS is doing is a red flag
18:58:39 <michi_cc[d]> From which follows that GS API probably needs to get better, which can include properties or variables on the GRF side.
18:59:27 <peter1138> So perhaps the issue is, after all, that GRF do control production with the callback, and GS doesn't. (But isn't there overrides?)
18:59:57 <michi_cc[d]> peter1138: Then we are back to the beginning of the conversation and where GS and GRF are "forbidden" to interact.
19:00:15 <andythenorth> there are the IndustryControlFlags
19:01:16 <peter1138> And they are not suitable because?
19:01:55 <andythenorth> they work
19:02:24 <peter1138> Working doesn't mean it's what you need.
19:02:37 <andythenorth> ok so they're a limited set of flags
19:02:52 <andythenorth> and obviously they're binary 1 | 0
19:03:05 <andythenorth> there's no way to communicate a more detailed intent like 'increase lots'
19:03:19 <talltyler> We could add flags
19:03:21 <andythenorth> there's also no method for GSIndustry.GetProdLevel()
19:03:25 <peter1138> So maybe add flags?
19:03:36 <andythenorth> so the GS cannot know the current state of the industry, except by simulating the grf
19:03:39 <peter1138> "Those are the flags" doesn't mean "Those are the only flags everf"
19:03:43 <pickpacket> "Do you have a flag?"
19:03:46 *** shrekshellraiser has joined #openttd
19:03:47 <shrekshellraiser>
19:03:47 <shrekshellraiser> Hi, I'm working on, last I left it off I had it in a functional state but it still has the issue of when loading the game after loading an old version you are given a warning due to the mismatched setting type. I changed `right_mouse_wnd_close` to be a uint8, and made an Enum specifically for this setting. Any idea what I can do to better handle this
19:03:47 <shrekshellraiser> type mismatch?
19:04:18 <peter1138> Simple solution, change the name of the setting ๐Ÿ™‚
19:04:46 <shrekshellraiser> I mean I suppose that works
19:04:57 <shrekshellraiser> is that really the best option I have?
19:05:00 <andythenorth> GetProdLevel is just `return i->prod_level` yes?
19:05:05 <peter1138> *May not be the best option
19:05:12 <andythenorth> I started a patch for it, but it's unclear what we actually want here
19:05:49 <shrekshellraiser> would it be accepted if I literally just changed the setting name so it doesn't conflict?
19:05:58 <shrekshellraiser> that feels like a hacky solution that would get turned down
19:07:23 <peter1138> Unlikely to just get "turned down"... if it's a PR, someone might suggest the proper way (I don't know offhand, but there is some provision for upgrading configs)
19:08:24 <andythenorth> hmm....we have `INDCTL_NO_PRODUCTION_INCREASE` so we'd never accept a PR for `INDCTL_PRODUCTION_INCREASE`?
19:08:35 <andythenorth> because it would lead to nonsensical situation if both were set?
19:08:42 <peter1138> don't set both?
19:09:06 <peter1138> It's not impossible to make flags exclusive.
19:09:19 <shrekshellraiser> okay but how else can I do it? I attempted to use `SDT_OMANY` and define my own load function, but I don't think that worked out considering my local changes just use uint8. It's been awhile since I've worked on this
19:09:33 <shrekshellraiser> I don't wanna do the hacky solution and then get asked to redo it in a different way
19:09:46 <peter1138> If I knew, I'd not have written "i don't know offhand" ๐Ÿ™‚
19:10:01 <shrekshellraiser> okay fair
19:10:12 <peter1138> change requests in PRs are nothing to be afraid of. It doesn't mean having to redo everything.
19:10:36 <talltyler> Yeah, we have GRF flags for "only build before 1950" and "only build after 1960" which likely conflict, because I doubt the game checks if both are set before failing when hitting the first one
19:10:37 <shrekshellraiser> well i gotta figure out how to get myself out of the git mess i'm in before i can get the PR ready
19:10:49 <andythenorth> talltyler: ok so we're not worried about footguns
19:11:43 *** frosch123[d] has joined #openttd
19:11:44 <frosch123[d]> shrekshellraiser: renaming the setting is the correct solution. we did that plenty of times before. we only do savegame conversions, no config conversions
19:12:34 <shrekshellraiser> oh okay
19:12:36 <frosch123[d]> people use the same config for multiple installations of ottd
19:12:39 <shrekshellraiser> thank you
19:12:40 <talltyler> We can do setting conversion in savegame conversions though, right? (could have sworn I've done it, but maybe not in a PR I actually opened)
19:13:01 <frosch123[d]> so even if you added compatibility code to the new ottd, the other installations would still annoy you
19:13:05 <peter1138> some of the ini files have "ini_version" and "version_number", yes.
19:13:24 <peter1138> secrets & private
19:13:48 <peter1138> Oh, even openttd.cfg does ๐Ÿ™‚
19:13:57 <frosch123[d]> talltyler: yes, for settings stored inside savegames
19:14:06 <talltyler> Aha, yes
19:14:40 <peter1138> Hmm, looks like those are write-only, or I dunno what I'm looking at.
19:14:54 <andythenorth> ho, would we allow GS to specify a value to be used 'next time CB 29 or CB 35 runs'?
19:14:54 <peter1138> Anyway, turns out my first suggestion is also what frosch said to do, so go with that ๐Ÿ˜„
19:15:24 <andythenorth> I have finally internalised that GS can't actually handle the CB directly ๐Ÿ™‚
19:15:34 <shrekshellraiser> recompiling now to make sure i renamed it everywhere
19:15:46 <peter1138> andythenorth: you mean one-shot?
19:15:59 <andythenorth> peter1138: yes, cleared after use I assume
19:15:59 <FLHerne> shrekshellraiser: adding some code to support setting type conversion on load would also be a correct solution, I'm sure
19:16:21 <FLHerne> but just renaming it is probably easier :-)
19:16:41 <FLHerne> oh, frosch123[d] has a point
19:16:56 <shrekshellraiser> FLHerne: tried this with ODT_OMANY and could not figure it out
19:17:05 <shrekshellraiser> plus I'm a beginner at C
19:17:15 <peter1138> Not impossible to add extra flags to do that (or other things)
19:17:31 <FLHerne> it would be inconvenient if it 'broke' people's settings for old games, but that does already happen when adding accepted values without changing the type
19:18:38 <frosch123[d]> once we changed the format for the display_options. everytime you switched between release and nightly build, you would get an error, because they stored them in different formats
19:19:01 <frosch123[d]> using the same config for stable, nightly, jgrpp, ... is no unlikely scenario
19:19:19 <frosch123[d]> so what does it help if one of them can convert a setting, the others wont
19:20:46 <talltyler> So renaming is the correct option, then ๐Ÿ™‚
19:20:59 <shrekshellraiser> Should I leave the translatable string names the same?
19:21:10 <shrekshellraiser> or change them to match the updated setting name
19:21:32 <peter1138> I'd leave them as they are, unless the translations all need to be updated anyway.
19:22:00 <pickpacket> Speaking of translations. How do I fix the Swedish translation for the strings I changed in my PR? ๐Ÿค”
19:22:20 <talltyler> You don't. Translators do them later in Web Translator
19:22:30 <peter1138> Are you a Swedish translator? ๐Ÿ˜„
19:22:35 <frosch123[d]> shrekshellraiser: we have a faq for changing english.txt:
19:23:14 <peter1138> (Oh yes, caveat, "i would do something" doesn't mean it's correct, and I might get... shown :-))
19:25:22 <andythenorth> so I considered patching `GSIndustry.SetProdLevel()` which would be direct and avoid faff
19:25:29 <andythenorth> but it wouldn't trigger a news message
19:25:49 <andythenorth> oh maybe it could pretend to be CB 29? ๐Ÿ˜›
19:26:05 <talltyler> You want it to trigger a news message but it doesn't?
19:26:26 <talltyler> Sounds like not patched all the way ๐Ÿ˜›
19:27:19 <andythenorth> I haven't patched any of it yet ๐Ÿ˜›
19:27:22 <andythenorth> considered
19:27:41 <talltyler> Oh I misread
19:27:55 <andythenorth> ok, so if basically, it was CB 29, but with an extra flag to grf, with the trigger reason (game, GS)
19:30:02 <andythenorth>
19:30:35 <andythenorth> and the grf could choose to handle it as case 04
19:32:16 <pickpacket> peter1138: I am Swedish and can translate it ๐Ÿ™‚
19:32:29 <peter1138> That wasn't what I asked though.
19:33:06 <talltyler> Translators use this tool:
19:34:10 <pickpacket> peter1138: I know ๐Ÿ™‚ Iโ€™m not a professional translator, if thatโ€™s what you meant.
19:34:28 <DorpsGek> [OpenTTD/team] Brickblock1 opened issue #437: [sv_SE] Translator access request
19:34:53 <shrekshellraiser> lol game crashed as soon as I opened settings
19:34:55 <peter1138> I don't think be assigned as a translator on our webtranslator counts as professional... no ๐Ÿ™‚
19:35:03 <peter1138> *begin
19:35:06 <peter1138> *being
19:35:35 * andythenorth looks for CB 29 in src
19:35:44 <michi_cc[d]> andythenorth: Would something like this totally untested commit be useful to you?`<>
19:39:29 <andythenorth> will test it shortly ๐Ÿ˜„
19:40:27 <_glx_> andythenorth: the issue with this is some grf authors will be mad if the production is controlled by something else than their grf
19:40:44 <andythenorth> yes, that's why it needs to be optin
19:40:51 <andythenorth> michi's patch has a flag I think
19:41:24 <_glx_> grf could set what they accept or not (as they are loaded before the GS)
19:41:50 <andythenorth> action 14? ๐Ÿ˜›
19:42:03 <_glx_> with default to accept nothing of course
19:42:10 <michi_cc[d]> Yes, I added a flag. There's no opt-in though, just a (one-way) notification via the flag.
19:47:05 <michi_cc[d]> _glx_: Has an author complained about `INDCTL_NO_PRODUCTION_DECREASE` or `INDCTL_NO_PRODUCTION_INCREASE` yet?
19:47:20 <michi_cc[d]> This is no different and we didn't really ask NewGRF authors about this either.
19:47:34 <andythenorth> michi_cc[d]: is there a PR for that? Or shall I just patch < foo.diff?
19:47:51 <michi_cc[d]> There is no PR. I can make one if necessary.
19:48:08 <andythenorth> michi_cc[d]: only me ๐Ÿ˜›
19:48:35 <_glx_> no decrease/increase just skips the grf decision
19:49:16 <michi_cc[d]> Yes. Which means production is not controlled by the GRF any more.
19:50:03 *** gelignite has quit IRC (Quit: Stay safe!)
19:50:06 <_glx_> these flags are more like a "cheat" option
19:51:22 <_glx_> and I think the idea behind is for the GS to pause unclaimed industries
19:51:41 <DorpsGek> [OpenTTD/OpenTTD] MasonGulu updated pull request #10204: Feature: Add alternative setting for right-click close window option to exclude pinned windows
19:54:26 <_glx_> anyway direct communication between GRF and GS is almost impossible as GS timing is unpredictable
19:55:50 <andythenorth> there is the proposed json spec
19:55:58 <andythenorth> but I have yet to find an actual case for it
19:56:13 <_glx_> won't help with the timing
19:56:35 <andythenorth> I think some kind of mapgen / saveload comms would be helpful
19:58:34 <_glx_> for mapgen it should be possible to call a specific GS function (with no opcode limit) to handle town/industries/objects placement
20:00:18 <andythenorth> that could be very useful
20:00:34 <andythenorth> most of all for storytelling GS
20:01:02 <peter1138> Doesn't the async command stuff help there already, or is that too unpredictable?
20:01:03 <DorpsGek> [OpenTTD/OpenTTD] michicc opened pull request #11141: Add: [Script] Game script control of industry production level.
20:01:20 <andythenorth> async seems to be great during gameplay
20:03:06 <andythenorth> I could just remove all the grf industries at start and re-place them
20:03:13 <andythenorth> seems wasteful ๐Ÿ™‚
20:03:46 <andythenorth> how would we call the GS function though?
20:03:54 <andythenorth> there's no callbacks
20:04:09 <peter1138> Is there a "main" function in gamescripts?
20:04:15 <_glx_> save and load are callbacks ๐Ÿ™‚
20:04:30 <andythenorth> MainClass
20:04:34 <michi_cc[d]> Now JGR can tell us that JGRpp already has someting like this all along, dp can say that it breaks CM and LC can accuse us all of ruining the game even more ๐Ÿ˜›
20:04:41 <andythenorth> ^ not sure if MainClass is a convention or not ๐Ÿ˜›
20:05:11 <peter1138> If you have a "mapgen" callback that executes on map start, then that could control whether default industry placement happens or totally custom.
20:07:09 <_glx_> save/load are callbacks called with opcode limit, but we also have some callbacks in info.nut which are called without opcode limit IIRC
20:11:34 <peter1138> mapgen callback would be useful for the GS that build roads linking towns.
20:12:12 <talltyler> Is mapgen inherently singleplayer? Do clients get kicked out when a server restarts while they're connected to it?
20:12:28 <talltyler> (thinking about async)
20:16:30 <andythenorth> imagine if we could call multiple GS ๐Ÿ˜›
20:16:39 <andythenorth> even if just at game start ๐Ÿ˜›
20:17:03 <andythenorth> "roadbuilder" would be so generic
20:19:11 <ahyangyi> ๐Ÿคฉ Running three instances of roadbuilder with different parameters
20:21:25 <andythenorth> players can do silly things anyway
20:28:38 <_glx_> talltyler: server really starts after mapgen
20:34:57 *** frosch123 has quit IRC (Quit: be yourself, except: if you have the opportunity to be a unicorn, then be a unicorn)
20:36:57 <_glx_> well, it's started just before mapgen but it won't do anything until generation is done
20:41:33 <_glx_> and clients are kicked and will try to reconnect in case of a server reboot
20:46:19 <andythenorth>
20:46:19 <andythenorth> michi_cc[d]: appears to work ๐Ÿ™‚
20:46:27 <andythenorth> didn't test every aspect of it ๐Ÿ™‚
20:48:17 <DorpsGek> [OpenTTD/OpenTTD] MasonGulu updated pull request #10204: Feature: Add alternative setting for right-click close window option to exclude pinned windows
20:48:29 <DorpsGek> [OpenTTD/OpenTTD] andythenorth commented on pull request #11141: Add: [Script] Game script control of industry production level.
20:48:45 <michi_cc[d]> andythenorth: That's still infinity-% more testing than I did :p
20:50:18 <andythenorth> is it supposed to reset to a default value if the flag isn't set?
20:50:48 <michi_cc[d]> Right now, no. It just restores handling of the production changes.
20:51:14 <andythenorth> should we add the ability to trigger a news message?
20:51:20 <andythenorth> maybe GS already can
20:51:21 <andythenorth> I'll look
20:51:44 <shrekshellraiser> can I get some git advice? I have done some hard resets, a rebase, and a sqaush on this PR to make it one commit. However after pushing I attempted building and realized there was a syntax error. After I fix this, should I just do another commit + squash so it stays a single commit?
20:53:54 <michi_cc[d]> shrekshellraiser: Yeah, we don't really want fix-up commits like this in the final history. If everything compiles on its own, we can also squash on final merge, but if you have to push something anyway, just do git commit --amend and force push.
20:55:39 <andythenorth> GSNews
20:55:41 <andythenorth> works
20:56:20 <andythenorth> although I don't know which newstype to use
20:56:20 <andythenorth>
20:57:37 <andythenorth> seems we don't have newstypes matching industries
20:57:39 <andythenorth>
20:58:13 <michi_cc[d]> Well, industries can provide custom news texts, so I think it would have to be built into the GS function.
20:58:54 <andythenorth> optional parameter for newstext?
21:00:03 *** jfs has joined #openttd
21:00:03 <jfs> andythenorth: NT_ECONOMY seems to be the one to use for industry news
21:00:19 <andythenorth> that's suppressed by my current settings
21:00:41 <andythenorth> more granular constants needed?
21:00:50 <jfs> actually, no it seems not, hm
21:03:26 <jfs> GSNews::Create even also only accepts three of the possible news type constants that are defined in the API
21:03:46 <andythenorth> can probably extend?
21:03:56 <jfs> I think that's a point to extend/loosen the API yes
21:04:43 <andythenorth> well this is promising
21:05:00 <jfs>
21:05:03 <andythenorth> also the nice thing...with async GS mode, it doesn't take 6 days to set prod level at all industries ๐Ÿ™‚
21:05:17 <jfs> lots more types defined in the main code than published in the API too
21:05:50 <andythenorth> ah ok, so I wouldn't want to be emitting all 3 types ๐Ÿ˜›
21:06:00 <andythenorth> we could do with a constant resolver function there ๐Ÿ˜›
21:06:20 <andythenorth> GSNews.GetIndustryNewsType(industry)
21:06:21 <andythenorth> or something
21:06:37 <andythenorth> or a magic constant that does the same thing
21:07:46 *** nielsm has quit IRC (Remote host closed the connection)
21:12:40 <DorpsGek> [OpenTTD/OpenTTD] michicc updated pull request #11141: Add: [Script] Game script control of industry production level.
21:13:47 <andythenorth> oh simultaneous ๐Ÿ™‚
21:13:48 <michi_cc[d]> andythenorth: Now with an option to generate the proper default industry production change news.
21:13:52 <andythenorth> I was just commenting about news ๐Ÿ™‚
21:14:06 <DorpsGek> [OpenTTD/OpenTTD] MasonGulu updated pull request #10204: Feature: Add alternative setting for right-click close window option to exclude pinned windows
21:14:06 <michi_cc[d]> For special news texts, GS can still manually generate a news item.
21:16:35 <andythenorth> `src/industry_cmd.cpp:2162:18: error: use of undeclared identifier 'indspec'
21:16:35 <andythenorth> SetDParam(2, indspec->name);
21:16:35 <andythenorth> `
21:16:49 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
21:18:30 <andythenorth> GH has found the same thing now ๐Ÿ™‚
21:20:25 <peter1138> More cheese?
21:22:18 <andythenorth> cheese dreams
21:22:58 <peter1138> "Well"
21:24:09 <DorpsGek> [OpenTTD/OpenTTD] michicc updated pull request #11141: Add: [Script] Game script control of industry production level.
21:33:32 <andythenorth>
21:33:47 <peter1138> Why is food?
21:34:37 <andythenorth> because reasons
21:37:39 <andythenorth>
21:37:50 <andythenorth> michi_cc[d]: not sure we can rely on the default production change texts ๐Ÿ™‚
21:38:02 <andythenorth> they have some...assumptions
21:38:43 <michi_cc[d]> Are GRFs usually providing custom news strings in the production CB?
21:39:38 <michi_cc[d]> I'm not against adding more news types to GS, but that can very well be a separate PR.
21:40:19 <andythenorth> yes
21:40:32 <andythenorth> GRFs have to put a string reference into a register I think
21:41:15 <andythenorth>
21:43:31 <DorpsGek> [OpenTTD/OpenTTD] andythenorth commented on pull request #11141: Add: [Script] Game script control of industry production level.
21:44:40 <andythenorth> is it sleeping time? ๐Ÿ™‚
21:58:41 <kamnet> No sleep 'til Brooklyn. When does your flight leave?
22:01:04 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler opened pull request #11142: Change: Use minutes instead of dates for automatic server restarts
22:02:16 <andythenorth> well that's most of GS fixed then ๐Ÿ™‚
22:02:28 <andythenorth> what's left?
22:02:38 *** keikoz has quit IRC (Ping timeout: 480 seconds)
22:02:45 <andythenorth> give it direct access to an OpenTTD pathfinder?
22:03:09 <andythenorth> and some kind of regions feature
22:06:37 <DorpsGek> [OpenTTD/OpenTTD] MasonGulu commented on pull request #10204: Feature: Add alternative setting for right-click close window option to exclude pinned windows
22:08:51 <shrekshellraiser>
22:08:51 <shrekshellraiser> Alright, that PR is ready to be looked at. I'd request a review, but I seemingly already have a review requested?
22:25:02 <peter1138> There's no real need to request a review, it will get seen in our own time.
22:25:36 <peter1138> It's not like IRC where if it scrolls off the screen it's just gone...
22:29:15 <dwfreed> that's why irc users have healthy scrollback and logs :P
22:29:17 <shrekshellraiser> peter1138: I just didn't know if after such long inactivity people wouldn't notice it
22:34:18 <talltyler> I always sort PRs by most recently updated ๐Ÿ™‚
22:47:08 <peter1138> And we get update notifications here.
22:51:03 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
22:51:11 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler commented on pull request #10204: Feature: Add alternative setting for right-click close window option to exclude pinned windows
22:57:02 <shrekshellraiser>
22:57:02 <shrekshellraiser> What do you mean by this?
22:58:09 <shrekshellraiser> oh nevermind
23:05:43 <peter1138> Best place to ask is with the review comments ๐Ÿ™‚
23:07:19 <_glx_> and ideally if you want to reply to multiple comments start a review ๐Ÿ˜‰
23:07:26 <shrekshellraiser>
23:07:26 <shrekshellraiser> I had saw this view, and did not understand why I couldn't reply to that discussion. Turns out there's more to the discussion that github just wasn't showing on that screen
23:07:42 *** tokai has joined #openttd
23:07:42 *** ChanServ sets mode: +v tokai
23:14:37 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
23:23:32 <DorpsGek> [OpenTTD/OpenTTD] MasonGulu updated pull request #10204: Feature: Add alternative setting for right-click close window option to exclude pinned windows
23:24:31 <DorpsGek> [OpenTTD/OpenTTD] MasonGulu commented on pull request #10204: Feature: Add alternative setting for right-click close window option to exclude pinned windows
23:28:17 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler commented on pull request #10204: Feature: Add alternative setting for right-click close window option to exclude pinned windows
23:34:47 <DorpsGek> [OpenTTD/OpenTTD] MasonGulu updated pull request #10204: Feature: Add alternative setting for right-click close window option to exclude pinned windows