IRC logs for #openttd on OFTC at 2023-03-13
⏴ go to previous day
00:18:09 *** bryjen has quit IRC (Quit: Leaving)
01:22:37 *** SoniEx2 has quit IRC (Ping timeout: 480 seconds)
02:10:18 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
02:14:47 *** WormnestAndroid has joined #openttd
03:01:18 *** Wormnest has quit IRC (Quit: Leaving)
03:14:13 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
03:14:17 *** WormnestAndroid has joined #openttd
03:22:48 *** debdog has quit IRC (Ping timeout: 480 seconds)
04:01:59 *** HerzogDeXtEr1 has joined #openttd
04:07:32 *** HerzogDeXtEr has quit IRC (Ping timeout: 480 seconds)
06:03:07 *** keikoz has quit IRC (Ping timeout: 480 seconds)
07:35:33 *** esselfe has quit IRC (Ping timeout: 480 seconds)
08:06:00 <andythenorth> electric monks 🙂
08:57:22 *** Soccerdog has joined #openttd
09:14:23 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
09:17:26 *** WormnestAndroid has joined #openttd
09:18:51 *** esselfe has joined #openttd
10:10:26 *** WormnestAndroid has quit IRC (Remote host closed the connection)
10:56:41 <petern> Hmm, can I make VS Code understand mid-statement alignment?
11:00:06 <petern> There's a plugin but of course the standard formatter then trashes it.
11:23:29 <Xarick> VSCode has a bad Undo compared to Notepad++
11:23:58 <Xarick> or maybe AutoSave is conflicting with Undo/Redo
11:35:26 *** WormnestAndroid has joined #openttd
11:48:00 <andythenorth> petern: but is it lunch?
11:49:57 *** gelignite has joined #openttd
11:51:47 *** gelignite has quit IRC (Read error: Connection reset by peer)
11:56:12 *** gelignite has joined #openttd
13:08:15 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
13:32:02 *** WormnestAndroid has joined #openttd
13:43:58 *** D-HUND is now known as debdog
13:51:03 <andythenorth> can it run Doom?
13:53:20 <petern> Well... it runs BBC BASIC... but no.
13:53:45 <petern> It's odd, they implemented MOS style commands and it's genuine BBC BASIC... for Z80.
13:55:23 <petern> Also 8-bit CPU but 24-bit addresses.
13:59:28 <andythenorth> are the offsets correct?
13:59:54 <andythenorth> ok in lunch news, I'm having leftover lamb biryani
14:00:24 <petern> Nice, I reluctantly had left over chicken biryani on Saturday.
14:00:35 <andythenorth> were you saving it up?
14:04:39 <petern> Depot issue should be fixed, but probably with a different strategy.
14:22:34 <Eddi|zuHause> well... it would require cancelling the current reservation
14:36:45 <dP> JGR already said one solution, remove reservation, run pf, restore reservation or change path
14:37:12 <dP> another way would be to link reservation to a train, would also solve corrupt reservation issue
14:38:08 <andythenorth> have a little timeout while the driver walks to the signal post to phone the signaller
14:38:13 <andythenorth> then the signaller phones control
14:38:24 <andythenorth> then the driver gets authorisation to proceed on a new path
14:40:57 <dP> it probably also affects servicing as it has the same problem of having to undo reservation to find closest depot to service
14:41:50 <dP> hm, that makes me really wonder how servicing even works, it only looks for depots that are quite close, but when they're close there is a good chance it already pathed past them...
14:42:37 <dP> so I'd guess with a signal gap over 20 tiles it won't service at all...
14:44:30 <andythenorth> meh, it could look ahead for servicing order when getting a reservation? 😛
14:44:43 <andythenorth> I guess it would need a heuristic for time / speed though
14:44:48 <dP> with order it would work, I mean automatic servicing
14:44:58 <petern> That doesn't help the pressing-the-depot-button case.
14:50:24 <dP> hm, I seem to recall another issue that is probably related
14:50:43 <andythenorth> RVs never service, they just drive past depots? 😛
14:50:56 <andythenorth> bad andythenorth clean repro, or it doesn't happen
14:52:44 <dP> when you place a signal before a moving train it never recalculates the path, even if hundreds of tiles away
14:53:24 <dP> so it just bumps into that signal and reverses even though there is a perfectly valid path
14:53:26 <andythenorth> that's how I frequently crash trains 🙂
14:53:43 <andythenorth> if the signal is two-way PBS facing the other way
14:53:49 <andythenorth> another train can leave a depot
14:53:55 <dP> well, it won't crash them unless you remove signalss
14:54:06 <andythenorth> it's always the case of an unsignalled route with one train
14:54:14 <andythenorth> then adding the first signal to that network
14:54:25 <andythenorth> I do it almost every game
14:54:42 <dP> hm, not quite understand what you mean
14:54:52 <Xarick> I wish... I really really wish I could get vehicle lengths
14:54:55 <andythenorth> I'll try and repro
14:54:59 <Xarick> without having a vehicle
14:55:00 <dP> but I recall having some weird depot-related crashes I never managed to understand
14:55:00 <andythenorth> I usually do it by accident 😛
14:56:07 <andythenorth> shall I video it?
14:56:33 <Xarick> how does an engine doesn't have a length before it is a vehicle? how does it then become a vehicle with a length?
14:56:51 <dP> there is a length callback
14:57:08 <dP> and property, so one of those
14:57:21 <petern> Engines don't "exist" -- they are prototypes.
14:57:56 <dP> somehow that reminds me of javascript xD
15:01:02 <andythenorth> javascript doesn't exist?
15:12:18 *** Wormnest has joined #openttd
16:06:04 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
16:34:34 <audigexJon> JavaScript isn’t real, it can’t hurt you
16:34:52 <audigexJon> Chanting that is the only way I can fall asleep at night
16:35:09 <audigexJon> Save us, typescript Jesus
16:40:54 <dP> hm, I have quite a few gameplay ideas where the amount of available vehicles of each type is limited
16:41:10 <dP> wonder if that needs patching vanilla or I can do something with name callback...
16:44:07 <dP> is it possible to pass some data to the name callback? via global var or smth
16:45:17 <Brickblock1> why would you want that
16:50:07 <dP> b) delivering x cargo to industry gives you one vehicle
16:50:51 <JGR> You can already access the current snowline height variable from within a callback
16:51:51 <dP> snowline height alone doesn't have enogh bits for that though
16:52:13 <dP> also, need it to be company-specific....
16:52:35 <dP> well, I guess I can always set different snowline for each company xD
16:53:03 <dP> actually, is setting snowline even possible now
16:53:03 *** crem has quit IRC (Read error: Connection reset by peer)
16:53:10 <JGR> You can add new variables simply enough if you're doing your own client
16:54:26 <dP> if I were doing incompatible client everything would be much simpler
16:56:22 <JGR> I can't really see how any of the current global variables could be repurposed this way
16:57:02 <dP> add a few gs-controlled global vars? xDD
16:57:18 <andythenorth> what technicality do I miss? 🙂
16:57:25 <andythenorth> GS is global state, runs on the server?
16:57:31 <Brickblock1> can we do that for grf while we are at it?
16:57:32 *** gelignite has quit IRC (Read error: Connection reset by peer)
16:57:33 <andythenorth> what's the global vars needed for? 🙂
16:58:50 <JGR> If it needs to be company-specific, then a global is insufficient
16:58:57 <Rubidium> dP: it might be hacky, but there is a setting for the limit of vehicles... couldn't you inject the appropriate settings command just before the vehicle building command (and after it to reset it)?
16:59:29 <dP> it's not a problem to limit building, a problem is providing a count in the ui
16:59:43 <andythenorth> have you heard the word...about the bird?
16:59:58 <andythenorth> the all purpose, all-singing, all-dancing monorail of extensible GUI
17:00:10 <andythenorth> global or per company
17:00:18 <andythenorth> update it as often as once a month!
17:00:31 <dP> and as usual wil all-solutions it's bad for anything particular :p
17:00:48 <andythenorth> but nothing changes unless it's used 😛
17:01:14 <andythenorth> I mean...why would I even need this?
17:01:18 <dP> I'm using it for engine goals, that kinda works
17:01:39 <andythenorth> it's lolz how easy it is to get it out of state on savegame load
17:01:47 <andythenorth> I managed to duplicate many many pages
17:02:05 <andythenorth> however that could be solved with 'skilled programming'
17:06:34 *** RGBCube has joined #openttd
17:06:34 <RGBCube> Has anybody else thought of making a better dedicated server console? because i am thinking of porting the console library PaperMC uses to C++
17:07:47 <andythenorth> hmm loot boxes then
17:07:56 <andythenorth> actual payments? 😛
17:08:57 <dP> RGBCube: idk what papermc is but I have something
17:09:04 <dP> very customized to citymania infra though
17:09:20 <RGBCube> No, i mean like a console like bash, with history, AutoComplete, etc
17:09:25 <RGBCube> but that does seem nice
17:09:54 <JGR> I've got partial tab-completion implemented in the console in my branch
17:10:36 <dP> it has console tab though it's just jquery-terminal
17:10:43 <RGBCube> are you planning to implement history & navigation using arrow keys?
17:11:17 <dP> don't remember if I did that or it just comes with the terminal though
17:11:33 <RGBCube> huh, i keep writing the [B codes when i press it on 13.0
17:11:44 <RGBCube> is it available in master?
17:12:02 <dP> no, that's not even in the game, that's on the website
17:12:14 <glx[d]> arrow up is the history
17:12:38 <dP> actually, yeah, the game has history too
17:12:45 <JGR> That only works in the GUI console
17:13:28 <JGR> Headless processes don't normally behave like terminals
17:13:28 <RGBCube> i was asking about the dedicated server console - so i can work on it, right?
17:14:03 <JGR> You can run you dedicated server in some sort of terminal environment like screen or tmux or whatever if you need terminal functionality
17:17:04 <RGBCube> i am using screen, I'm talking about making the dedicated server terminal behave like a bash terminal, because currently it only accepts input and enter - no navigation or history
17:20:18 <andythenorth> dP: ever considered a hyperlink or button to open story book? 😛
17:20:40 <andythenorth> lol I just had a truly horrific idea
17:21:45 <andythenorth> in Flash, you could attach arbitrary named functions to UI components
17:22:14 <andythenorth> for the usual UI widget events (onclick, onmouseup, onhover, onchange etc)
17:22:43 <andythenorth> imagine if we could extend the UI this way 😛
17:23:31 *** ChanServ sets mode: +v tokai
17:23:53 *** Smedles_ has joined #openttd
17:23:58 <JGR> So when you mouse over a button, the whole UI jerks around for 10 seconds?
17:24:20 <JGR> It'd be like early DHTML websites all over again
17:25:02 *** gelignite has joined #openttd
17:26:55 <JGR> For anything like that to make sense you'd need to be able to run the script on the same instance as where the UI is shown
17:27:13 *** Smedles has quit IRC (Ping timeout: 480 seconds)
17:29:21 <andythenorth> JGR: an unwise use could cause that yes
17:29:30 <andythenorth> especially given the CPUs of the time
17:29:42 <andythenorth> and it was exactly like early DHTML websites
17:30:32 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
17:30:50 <andythenorth> hmm I wonder if we could limit it only to client-side things
17:30:58 <andythenorth> nah probably not useful
17:37:55 <audigexJon> Technically most websites are still DHTML, the term has just dropped out of use as JS became ubiquitous and "DHTML" became synonymous with bad early practices
17:39:47 <andythenorth> ok has anyone used GS story book buttons?
17:40:48 <Brickblock1> I don't know but I haven't seen any GS do it other than your ones
17:41:55 <JGR> The usual method for GS to user communication is pasting text into town windows
17:42:22 <andythenorth> I think I need to write book-keeping, so that the event dispatcher knows which widget was clicked, and can resolve a function appropriately
17:42:43 <andythenorth> I also want to avoid storing all the needed function params etc in the dispatcher
17:42:54 <andythenorth> so I need some kind of book-keeping table
17:43:35 <andythenorth> I shall enjoy greatly
17:44:15 <JGR> Seems like making a very spiky rod for your own back
17:44:34 <andythenorth> it's quite primitive
17:44:42 <andythenorth> but then so was nfo when I started using it
17:44:53 <andythenorth> the only way to handle a story book button click
17:45:00 <andythenorth> is to catch it in the GS main loop as an event
17:45:20 <andythenorth> then search for the widget ID, which appears to be a UUID (per company, or global, not sure yet)
17:46:10 <andythenorth> oh and the main loop with the event handler is recommended to run not more than every 5 game days
17:47:48 <glx[d]> GS event system is really not the best choice for button handling
17:48:45 <andythenorth> hmm my FIRS GS has been running with only sleep(1) in the main loop 😮
17:48:48 <andythenorth> not the 5 day delay
17:49:02 <andythenorth> this means a lot of things might be much slower than I've been testing with
17:49:27 <andythenorth> 5 days is *really* a slow update interval for game scripting
17:49:49 <JGR> Normally with event loops you are woken when an event arrives
17:50:16 <andythenorth> oh so GS main loop could run with sleep(1), and check for events on that?
17:50:17 <JGR> Having to poll at a fixed interval is not really what you want
17:50:52 <JGR> andythenorth: As in with normal event APIs you do something like sleep(until_an_event_arrives)
17:50:54 <andythenorth> does waking up the event loop require once again explaining to me what callbacks are, and why GS can't have them architecturally?
17:52:06 <andythenorth> "event driven" in GS doesn't tally with "event driven" in other UI systems I've used, where objects / widgets subscribe to events, and are notified about them
17:52:18 <andythenorth> but we discussed that to death 🙂
17:52:37 <glx[d]> it all comes from AIs where events are just an info
17:53:20 <andythenorth> I am concerned currently about my use of sleep(1) in all recent testing 😛
17:53:45 <andythenorth> as I remember it, I tested the effect of this vs. the 5 day sleep, and sleep(1) kills FFWD performance
17:53:45 <glx[d]> sleep(1) just means my tick is done
17:55:32 <andythenorth> I think an intense GS causes FPS lags, even without FFWD
17:55:41 <andythenorth> if it's consuming all available opcodes
17:55:43 * Rubidium wonders how those async events are going to hurt other processes of the script, by changing global state when iterating over something etc. So you'd want to have locking/synchronisation/mutexes of some sort
17:55:46 <glx[d]> but your tick may actually be 2 or more depending on number of opcodes
17:56:40 <glx[d]> or if you issued commands
17:57:10 <Rubidium> and synchronisation might (still) mean that the event is going to be handled months later
17:57:56 <Rubidium> with of course many many events that need to be handled at that point, so potentially quite a while from the main loop might get lost
17:58:02 <andythenorth> GS: 9 / 10 chance that you shoot yourself in the foot with it
17:58:05 <Rubidium> (due to the o codes)
17:58:06 <andythenorth> especially on larger maps
17:58:39 <JGR> There is a reason that nearly all of the actually useful GSs are just twiddling town growth values
17:58:40 <Rubidium> so, IMO you shouldn't call sleep directly but via some function that also processes the pending events
17:59:23 <andythenorth> JGR: ultimately all I'm doing most of the time is managing town growth and industry production
17:59:35 <Rubidium> in other words: "I'm done with the main work, I'm essentially ready to sleep but check for pending events first"
17:59:39 <glx[d]> and often enough in any subfunctions
18:00:14 <andythenorth> if someone implements the promises batching, I think one class of GS bottlenecks will disappear, up to the limit of OpenTTD / host performance
18:00:16 <JGR> Recursively handling events from with event handlers can lead to unpleasant surprises
18:01:19 <andythenorth> I suspect that the common case of managing towns / town window / story pages can be significantly less blocking
18:01:29 <andythenorth> silly things like walking tiles etc, maybe not so much
18:01:50 <JGR> In most cases the GS doesn't care about or check the command result at all
18:02:06 <JGR> So you could just fire and forget it
18:02:48 <glx[d]> some commands are fire and forget (like setting town stuff), some depends on the previous one (building, modifying a tile)
18:03:33 <andythenorth> it's quite hard to see how to use the more complex chaining of commands
18:03:43 <andythenorth> it's not like there's a transaction that can be undone of the full chain fails
18:04:29 <glx[d]> build bridge for instance can actually be up to 3 commands
18:04:34 <andythenorth> terraforming for an industry is a case in point
18:04:42 <andythenorth> if I wanted to modify terrain to a specific industry layout
18:04:51 <andythenorth> that seems really quite complex
18:04:55 <JGR> Do we need io_uring in GS? 😛
18:04:59 <glx[d]> because it builds the bridge then automatically tries to put road on each end
18:05:34 <andythenorth> so the command returns failed, then what?
18:06:35 <andythenorth> - clear two tiles
18:06:49 <andythenorth> command fails...restore the two tiles?
18:07:12 <andythenorth> can try it in test mode first, but can't test until the tiles are cleared
18:07:36 <andythenorth> these aren't architectural problems though, just script design challenges?
18:07:52 <andythenorth> it's almost like we need a copy of the whole map 😛
18:07:56 <andythenorth> but imagine the RAM use
18:07:59 <JGR> It should just be made a single command, instead
18:08:35 <JGR> With the new command system you can easily pass as much extra policy as you need
18:09:03 <andythenorth> ach I lack enough comp sci knowledge
18:09:32 <andythenorth> but with a transactional database, you can run a complex view method to write to multiple records
18:09:42 <andythenorth> and then if something fails, undo the whole transaction
18:09:49 <andythenorth> preserving initial state
18:09:59 <glx[d]> there's no undo in openttd
18:10:02 <andythenorth> it's slow because only one can write at a time
18:10:23 <andythenorth> it scales badly for write in certain circs
18:10:31 <glx[d]> but writes are limited to one at a time
18:10:48 <andythenorth> yes, I am not asking for this in OpenTTD 🙂
18:11:10 <andythenorth> it's quite interesting to think about shadow-copy of the map 😛
18:11:18 <andythenorth> not really going to happen
18:12:34 <JGR> You can do a certain amount of undo, backups, etc within the command handlers
18:13:28 <andythenorth> imagine the case of terraforming for an industry...let's say ECS Hotel?
18:13:49 <andythenorth> GS could get the inferred tile heights from grf, with a small amount of work, but ignore that issue
18:14:08 <andythenorth> assuming GS has an [x, y, [corner heights]] list of tiles
18:14:19 <andythenorth> what's the sequence of commands?
18:14:49 <JGR> I'd argue that this is not something that GSs should be trying to do
18:15:11 <glx[d]> raising lowering 1 tile may alter the neighbours
18:21:05 <andythenorth> JGR: yeah, I have concluded the same so far
18:21:11 <andythenorth> although I'm tempted to try to see what the problems are
18:21:41 <andythenorth> in principle OpenTTD could do this on behalf of industry grfs, the relative tile heights can be inferred or explicitly provided
18:22:59 <andythenorth> but GS is a playground for trying things 😛
18:24:42 <andythenorth> I guess if you're proficient in C++ and understand the game internals, you already have a playground 😛
18:25:41 <JGR> As far as "mod" interfaces go, I'd rather work with NewGRF
18:41:36 *** WormnestAndroid has joined #openttd
18:59:49 <FLHerne> JGR: I don't see why GS shouldn't do that, one of AI's main functions is terraforming to build infrastructure and it's pretty much the same API
19:00:03 <FLHerne> it's true that both AI and GS kind of suck at it
19:00:05 *** Flygon has quit IRC (Quit: A toaster's basically a soldering iron designed to toast bread)
19:00:31 <FLHerne> but that's an implementation problem rather than a concept one
19:05:25 <dP> yeah, map generation is very much GS domain
19:05:30 <JGR> It'd be better to do it properly as part of industry generation
19:06:06 <dP> newgrf doesn't have enough context for map generation
19:07:00 <dP> what if I need GS to build Karlstein for the intended gameplay?
19:09:01 <JGR> In the context of the current API, yes
19:10:06 <dP> int the context of api required newgrf is a worthless pile of ancient junk :p
19:12:11 <JGR> I don't see anything wrong with more declaritive interfaces at all
19:13:11 <dP> declarative is good but not when you need logic
19:13:30 <JGR> A "build industry and just do the terraforming please" command would in any case make much more sense than GSs ever so slowly trying to do the terraforming manually
19:13:54 <dP> declarative = implemented in the game instead of a mod
19:14:40 <dP> well, how about build industry in a way that any station accepting cargo is no further than x tiles from the town center?
19:15:08 <JGR> Why should the game care about that, that's the player's problem to solve 😛
19:15:38 <dP> players just file bug reports when their cargo isn't counter
19:15:50 <andythenorth> "Why should the game care about X" is an interesting class of objections for things
19:16:02 <andythenorth> it's quite a common objection to e.g. extending the existing APIs
19:16:21 <andythenorth> can also just flip it over, "Why shouldn't the game care about that?"
19:16:26 <dP> dP: this is a legit feature that works quite well on citymania btw
19:16:34 <andythenorth> assuming "the game" is somewhat content
19:16:56 <JGR> It seems like overly handholding the player to me
19:17:28 <andythenorth> my point is just to argue in favour of APIs, and not trying to pre-judge how they're used 🙂
19:17:38 <dP> there is no good way to tell the player that cargo acceptance in cb has a range limit
19:17:56 <dP> before I implemented that thing I regularly had players complaining their cargo isn't accepted
19:18:54 <andythenorth> I think it's interesting that me and dP come at this from very different perspectives (deep into grf vs. deep into patched clients)
19:19:01 <andythenorth> and we don't see eye to eye on some things
19:19:16 <andythenorth> but we seem to concur about needing the API
19:20:39 <dP> I mostly come from the "do whatever it takes to implement desired gameplay" perspective
19:20:59 <dP> well, and most of the time "desired gameplay" includes having no newgrfs xD
19:21:23 <andythenorth> I have tried doing all of "desired gameplay" in grf, and found the limits 😛
19:21:36 <andythenorth> same core issue: modifying gameplay
19:21:46 <andythenorth> which means access to core game state, loops, and entities
19:22:07 <andythenorth> JGR: took a different approach 🙂
19:22:12 <JGR> I'd rather add the core functionality to the game
19:22:32 <JGR> Declarative interfaces to configure things can be added to GRF or wherever as needed
19:23:27 <dP> and I keep recalling builtin vanilla citybuilder as adding functionality to the game :p
19:24:31 <JGR> I suppose with your own server you have all the benefits of GS without having to put up with squirrel or the bizarro execution model
19:24:51 <dP> yeah, that has a lot of benefits
19:25:06 <dP> and one big donside, c++ isn't any better 🤣
19:26:17 <JGR> You could set up FFI bindings for rust or whatever if you really wanted
19:26:43 <dP> if I were writing it from scratch now I'd probably even do wasm or smth
19:27:00 <dP> but that's a lot code to rewrite now
19:28:15 <JGR> TBH I don't really understand the attraction of wasm outside of web contexts at all, but I haven't really looked into it much
19:29:09 <andythenorth> someone put a great video about it in irc channel a few years ago
19:29:15 <andythenorth> once the compilers are in WASM....
19:29:18 <dP> same as web context, sane way to embed logic
19:29:20 <andythenorth> we have excess portability
19:29:53 <andythenorth> I thought it would be a hype video, like when java was going to be universal
19:29:58 <andythenorth> but it was quite compelling
19:37:47 *** andythenorth is now known as Guest7594
19:37:48 *** Guest7594 is now known as andythenorth[d]
19:40:41 <FLHerne> JGR: best-of-both-worlds appeal :p
19:42:21 <FLHerne> you can have a pretty secure sandboxed cross-platform runtime to meet the needs that JS/Lua/Squirrel are supposed to
19:43:13 <FLHerne> but still write the code in C/C++/Rust/whatever, using existing libraries and tooling for those languages
19:45:14 <FLHerne> presumably you've seen the thingy with OpenTTD compiled to run in a browser?
19:46:29 <FLHerne> sure, that means you can run OTTD in a browser which is neat, but it also shows that you could move any part of OTTD to being run in a wasm environment on normal clients
19:47:54 *** SosMakaroni has joined #openttd
19:47:54 <SosMakaroni> Hello! I can clearly see that in NML, the "direction" vehicles variable, does it only ask for the direction when you load the GRF? Or is it just me that has this "error"?
19:48:29 <JGR> FLHerne: That makes perfect sense for run-time pluggable libs/content
19:50:19 <FLHerne> SosMakaroni: I'm not certain I understand the question, but if you use `direction` in a callback it should be updated every time the vehicle changes direction
19:51:32 <FLHerne> somewhere on my to-do list is trying to stuff TGP into a wasm interpreter
19:51:44 <FLHerne> you can't do mapgen with GS, it's way too slow
19:51:58 <FLHerne> and the required API is pretty tiny so it would be a good test case
19:52:14 <FLHerne> and I kind of hate TGP's maps sometimes :p
19:52:55 <SosMakaroni> FLHerne: Thanks for the reply! Then the length of the vehicle cannot be changed, only in the depot.
19:53:29 <FLHerne> SosMakaroni: correct, you should never change vehicle length outside a depot
19:53:49 <FLHerne> it should display a warning if you try, I believe
19:54:09 <FLHerne> (because it can cause desyncs in multiplayer for some reason I don't understand)
19:55:10 <SosMakaroni> Then I need some new tactic for the correct east/west graphic length. 😄
19:55:21 <JGR> Even when you're not in multiplayer, it is problematic
19:55:46 <FLHerne> SosMakaroni: sadly I don't think there's any workable solution to that :-(
19:55:48 <JGR> Really you shouldn't be changing length dynamically at all
19:56:28 <FLHerne> Pikka tried rendering them proportionally but with gaps at some angles, but at least in my opinion it was uglier than the normal way
19:57:48 <SosMakaroni> Yes, I saw at several GRFs that they used a different scale for east/west.
20:00:30 <dP> yeah, that's just how the game is, it uses different projections for / \ and - | views
20:03:05 <dP> stretching the model on x and y for / \ view seems to be the best solution
20:05:14 <petern> Why are you trying to change length for west/east view?
20:06:21 <dP> because the game changes length it's a reasonable attempt to try to change it back :p
20:08:03 <SosMakaroni> I modeled it in Voxel, and due to keeping the proportions, the wagons go far from each other in the east/west direction.
20:10:01 <dP> oh, I recognize that model xD
20:11:30 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
20:12:13 <petern> 1) align it properly 2) stretch it in that view.
20:13:10 <SosMakaroni> I wanted to avoid stretching, because of the realistic proportions.
20:13:18 <petern> The standard vehicles are also "too short" in east/west views, but because it's only 1 part it's not so bad.
20:13:31 <petern> Yeah, don't use realistic proportions.
20:15:43 <dP> SosMakaroni: used it for testing my voxel stuff too xD
20:15:48 <andythenorth[d]> chibi the things
20:17:37 <dP> well, it's a different model but similar train
20:17:59 <FLHerne> Shortening it in the \/ views is probably better than stretching it in --
20:18:09 <SosMakaroni> dP: It's not the same, but from the same country 😄
20:18:09 <SosMakaroni> This is a Ganz G2 proto, yours is an Alstom M2.
20:18:20 <FLHerne> or at least it's what most sets seem to do
20:21:50 <andythenorth[d]> ok what GS thing am I doing next?
20:25:04 <SosMakaroni> Yes I see. Only in zoom it's not pretty anymore. I can see the "puffing" in the zoom sets.
20:25:04 <SosMakaroni> Thank you for your answers. And sorry for posting in the wrong topic. Good night (EU).
20:25:18 <andythenorth[d]> watching the GS performance chart...
20:25:35 <andythenorth[d]> these spikes are occasional, always the same size
20:25:56 <JGR> Garbage collection, perhaps?
20:26:36 <petern> Too busy drawing chunky pixels.
20:26:44 <andythenorth[d]> at this point, the GS is just in a loop, all it does is count ticks and poll for events
20:26:53 <andythenorth[d]> it only runs stuff once a month
20:27:31 <andythenorth[d]> actually with game paused, there are occasional spikes of 3-4ms
20:27:48 <dP> SosMakaroni: if you don't scale z axis it won't look that "puffed"
20:30:03 <andythenorth[d]> this is curious, the scale and rate jitters
20:30:19 <dP> SosMakaroni: also, are you rendering it with perspective or smth? the game is kinda orthogonal 😅
20:30:19 <andythenorth[d]> is that expected, or is the mac build weird?
20:30:23 <andythenorth[d]> oh this might be debug build
20:31:57 <dP> dP: though maybe it just looks like that because of the elevated view...
20:34:32 <petern> andythenorth[d]: how do I make a NewGRF?
20:38:34 <petern> (I'm rebasing NewGRF docks, which now has to change its feature)
20:41:04 <andythenorth[d]> or you write bytecode 😛
20:41:13 <andythenorth[d]> shall I write one for you?
20:41:15 <andythenorth[d]> what does it do?
20:41:53 <petern> I have one but I need to update it. Not sure I have the source any more 😄
20:41:59 <andythenorth[d]> 'in a branch'
20:42:09 <andythenorth[d]> have you heard of github?
20:42:14 <andythenorth[d]> it's quite new, but gaining popularity
20:44:40 <petern> Hmm, also map changes, hmm.
20:47:14 <andythenorth[d]> does OpenTTD have any loops that run mid-month?
20:47:32 <andythenorth[d]> considering offsetting some GS stuff from OnNewMonth()
20:47:42 <andythenorth[d]> to avoid chance of stuttering / running behind
20:48:23 <andythenorth[d]> is GS suspended for autosave also?
20:49:08 <petern> save and autosave are the same thing
20:49:49 <andythenorth[d]> is GS suspended for save also?
20:49:56 <andythenorth[d]> I should learn to words better
20:50:48 <andythenorth[d]> GSDishwasher.Empty()
20:58:16 *** esselfe has quit IRC (Quit: rebooting)
21:02:08 *** WormnestAndroid has joined #openttd
21:03:01 *** esselfe has joined #openttd
21:04:52 *** nielsm has quit IRC (Ping timeout: 480 seconds)
21:10:45 <andythenorth[d]> maybe I can extend IndustryControlFlags
21:12:09 <andythenorth[d]> ok game design time 😛
21:12:18 <glx[d]> everything is suspended during saving, but GS are called back for the data they want to put in save
21:12:18 <andythenorth[d]> it's more fun writing debug tools, no gameplay effect
21:13:28 <andythenorth[d]> ok so the gameplay idea is that primary industry production has a chance to increase if the town is happy
21:13:46 <andythenorth[d]> I wonder how many levels of happiness there might be
21:14:24 <andythenorth[d]> neutral | happy | very happy
21:14:42 <andythenorth[d]> or `unhappy | neutral | happy`
21:34:47 *** keikoz has quit IRC (Ping timeout: 480 seconds)
21:40:59 <andythenorth[d]> lol this idea fails
21:41:19 <andythenorth[d]> my plan was all GS would set flags for all industries in town
21:41:50 <andythenorth[d]> industry would read the flag, then if town is happy, use monthly production cb for a dice roll for production increase
21:42:05 <andythenorth[d]> but this means all industries in the town might increase at the same time
21:42:31 <andythenorth[d]> and there's no event GSEventIndustryProductionIncreased
21:42:45 <andythenorth[d]> and if there was, the latency means it will run behind the grf anyway
21:46:24 <andythenorth[d]> ok maybe the GS selects which industry
21:47:58 <andythenorth[d]> ok that means I only need one flag
21:48:32 <andythenorth[d]> lol I could set INDCTL_NO_PRODUCTION_INCREASE, but meaning the inverse
21:49:29 <andythenorth[d]> or...I could...set it for every industry, and....only unset it when the industry should increase
21:49:57 <andythenorth[d]> wow, eventually the lightbulb turns on in my brain 😛
21:52:04 <andythenorth[d]> hmm grf var 0x47 reads these flags, but grf can't set them
21:52:20 <andythenorth[d]> means I have to use GS to set the GameScript control flags
21:52:26 <andythenorth[d]> but GS will be slow to do that 😛
22:11:25 <andythenorth[d]> if I look for python True or False with isinstance(foo, bool)
22:11:35 <andythenorth[d]> do I also catch 1 and 0 unintentionally?
22:13:56 *** gelignite has quit IRC (Quit: Stay safe!)
22:30:52 <Rubidium> oh MSVC, you're the best again ;) return (y < x ? (1 + y - x) >> 1 : 0) + TILE_HEIGHT; yields "negative integral constant converted to unsigned type"
23:20:23 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
continue to next day ⏵
