IRC logs for #openttd on OFTC at 2024-08-08
⏴ go to previous day
02:10:00 *** gnu_jj_ has joined #openttd
02:13:09 *** gnu_jj has quit IRC (Ping timeout: 480 seconds)
02:18:15 *** Wormnest has quit IRC (Quit: Leaving)
02:41:09 *** debdog has quit IRC (Ping timeout: 480 seconds)
04:44:09 <DorpsGek> - Update: Translations from eints (by translators)
06:23:27 <andythenorth> ach maybe I can shard the randomised switch chains
06:39:40 <andythenorth> 117 of the Horse concurrent varact2 IDs are due to randomised vehicles
07:05:57 <andythenorth> the thing with sharding
07:07:20 <andythenorth> (is that sharding is the wrong name for my idea)
07:07:43 <andythenorth> my solution is to add a switch to *every* vehicle
07:08:30 <andythenorth> the randomised vehicle graphics chain then stores the target vehicle ID in a register, and walks the list of *all* vehicles, comparing the target ID with the ID in the register
07:09:09 <andythenorth> this should significantly cut the concurrent varact2 requirements, as we should just be able to recurse up through the vehicles with a single varact2 ID
07:09:42 <andythenorth> but it means the graphics chain is potentially walking 6474 varact2s in the most pathological case
07:10:11 <andythenorth> is that negligible for performance ?
07:30:04 *** peter1138 has joined #openttd
07:40:52 *** kuhnovic has joined #openttd
07:40:52 <kuhnovic> Silly gitlab. Starts a new build when you add a reviewer to a MR.
07:41:01 <kuhnovic> Might just be my company's settings though.
07:48:58 <truebrain> that is just odd ...
07:49:12 <truebrain> did someone not write a proper gitlab ci file? 😄
07:51:44 <LordAro> in fact, i don't know how you do that
07:51:58 <LordAro> the only triggers i'm aware of are MR creation, and adding new commits
07:53:28 <truebrain> maybe they configured their webhook to trigger the pipeline API, causing a CI event? 😛
07:53:40 <LordAro> but that feels intentional
07:54:02 <truebrain> no `$CI_PIPELINE_SOURCE == "merge_request_event"` in the `gitlab-ci.yaml` I guess 😛
07:54:15 <truebrain> but yeah, gitlab doesn't do that by default 🙂
07:56:19 <kuhnovic> It even triggers a build when you change the title of your MR 😛
07:56:53 <kuhnovic> We recently migrated to Gitlab so there are definitely some kinks that have to be ironed out
07:57:18 <truebrain> it is really odd someone managed to do that 😄
07:57:24 <truebrain> well, kinda depends, I guess
07:57:28 <truebrain> is the CI of Gitlab used?
07:57:32 <truebrain> or still the "old" system?
07:57:50 <truebrain> as if the latter, someone just isn't filtering on what events to actually trigger a build 😄
07:58:24 <truebrain> now it makes more sense 🙂
07:58:39 <kuhnovic> There must be something funny going on in the script / bridge that runs that part
08:00:15 <LordAro> we migrated everything all at once
08:00:30 <LordAro> not least because the previous build system was a complete kludge of php, python & makefiles
08:01:10 <andythenorth> Buy a 'random vehicle', the random vehicle has a list of candidates, which are the IDs of real vehicles.
08:01:10 <andythenorth> What's more plausible?
08:01:10 <andythenorth> (1) the random vehicle has an ID and gets built, but the action 3 is redirected to the action 3 for the 'randomly selected' vehicle
08:01:10 <andythenorth> (2) the random vehicle is never built, and one of the real vehicles is built directly
08:53:29 *** mindlesstux has joined #openttd
09:15:05 *** Smedles has joined #openttd
10:21:55 <andythenorth> pff, to replicate what Horse is doing, I'd need it to be able to callback against the chain of vehicles it's attached to
10:22:20 <andythenorth> Horse wagon 'randomisation' is weighted to produce runs of similar wagons
10:25:05 <peter1138> Buying an engine has no knowledge of an existing chain.
10:25:24 <andythenorth> so 'need' wouldn't work
10:26:25 <andythenorth> I also don't mean callback, I mean 'var'
10:26:33 <peter1138> There are statistics available on the number of engine types each player has.
10:26:44 <peter1138> And that is available at the group level.
10:26:56 <peter1138> But then buying an engine has no knowledge of which group it'll be in.
10:27:14 <andythenorth> maybe I make a GS Story page to buy vehicles? 🙂
10:27:21 <andythenorth> "that will go well"
10:28:04 <peter1138> Here's something horrible.
10:28:11 <peter1138> Make the engine type *change* when attaching it.
10:28:22 <peter1138> replace-on-wagon-attach.
10:28:37 <peter1138> Randomness can then decide based on the chain.
10:29:13 *** Flygon has quit IRC (Quit: A toaster's basically a soldering iron designed to toast bread)
10:30:10 <andythenorth> I have had a worse idea
10:30:35 <andythenorth> if there was a consist entity (distinct from lead engine)
10:31:07 <peter1138> Remove cargo refits, make them variants that get type-swapped?
10:31:08 <andythenorth> and the consist had a known length, and a callback to change what vehicle is in any specific position in the consist
10:31:16 <andythenorth> and the callback had triggers
10:31:49 <andythenorth> hmm no, I don't see how it would get the candidates for 'randomisation'
10:32:07 <andythenorth> oh that would do templated replacement as well
10:32:26 <peter1138> Okay, second play-through had no noise, must've been dust or hair on the vinyl.
10:32:30 <andythenorth> how would the consist know the length (and no. of vehicles, or a fixed tile length?)
10:33:09 <reldred> I still need to figure out how to balance my record player on top of my stereo stack, hmm
10:33:22 <reldred> and I still need to get that matching CD deck
10:33:29 <andythenorth> oh this is accidentally like Railroad Tycoon, where a consist has a length, and then each slot is given possible vehicles
10:33:34 <andythenorth> and the game sorts it out
10:34:01 <andythenorth> oh then we could have 'shunting'
10:34:04 <andythenorth> but it would be in depots
10:34:15 <andythenorth> you could have an order to 'add a banker engine'
10:34:18 <andythenorth> 'remove a banker engine'
10:34:34 <andythenorth> 'go to fartingpool depot and remove 3 wagons'
10:35:09 <andythenorth> it wouldn't be 'shunting' like combining 2 consists into 1 though, that's something else
12:00:29 *** XYZ has quit IRC (Ping timeout: 480 seconds)
12:06:19 *** gnu_jj_ has quit IRC (Ping timeout: 480 seconds)
13:43:29 *** audigex has joined #openttd
13:43:29 <audigex> andythenorth: I'd love option 2 to be possible - place items in the purchase list that invoke the purchase of a different vehicle
13:43:29 <audigex> You can just do it by duplicating the vehicle but autoreplace etc don't work and it's more work to maintain
13:44:15 <andythenorth> oof I thought of another use case
13:44:43 <audigex> peter1138: I've been saying for a while that I think it would be good if we could just throw the current `cargo_subtype_text` and `default` (using `cargo_subtype`) switches at the game and it iterates the livery variants for us
13:45:08 <audigex> andythenorth: All fun and games until it goes wrong and you end up with half a 142 attached to a Class 43 power car
13:45:54 <audigex> Poor leyland bus being yanked backwards up the ECML at 125mph
13:48:08 *** felix_ has quit IRC (Ping timeout: 480 seconds)
13:55:30 <peter1138> audigex: no, it would need to be done at the NewGRF preparation stage.
13:57:10 <peter1138> Enumerating cargo subtypes depends on too many run-time variables for it to be feasible.
13:57:30 <peter1138> e.g. they can differ depending on the current game date.
13:57:44 <audigex> Yeah I've proposed it as potentially being part of NML, so by the time the game sees it then it's already iterated out
13:57:52 <audigex> The main sticking point is handling of IDs
13:58:41 <audigex> Basically we stop abusing cargo_subtype and instead provide a similarly-intentioned list that NML iterates for us
13:58:57 <peter1138> NML would have the same issue. cargo subtype depends on at least the cargo type, and often on dates, and NML can't really be expected to evaluate all that.
13:59:26 <audigex> It wouldn't be cargo subtype anymore? It would just be a couple of lists. That's kinda the point
13:59:45 <peter1138> Well, you starts with "throw the current cargo_subtype_text ...."
13:59:58 <peter1138> Whereas what it needs a totally different thing in NML.
14:00:29 <audigex> Yeah, exactly? We stop abusing cargo_subtype but use the same "here's a list of livery names and it's matching list of spritesets" principle in a different, more sensible mechanism
14:00:57 <audigex> Right now we're using cargo subtype in a way it was never intended to be used
14:01:36 <peter1138> Well it probably is the way it was meant to be used, it's just not very good...
14:01:51 <andythenorth> I proposed a livery spec once
14:02:00 <andythenorth> that would have possibly exposed them also to company colour pickers
14:02:12 <andythenorth> so liveries could be set for groups, if supported
14:02:12 <audigex> ^ I support this lunatic
14:02:23 <andythenorth> I never found it convincing
14:03:00 <audigex> I think variants do the job pretty nicely tbf - although that "You can just specify another vehicle to copy" idea would make it a lot nicer to work with if that gets merged
14:03:09 <audigex> Just over-riding anything that's different
14:04:36 <andythenorth> if only nml wasn't nml
14:05:49 <andythenorth> it's just a list of keywords
14:06:16 <andythenorth> in this case it's so you can buy 2 class 20s as a single unit, or just 1, as variants
14:06:23 <audigex> That's all greek to me, chief
14:06:31 <andythenorth> yeah it's the problem of nml
14:06:35 <audigex> Never jived with Python
14:06:40 <andythenorth> it's designed for non-programmers, so it's broken
14:06:51 <andythenorth> all semi-code systems are broken
14:07:04 <andythenorth> non-programmers should learn to program
14:07:14 <andythenorth> instead of trying to use broken lego duplo tools
14:07:48 <audigex> Tbf I am a developer, I've just never taken the time to work out what you're actually doing with your stuff 😂
14:07:48 <audigex> I probably wouldn't have started BRTrains with raw NML if I'd been the one who'd started coding it in 2016, but it was already too far gone by the time I got to it to want to rebuild the whole thing
14:08:06 <andythenorth> possibly grf2py will solve all this, but it's early days
14:09:02 <audigex> My main query about grf2py or py-grf etc etc is whether they'll have the same flexibility as NML. You can do a lot of whacky stuff with NML and it allows for some creativity. I don't want a new system to be too rigidly opinionated and stop me doing things my own way
14:11:19 <locosage> grf-py is already way more flexible than nml can ever hope to be
14:11:33 <locosage> if there is one thing grf-py doesn't lack it's flexibility
14:12:05 <audigex> Does it expect one livery per file there? Presumably there's an override where I can give XY coords?
14:13:22 <audigex> Cause I'm sure as shit not copying 2500 spritesets out into separate files now 😂
14:14:26 <locosage> that's just how liveries for those particular trains are organized
14:15:12 <audigex> tbf I think grf-py is a good solution for new projects, I've just balked at the conversion work needed and I'm a little wary of it being newer (eg if you disappeared from the community, would someone else pick it up?)
14:15:12 <audigex> For me it's just a case of BRTrains being such a huge project with such massive investment that I want to be 100% confident that it'll do everything I need forever, before making a big move with it
14:15:45 <andythenorth> I haven't tried grf-py, but most python packages of this sort can be monkey-patched or otherwise modified locally if needed
14:15:54 <audigex> I'm more tempted at the moment to roll my own NML-builder like Andy does, since I'll have my own understanding of it and worst case scenario it spits out NML that someone else can pick up
14:15:56 <andythenorth> or have configuration points for additional modules
14:16:33 <audigex> But I've deliberately held off doing either because I'm just not sure what the best choice is. Result: I write a load more NML 🙄
14:17:04 <locosage> grf-py started as nml-builder too
14:17:08 <locosage> that didn't last long though
14:21:54 <peter1138> All my little tests have been done with grf-py.
14:22:09 <locosage> for multiple climates at once
14:22:19 <peter1138> There's very little chance I'll ever modify NML or grfcodec to handle SVG sprites, for example.
14:23:04 <locosage> yeah, python is great for monkey-patching and extending
14:23:14 <locosage> and I keep that usecase in mind for grf-py too
14:24:49 <peter1138> Is creating a classes to add new features "monkey-patching"?
14:25:06 <andythenorth> no, monkey patching is over-riding classes in modules at run time
14:25:38 <locosage> peter1138: that's why I added "extending" xd
14:25:55 <locosage> monkey-patching would be adding new callbacks or properties
14:26:03 <peter1138> grf.ReplaceOldSprites is standard.
14:26:09 <peter1138> SVGSprite is custom.
14:27:27 <andythenorth> the reasons I haven't tried / switch to grf-py
14:27:27 <andythenorth> - not enough authors/maintainers yet...single person project can die too easily
14:27:27 <andythenorth> - I think I'd end up having to write docs because others wouldn't, and I really don't enjoy writing docs
14:27:27 <andythenorth> - TrueGRF showed how fast Rust was to compile grf, and I was hoping we'd get a Rust grf compiler
14:27:27 <andythenorth> - it's not in the OpenTTD repo world
14:27:29 <andythenorth> - my stuff is very large, although there's an automated port of Horse to grf2py, there's a lot of compile architecture in place that defines the current 'grf' and all of its supporting assets
14:28:06 <locosage> I have sprite encoder in rust that's faster than truegrf one :p
14:28:31 <andythenorth> I do think we should dump nml and have a new compiler at some point
14:28:33 <andythenorth> but it's not a small thing
14:28:48 <peter1138> So you want grf-rust?
14:28:50 <andythenorth> and it's not the fun part of making grf
14:29:59 <locosage> imo coding whole grf in rust would be just an added pita not performance benefit
14:30:09 <audigex> Yeah I'm in pretty much the same place as Andy. I like the idea, I'm waiting for others to be the guinea pigs
14:30:09 <audigex> The other thing for me, that I might just be misunderstanding - how do you keep grf-py up to date? It seems like I have to build my project *as* grf-py, so I can't just `pip update grf-py` and have the newest version?
14:30:41 <locosage> I can do time-critical things in rust or c in grf-py already and grf definitions themself are fast enough imo
14:31:09 <peter1138> modern C++ that is...
14:31:11 <audigex> I feel like what I actually want is essentially NML2, which might run grf-py as the compiler, but is built in a more extensible way whereas NML was more of a GRF/NFO abstraction rather than GRF-building language
14:31:50 <audigex> Fundamentally I *like* how NML works. For the most part I just define the vehicles as not-quite-JSON and off it goes
14:32:39 <locosage> audigex: well, right now the recommended way is install latest grf-py from github and stick to that version until you need something new
14:33:07 <locosage> audigex: that makes no sense to me tbh, you want more high-level language work as a compiler for tho low-level one?
14:33:35 <audigex> Not quite. I struggle to express myself with this stuff as I'm not deep enough into it to phrase things well
14:34:57 <locosage> I guess the main idea of grf-py is that it allows you to easily create your own "NML2"
14:35:08 <andythenorth> In my 35 years experience of programming, every abstraction to “not code” fails
14:35:17 <locosage> meaning a high-level interface for defining your stuff in a way you need
14:37:02 <andythenorth> “Just write code” is far better than “write not code, but still with fiddly context”
14:46:39 <audigex> Eg I like the way NML defines vehicles, I'd like to be able to just do something similar but neater where I say "here are the properties, figure it out"
14:46:39 <audigex> group: supersprinter // variant
14:46:39 <audigex> name: Class 158 // Optionally an externally defined string but most of the time probably not
14:46:43 <audigex> tractive: 50 // work out the TE coefficient for me...
14:46:43 <audigex> costs: auto // calculated based on everything else here
14:46:45 <audigex> loadingspeed: intercity
14:46:47 <audigex> sprites (diesel/158, 8) // Graphics folder and unit length
14:46:51 <audigex> frontpantograph: //blank = optional just here for demonstration
14:46:57 <audigex> liveries { GWR, Northern, TfW} // translates to eg gwr.png in the folder above
14:47:01 <audigex> (front, middle:1, rear)
14:47:03 <audigex> Obviously it would have slightly different structures for steam trains, wagons, freight units etc and fancier layouts, but for me at least that would be a neat way to define the vast majority of units
14:47:03 <audigex> And yeah I've just thrown this together as thoughts into words, please don't consider it to be a spec or proposal 😂
14:47:28 <audigex> There are a million and one problems with it, but I think that's an accessible level of abstraction for non-coders without them having to learn python or whatever
14:48:20 <audigex> It would then iterate through the liveries and consists to build out the variants
14:49:01 <audigex> I'm not really expecting that to become a thing, just a point for discussion about how NML could be taken to another level of abstraction
15:01:14 <andythenorth> what does grf2py use as the configuration format for content?
15:02:39 <locosage> I probably need to rebrand it before it's too late xD
15:02:48 <locosage> it doesn't force any particular format to define stuff
15:03:19 <locosage> it just (ideally) provides generic classes that you can specialize for your usecase and use that as a "configuration format"
15:04:17 <andythenorth> I have written maybe 5 or 6 configuration 'formats' that I can remember. A couple for grf, and a couple for website CMSes, and a couple for games
15:04:54 <andythenorth> I have used XML, .cfg files, plain text, csv and name/value pairs on a query string type format
15:05:06 <andythenorth> all of them are great until
15:05:22 <andythenorth> or we need to handle optional values that are inherited from a default
15:05:34 <locosage> well, with grf-py it's all python
15:05:38 <andythenorth> or we have strings with characters that need escaped
15:05:48 <andythenorth> or we need to reference another object
15:05:54 <andythenorth> so yeah....not a fan
15:06:11 <locosage> just some python is logic-heavy and some is more declarative
15:06:17 <andythenorth> every intermediate format requires maintaining a format parser
15:06:30 <andythenorth> and that gets increasingly complicated as soon as we want to do anything useful
15:06:43 <locosage> well, except switch code language, that's dsl, not python
15:06:44 <andythenorth> and if it's designed for non-technical authors they will repeatedly come unstuck
15:07:01 <peter1138> grf-py lets you read a spreadsheet that defines all properties...
15:07:09 <andythenorth> so yeah....just configure content in the programming language
15:07:12 <peter1138> Or you can individually declare it all
15:07:34 <locosage> yeah, I guess declarative part doesn't have to be python with grf-py
15:07:57 <andythenorth> could be anything
15:08:20 <andythenorth> json and yaml fall into 'possibly' because they do more about providing sensible types etc
15:08:29 <andythenorth> and the parsers are off-the-shelf and standard
15:08:44 <andythenorth> even though they're not programming languages
15:10:21 <_glx_> the magic with python is it could read many different formats for properties
15:11:59 <locosage> and that's the boring part, real magic is how it can do sprites out of anything
15:12:34 <locosage> .ase, .psd, procedurally-generated, anything goes
15:14:40 <andythenorth> nmlc is going to have to die some how
15:15:11 <_jgr_> All the existing GRFs written in NML are not going to go away
15:15:23 <andythenorth> grf2py can ingest nml
15:16:04 <locosage> there is grftopy, but it's grf decompiler so code it generates isn't great
15:16:13 <peter1138> You'd have to write an nml parser...
15:16:20 <andythenorth> oh I misunderstood what you did with Horse
15:16:26 <locosage> I could in theory do nml to python translator but that's a lot of work I don't fancy doing
15:16:59 <locosage> yeah, horse I just rewrote in python
15:17:00 <locosage> well, some parts of it
15:18:11 <locosage> locosage: and I mean grf-py python instead of nml-generating python xD
15:18:53 <locosage> though I did decompile horse on other occasions too frr various reasons
15:24:24 <audigex> Fundamentally there are a lot of things we can do with sprites and vehicles, any format is gonna be somewhat messy in terms of the numbers of ways we have to be able to overload things
15:25:10 <audigex> Simply because an "engine" can be a single engine, a dual-headed loco, or an articulated vehicle, and how many different ways we can do things with wagons etc
15:25:19 <audigex> GRF is impressively powerful, really
15:38:12 *** LordAro has joined #openttd
18:44:43 *** Wormnest has joined #openttd
19:50:41 *** HerzogDeXtEr has joined #openttd
21:02:43 *** nielsm has quit IRC (Ping timeout: 480 seconds)
21:33:11 *** virtualrandomnumber has joined #openttd
21:33:52 *** virtualrandomnumber has quit IRC ()
21:45:15 *** ChanServ sets mode: +v tokai
21:51:54 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
21:56:44 *** keikoz has quit IRC (Ping timeout: 480 seconds)
22:17:42 <peter1138> andythenorth: your feature request for your NewGRF breaks your NewGRF.
22:23:30 *** goddess_ishtar has joined #openttd
continue to next day ⏵
