IRC logs for #openttd on OFTC at 2024-08-02
⏴ go to previous day
01:01:49 *** Flygon has quit IRC (Read error: Connection reset by peer)
01:59:19 *** Wormnest has quit IRC (Quit: Leaving)
02:16:22 *** gnu_jj_ has joined #openttd
02:19:49 *** gnu_jj has quit IRC (Ping timeout: 480 seconds)
02:47:14 *** D-HUND has quit IRC (Ping timeout: 480 seconds)
04:43:50 <DorpsGek> - Update: Translations from eints (by translators)
05:05:25 <andythenorth> peter1139: I can probably change it
06:01:31 <johnfranklin> Is conversion from VSCode to Emacs a hard one?
06:15:27 *** HerzogDeXtEr has joined #openttd
06:36:43 *** gelignite has joined #openttd
06:46:36 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
06:59:12 *** SigHunter has quit IRC (Remote host closed the connection)
07:00:13 *** SigHunter has joined #openttd
08:35:45 <peter1139> andythenorth, looking at it, I'm not sure how you would.
08:39:25 <peter1139> Well, there are tiles being animated that actually have no apparent graphical variations for any frame.
08:42:10 <andythenorth> I forget how animation works, I templated it all away about 10 years ago
08:43:01 <andythenorth> but iirc there are two approaches to it, one is to actually step through animation frames sequentially, and the other is to use the frames as a counter to make decisions in switches
08:43:33 *** guru3 has quit IRC (Quit: leaving)
08:43:36 <peter1139> The counter method is the issue. Every time the counter changes it marks the tile dirty.
08:44:14 <andythenorth> most of the animations are just repeating loops
08:44:15 <peter1139> If all your industry tiles do this, it's basically marking a large portion of the map dirty every tick.
08:44:25 <andythenorth> not much in the way of random triggers
08:45:34 <andythenorth> haven't looked at it in years though 🙂
08:46:13 <peter1139> If all the FIRS forks follow the same system, then they're all going to be slow as well...
08:46:23 <peter1139> What have you done! You monster!
08:46:38 <andythenorth> but they've mostly built from the generated nml, so it won't be easy for them to consume
08:47:32 <peter1139> They don't even modify the source? :o
08:50:04 <andythenorth> 270k lines of nml in a single file is just easier
08:50:15 <andythenorth> compared to getting a working python compile and dealing with that
08:56:09 <pickpacket> I didn't (and still don't) know how to change just part of the tile. Each sprite is the full tile
09:01:59 *** mindlesstux has joined #openttd
09:09:24 <peter1138> That looks very weird.
09:13:32 <peter1138> I guess you could do that by having the 1 ground layer and then have a 2-pixel person sprite that is moved around. You'd need multiple sprites to get around the low resolution of the 16-subtile coordinates.
09:14:17 <peter1138> If every plantation tile is animated all the time then that will cause the game to slow down.
09:14:22 <pickpacket> Yeah, I believe I could do that. I'd need to find an example somewhere to understand how, though
09:15:14 <peter1138> There's a reason animation triggers exist... you can make it animate only when something is happening.
09:16:45 <peter1138> You can also trigger on the tile loop.
09:17:52 <peter1138> With that you can then run a short non-looping animation, so it still has "life" but doesn't bog down the rendering by running all the time.
09:18:11 <peter1138> Your approach is at least rendering something different every time.
09:18:23 <peter1138> With FIRS it often isn't.
09:18:44 <pickpacket> what exactly is the tile loop?
09:20:48 <peter1138> It's a periodic loop that scans the whole map in a pseudo random (not exactly, but it's not sequential) way such that every tile gets a tick after 256 (IIRC) game ticks.
09:22:22 <pickpacket> that should be enough for most animations
09:40:19 <andythenorth> this has 2 different animated tiles, example switch name is `basic_oxygen_furnace_tile_1_industry_anim_control`
09:40:28 <andythenorth> I haven't read what they're actually doing
10:35:35 <peter1138> The basic oxygen furnace is actually okay for animated tiles.
10:36:28 <peter1138> The whole thing is refreshed about once a second, which might be excessive but not too bad.
10:38:00 <peter1138> Tube & Pipe Mill is an offender for refreshing too often.
10:38:22 <peter1138> Press Ctrl-I and watch the tiles being updated.
10:40:27 <peter1138> The big patch of yellow is where it has refreshed the whole industry in the same tick. It does this basically every other tick or so.
10:42:20 <peter1138> Var 44 is constantly increasing. Each time it does the tile is redrawn, even though you don't select different graphics.
10:45:34 <andythenorth> I am somewhat constrained on tile IDs so I tend to use animation on every tile even if only one tile has animated sprites
10:46:38 <FLHerne> do FIRS industries still have that thing where every tile of an industry is the same, then has a switch on its coordinates in the layout?
10:48:24 <peter1138> Compounded performance issues then.
10:48:28 <_jgr_> Pretty much all industry GRFs do that
10:48:48 <peter1138> You really should control animation based on the coordinates and only animate tiles that are actually animated.
10:49:17 <peter1138> It's not really possible for OpenTTD to determine if the changed animation frame will result in different graphics.
10:50:09 <_jgr_> It's not too difficult to work out if the graphics for a given tile don't depend on the animation frame at all
10:50:21 <andythenorth> FLHerne: Yes, that’s the recommended approach
10:50:48 <andythenorth> Unless industry tile IDs increased when objects did?…
10:51:29 <FLHerne> I thought they did, was just trying to find any such commit
11:10:08 *** mindlesstux has quit IRC (Ping timeout: 480 seconds)
11:13:53 *** mindlesstux has joined #openttd
11:29:00 *** milek7 has quit IRC (Remote host closed the connection)
11:34:36 *** SigHunter has joined #openttd
12:13:39 *** SigHunter has quit IRC (Ping timeout: 480 seconds)
12:26:54 <peter1139> Who even cares what an archived personal page says...?
12:27:04 <peter1139> (Unless it's something offensive/illegal)
12:39:38 <peter1138> _jgr_: Sounds like you'd need to evaluate all act2 chains and in the case of a tile being reused, sometimes with animation, sometimes not, it might not be workable.
12:43:26 <_jgr_> I'm already doing this analysis in my branch, with FIRS-style industries being the main motivation. Its not unworkable.
12:48:39 <peter1139> I guess I'm thinking of perfection instead of something that will improve most things...
12:52:14 <peter1139> Even better would be for the NewGRF to not animate things that don't animate :p
12:54:11 <reldred> people make do with the tools they have
13:01:30 <peter1138> That sort of comment is so ...
13:03:39 <peter1139> People do things and don't realise some of the consequences, sure. But also if we don't "call it out", how will they know...
13:04:43 <reldred> sure, but if they're doing things in a certain way because it's the only way to achieve the desired goal, then there's only really three options; keep putting up with the bad situation, give them better tools to achieve their ends, or take their toys away from them.
13:05:16 <peter1139> But it isn't the only way.
13:06:37 <reldred> you tend to take a very black and white view on some of the things newgrf authors do sometimes, take overlapping tiles - they exist because the authors have no better way of achieving a certain end goal. Give them the tools they need to do things better and they'll stop making the overlapping tiles. I mean we have that now with roadstops for example.
13:07:13 <reldred> I'm not really trying to throw shade,
13:07:55 <reldred> mostly trying to offer some small defence to why people sometimes do the things they do
13:08:02 <_jgr_> A typical NewGRF author using NML does not have a reliable model of how what they write relates to performance in any useful way
13:08:58 <_jgr_> It is essentially opaque unless you know how the internals of the codebase work
13:09:43 <peter1139> I'm reading this as "NML authors don't know things might be an issue, therefore we shouldn't tell them"
13:10:58 <reldred> I feel that's jumping immediately to the worst conclusion you possibly could. What I was trying to imply was, if they're doing something wrong, tell them, but also give them a better way of doing things.
13:12:19 <FLHerne> also, telling them doesn't work retroactively, and it only works if you keep telling every future author too
13:14:29 <FLHerne> whereas mitigating the problem code-wise improves things for every affected grf past/present/future
13:14:40 <reldred> sure, but if BadMethod is the only way of doing something what else are they going to do? they're going to keep doing BadThings, then everyone starts resenting each other.
13:14:58 <reldred> well yeah, so two approaches then, either give them a better method, or make BadMethod suck less.
13:16:25 <FLHerne> I think some of it could be improved by adding more expressivity to NML, so grf authors don't need to keep rolling their own things
13:16:43 <FLHerne> (and generally making NML codegen less bad)
13:17:35 <FLHerne> every major grf seems to use some kind of templating solution on top of NML, which tends to isolate authors from the output
13:18:31 <reldred> NML already isolates authors from their output quite a bit compared to NFO
13:18:47 <reldred> But that's kinda the eternal curse of abstraction innit?
13:19:25 <reldred> not sure I want to write too much more nfo in my life though I must admit.
13:20:39 <_jgr_> NML codegen issues she on large part because of how awkward a format NFO is
13:22:40 <FLHerne> IMO it's more that nmlc is written backward :p
13:25:48 <FLHerne> the codegen is very bottom-up, "this syntax represents this action", which makes any kind of optimization pass beyond the very local quite difficult to implement
13:41:37 <_glx_> about overlapping tiles I can understand some of their (ab)use, like metro like stuff, but some 4-tiles objects/houses are really the same big sprite drawn 4 times, and in this case it should have been properly cut
13:44:02 <_glx_> FLHerne: yup and that cause pain to implement stuff like stations as the expected nml syntax doesn't match the internal actions
13:47:32 <_glx_> I once tried to filter duplicate varact2 blocks, but it's almost impossible to do without huge impact on performance
14:02:00 <audigex> _jgr_: Completely agree with this - as a GRF developer I have literally ZERO idea of what performance implications there are of what I'm doing
14:02:00 <audigex> Eg does position_in_consist reference a variable already assigned to the vehicle on creation and therefore runs in O(1) or does it traverse a list and run in O(N), or is it doing something better or worse than that? The same for everything else we do
14:02:00 <audigex> I don't think I've ever seen anything in the docs to suggest how good or bad it is
14:09:56 <_jgr_> For position_in_consist, it's essentially O(N), but then cached so subsequent reads in the same callback/graphics call are O(1)
14:11:37 <audigex> See, useful to know but not something I've ever seen in any of the docs so I'd have had no idea
14:11:48 <audigex> It couldn't been N^2 for all I knew (I'm not sure how, but you never know...)
14:16:58 *** gelignite has quit IRC (Quit: Stay safe!)
14:30:12 <peter1139> Hmm, is using the map for animated tile state valid or wasteful...
15:29:27 <michi_cc[d]> peter1139: My "secret" newmap plan would have a new MP_ANIMATION sub-tile to be able to shrink the general tile size down. As I haven't progressed to that point so far, I don't know if it actually is a good idea or not 😛
15:55:07 <peter1139> (I don't really think a discussion about it is that useful, it needs someone to work on it, not talk about it :p)
15:56:07 <talltyler> Well, I need help understanding how to handle the NewGRF interface 🙂
15:56:23 <peter1139> Step 1) Completely ignore NewGRF.
15:56:27 <FLHerne> I was going to link it to the discussion but it's so garbled there seems little point
15:57:20 <FLHerne> completely ignoring NewGRF causes problems with tail lights and exhaust/sparks positioning and blah
15:57:49 <_glx_> first step is always make it work with pure vanilla 🙂
15:58:16 <_glx_> then props, vars, callbacks can be added for newgrf as needed
15:59:16 <talltyler> Yes, I think separating consist information from the lead vehicle is the necessary first step. Michicc was thinking about it but I don't think ever wrote any code for it.
15:59:59 <peter1139> Not sure about necessary, but it would make some things simpler I think.
16:01:43 <_glx_> consist could contain a vector of vehicles, easy to iterate and reverse iterate
16:02:51 <peter1139> I had a patch once that allowed the engine to be in any position...
16:02:58 <peter1139> I wonder what I did with it :D
16:04:08 <peter1139> You can make "free-wagons" in depots behave exactly the same as a regular consist. They just can't be started because there's no engine.
16:04:22 <peter1139> That allows building up a train that doesn't start with an engine.
16:06:46 <talltyler> That would be a start, I guess. I think we'd still need a flag for if a wagon is allowed to lead a train -- players won't want every train backing up unexpectedly
16:08:40 <peter1139> Again, you can define the rules about when push-pull can be activated after it's actually working...
16:08:51 <peter1139> It does not need to be an initial focus point.
16:13:04 <peter1139> You know it will get complicated when authors want only a specific pattern of consists to be able to push-pull...
16:16:24 <andythenorth> can we have a consist that is abstracted from the consist?
16:25:33 *** HerzogDeXtEr has joined #openttd
16:26:38 <gwyd4016> Can we get more than 4 tile types for stations yet?
16:31:47 *** Smedles has joined #openttd
16:33:32 <gwyd4016> peter1139: yes, it would just be handy for something I'd like to make now
16:35:44 <andythenorth> all the magic we can do if consists are consists
16:35:52 <andythenorth> - templated replacement
16:36:24 <peter1139> No, not really that.
16:36:31 <andythenorth> what about all the lifetime profit and stuff?
16:36:42 <andythenorth> that gets copied at the moment by autoreplace?
16:49:03 <peter1139> Hmm, something is not *quite* right.
16:54:34 <andythenorth> we could have a multiplier for cost when replacing a vehicle to a variant
16:54:39 <andythenorth> simulating 'repaint'
16:58:42 <peter1138> After removing the NewGRF...
16:58:45 <peter1138> I guess it's fine 🙂
16:59:45 <_glx_> using modulo for fallback ?
17:00:12 <peter1138> Or I can just first the first one (+ axis)
17:00:37 <peter1138> (The current pushed version forgot about axis which is what is "not quite right" :))
17:00:41 <_glx_> skipping roof tile might look better
17:00:58 <goddess_ishtar> FLHerne: Why *do* all the major grfs use templating on top of NML? Is that just due to scale, or something that NML doesn't do that they want, or...?
17:04:10 <_glx_> usually you have many similar blocks for each item, so it's easier to have something to generate them, that way you only have to edit one location to apply a change everywhere
17:05:26 <peter1138> It allows you to code more efficiently without actually producing efficient code :p
17:06:28 <peter1138> First was modulo, this is simply first + axis if out of range.
17:07:28 <peter1138> Second is probably slightly better, but it does not really matter given you have to change NewGRFs to see it.
17:10:20 <gwyd4016> This is an extreme edge case and both just different ways of saying "you broke it"
17:10:27 <gwyd4016> But it seems the grf works as expected
17:12:26 <peter1138> I'm wary of the non-modulo way because it relies on axis, but this function is called for any type of station. It's only stations that have axis as the first bit.
17:21:02 *** gelignite has joined #openttd
18:25:15 *** SigHunter has joined #openttd
18:30:35 <audigex> You have to use *some* kind of templating to have a hope in hell of organising it - otherwise BRTrains would be something insane like a single 50,000 line file
18:30:35 <audigex> Many GRFs don’t do full “templating” though but rather just split things out into partial NML files for each unit
18:31:15 <goddess_ishtar> oh, I thought like a full-on preprocessing stage with python or makefiles
18:31:30 <goddess_ishtar> Instead of just pnml
18:31:50 <andythenorth> (1) NML is horrific (2) pnml is even worse (3) the 'grf' isn't adequately composable from NML
18:31:52 <goddess_ishtar> or writing python that *generates* NML or something
18:32:46 <andythenorth> unless an author is prepared to write an NML parser yourself, they can't generate docs from NML
18:32:52 <andythenorth> and without docs a project is a turkey
18:33:23 <andythenorth> and pnml is truly truly dreadful
18:33:36 <FLHerne> goddess_ishtar: that's a thing, yes
18:34:34 <audigex> goddess_ishtar: Both of those things are possible
18:34:34 <audigex> Andy’s is closer to “Python that generated HTML”
18:34:34 <audigex> Many other sets are just Python or makefile that compile the PNML into one big file to run it
18:35:11 <andythenorth> I always found the pnml route needlessly complex
18:35:15 <audigex> You’ll find sets that do both or neither. Plus there’s pygrf or grfpy (I forget which) that skips the NML stage entirely
18:35:27 <andythenorth> I remember one of the openttd devs looking at pnml years ago and saying it was ridiculously over-engineered
18:35:34 <andythenorth> varadic macros and crap
18:35:38 <andythenorth> constant def / undef
18:36:28 <gwyd4016> pnml is good and sensible
18:36:37 <audigex> andythenorth: Again, because you do everything via python generation. Although to be clear I’m just talking about partial files rather than anything you’re mentioning there
18:36:40 <gwyd4016> I like to work on 200 line files rather than 50000 line files
18:37:02 <andythenorth> FIRS was converted from nfo to pnml by the nml devs as a test project
18:37:13 <andythenorth> I then converted it to python, so I could get stuff done
18:37:28 <audigex> BRTrains is just 200 line files for each train that are compiled into the 50k line file to run through nmlc
18:37:28 <audigex> Whatever PNML you’re talking about with macros and def/undef is something else
18:37:28 <gwyd4016> I'm going to make a lua grf
18:37:38 <andythenorth> pnml is c-pre-processor
18:37:43 <audigex> Maybe it’s just using the same extension of .PNML?
18:37:58 <andythenorth> it's the coop makefile stuff, and optional generation from a csv
18:38:04 <gwyd4016> The tool used for pnml can do a lot more
18:38:25 <audigex> Then yeah different conversations slightly going on. I just use partial NML files that’s compiled together by Python and then run through NMLC as one file. Nothing else
18:38:36 <gwyd4016> This is the normal thing I feel
18:39:14 <andythenorth> write a csv to define your vehicles, escaping loads of things, and using magic characters to define behaviour, then write templates in a dreadful templating language, then assemble it
18:39:31 <andythenorth> it wasn't even a good idea in 2008, it was just a case of people reaching for nearby tools
18:40:56 <gwyd4016> How does these new station name properties work
18:43:18 <gwyd4016> D4XX text ID set as a D0XX in action 4?
18:44:04 <peter1138> Same as any other string set by a property.
18:45:49 <peter1138> Use DC00-FFFF text IDs.
18:47:05 <gwyd4016> Ah right the do what you want bit of the text IDs
18:47:51 <andythenorth> isn't there a slow mass switch to grf2py now?
19:06:53 <peter1138> It uses NML too, so I guess it's just an NML preprocessor really 😉
19:09:31 <andythenorth> I thought it wrote out grf directly? 😮
19:11:25 <goddess_ishtar> yeah when I say pnml I usually just mean seperate NML files concatenated by a simple script
19:11:37 <goddess_ishtar> the C preprocessor stuff does exist and it terrifies me
19:12:20 <goddess_ishtar> peter1138: locosage pretty sure it complies directly into .grf files from Python
19:21:34 <_glx_> gwyd4016: for station IDs 00-FF you can use C5xx and C4xx without any special property, else it's prop 1C et 1D and DCxx strings
19:22:32 <gwyd4016> Great, will DCxx strings still work for station IDs 00-FF
19:23:21 <_glx_> they do with the properties
20:07:21 *** gelignite has quit IRC (Quit: Stay safe!)
20:21:24 *** Wormnest has joined #openttd
21:19:19 *** dwfreed has joined #openttd
21:28:29 *** keikoz has quit IRC (Ping timeout: 480 seconds)
21:44:32 *** tokai|noir has joined #openttd
21:44:32 *** ChanServ sets mode: +v tokai|noir
21:46:25 *** maverickfischer has quit IRC (Server closed connection)
21:46:36 *** maverickfischer has joined #openttd
21:51:24 *** tokai has quit IRC (Ping timeout: 480 seconds)
21:56:38 <locosage> goddess_ishtar: yeah, it does grf file directly
21:57:12 <locosage> it only uses nml as a module to encode strings and sprites
21:57:29 <locosage> and sprite encoder I already have my own prepared so that can be dropped any time
21:58:28 <locosage> so only strings are still left but that can be replaced pretty easily too
21:58:32 <locosage> it's just a non-goal
21:58:48 <locosage> either way, it's definitely not an nml preprocessor
23:18:27 <wensimehrp> andythenorth: If anyone is looking for a templating tool, there's Timberwolf's Roadie
23:29:27 <peter1138> And I think it's desync-safe.
continue to next day ⏵
