IRC logs for #openttd on OFTC at 2025-05-16
⏴ go to previous day
00:08:54 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
00:12:58 *** WormnestAndroid has joined #openttd
00:49:46 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
00:53:33 *** WormnestAndroid has joined #openttd
01:40:05 *** ChanServ sets mode: +v tokai
01:42:09 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
01:42:51 *** WormnestAndroid has joined #openttd
01:43:47 *** Wormnest has joined #openttd
01:47:01 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
02:16:40 *** Wormnest has quit IRC (Quit: Leaving)
03:00:43 *** gnu_jj_ has joined #openttd
03:04:03 *** gnu_jj has quit IRC (Ping timeout: 480 seconds)
04:47:35 <DorpsGek> - Update: Translations from eints (by translators)
06:06:25 *** Flygon has quit IRC (Read error: Connection reset by peer)
08:03:40 <pickpacket> Too soon. Need more badgers
09:13:38 *** mastertrams has joined #openttd
09:13:38 <mastertrams> If I may ask a question, how easy/difficult is it to code for vanilla OpenTTD? Ignoring the fact that I'd then have to get it approved which would be an entire other kettle of fish...
09:18:35 <peter1138[d]> Probably depends how proficient you are in C++. Best way to find out is to get stuck in. We do have requirements for code style and commit style.
09:19:27 <mastertrams> Never coded in C+, but I did do a GCSE in Computer Science, so I'd probably be able to muddle my way through that...
09:20:20 <LordAro> the principles should be there then
09:20:51 <peter1138[d]> Also, nobody just "knows how to code", I learned everything I know from trying it.
09:21:40 <mastertrams> For context, I was just thinking about how this game doesn't really have any support for containerisation, despite it being the single most important logistics innovation of the second half of the 20th century... And, I'd need to flesh it out properly, but I think I've had an idea for how it could work...
09:21:43 <peter1138[d]> I'll tell you what everybody does know though.
09:21:51 <peter1138[d]> Bodger loves mash potato.
09:23:00 <peter1138[d]> Badger actually 😮
09:24:19 <mastertrams> Well, I wasn't expecting to watch something like that today... Interesting.
09:28:52 <mastertrams> Honestly, thinking about this more, the graphics will be the hardest part, as I've never done that... This is almost seeming too simple to work...
09:29:26 <reldred> Start small, find something that is seemingly controlled with an arbitrary value that you disagree with and try changing it
09:30:06 <reldred> then try wrapping a setting around it, and then getting that change merged without upsetting Literally Everyone (the other devs most importantly).
09:30:49 <reldred> changing fundamentals of how cargo moves in the game might be biting off a bit and also fall under the category of 'can't this just be done with a newgrf'
09:31:22 <reldred> you'll always piss off a certain subset of users so don't worry about that lol
09:31:31 <_zephyris> As a self-taught c++ noob, my advice is to start with bug fixes.
09:31:31 <LordAro> also "how does this improve gameplay"
09:31:38 <mastertrams> reldred: Trouble is, you've done too good a job over the last 20 years. None of the (very little) stuff I dislike about the game could even remotely be described as "small"...
09:31:57 <reldred> lol I haven't done shit 😛
09:32:24 <reldred> I've got a couple of little niche interest nuggets in jgrpp but jgr did a lot of hand holding on those
09:33:11 <reldred> But yeah, small changes and bug fixes. Learn how they run the repo.
09:33:30 <reldred> Don't just drop a 5000 line PR and no explanation and get upset when it never gets merged.
09:34:11 <reldred> or when *I* get upset that my favorite buggy patch doesn't just get yolo merged 😛
09:34:26 <mastertrams> reldred: I'll be honest, from the little consideration I've done so far, I'd be very surprised if it got to that many lines.
09:35:18 <LordAro> i'm not immediately sure how you'd represent "containerisation" within the game
09:35:22 <LordAro> beyond... transfer orders
09:36:07 <reldred> Yeah I'm not sure either beyond adding a full end to end cargo system that tracks each unit of quantity from source to sink including encapsulation inside pallets, containers, yadda yadda
09:36:30 <mastertrams> The idea I've had is to basically just create a new "container" cargo. So this new cargo would work exactly the same way as the existing cargoes, the only bit I'd need to change is the industry-station interface...
09:36:38 <reldred> also how would that work with a country like australia where we have non ISO standard pallets and containers that won't fit in the other? 😛
09:37:05 <mastertrams> reldred: A little bit of magic called: *ignorance*
09:37:19 <reldred> Yeah but these are the type of things that are gonna come up
09:37:40 <reldred> and you suddenly realise what you thought was straight forward is anything but
09:37:51 <reldred> also how would it interact with existing newgrfs etc.
09:37:59 <mastertrams> Maybe in JGR, but I'd hope the vanilla playerbase are casual enough to not care.
09:38:30 <reldred> rabbit holes get deeper and deeper
09:38:36 <mastertrams> reldred: I'm anticipating that, but given this idea is only circa 10 minutes old, it's not yet reached that stage.
09:39:51 <_jgr_> I happen to live quite close to one of the UK's main container ports, so I've thought about this a few times. Enough to see that it would be a rather big job to do properly.
09:40:12 <reldred> I do find the idea fascinating personally
09:40:26 <reldred> Especially with how networks would change around the 1950's/1960's
09:40:31 <peter1138[d]> If you just want a "container" type cargo, then NewGRF can do that. But there'd be no way to track what's in them, so you have a magical convert-anything-containerisable-to-anything-else path.
09:40:43 <reldred> But yeah, not exactly a straight forward task.
09:41:14 <reldred> star citizen had a fun time working out an entire object container system to track containers, container sizes, container contents, yadda yadda.
09:41:41 <reldred> but that's also a whole other kettle of fish in itself
09:42:03 <reldred> road vehicles get interesting, different vehicles can carry different container sizes,
09:42:10 <mastertrams> peter1138[d]: Does OpenTTD not have some sort of note/flag system?
09:44:12 <LordAro> > I'd hope the vanilla playerbase are casual enough to not care
09:46:01 <mastertrams> Most of the world uses a standard container, so all this "what if x place uses different container sizes" just appears to be deliberately making it harder for yourself... I get that we're all nerds here, but still...
09:46:59 <reldred> containers are not all the same size even talking just about ISO containers
09:47:17 <reldred> not silly australian ones
09:47:30 <_jgr_> I think it'd be fine to gloss over that detail
09:47:32 <peter1138[d]> Container size is a distraction, the meat of it is the complex bpart.
09:47:56 <peter1138[d]> Just like we gloss over the size of ships.
09:53:10 <andythenorth> vehicles in vehicles though
09:53:32 <andythenorth> programmable signals in vehicles?
09:54:33 <peter1138[d]> VinV is still an interesting idea, mainly for ferries I guess.
09:55:57 <peter1138[d]> You could perhaps combine the concepts, and make a container a new vehicletype that can be loaded onto other vehicles.
09:56:05 <peter1138[d]> But, uh, let's say not a 5 minute job.
09:56:22 <peter1138[d]> Cargodist would be a pain.
09:56:36 <reldred> come on peter you could bash it out in an afternoon
09:57:36 <peter1138[d]> I would but my coffee ran out, so I'm stuck.
09:57:55 <reldred> understandable, have a nice day
10:10:32 <peter1138[d]> Specialised container vehicles can then come in different sizes, capacities and graphics, and can be refit to any containerisable cargo type, "solving" all those niggles...
10:12:39 <xarick> iterating OrderList isn't quite as fast as I hoped
10:16:49 <_jgr_> Sure, I can take a look this evening
10:33:24 <xarick> > While only baboons enter extreme values
10:33:52 <xarick> I've always done that when I intended to just get the max value possible
10:58:46 <xarick> hmm apparently it's not orderlist that is slow
11:00:12 <xarick> ScriptVehicleList_Station behaviour changed a bit...
11:16:05 <xarick> oh snap, I think my AI is doing cache stuff on load 😦
11:16:46 <xarick> dang, got to load caches first
11:48:28 <mastertrams> If I put a link to a Google Doc in here, would that work for explaining my idea and having someone (or multiple) evaluating its viability?
12:00:43 <talltyler> That seems fine. It's always nice to read a proposal before trying to review code 🙂
12:01:17 <talltyler> I usually start GitHub discussions for my feature proposals, it's a bit less ephemeral than Discord links
12:49:56 *** brickblock19280 has joined #openttd
12:49:56 <brickblock19280> Would be nice if we could consider 1st and 2nd class pax too maybe allow creating a cargo which is a specific version of another one and which can be carried by vehicles which support the class it extends/is specific from
12:55:12 <pickpacket> passenger ships should be able to sink and only first class passengers get lifeboats
12:55:43 <pickpacket> I totally didn't understand that whole "container" discussion earlier. Was very confusing.
12:56:16 <pickpacket> a new cargo that's just "container"? Containing what? I must have misunderstood something
13:00:58 <mastertrams> pickpacket: These things, which can carry basically anything.
13:01:46 <pickpacket> mastertrams: yeah, but... what would be the point?
13:02:18 <pickpacket> could just make a train carriage that can be refitted to anything but livestock, passengers, and liquids
13:04:00 <mastertrams> It's just that it's the single most important innovation in logistics in the last 70-80 years, and unless I'm mistaken, it has no representation in the game.
13:04:50 <mastertrams> pickpacket: A train carriage cannot go on trucks or ships or planes in this game. And containers do.
13:05:01 <pickpacket> I can't see that it does, but I can't see that it matters
13:05:07 <pickpacket> cargo can be transferred
13:05:39 <pickpacket> I'm not sure it adds anything of value to the game to abstract cargo that much.
13:06:00 <pickpacket> we have "units" which can really be anything.
13:08:04 <talltyler> Adding content to vanilla OpenTTD is extremely unlikely — it's just an invitation for endless debates and arguments over balance and design choices. Would your suggestion be possible with a NewGRF that provides container wagons, like Iron Horse 3?
13:10:15 <mastertrams> talltyler: It's possible. That was part of the reason for asking here, to see if people thought it was even remotely likely.
13:13:20 *** WormnestAndroid has quit IRC (Remote host closed the connection)
13:13:36 *** WormnestAndroid has joined #openttd
13:16:54 <talltyler> The missing link for NewGRF containers, in my view, is that we have containers on trains (Iron Horse, NARS) and containers on stations (ISR), but the sprites don't match and I don't know of any road vehicle sets with containers. 🙂
13:17:19 <andythenorth> I'd rather have something more abusable than a specific implementation of ISO boxes
13:17:27 <talltyler> Somebody just needs to draw a full set of infrastructure that visually matches (Road Hog 2 plz) 😛
13:17:42 <andythenorth> if containers could contain the game cargos...but also other entities
13:17:52 <andythenorth> then we can do something like redstone
13:17:58 <andythenorth> and we get more programmable stupidity
13:18:08 <talltyler> I am terrified (and incredibly curious) to see what you'd do with container spec 😛
13:18:29 <talltyler> New levels of roleplay previously thought impossible
13:18:47 <mastertrams> *(Another part of the reason for asking here is that I don't want my idea to depend on non-vanilla vehicles, so getting in vanilla was a potential way to ensure that)*
13:19:49 <talltyler> What's the problem with non-vanilla vehicles?
13:20:53 <mastertrams> The fact that not having those NewGRFs would then render my addition completely unplayable.
13:21:31 <talltyler> I read your doc, isn't it just regular cargo that looks like containers?
13:22:10 <_glx_> I don't think vanilla vehicles will change
13:22:17 <talltyler> Transfering cargo at stations is not specific to containers, you can do that already 😄
13:23:19 <mastertrams> _glx_: Which is why I want my NewGRF to be compatible with them...
13:24:54 <talltyler> andythenorth: What other entities? Do you mean vehicles (ferries, Chunnel truck shuttle, etc.) or something else? A new type of entity?
13:25:11 <mastertrams> I guess a better way of putting it is that there are multiple different vehicle NewGRFs out there, and I don't want my idea to be unplayable just because people prefer a different GRF to the ones I like.
13:25:49 <talltyler> Most GRFs disable vanilla vehicles, so that would make your idea unplayable. 🙂
13:26:15 *** WormnestAndroid has quit IRC (Remote host closed the connection)
13:26:19 *** WormnestAndroid has joined #openttd
13:26:56 <mastertrams> Now out of curiosity, is something like FIRS playable with vanilla vehicles or not?
13:28:26 <talltyler> Yes, they won't have correct cargo sprites but all cargos can be carried (assuming FIRS is set up properly) with close-enough wagons chosen for each cargo.
13:30:57 <mastertrams> Yeah, that's the sort of thing I mean. Because my idea is to add a cargo instead of vehicles, making it compatible with vanilla vehicles guarantees (or at least makes it a straightforward job) compatibility with any NewGRF vehicle, rather than limiting players to one particular GRF.
13:32:30 <yiffgirl> cargo isn't limited to specific vehicle grfs, most of them take a huge variety
13:33:28 <yiffgirl> and if your cargo classes are set right basically all of them will, just maybe not with graphics
13:39:08 <pickpacket> mastertrams: if you set up a multiplayer server with your selection of NewGRFs everyone who connects will use the same selection. I would suggest making a vehicle NewGRF.
13:39:19 <pickpacket> yiffgirl: what are the cargo classes, again?
13:41:16 *** WormnestAndroid has quit IRC (Remote host closed the connection)
13:41:20 *** WormnestAndroid has joined #openttd
13:48:25 <talltyler> Containers should not be a cargo, as cargos cannot contain other cargos (and changing the data structure of cargo packets is not done lightly, since there's so many cargo packets in the map keeping track of them is a storage consideration).
13:49:51 <talltyler> Anyway, cargos are defined by industry sets, not by vanilla OpenTTD 😉
13:50:11 <talltyler> (besides the built-in economies, of course)
13:52:10 <_zephyris> I think the proposal actually boils down to multi-cargo transport by a single vehicle.
13:52:21 <_zephyris> (Which I think someone else said about 1st/2nd class pax)
13:52:25 <pickpacket> talltyler: that's my thinking, too. Make vehicles and stations with matching container sprites and use the appropriate cargo classes for the vehicles
13:52:28 <talltyler> There is no way to guarantee all players will use your idea, even if you were to add it to vanilla. I worked 20 hours a week for 13 months adding the ability to control calendar speed, and 90.6% of players do not use it, according to the latest survey. 😄
13:53:24 <pickpacket> talltyler: BUT! Those who *do* use it value it highly, afaiu
13:53:45 <xarick> I'd use it if it wasn't incomplete
13:54:23 <mastertrams> talltyler: No, no, I don't want to *guarantee* that everyone uses it, but I want it to be **possible** for everyone to use it.
13:55:22 <talltyler> pickpacket: I use it, and that's enough for me 🙂
13:55:45 <talltyler> As much as I like you all, I work on OpenTTD for myself 🙂
13:55:59 <pickpacket> talltyler: that's my thinking with my NewGRFs, too :) As long as you use them that's enough for me
13:56:21 <talltyler> mastertrams: It is possible for everyone to use it, they just have to use your NewGRF 😉
13:57:21 <pickpacket> 0.3% use my NewGRFs 💪
13:58:33 <pickpacket> That's more than only me!
13:58:34 <mastertrams> talltyler: As in: that's why I don't want to tie it to a specific vehicle NewGRF.
13:58:55 <pickpacket> mastertrams: is the issue here that you want everyone to use it?
14:00:26 <mastertrams> Is just wanting it to be able to work on its own, with no other NewGRFs, an issue?
14:01:16 <pickpacket> wanting it to? Nope, no problem
14:01:39 <talltyler> Your GRF + vanilla vehicles = no problem
14:01:59 <talltyler> Just make a container wagon and pull it with vanilla locos
14:02:45 <pickpacket> talltyler: is it possible to remove some of the vanilla wagons with a newgrf?
14:02:48 <talltyler> If you want it to change the behavior of other GRFs, that is...unlikely to ever work.
14:03:03 <talltyler> Yes, you can choose which vanilla features to disable
14:03:50 <talltyler> Not just vehicles, but industries, cargos, houses, and airports
14:03:57 <pickpacket> mastertrams: the first thing I wanted to do with OpenTTD was to add a beard to some of the company president faces. I had this big idea that I could do that with my pres and everyone else would see it the way I intended it to be seen
14:04:34 <talltyler> I'm still waiting for your New Face Types to make my NFT investment! 😉
14:04:54 <pickpacket> but I quickly realised that the game just isn't structured that way. Servers and clients don't send graphics between them, and I can't control which GFX package anyone else is using
14:06:18 <pickpacket> A full on Oblivion-style character appearance creator would be *awesome*. And also probably require a re-write of the whole game 😂
14:07:16 <tabytac> pickpacket: yes and?! get to it!
14:07:26 <talltyler> It would be a new GRF spec for sure, but I don't think it would be that hard. All you're doing is defining custom sprite layers and then providing sprite options for each layer.
14:07:43 <pickpacket> since the game is open source you can be 100% certain that someone would fork the client and suddenly you have players joining your server with pics of swastikas instead of faces
14:07:59 <talltyler> No, the graphics would be provided by the GRF
14:08:17 <talltyler> You would have to load a FaceTypes GRF that all players would use
14:08:36 <talltyler> Sending custom images is ripe for abuse yes, but more importantly not supported by OpenTTD 😛
14:08:55 <pickpacket> talltyler: that's what I meant when I said it would require a re-write 😂
14:09:24 <pickpacket> hold on, though. Can a client have specific GRF settings that it shares with the server and other clients?
14:09:57 <_glx_> grf are decided by servers, but client may have static grf
14:10:16 <talltyler> Your face choices are shared with other clients, thought.
14:11:23 <pickpacket> Careful now, guys... if I get too much encouragement there'll soon be a NewGRF called OnlyBeards
14:11:58 <talltyler> So even with a NewFaceTypes GRF, everyone would see your face the way you've chosen. No difference than how they see the NewGRF trains you've chosen.
14:12:32 <pickpacket> EVERYONE WILL HAVE A BEARD!
14:12:37 <talltyler> GRF spec isn't easy to work on, sadly 🙂
14:12:55 <_glx_> static grf can change how it's viewed, but not the underlying types
14:13:44 <talltyler> Right, static GRFs can only override sprites and are only seen by the person who's selected the static GRF
14:14:10 <talltyler> So you could do a static beard GRF that overrides the face sprites
14:14:27 <talltyler> But not add a new sprite layer for beards, because that doesn't exist
14:18:42 <xarick> VehiclesNearTileXY is heavy
14:20:36 <xarick> Function Name Total CPU [unit, %] Self CPU [unit, %] Module
14:20:36 <xarick> | - VehiclesNearTileXY::Iterator::SkipFalseMatches 557 (16,61%) 480 (14,31%) openttd
14:21:47 <xarick> my autoreplace shennanigans is calling GetGroupNumEngines which is kind of ... heavy, not too heavy, but...
14:36:32 <xarick> CmdBuildRailVehicle is slow
14:40:27 <xarick> how does it get to UpdateAutoReplace
14:43:01 <xarick> group_cmd stuff wasn't supposed to be slow...
14:44:30 <xarick> `std::map<EngineID, uint16_t> num_engines{}` how fast/slow is using .find on a std::map?
14:45:01 *** paperworkpencil has joined #openttd
14:45:16 <xarick> could something else than map be used?
14:45:23 *** paperworkpencil has quit IRC ()
14:57:54 <xarick> _engine_renew_pool has 2932 items... how did that came to be?
14:58:33 <xarick> I'm using the default vehicles
14:58:39 <xarick> there aren't that many engines
15:01:49 <xarick> each group defines its own replace stuff
15:03:23 *** Wormnest has joined #openttd
15:05:58 <xarick> there are 2482 groups atm
15:06:31 <xarick> I wonder if I can run out of autoreplace entries
15:06:57 <xarick> something tells me that yes
15:07:02 <xarick> but im not gonna test that now
15:13:40 <xarick> unsure it's safe to use global autoreplace
15:13:48 <peter1138[d]> talltyler: Not saying anything but, uh, well you know...
15:14:07 <peter1138[d]> xarick: Can, but doesn't have to.
15:14:51 <peter1138[d]> Also, with things like vectors/smart pointers, these days I wouldn't have used a pool for engine renew information.
15:15:03 <peter1138[d]> In fact, similar to the OrderList PR.
15:16:03 <_glx_> most limits are because IDs
15:17:17 <peter1138[d]> With the OrderList PR, there is no longer an OrderID.
15:18:03 <peter1138[d]> Which is fine, nothing actually uses an order's index except the saveload system needing it to save references.
15:21:32 <xarick> the AI can build road stops and drivethrough stops, it's not safe to use global autoreplace on road vehicles
15:21:49 <xarick> safe with default vehicles, but not with newgrfs and articulated
15:22:23 <xarick> unless I purposedly stop building non drive through road stops
15:23:41 <xarick> not sure about aircraft
15:23:57 <xarick> small plane vs large place on small/large airports
15:28:55 <pickpacket> xarick: the passengers of the Titanic disagree 😉
15:30:13 <mastertrams> Are you currently developing an AI or something? I've not understood what you've been talking about today.
15:31:13 <xarick> yes, I have an AI script
15:39:18 *** michi_cc_ has quit IRC (Ping timeout: 480 seconds)
15:46:17 *** michi_cc_ has joined #openttd
16:01:36 <xarick> dear... someone, can you make BuildRailWagon not iterate from the vehicle pool?
16:01:52 <xarick> how feasible can that be done
16:05:24 <Rubidium_> I don't think it's that hard to achieve
16:15:09 <_glx_> how would you detect the free wagon chain in the same depot ?
16:37:58 <_glx_> hmm could use VehicleOnTile maybe
16:43:01 <_glx_> no need to test `w->tile == tile` 😉
16:43:50 <xarick> what if the train is leaving depot
16:44:11 <_glx_> free wagons can't leave
16:49:10 <_glx_> if depot is flooded yes
16:55:18 <_glx_> funny you can buy new stuff and it will be destroyed 🙂
16:55:53 <_glx_> once flooded vehicles are gone the depot is removed
16:56:41 <xarick> do I need this `if (t->type != VEH_TRAIN) continue;`
16:56:56 <xarick> aircraft could be there?
16:57:57 <_glx_> yes that's needed because it lists all vehicle types
16:59:39 <_glx_> get numbers before the PR
16:59:50 <_glx_> is it really an improvement ?
17:01:09 <_glx_> still release build and TicToc() around the for
17:13:17 <peter1138[d]> Only slightly faster :p
17:13:33 <peter1138[d]> You still haven't figured out this thing call averaging yet...
17:37:38 <peter1138[d]> Are you testing the whole command or just the code that is replaced?
17:39:10 <xarick> I was testing like this
17:40:15 <peter1138[d]> Okay so the issue is you're also timing the command itself.
17:40:57 <peter1138[d]> Unfortunately as it continues if the command fails, I don't think there's a way around that.
17:48:41 <xarick> could it be because I used const Vehicle, const Train?
17:53:33 <_glx_> no, const or not should not affect
17:58:09 <xarick> master also has some extra time added from time to time
17:59:27 <xarick> I'm not enjoying these 140+ ms spikes the AI is producing though 😦
18:00:19 <xarick> probably autoreplace related, will take a look at it
18:40:34 <peter1138[d]> Bah, can't use vehicle tile hash for effect vehicles (they don't set v->tile)
18:45:00 <xarick> 100% reliability during test?
18:47:44 <xarick> oh... openttd performance
18:51:59 <DorpsGek> [OpenTTD/OpenTTD] JGRennison opened issue #14271: [Crash]: Assertion failure when displaying a set order speed limit with an unset travel time in the timetable window due to an incorrect string parameter offset in STR_TIMETABLE_TRAVEL_NOT_TIMETABLED_SPEED https://github.com/OpenTTD/OpenTTD/issues/14271
19:11:14 *** kuka_lie has joined #openttd
19:21:18 <DorpsGek> [OpenTTD/OpenTTD] glx22 commented on issue #14271: [Crash]: Assertion failure when displaying a set order speed limit with an unset travel time in the timetable window due to an incorrect string parameter offset in STR_TIMETABLE_TRAVEL_NOT_TIMETABLED_SPEED https://github.com/OpenTTD/OpenTTD/issues/14271
19:25:47 <peter1138[d]> This is one another of those... do we handle it gracefully, risking it never being reported, or let it crash, so it does get reported.
19:27:26 <peter1138[d]> > Output the one from the master string... it's always accurate.
19:41:00 <xarick> have openttd automatically send crash logs on crash
19:53:49 <peter1138[d]> Yeah but lemon puffs.
20:11:39 <xarick> how do i make emscripten happy?
20:13:20 <_glx_> "wasm-ld: error: initial memory too small, 70097392 bytes needed" that will be hard
20:14:03 <xarick> but i need performance
20:15:05 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
20:15:07 *** WormnestAndroid has joined #openttd
20:30:37 *** Flygon has quit IRC (Read error: Connection reset by peer)
20:51:33 *** nielsm has quit IRC (Remote host closed the connection)
21:49:48 *** keikoz has quit IRC (Ping timeout: 480 seconds)
22:00:14 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
22:01:50 *** nielsm has quit IRC (Ping timeout: 480 seconds)
22:27:11 *** kuka_lie has quit IRC (Remote host closed the connection)
continue to next day ⏵
