IRC logs for #openttd on OFTC at 2023-12-28
โด go to previous day
00:33:40 <peter1138[d]> Way too many LOC currently ๐ฎ
00:35:35 <reldred> man this town really doesn't want me to build this freight bypass ๐
00:37:01 <reldred> peter1138[d]: Still, good work getting it to PR state ๐
00:38:17 <Eddi|zuHause> reldred: the NIMBYs are everywhere.
00:38:51 <reldred> the problem more is the amount of back yards I'm destroying entirely ๐
00:54:06 <Eddi|zuHause> "our cities will not be bulldozed for the car, they will be bulldozed for the train" :p
01:03:52 *** Extrems has joined #openttd
01:26:25 <reldred> I do need to start building highways soon, so a little of column A, a little of column B
01:42:33 *** Extrems has joined #openttd
01:56:03 *** Extrems has joined #openttd
02:58:00 <talltyler> Oof committing through GitHub.com
03:01:10 *** herms has quit IRC (Ping timeout: 480 seconds)
03:18:07 *** Wormnest has quit IRC (Quit: Leaving)
04:05:11 *** D-HUND has quit IRC (Ping timeout: 480 seconds)
05:11:26 <locosage> jfs: well, I did say it at the beginning of its development :p
05:11:40 <locosage> my only hope is that it's still possible to get rid of it completely with a server patch
07:31:00 *** ChanServ sets mode: +v tokai
07:37:56 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
07:53:05 *** keikoz has quit IRC (Ping timeout: 480 seconds)
08:22:47 <peter1138[d]> talltyler: don't worry, you'll get tons of sarky useless comments when it is done.
09:07:54 <truebrain> And there is always need for a Marvin, otherwise the story isn't complete
09:13:03 <truebrain> Stupid GitHub, folding files ..
09:13:11 <truebrain> That was confusing! ๐
09:14:03 <emperorjake> truebrain: Yep, it works
09:14:18 <emperorjake> (I was asleep by that time) ๐
09:14:30 <truebrain> emperorjake: Sweet! Tnx for testing ๐
09:14:36 <truebrain> Pff, sleep is overrated!
09:20:02 <truebrain> now I just need to add signing to the MacOS binaries ... that will be "fun" ๐
09:20:50 <andythenorth> truebrain: "Without shade there can be no light" (or something)
09:23:56 <truebrain> pff, all that hippy talk
09:24:19 <andythenorth> think it's Taoism, ying-yang
09:39:23 <andythenorth> is there any way to tell how long a train is without sending it to depot?
09:39:37 <truebrain> 1, 2, 3, 4, ... ๐
09:39:38 <andythenorth> usually I do it by cloning one in depot, then deleting it
09:40:13 <andythenorth> now I delete train 93 ๐
09:40:17 <andythenorth> it's like a ruler
10:04:55 <georgevb> andythenorth: I see so much efforts on docks and ship movement, is there a chance to fix the main problem with ships - they can't go up and down the slopes on the rivers? It would be very nice to get a new way of transportation - by ships via rivers. Even some industries could have higher probability to be build near rivers, like forest and sawmills.
10:06:17 <locosage> there is a bit of downside that no one takes rivers seriously in mp
10:06:25 <locosage> at least with locks you can somewhat see it's used
10:09:49 <locosage> but that assumes that whoever wants to cross it actually bothers to check...
10:13:14 <locosage> it kind of needs to be establish whether rivers are for eyecandy or for transportation
10:14:11 <andythenorth> georgevb: I agree, ships navigating rapids would make better gameplay, but consensus so far has been 'no'
10:15:42 <andythenorth> locosage: rivers are for lolz, and we should start from that perspective ๐
10:16:23 <emperorjake> Nah, why would you want to skip the requirement for locks? It makes sense to have to do some infrastructure upgrades to make a river navigable
10:16:45 <locosage> - maybe narrower than canals
10:16:46 <locosage> - slope is just river so no locks
10:16:48 <locosage> - can't be destroyed
10:17:33 <locosage> eyecandy can even just be auto-removable like farm fields
10:19:11 <locosage> though if rivers need no locks what do to with canals and locks in general...
10:20:45 <emperorjake> eyecandy rivers already exist in the form of objects
10:21:18 <locosage> to me that is equivalent of not existing
10:21:21 <emperorjake> perhaps the spec for randomly generated map objects could include a pathfinder to generate object-rivers?
10:22:45 <locosage> that's just piling up hacks
10:24:54 <ahyangyi> I don't think we should change the default behavior of rivers, but why can't we add extra options?
10:25:20 <ahyangyi> (and grab that "construct river" option from jgrpp too)
10:25:36 <emperorjake> Yes, that's badly needed in vanilla
10:29:55 <andythenorth> so much water talk ๐
10:53:51 <xarick> I found there's way more places in OpenTTD code that could benefit from #10548. I'm just not sure if it's too much work for too little benefit
10:54:16 <xarick> I searched for Vehicle::Iterate
10:54:37 <xarick> there's that many instances to investigate if it's worth switching to
10:55:43 <xarick> how should I undertake a change of this magnitude?
10:55:48 <xarick> what's the best approach?
11:00:23 <locosage> xarick: `Company::Get(c->index)` => `c`
11:03:55 <xarick> improvements in the code
11:11:17 <xarick> I have a big dilema to solve, before I fully commit to this
11:13:02 <locosage> Vehicle is likely faster but any mistake can crash the game
11:13:25 <locosage> though as you use Get there isn't much a difference wrt crashes
11:15:13 <locosage> VehicleID probably uses less memory though
11:15:35 <xarick> the "auto" feature is a curse... I can't exactly search the code for "VehicleID"
11:29:45 <xarick> I think I'm switching my auto's to what they really are, forgive me if that's anti-modern
11:30:10 <xarick> it at least allows me to search the entire project
11:30:11 <Rubidium> but do you really know what they really are?
11:37:58 <LordAro> i tend to agree for "basic" types
12:07:49 <xarick> so many errors after thoroughy re-reviewing my own code ๐ฎ
12:08:15 <xarick> not exactly game breaking errors, but some repetition
12:10:10 <xarick> I keep forgetting that in a for loop
12:10:33 <xarick> using stuff like Company::Get(c->index) costs time
12:36:56 <LordAro> xarick: Group::Get(g->index) can also just be replaced by g
12:37:08 <LordAro> assuming it's a Group
12:57:40 <xarick> i fail at these obvious things
13:30:50 <peter1138[d]> auto is reasonable for iterators or long templates but... yeah.
13:34:27 <xarick> I just noticed there's a Aircraft::Iterate() and a RoadVehicle::Iterate()
13:34:44 <xarick> need to check how these work
13:41:27 <xarick> oh, it still goes through the big pool of vehicles... nothing special ๐ฆ
13:43:09 <truebrain> sorry talltyler , thought the update was from after the conversation ๐
13:45:06 <talltyler> I will try to get to it this morning
13:48:05 <peter1138[d]> New setting... Bike shed level: 150%
13:54:31 <truebrain> dbg: [misc] [Social Plugin: discord/libdiscord-social.so] Failed to initialize: Discord is not running
13:54:31 <truebrain> dbg: [misc] [Social Plugin: discord-social-v1.0.12-linux-amd64/libdiscord-social.so] Another plugin for Discord is already loaded
13:54:41 <truebrain> nice ๐ That should prevent most of the horrible mistakes users can make ๐
13:56:50 <truebrain> #0 0x0000000000000000 in ?? ()
13:56:50 <truebrain> #1 0x0000000000000000 in ?? ()```
13:56:54 <truebrain> hmm ... that is ... hmmmmm
14:00:06 <Rubidium> ... less than ideal?
14:02:49 <truebrain> but a null deref should trigger a crash ... and show the backtrace who was doing that ๐
14:03:15 <jfs> shouldn't have two stack frames with return address zero, that kind of smells like stack smashing
14:03:55 <jfs> of course a single frame with zero return address is bad enough
14:04:42 <truebrain> the worst part is, I wasn't aware I made any changes that could impact anything ๐
14:14:59 <_glx_> xarick: Iterate is declared at pool level, so of course it does the same thing everywhere, just each subclass auto apply filtering
14:15:50 <truebrain> unrelated, valgrind shows `LoadFromHighScore` has a `Conditional jump or move depends on uninitialised value(s)`
14:18:13 <peter1138[d]> Yeah, highscore.cpp:156 & 157 look fishy.
14:18:32 <peter1138[d]> Oh, limits. Hmm.
14:18:50 <peter1138[d]> Well, it's not initialised, but then it shouldn't be used if it failed to be loaded. hMM.
14:18:55 <truebrain> buffer is never initialized ๐
14:19:32 <peter1138[d]> It is "initialised" by fread.
14:21:09 <truebrain> okay, so I get a pointer from dlsym .. and for some reason it has become invalid or something .. hmm
14:22:12 <truebrain> ah, object is moved .. right
14:24:39 <truebrain> this happens if you want to be fancy, I guess
14:24:47 <truebrain> you get punished! ๐
14:30:02 <truebrain> well, this is odd .. a dtor is called on an object I did not expect to be destructed yet .. eeeuuhhhh ... what is going on? ๐
14:30:43 <xarick> Can I do this, or is it unacceptable? Redefine *v to a different type?
14:30:43 <xarick> ` for (const Vehicle *v : stats.vehicle_list) {
14:30:43 <xarick> Aircraft *v = Aircraft::From(v);`
14:30:59 <xarick> wow, discord is bad at quoting *
14:31:20 <peter1138[d]> Use triple back-ticks for block quoting.
14:31:53 <peter1138[d]> But no, you can't do that.
14:32:48 <xarick> why im so bad at discord
14:33:21 <truebrain> okay, I think I am doing something silly wrong here ...
14:33:22 <truebrain> `static std::vector<SocialPresencePlugin> _plugins;`
14:33:27 <truebrain> `SocialPresencePlugin &plugin = _plugins.emplace_back(filename, basepath);`
14:33:38 <truebrain> for some reason the dtor is called on items still in the vector ..
14:35:16 <_jgr_> vector will call the destruct, construct, move, etc elements when the backing array is re-allocated
14:35:22 <talltyler> Widget text is now black by default (since #10051) so I wonder if we can get rid of most of the {BLACK} colour codes that start about 1400 strings in English.txt ๐ค
14:35:36 <truebrain> _jgr_: really? I thought it only reallocated the memory?
14:35:42 <peter1138[d]> talltyler: Yes, I just never got around to it.
14:36:09 <_jgr_> truebrain: It still has to get the elements from the old piece of memory to the new one
14:36:19 <truebrain> I assumed a memmove would do that
14:36:32 <_jgr_> Presumably your object isn't a POD
14:36:38 <talltyler> Weโd have to do some good find and replace to avoid breaking translations
14:36:53 <talltyler> Meaning weโd want to update translations too
14:37:48 <peter1138[d]> Is it enough to implement a move constructor?
14:38:15 <truebrain> I deleted the copy ctor, to be sure ๐ I defaulted the move ctor
14:38:27 <truebrain> anyway, making it unique_ptr solves the issue too
14:38:40 <truebrain> tnx _jgr_ .. did not know a vector did something more with it than just a move
14:38:40 <peter1138[d]> That'll work ๐
14:39:19 <truebrain> `auto &plugin = _plugins.emplace_back(std::make_unique<SocialPresencePlugin>(filename, basepath));`
14:39:21 <truebrain> bit lengthy now ๐
14:43:26 <truebrain> let's see how much I broke Windows
14:45:30 <truebrain> ofc I picked a name that fully collides with Windows functions ๐ Haha
14:47:15 <xarick> Why can I do this with no errors using the same v, but not this, using a?
14:48:51 <_jgr_> You can't remove the constness in an assignment like that
14:50:25 <xarick> I can't? it could with v
14:51:32 <peter1138[d]> You need `const Aircraft *`
14:51:46 <_jgr_> You can't in the first one either, your editor may not have noticed because you've shadowed another variable
14:51:56 <xarick> I need to change orders from the aircraft, can't be const Aircraft *
14:52:08 <xarick> it let me build though
14:52:17 <xarick> let me confirm the aircraft get their orders changed
14:52:56 <peter1138[d]> Then don't use `const Vehicle *v` in your for loop.
14:53:15 <peter1138[d]> (Assuming your vehicle_list is not `const Vehicle *` too.
14:54:07 <xarick> it's not really my list, it's how VehicleList was defined 15 years ago, was attempting to re-use it
14:54:41 <peter1138[d]> You can probably not use that.
14:55:12 <peter1138[d]> It's basically a left-over from when we didn't use vectors and such like.
14:56:24 <peter1138[d]> Or you can use Vehicle::Get(v->index) ๐
14:57:57 <xarick> oh, you're right, it didn't work
15:01:10 <xarick> peter1138[d]: fantastic, that did it
15:01:42 <xarick> Aircraft *v = Aircraft::From(Vehicle::Get(a->index));
15:05:36 <peter1138[d]> xarick: Of course, if you are ALWAYS using Vehicle::Get from your list, and never need the `const Vehicle *` because you always need it non-const, then you can use `std::vector<VehicleID>` instead. Or `std::vector<Vehicle *>`
15:07:25 <truebrain> one day I will make a big PR without any silly mistakes ... ๐
15:07:40 <truebrain> I am happy running CI aborts these days ๐
15:08:57 <talltyler> Okay truebrain , NOW itโs updated ๐
15:10:34 <truebrain> so now for a place in the UI .. I was thinking in Game Options, a new tab called "Socials"
15:10:52 <truebrain> would mean I need to widen the window a bit
15:11:18 <peter1138[d]> That's fine, it's only that narrow now because nothing forces it to be wider.
15:11:39 <peter1138[d]> If it's wider, than the baseset descriptions will take up less height ๐
15:11:41 <truebrain> guess I should list all the plugins detected, and their state .. and for now, I guess that is about it
15:11:51 <truebrain> or maybe a button to disable a specific plugin ..
15:12:02 <truebrain> but that requires me to write stuff in the config file ๐
15:17:24 *** greenmotivations has joined #openttd
15:17:24 <greenmotivations> 50 ะฑะฐะบัะพะฒ ะฝะฐ ััะธะผ
15:18:19 <peter1138[d]> You know your monitors are a bit shit when the bootstrap chequer pattern has a green hue...
15:19:42 <peter1138[d]> (And it's also non-uniform)
15:20:02 <peter1138[d]> Hmm, unless it is actually green...
15:20:15 <peter1138[d]> Desktop Magnifier says no ๐
15:22:38 <truebrain> there, all OSes compile again, the plugins compile .. good. Now first food, then UI stuff ... "fun" ๐
15:33:42 *** Flygon has quit IRC (Quit: A toaster's basically a soldering iron designed to toast bread)
15:53:50 <peter1138[d]> Hmm, where did palette_key.png come from...
15:54:24 <peter1138[d]> The colours in it do not match table/palettes.h
15:55:48 <georgevb> A small question about NML specification
15:55:48 <georgevb> > The life cycle of a vehicle model consists of three phases, as outlined in the following table. The length of each phase and the starting, peak, and final reliabilities are randomized for each engine when starting a new game. Also note that phase 2 (the vehicle's peak performance) is actually about 8 years shorter than the model_life parameter.
15:55:48 <georgevb> does it mean that minimal allowed value for model_life is 9 years?
15:56:53 <peter1138[d]> "peak performance" probably means "peak reliability"
15:58:11 <peter1138[d]> I guess that means it just won't really reach peak reliability if life length is short.
15:59:25 <georgevb> What would happen if I specify, for example, 1 year? When would such model disappear (when vehicles never expire is off)?
16:01:45 <georgevb> As I can see, small values for model_life work strange
16:02:10 <georgevb> Vehicles do not disapper for ages
16:02:55 <georgevb> While retire_early is set to 0
16:04:39 <georgevb> When should such vehicles (with model_life = 1) disappear?
16:04:45 *** Wormnest has joined #openttd
16:07:09 <peter1138[d]> Well 1) it's randomised 2) I'm absolutely sure you have the ability to test it.
16:10:21 <georgevb> My tests shows some values about 10-20 years, so I'm expecting there is some bug. That's why I'm asking, because I think I might have misunderstood the specification
16:15:05 <georgevb> So I set model_life to 1 and get 20 years availability in game. That is not my intention about randomisation, but may be it is intended, but not described in the specification?
16:16:26 *** gelignite has joined #openttd
16:16:32 <peter1138[d]> Values under 8 are likely to underflow.
16:16:58 <georgevb> So, minimal possible value is 9?
16:17:20 <peter1138[d]> base_life doesn't directly set how long the engine is available, it affects how long it is in phase 2 of reliability.
16:17:39 <peter1138[d]> 8 won't underflow, so I'd say the minimum is 8.
16:18:06 <peter1138[d]> It might not underflow with lower values, but you can't control that.
16:18:51 <peter1138[d]> I suppose we could clamp it to stop it underflowing.
16:19:24 <peter1138[d]> But probably some NewGRF intentially does it ๐
16:20:12 <georgevb> Should I make a bug report for this case?
16:21:20 <georgevb> So having model_life = 1 may cause 2-3 years because of randomisation, but not more
16:27:30 <peter1138[d]> Again, model_life does not directly correlate with the number of years a model will be available. Phase 1 is completely random, between 7 months and 38 months. Phase 2 can add another 15 months on top of (model_life-8) years. Phase 3 is at least 10 years, but could be 20 years and 7 months.
16:27:49 <peter1138[d]> I guess uUse retire_early if you really want a short life
16:29:34 <georgevb> What values should I specify if I want to make a model be available about a year?
16:29:51 <peter1138[d]> I suggest not bothering to introduce a vehicle that only exists for 1 year.
16:31:02 <peter1138[d]> merni: only when you try to make a 'specification' out of a game mechanic that is intended to randomize things.
16:31:59 <merni> Arguably when you're allowing people to create new vehicles they should be able to specify things as they want. But of course, 25 year old stuff :p
16:32:09 <peter1138[d]> e.g. 15 = 4 bits of random data, 38-7 = 5 of random data, and 20 - 10 is 7 bits of random data.
16:32:56 <talltyler> thereโs no way a NewGRF author would intend to underflow, I think we should absolutely clamp it
16:33:07 <peter1138[d]> It's only the realistic-railwayers that get caught up in trying to make things exist exactly as they did in real life.
16:33:42 <talltyler> Also, vehicles that only exist for one year are more viable when we slow down calendar time
16:34:08 <talltyler> (Not that I think itโs good design)
16:34:41 <xarick> disaster vehicle targeting a random train, I'm about to change the rules a bit ... it's gonna be a different type of random, still random, but not the same result as the previous random
16:35:07 <peter1138[d]> If it exists only for a year, then either nobody will use it because it must have been a terrible design, or players will just turn on never expire so they can continue with it.
16:35:41 <peter1138[d]> As long as it's not InteractiveRandom...
16:53:49 <peter1138[d]> NewGRF reliability?
16:54:34 <peter1138[d]> Static values or callbacks...
16:55:26 <xarick> it's because I have to iterate the global train group for each company, I have to iterate companies... to count number of valid targets
16:56:30 <peter1138[d]> Not sure how you'd express the 6 values required for reliability...
16:56:49 <peter1138[d]> Or just give the NewGRF full control.
16:57:29 <georgevb> georgevb: peter1138[d] my question is still valid. What values should I specify to get the behaviour similar to intended as closed as possible?
17:04:49 <_glx_> xarick: this disaster affects only real players, not AIs
17:05:40 <_glx_> and it's not very frequent (and in most case disasters are disabled)
17:15:10 <xarick> waiting for a disaster vehicle hit a road vehicle
17:15:24 <xarick> see if i get this codechange working
17:16:00 <xarick> I have to go through 100s Vehicle::Iterate... this is gonna take forever :9
17:19:24 <_glx_> I think you are going too deep
17:20:33 <xarick> I had a dream I wanted to see if there was a real gain in performance, other than just for AIs
17:21:14 <xarick> change most parts than iterate vehicles to use the cached lists
17:21:22 <_glx_> the game loops through all vehicles at least once per tick
17:22:45 <_glx_> I can understand a need to cache for AIs (because they might do silly expensive things), but for normal game loop stuff it's most likely not needed
17:26:20 <_glx_> and the cache would also be used for group related accesses in openttd, but it's probably not needed to use it everywhere
17:35:31 <xarick> size() is correct for vector lists?
17:36:28 <_glx_> I think in this case it's faster to use RoadVehicles::Iterate() and filter out AI companies
17:37:01 <xarick> no this one actually targets whoever's company
17:37:17 <_glx_> ah right it's non destructive
17:37:40 <xarick> it destroys the road vehicle
17:38:13 <_glx_> oh I hope AIs handle that ๐
17:39:11 <_glx_> but yeah the rail destruction for bug UFO is way harder from AI POV, that's why they are not targetted
17:41:39 <xarick> IsFrontEngine, I see it's not needed, I can ommit this check. The vehicles are only added to the cache if they pass IsPrimaryVehicle
17:41:55 <xarick> which is another alias for IsFrontEngine
17:42:06 <xarick> at least for road and trains
17:43:02 <_glx_> for me the cache should store VehicleID only, as what matters for ScriptVehicleList
17:44:01 <xarick> I was thinking dropping the const, but still use Vehicle *
17:44:08 <xarick> it would simplify the code so much
17:44:29 <_glx_> but you would just duplicate the pool
17:45:30 <_glx_> they would just be pointers, so not that much
17:49:18 <_glx_> the const here is because you really don't want the data to be modified
17:50:15 <peter1138[d]> The pool itself is just pointers ๐
17:51:26 <_glx_> and a cache is usually only to get faster read so const is expected
17:52:14 <_glx_> if you want to modify the object you don't do it via the cache
18:05:12 <xarick> wow, this one is a tough one, change ownership of company
18:06:28 <locosage> _glx_: that's nonsense, caches/indexes are done to improve performance, const or not
18:06:35 <locosage> if cache duplicates pool drop pool
18:07:20 <peter1138[d]> If cache duplicates pool, drop cache.
18:08:42 <locosage> there is no use for a pool with inadequate performance
18:08:48 <locosage> call cache the new pool if you want
18:09:40 <_jgr_> Pools don't have any particular performance issues with lookups
18:10:16 <locosage> well, lookup clearly isn't the only operation needed here
18:11:11 <_glx_> the main issue here is ScriptVehicleList generation, not the pools performance
18:15:09 <peter1138[d]> Yeah, it's the act of having to make a list, instead of just filtering as you go.
18:27:00 <xarick> '+=': conversion from 'size_t' to 'uint', possible loss of data ๐
18:28:04 <xarick> n += (uint)stats.vehicle_list.size(); will this fix it?
18:33:56 <peter1138[d]> `e->age = (aging_date - e->intro_date).base() >> 5;`
18:34:26 <peter1138[d]> That `>> 5` looks like `/ 32` , and a suspiciously wrong way to convert days to months...
18:34:54 <peter1138[d]> Hmm. Maybe one of talltyler's changes tackles that.
18:35:15 <xarick> wow, security bot found a serious issue...
18:35:22 <xarick> there are two v's there
18:36:00 <talltyler> peter1138[d]: I no longer touch vehicle age, that stays calendar
18:36:14 <peter1138[d]> Makes sense, but /32 doesn't ๐
18:36:40 <peter1138[d]> I wonder if it's noticable though.
18:37:57 <talltyler> I used to touch aging code before you explained why it should stay calendarโฆ itโs a strange place
18:38:37 <DorpsGek> - Update: Translations from eints (by translators)
18:40:12 <peter1138[d]> Trying to work out why these engines are permanently present ๐
18:42:08 <Rubidium> isn't `aging_date - e->intro_date` promoted to an int, and then becomes slight negative? After which bit shifting makes it about 2**27?
18:42:28 <xarick> I'm unsure about the IsEngineCountable part
18:42:43 <xarick> will this count wagons?
18:44:29 <peter1138[d]> Oh, it's by design... `_year_engine_aging_stops`
18:45:38 <talltyler> Classic โintended behaviorโ
18:45:46 <xarick> let's try build a wagon and see what IsEngineCountable tell
18:46:47 <peter1138[d]> Rubidium, they're int anyway, no promotion.
18:47:00 <peter1138[d]> Technically bit-shifting signed integers is wrong.
18:47:36 <talltyler> Right, does it shift the signed bit?
18:47:36 <xarick> yep, it counts wagons... ๐
18:47:42 <peter1138[d]> I think it's okay if the value is positive.
18:47:58 <talltyler> Because the unsigned bit is off ๐
18:48:18 <peter1138[d]> But this `>> 5` might just be represented as `/ 32` or...
18:48:23 <talltyler> But if itโs safe to shift because itโs always positive, it should just be unsigned ๐
18:48:31 <peter1138[d]> Do we have a better way of getting months from two absolute dates?
18:48:42 <peter1138[d]> unsigned is dangerous ๐
18:49:24 <talltyler> Getting months from the difference between two dates?
18:50:38 <peter1138[d]> Getting months between two dates.
18:51:16 <peter1138[d]> There's no particular need to get the difference first, here.
18:51:32 <peter1138[d]> I figured you'd know about it ๐
18:51:53 <talltyler> I donโt know of a simple way
18:52:26 <talltyler> Oh, maybe converting it to YMD first would be helpful
18:52:44 <peter1138[d]> Yeah, that's just where I was heading ๐
18:53:58 <xarick> v->InvalidateNewGRFCache(); is this for any kind of vehicle, or just primary vehicles? I keep seeing this
18:54:38 <peter1138[d]> v->InvalidateNewGRFCacheOfChain() is the call for the head vehicle.
18:55:20 <xarick> oh, sheesh, can't give the group list treatment then
18:56:48 <Rubidium> I'd almost use std::chrono to get the number of months ;)
18:58:20 <jfs> std::chrono doesn't have any calendar functionality afaik
19:05:15 <peter1138[d]> Seems to be a fairly big difference...
19:06:40 <peter1138[d]> As they are all January, easy to check too...
19:07:10 <peter1138[d]> `>> 5` seems to be wrong by quite a lot.
19:10:11 <peter1138[d]> I think it means if you start a game in the year 2000, the engines will stay around longer than if you started in 1950...
19:10:40 <jfs> Rubidium: you can't convert a number of days to a number of months without having a base date at one or the other end, since months differ in length. I would not call that calendar aware at all. besides, OpenTTD is not really implementing a real-world calendar, but rather the game time calendar that was present in Transport Tycoon (which just happens to be very similar to the gregorian)
19:11:05 <peter1138[d]> We already have our own calendar functions, I'm not making new ones.
19:39:20 <peter1138[d]> (Can probably take those static_asserts() out, I wanted to make sure some environment didn't come up with different values.)
20:04:37 <jfs> or at least that is my intention when I wrote that comment
20:05:41 <peter1138[d]> Should I write as percentage points?
20:06:18 <peter1138[d]> (25% on top of 25% is 31.25%)
20:07:03 <jfs> supposedly %pt. or pp are more common abbreviations
20:13:02 <xarick> how does the setting elrail works when combined with NewGRFs tracks and engines?
20:13:22 <xarick> enable the "disable electric rails"
20:13:53 <peter1138[d]> Only with the default electrified rails, I believe.
20:14:22 <peter1138[d]> It is mostly a compatibility setting, for loading older games before elrail existed.
20:15:22 <peter1138[d]> "Disable electric rails" should probably be removed from the settings window.
20:15:48 <peter1138[d]> (Given there are other more useful settings that are already hidden...)
20:16:29 <peter1138[d]> Of course that'll probably ruin somebody's specific way of playing the game...
20:16:43 <jfs> yeah it would more be a setting for OpenGFX+ Trains nowadays
20:17:13 <jfs> except that it's required to be compatible with loaded TTD savegames where electrified rail does not exist
20:18:31 <_glx_> or when they do they replace monorail or maglev
20:19:03 <_glx_> but that would be a TTDp save
20:21:17 <jfs> I don't remember if we even load ttdpatch saves? I don't think it stores the active settings in the savegame so it's not quite knowable what features are needed/used
20:22:44 <_glx_> I think we try to load them, but they use newgrf from the config, like very old OTTD saves
20:37:17 *** gelignite has quit IRC (Quit: Stay safe!)
21:15:17 <xarick> well, there were gains, but....
21:15:58 <xarick> pretty sure this workaround is nulling any advantage Train *t = Train::From(Vehicle::Get(v->index));
21:17:35 <_jgr_> Probably not, but you may find it useful to do some reading on const_cast
21:26:23 <xarick> I tried Train *t = Train::From(const_cast<Vehicle *>(v));
21:26:55 <xarick> not much of a difference
21:27:30 <xarick> btw, the *'s are there, but discord eats them and casts itallic
21:33:12 <xarick> I still remember the goal for AirportGetNearestTown which was to improve AIs looking for places for an airport
21:33:36 <xarick> I wanted to keep it lean, but now there's asserts ๐ฆ more code
21:34:32 <_glx_> I would not look too much into the cost of a setting callback, especially when it's a setting you won't change multiple times during a single game
21:35:33 <peter1138[d]> xarick: asserts are removed in releases.
21:36:40 <_glx_> oh and when comparing performance I hope you use release builds
21:36:43 <xarick> maybe the iterator clone might make up for it
21:37:22 <peter1138[d]> Those assert don't exist in releases, so there's nothing to "make up"
21:38:08 <xarick> how do I disable asserts?
21:39:03 <_glx_> if you did all your tests with debug build they are useless
21:39:28 <xarick> nop, it was release build, but they still have asserts
21:39:41 <peter1138[d]> Note I said releases, not release build ๐
21:40:48 <peter1138[d]> OPTION_USE_ASSERTS ON
21:41:20 <_glx_> stable releases yes, you can add `-DOPTION_USE_ASSERTS=OFF` to your cmake config
21:41:48 <peter1138[d]> Of course if you disable asserts, your code will probably break in horrible ways :p
21:42:24 <xarick> there should be a dropdown there with a choice for no asserts
21:43:06 <_glx_> you can add more config than MSVC provides by default
21:43:54 <_glx_> I don't have a "no assert" one ๐
21:44:05 <peter1138[d]> There is no 'no assert' variant.
21:44:56 <peter1138[d]> Those are the things VS Code gives. Dunno why MSVC thinks you want to build for x86 and x64...
21:44:58 <_glx_> yeah that's the 4 cmake options
21:45:17 <xarick> I don't have more than 1 option for the Release variants
21:45:33 <_glx_> I have a customised CMakePresets.json
21:47:24 <_glx_> the presets also has WSL
21:47:51 <_glx_> for grfcodec I added more options for linux
21:48:22 <_glx_> well just a clang option
21:48:59 <xarick> how do I make it list Debug, Release, MinSizeRel, RelWithDebInfo?
21:49:27 <_glx_> you really only need Debug and RelWithDebInfo
21:50:07 <xarick> did you manually input those in? I thought it was a preset, loaded from somewhere
21:50:16 <_glx_> but you can add config via "manage configurations..."
21:50:46 <_glx_> I added stuff to the basic preset file
21:53:06 <talltyler> Oh yay, more conflicts ๐
21:53:34 <talltyler> Jk, the YMD improvement is good ๐
21:54:07 <_glx_> learn how to use the tools ๐
22:20:50 <_glx_> you can't have more than 1 configurationType in open folder mode
22:21:48 <reldred> Are there any chicken scratchings anywhere about setting up VS Code to build OpenTTD? I've never had too many problems getting VS2022 to build but VS Code gives me the shits (but it's what I use for pretty much everything else...)
22:25:14 <xarick> I disable asserts, but it keeps enabling them on refresh
22:26:15 <_glx_> reldred: I think the first step is to install "cmake tools" extension
22:27:28 <reldred> _glx_: Yeah I installed the cmake and cmake tools extension plugins, over on VS2022 I'd just throw in my additional command line arg to load the VCPKG stuff but it never seems to work in vs code
22:30:31 <xarick> this doesn't save my changes for some reason
22:31:50 <_glx_> I just tested opening my folder in vscode, then I selected one of my usual presets for configure
22:32:17 <_glx_> that's where you set vcpkg stuff
22:34:21 <_glx_> xarick: then open the json directly
22:34:40 <_glx_> it's simpler to edit the file than using the GUI
22:35:33 <_glx_> and btw the method you are using is being deprecated and replaced by presets
22:35:50 *** keikoz has quit IRC (Ping timeout: 480 seconds)
22:36:48 *** rau117 has quit IRC (Quit: User went offline on Discord a while ago)
22:39:27 <truebrain> oops @ thread issues .. I should have checked that ๐ Seems some locking is in order ... ๐
22:39:58 <peter1138[d]> Or a message buffer.
22:40:15 <truebrain> a thread-safe queue you mean?
22:40:17 <_glx_> hmm could that explain the hangs ?
22:41:24 <xarick> too noob for this vscode stuff
22:41:55 <_glx_> I didn't say to switch to vscode
22:42:10 <xarick> how do I do whatever the heck the notification says?
22:44:20 <_glx_> VS does a lot of things automatically compared to VSCode
22:48:18 <reldred> _glx_: Thanks. Might ping you later today/tomorrow when Iโm back at my windows PC, Iโm infront of a Mac atm for the next eight hours..
22:52:17 <truebrain> yeah, okay, OnReceiveData is always called from the ottd:http thread ... that gives a bit nasty side-effects ๐
22:53:10 <truebrain> so indeed, a queue between there, and it should be fine ๐
22:53:55 <truebrain> and `isCancelled` needs to be an atomic boolean, I guess ๐
22:54:19 <truebrain> pretty likely this is also an issue on Windows ๐
23:01:41 <xarick> ah, OPTION_USE_ASSERTS is a string, not a bool
23:01:59 <xarick> "OFF", "ON", this is detected incorrectly
23:02:19 <xarick> it's not true or false, it's "OFF", "ON"
23:03:41 <xarick> how do I make sure this really built with disabled asserts?
23:04:36 <xarick> hmm let's try assert(false); somewhere
23:05:58 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
23:06:13 <xarick> yeah! it works! it's not asserting!
23:14:29 <xarick> interesting, the gains enlarged
23:16:24 <_glx_> yeah asserts slow things
23:18:03 <xarick> the first image: Train *t = Train::From(const_cast<Vehicle *>(v));
23:18:03 <xarick> the third image: Train *t = Train::From(Vehicle::Get(v->index));
23:19:32 <_glx_> Get needs to ask the pool, while the cast just change the pointer type
23:21:40 *** nielsm has quit IRC (Ping timeout: 480 seconds)
23:22:12 <peter1138> const_cast should be avoided.
23:24:18 <xarick> okay... I was about to use const_cast everywhere
23:25:33 <_jgr_> Using Vehicle::Get to obfuscate the fact that it's really a const_cast is not something to do for the sake of it either
23:26:33 <peter1138[d]> Just make your list items non-const if it needs to be non-const.
23:26:46 <peter1138[d]> You are then not pretending it is something it is not.
23:27:53 <xarick> oh, I'll try that tomorrow
23:40:51 <xarick> oops, the include was supposed to be removed
23:47:16 <xarick> bed time, cyas goodnight
continue to next day โต
