←2022-08-01 2022-08-02 2022-08-03→ ↑2022 ↑all
00:12:31 <esolangs> [[Ajsone]] https://esolangs.org/w/index.php?diff=101571&oldid=44280 * Esolanger12345 * (+23)
00:16:24 -!- sprocket has changed nick to sprock.
02:07:34 <esolangs> [[G arD^EN CorUtY@rD]] M https://esolangs.org/w/index.php?diff=101572&oldid=101492 * PythonshellDebugwindow * (-1) Remove extra line
02:16:10 -!- impomatic has joined.
02:20:17 -!- impomatic has quit (Client Quit).
02:20:37 -!- impomatic has joined.
02:35:46 -!- impomatic has quit (Quit: impomatic).
02:36:05 -!- impomatic has joined.
02:40:19 -!- impomatic has quit (Client Quit).
02:40:39 -!- impomatic has joined.
04:20:51 -!- impomatic has quit (Ping timeout: 268 seconds).
05:07:50 -!- SGautam has joined.
06:16:37 <esolangs> [[Special:Log/newusers]] create * AntThrowPology * New user account
06:22:34 <esolangs> [[Esolang:Introduce yourself]] https://esolangs.org/w/index.php?diff=101573&oldid=101446 * AntThrowPology * (+243) /* Introductions */
06:57:56 -!- tromp has joined.
07:40:27 -!- user3456 has quit (Ping timeout: 245 seconds).
07:45:31 -!- user3456 has joined.
07:48:26 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
07:53:54 -!- Sgeo has quit (Read error: Connection reset by peer).
08:49:47 -!- wib_jonas has joined.
08:57:20 <wib_jonas> int-e: re https://logs.esolangs.org/libera-esolangs/2022-07.html#lkEb about shapez.io, I decided eventually to not use the same mine for more than one different output. When I did, then to keep up the balance between the two without the machine getting clogged. To solve this, either I have to vent both of the outputs to trash (at lower priority)
08:57:20 <wib_jonas> which means that even when neither output is used to full capacity, the machine will produce at full capacity, which makes debugging harder and I suspect might waste computation time; or I need some stupid two-tank stateful wire thingy to trash only as many shapes as there's excess of use of the other shape, of which I did make a proof of concept
08:57:21 <wib_jonas> but it's kind of silly.
09:08:26 <wib_jonas> "<zzo38> I had started to write a change file for patching SQLite to not use Unicode" => all the parts that use unicode are already optional. there's a statement hidden in https://sqlite.org/invalidutf.html that if you never cause sqlite to convert strings to utf-16 (such as with the sqlite3_value_text16 or sqlite3_result_text16 functions, or
09:08:27 <wib_jonas> PRAGMA encoding, or substr SQL function) then all its operations work on any byte strings.
09:10:39 <wib_jonas> I also don't think it causes SQLite to run slower, except from minor effects from the code having some parts that you don't use, but there's almost always large parts of the SQLite code that you don't use in your program regardless.
09:13:12 -!- tromp has joined.
09:13:14 <wib_jonas> "<zzo38> Does any UNIX shell have a command to create a unnamed temporary file and then returns the file path in /proc to that file" => no, because /proc isn't even a Unix thing, it was invented by Linux specifically. but it wouldn't be hard to write this yourself in C.
09:14:31 <wib_jonas> "<companion_cube> Can you even have nameless files on Linux?" => yes, you could always create a file and unlink it and handle it that way. these days you can even create files unnamed. there are filesystem limitations, in particular "unnamed" files on NTFS will have a name.
09:47:21 -!- SGautam has quit (Quit: Connection closed for inactivity).
09:55:54 -!- __monty__ has joined.
10:05:29 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
10:09:08 -!- tromp has joined.
10:14:06 <wib_jonas> https://xkcd.com/2653/ => I'm disappointed that this has no goat parts
11:21:00 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
11:26:58 -!- tromp has joined.
11:48:17 -!- wib_jonas has quit (Quit: Client closed).
12:02:26 -!- wib_jonas has joined.
12:22:50 <int-e> /lastlog int-e 2
12:26:01 <wib_jonas> @type second
12:26:03 <lambdabot> Arrow a => a b c -> a (d, b) (d, c)
12:26:06 <wib_jonas> no
12:26:08 <int-e> wib_jonas: I have output overflow buffers to compensate for uneven loads... but still, this harvester isn't worth it; the shapes are far too unevenly distributed for that (circles seem to be so abundant that you can find *pure* circles far out, while the windmill shape is hard to find even in quarters. Rectangles and stars seem to be frequently available in halfs.
12:26:08 <wib_jonas> @type snd
12:26:10 <lambdabot> (a, b) -> b
12:26:51 <int-e> (overflow buffers: see the storage thingies to the right in https://int-e.eu/~bf3/tmp/shapez-monster-v2.png )
12:27:45 <int-e> Anyway, I'm going to use single-shape harvesters as well. Ressources are plentiful in the game and wasting them saves significant space.
12:37:17 -!- wib_jonas3 has joined.
12:37:58 <wib_jonas3> int-e: yes, that's the former solution, you're always running that machine even if much less is consumed than it can produce\
12:38:31 <wib_jonas3> I made a working solution that avoids that for two outputs, but never tried more than two outputs
12:38:36 <wib_jonas3> why would I even want more than two outputs?
12:38:55 -!- b_jonas has quit (Killed (NickServ (GHOST command used by wib_jonas3!~wib_jonas@business-37-191-60-209.business.broadband.hu))).
12:38:59 -!- wib_jonas3 has changed nick to b_jonas.
12:39:26 -!- wib_jonas has quit (Ping timeout: 252 seconds).
12:40:42 -!- b_jonas has changed nick to wib_jonas.
12:40:53 <wib_jonas> oops, I ghosted the wrong thing
12:40:55 <wib_jonas> anyway
12:45:05 <wib_jonas> I think at one point I even made a stupid design for the rocket where I had two submachines that gave two outputs each and consumed one output of the other, which also locks up super easily. but I'm not sure of the details.
13:17:46 -!- impomatic has joined.
13:22:45 -!- SGautam has joined.
13:26:23 -!- impomatic has quit (Quit: impomatic).
13:26:44 -!- impomatic has joined.
13:29:00 <int-e> wib_jonas: Hmm. I have a slice factory, but how do I copy it... do I really need to copy the layers separately...
13:52:01 <wib_jonas> int-e: if you mean the belt/machine layer and the wire/gate layer then yes
13:52:12 <int-e> yeah that's what I meant
13:52:28 <wib_jonas> yeah, that's a FAQ, it probably won't be changed in shapez.io 1
13:53:40 <int-e> this is a bit annoying... copying is kind of okay actually, but moving things is destructive when the layers collide. As I'm sure you know... I'm just discovering this.
13:55:16 <int-e> "two submachines that gave two outputs each and consumed one output of the other" ... that does sound insane. How do you even get that started?
13:56:09 <int-e> I have one or two large factories where I had to drain some internal lines to get things up to speed. No huge lockups yet.
13:56:49 <int-e> (I mean, no huge lockups from machines that I thought were running smoothly... obviously all sorts of things go wrong while editing)
13:57:33 -!- __monty__ has quit (Quit: leaving).
13:59:06 <int-e> Other things I wish I could do... get rid of all the garbage stored in the hub.
13:59:50 <int-e> (selectively)
14:04:26 <wib_jonas> I think it's actually a good feature, even if it doesn't seem like that at first.. Having to copy both layers is a very small inconvenience. If copy+paste or delete acted on both layers, then I could edit a part of the factory that's completely in the belt layer, and wouldn't even notice that I broke an unrelated wire that happens to cross through
14:04:27 <wib_jonas> that between other sections, since the wires are completely invisible when I do this.
14:05:07 <int-e> Sure, it has to be a deliberate choice
14:05:22 <int-e> and I guess we've run out of modifiers already
14:05:43 <int-e> shift, ctrl, alt, what is this, emacs?
14:07:22 <wib_jonas> int-e: as for the two co-dependent submachines, dunno, I can try to reconstruct why that happened later
14:08:36 <wib_jonas> int-e: so are you trying to solve freeplay levels yet? and which section of freeplay levels (there are between two to seven sections depending on how you count)?
14:09:17 <int-e> I haven't even done the first freeplay level. Though I'm about ready for that, I think.
14:09:44 <wib_jonas> have you solved all non-freeplay levels?
14:09:55 <int-e> Yes.
14:10:53 <int-e> Also got everything to tier 15? Factor 8.9. But that's just because designing an automated factory takes so long.
14:11:32 <wib_jonas> sure, that's how "not idle game" usually works, there's always something else to do while you wait for something. that's definitely a feature.
14:12:41 <wib_jonas> mind you, shapez.io gets this partly wrong because it only tells you about one level shape at a time, you don't see the next ones so you can't start building for the next one while you're waiting for a slow machine of the previous one
14:13:19 <wib_jonas> this is especially annoying in freeplay, which you could play much faster if the hub gave you the next shape
14:15:51 <wib_jonas> it helps a bit that there are two hard puzzles to solve for upgrades while you are solving the last non-freeplay levels
14:16:42 <wib_jonas> but even so, other games often do it better, always giving you several goals that you know of so you can think ahead
14:18:24 <int-e> I actually worked a bit on reducing the factory's latency on switchovers.
14:19:19 <int-e> Oh well. I'll probably say something when the pieces come together.
14:19:24 <wib_jonas> and it's not just about the waiting, there are intermediate shapes that I want to build a bigger factory of immediately because I know it's needed for another level or upgrade, most importantly I want more of the tier 5 stacking upgrade shape because the tier 6 shape needs it
14:19:53 <wib_jonas> also the tier 5 and 6 painting shapes
14:20:24 <wib_jonas> in fact, all four pairs of tier 5 and 6 shapes are like this
14:21:03 <int-e> oh you mean the thing where the next tier just adds another layer of the same kind on top
14:22:07 <wib_jonas> the painting upgrade does that; the other three upgrades add another layer but not of the same kind
14:30:28 <int-e> https://int-e.eu/~bf3/tmp/shapez-foo.png ...fun little corner case (it does what I thought it would)
14:35:59 <sknebel> has anyone turned shapez into an esolang already?
14:38:05 <int-e> Like, if you allow infinite towers, can you do arbitrary computations without the wire layer? :P
14:45:42 <int-e> wib_jonas: I watched this yesterday, https://www.youtube.com/watch?v=-3CroGG9wKE ...clearly having a list of shapes in advance is very helpful (and there's some pretty clever planning in there when it comes to reusing machinery. not that I really followed what those modificationss did exactly)
14:46:51 -!- impomatic has quit (Quit: impomatic).
14:47:02 <int-e> I like how the last 18 minutes is just "waiting for rockets".
14:49:42 <wib_jonas> int-e: as for fun little corner cases, did you know that (a) the mixer can mix pigments redundantly, with both inputs being dark on one channel, (b) the hub doesn't accept pigments, so belts to the hub can be blocked just like belts to most machines?
14:51:04 <int-e> wib_jonas: (a) yes, but why would I waste paint like that? (b) you mentioned that the other day.
14:51:27 <int-e> I found out about the "B" key yesterday. That's so much better than cutting and repasting.
14:51:37 <int-e> (And it should work on the hub. I hope.)
14:51:43 -!- impomatic has joined.
14:51:57 <int-e> (This is when you have a selection; "B" clears selected belts)
14:52:33 <wib_jonas> there are also some more usable tricks that you might be spoiled on by now
14:53:31 <wib_jonas> almost certainly if you watched a speedrun
14:54:16 <int-e> Yeah, I saw a few cute editing tricks. But I don't care too much about fast editing.
14:54:49 <int-e> I've glimpsed at some machines that look quite compact, but I didn't actually try to work them out.
14:54:57 <wib_jonas> I don't mean editing, I mean that unintended thing on how to reduce latency on long belts
14:55:37 <int-e> Ah.
14:56:00 <int-e> Yeah, that was in the 16 minutes speedrun to blueprints... that was funny.
14:56:11 <int-e> I might use it later. Maybe.
14:57:31 <wib_jonas> and also for how to get more than 16 belts' worth speed of shapes into the hub
14:58:47 <wib_jonas> wait, 16 minutes to blueprints? that can't be the same thing, you don't unlock the latency reduction until later
14:59:36 <int-e> https://www.youtube.com/watch?v=AGLpoVbm4JY
15:00:31 <wib_jonas> int-e: can you give a timestamp?
15:00:34 <int-e> The player mentions the lower latency in passing.
15:00:53 <wib_jonas> oh, so it's just in the dialog
15:01:16 <wib_jonas> (the latency test at https://i.stack.imgur.com/ITv1a.png gives away the secret)
15:02:18 <int-e> I'm pretty sure he mentioned that just making a highway of those merger/splitters would make things arrive a bit faster. But I may have forgotten about a caveat, I wasn't paying close attention.
15:03:50 <wib_jonas> no it wouldn't
15:04:07 <wib_jonas> mergers or splitters would be slower or have the same latency at best case
15:04:30 <wib_jonas> balancers can help increase the *throughput* to the hub, if you place them properly
15:04:41 <wib_jonas> it doesn't help with the latency of a highway
15:05:21 <int-e> Anyway, I'll worry about these things later, or possibly never.
15:05:27 <wib_jonas> and AFAIU using balancers is the only way to get more than four belt speed's worth into the hub
15:05:47 <wib_jonas> I never used that accidental feature by the way, only the latency reduction
15:05:55 <wib_jonas> ... yet?
15:06:13 <int-e> I meant the balancer, I'm just thinking of it as a combined merger and splitter.
15:06:58 <wib_jonas> yes, and a balancer can't help you reduce latency of a long distance highway compared to a long straight belt
15:07:51 <wib_jonas> unless there's some FPS-dependent phenomenon that I haven't seen that is
15:10:08 <int-e> well, you're wrong.
15:13:10 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
15:20:18 <int-e> wib_jonas: I just started with https://int-e.eu/~bf3/tmp/balancer-1.png triggered by pasting in 4 belt pieces (so they start simultaneously), and arrival ~140 blocks further to the right looked like this: https://int-e.eu/~bf3/tmp/balancer-2.png. That's with a speedup of 8.9 for everything, maybe that matters (rounding? I have not looked at any code.)
15:23:00 <wib_jonas> int-e: dunno, that might match https://i.stack.imgur.com/ITv1a.png where apparently the first square arrives earlier but the next one later than the ones from the belt.
15:24:34 <wib_jonas> so maybe you can get better latency for one or two shapes, but sadly it's something like the 100th to 400th shape that will matter
15:52:09 -!- SGautam has quit (Quit: Connection closed for inactivity).
15:54:29 <int-e> Well, let's use a bigger setup then... https://int-e.eu/~bf3/tmp/balancer-3.png arrival: https://int-e.eu/~bf3/tmp/balancer-4.png 256 squares worth of stuff later: https://int-e.eu/~bf3/tmp/balancer-5.png ...looks pretty much the same (damn, I should've made sure to make those screenshots at the same scale)
16:00:03 <wib_jonas> int-e: hey, that's not fair! I have no reason to think that curved belts behave the same as straight belts
16:00:16 <wib_jonas> oh, sorry, that's just the input buffer
16:00:33 <wib_jonas> I just used miners that saturate the belts plus circuits to start and stop them for that
16:00:35 <wib_jonas> no buffer
16:00:48 <wib_jonas> also interesting
16:00:59 <wib_jonas> that shows that the balancers are a bit faster for you
16:01:01 -!- LaughingMan has changed nick to Church.
16:01:04 <wib_jonas> I don't know what to think then
16:01:28 <wib_jonas> in any case that no longer matters in late game, which is when you care about the latency more
16:01:38 <wib_jonas> er postgame I mean
16:01:46 <wib_jonas> freeplay is postgame, right?
16:08:36 <int-e> works for me
16:09:02 <int-e> wib_jonas: I was worried about the curves even for the buffer... but all paths have the same curving, so it should be fair.
16:09:18 <int-e> length for that experiment was 144 exactly
16:12:53 -!- impomatic has quit (Read error: Connection reset by peer).
16:13:07 -!- impomatic has joined.
16:13:49 <esolangs> [[BunnyBell]] https://esolangs.org/w/index.php?diff=101574&oldid=101477 * PixelatedStarfish * (+231) /* Casting */
16:14:32 <esolangs> [[BunnyBell]] https://esolangs.org/w/index.php?diff=101575&oldid=101574 * PixelatedStarfish * (+13) /* Assignment */
16:16:14 -!- sprout has quit (Ping timeout: 255 seconds).
16:16:26 -!- impomatic has quit (Client Quit).
16:16:46 -!- impomatic has joined.
16:17:25 <int-e> tunnels, otoh, seem to introduce a bit of a delay
16:17:39 -!- impomatic has quit (Read error: Connection reset by peer).
16:17:59 -!- impomatic has joined.
16:19:53 -!- impomatic has quit (Read error: Connection reset by peer).
16:20:07 -!- impomatic has joined.
16:27:24 <int-e> Oh but with 9x speedup that delay is significantly smaller. So... maybe a similar thing could be happening with the balancer where the results vary with the speedup factor?
16:28:19 <wib_jonas> int-e: quite possible. the details of everything like this depend on fps so they probably depend on the upgrades too
16:28:46 <int-e> In any case, none of this seems very relevant. I can see the value of throughput, but a 5, maybe 10% reduction in latency? Not something I actually worry about. It's a fascinating phenomenon though.
16:29:10 <wib_jonas> and by fps I mean the setting that sets the number of computed frames per in-game seconds, which are often be slower than real time if the game is lagging
16:29:43 <wib_jonas> int-e: yes, it usually doesn't matter
16:29:47 <int-e> Tick rate is 60Hz, fwiw.
16:30:12 <wib_jonas> that's the default, yes
16:30:54 <wib_jonas> that makes it even more moot because the better way to get low latency for long straight passages works better at high tick rate than low tick rate
16:33:11 <int-e> Anyway, enough experimentation. In fact, enough of that game for today. I'll assemble and finally complete level 27 tomorrow. And then I'll see what twists await me.
16:35:33 <wib_jonas> good
16:45:46 -!- wib_jonas has quit (Quit: Client closed).
16:55:05 -!- tromp has joined.
17:02:03 <esolangs> [[User talk:Yes]] https://esolangs.org/w/index.php?diff=101576&oldid=101559 * Yes * (+104)
17:02:34 <esolangs> [[User talk:Yes]] https://esolangs.org/w/index.php?diff=101577&oldid=101576 * Yes * (+80)
17:02:53 <esolangs> [[User talk:Yes]] https://esolangs.org/w/index.php?diff=101578&oldid=101577 * Yes * (+4)
17:03:26 <esolangs> [[User:Yes]] https://esolangs.org/w/index.php?diff=101579&oldid=101508 * Yes * (-5)
17:11:51 -!- impomatic has quit (Quit: impomatic).
17:12:11 -!- impomatic has joined.
17:16:23 -!- impomatic has quit (Client Quit).
17:16:43 -!- impomatic has joined.
17:33:18 -!- sprout has joined.
18:02:03 -!- SGautam has joined.
18:04:31 -!- Lord_of_Life_ has joined.
18:04:59 -!- Lord_of_Life has quit (Ping timeout: 252 seconds).
18:05:47 -!- Lord_of_Life_ has changed nick to Lord_of_Life.
18:06:51 -!- impomatic has quit (Quit: impomatic).
18:07:11 -!- impomatic has joined.
18:11:23 -!- impomatic has quit (Client Quit).
18:11:45 -!- impomatic has joined.
18:16:51 -!- impomatic has quit (Quit: impomatic).
18:17:11 -!- impomatic has joined.
18:21:27 -!- impomatic has quit (Client Quit).
18:21:49 -!- impomatic has joined.
18:33:13 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
18:35:55 -!- tromp has joined.
18:37:04 -!- impomatic has quit (Quit: impomatic).
18:51:41 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
19:15:39 -!- tromp has joined.
20:21:34 -!- SGautam has quit (Quit: Connection closed for inactivity).
20:25:03 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
22:45:41 -!- Sgeo has joined.
23:45:08 -!- Guest667 has joined.
23:45:42 <Guest667> 01->1# +# :# 0# g# ,# :# 5# 8# *# 4# +# -# _@
23:52:33 <fizzie> `! befunge 01->1# +# :# 0# g# ,# :# 5# 8# *# 4# +# -# _@ just for the record
23:52:35 <HackEso> 01->1# +# :# 0# g# ,# :# 5# 8# *# 4# +# -# _@
23:55:52 -!- Guest667 has changed nick to unicode1.
23:56:41 <unicode1> https://esolangs.org/wiki/Esoteric_Awards so they stopped after 2006?
23:56:47 <unicode1> whats to stop it from being revived?
←2022-08-01 2022-08-02 2022-08-03→ ↑2022 ↑all