< 1730333000 791298 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :96 gigabytes of ram? < 1730333002 24342 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :wow < 1730333024 238173 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :do you own that or is that a work or research machine that you have access to? < 1730333035 73089 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :It's just a fairly high end laptop. > 1730333092 548820 PRIVMSG #esolangs :14[[07PyFuck14]]4 10 02https://esolangs.org/w/index.php?diff=144608&oldid=144603 5* 03Ais523 5* (+70) 10formatting < 1730333096 847582 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :That's $240 of laptop RAM lol. < 1730333132 739108 :zzo38!~zzo38@host-24-207-52-143.public.eastlink.ca PRIVMSG #esolangs :Is there TLS implementation that only implement the protocol, and you can include your own code for other stuff (without having dependency on specific libraries; you can use any function that implements them)? > 1730333165 327498 PRIVMSG #esolangs :14[[07PyFuck14]]4 10 02https://esolangs.org/w/index.php?diff=144609&oldid=144608 5* 03Ais523 5* (+17067) 10/* Variants */ move the Hello World program here from the Hello World list, because it's too long for that page < 1730333198 231248 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :https://www.newegg.com/mushkin-enhanced-96-gb-262-pin-ddr5-so-dimm/p/0RM-001Z-000X4 this stuff < 1730333270 923957 :zzo38!~zzo38@host-24-207-52-143.public.eastlink.ca PRIVMSG #esolangs :(The functions such as hashes, encryption, public key handling, ASN.1, etc are things that would be usable independently, and a program might have them for other reasons, even if there is a conditional compilation for use or not use oF TLS) > 1730333281 298170 PRIVMSG #esolangs :14[[07Hello world program in esoteric languages (N-S)14]]4 10 02https://esolangs.org/w/index.php?diff=144610&oldid=144606 5* 03Ais523 5* (-22302) 10/* PyChr */ /* PyFuck */ these programs are too long for this page, move them onto the language page < 1730333307 706710 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :zzo38: Twisted Python comes to mind. < 1730333332 998788 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Oh, no, sorry, that's only SSH. I think their TLS is via OpenSSL or other system libraries. Nevermind. < 1730333350 748722 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :Lymia: you it's not just the RAM, you need a motherboard that can use it all > 1730333370 629643 PRIVMSG #esolangs :14[[07PyChr14]]4 M10 02https://esolangs.org/w/index.php?diff=144611&oldid=144607 5* 03ShirAko 5* (-378) 10Shortened Hello World by 2% ! < 1730333374 475238 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Yeah, fair. < 1730333408 413652 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Framework 13 AMD. < 1730333416 157199 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Wtf, desktop RAM is more expensive than laptop right now? < 1730333441 676677 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :the motherboard that I'm using for my personal desktop supports at most 64 GB of RAM, and I bought this in 2021 < 1730333452 754322 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :I have 32 GB of RAM in it < 1730333484 919867 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :desktop RAM is more expensive? hehe, that's like how micro-SD cards are cheaper than SD cards with the same speed and capacity > 1730333507 948707 PRIVMSG #esolangs :14[[07Hello world program in esoteric languages (N-S)14]]4 10 02https://esolangs.org/w/index.php?diff=144612&oldid=144610 5* 03Ais523 5* (+5) 10/* PyChr */ better link < 1730333509 210885 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :even though you get a free SD card converter with the micro-SD card < 1730333512 847700 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :I have a space-heater workstation purchased used on eBay. It has 150 GiB of RAM and cost me $150. Model's Dell Precision T3910; I think it listed for like $1500 originally, so I got a 90% discount buying used. < 1730333517 47295 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :This was 2023Q4, so, definitely newer. < 1730333522 856501 :zzo38!~zzo38@host-24-207-52-143.public.eastlink.ca PRIVMSG #esolangs :I am using C and not Python. < 1730333538 469767 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :I got a very new laptop since, uh... I don't intend on fully replacing it for years. < 1730333545 715401 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :If you *want* RAM, then it's very cheap in the secondhand marketplace. Lots of old workstations needing some love. > 1730333547 752926 PRIVMSG #esolangs :14[[07PyChr14]]4 M10 02https://esolangs.org/w/index.php?diff=144613&oldid=144611 5* 03ShirAko 5* (+236) 10Added Translator/Encoder < 1730333563 997142 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :And I expect RAM is going to be what fucks me up 10 years down the line. > 1730333570 241482 PRIVMSG #esolangs :14[[07PyFuck14]]4 10 02https://esolangs.org/w/index.php?diff=144614&oldid=144609 5* 03Ais523 5* (-17423) 10remove content that's duplicated in the [[PyChr]] article, replacing it with a "See also" section < 1730333574 699917 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Looking at the trends over the past decade. x.x; < 1730333583 449824 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :yeah < 1730333618 999697 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :96 GB might be enough to run bovex > 1730333620 880955 PRIVMSG #esolangs :14[[07PyFuck14]]4 10 02https://esolangs.org/w/index.php?diff=144615&oldid=144614 5* 03Ais523 5* (+100) 10restore the categories, which I deleted by mistake < 1730333635 418153 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :though you also need an expensive graphics card > 1730333662 455856 PRIVMSG #esolangs :14[[07PyChr14]]4 10 02https://esolangs.org/w/index.php?diff=144616&oldid=144613 5* 03Ais523 5* (+30) 10see also < 1730333713 93528 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Is that a "bovine database"? My search engine seems to think it's cattle-related. < 1730333773 407349 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :no, https://esolangs.org/wiki/BoVeX < 1730333796 468502 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :the "bov" part comes from the name of Harry Q. Bovik, a fictional person in whose honor the joke conference is held < 1730333924 393761 :salpynx!~salpynx@161.29.22.222 PRIVMSG #esolangs :in the context of BoVeX, i don't know if "parahgraphs" is a typo, or an in-joke < 1730333945 986213 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :that is a typo > 1730333956 348343 PRIVMSG #esolangs :14[[07BoVeX14]]4 10 02https://esolangs.org/w/index.php?diff=144617&oldid=129698 5* 03B jonas 5* (-1) 10 < 1730334066 525505 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :BoVeX is absurd, lmao. < 1730334086 227815 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Yeah, no, I only have iGPU right now. < 1730334091 38183 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Will have an eGPU some day, but that day isn't today. < 1730334097 23287 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :And it probably won't be high end enough for that nonsense. < 1730334172 249218 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :yeah, tom7 specifically explains somewhere in the article that “largest video card” (commercially available at the time) is not an exaggeration < 1730334195 798231 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :or maybe it was on the blog, not the article < 1730334217 74268 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :wait, why doesn't that wiki page link to the video? < 1730334693 552411 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :http://radar.spacebar.org/?month=1&year=2024 mentions it only in brief, it's the article that says “the world's (physically) largest video card […] the GeForce 4090”, and also his computer has 256 GB of RAM, of which 130 GB is needed for the language model that he uses, so no, 96 GB wouldn't be enough > 1730334751 160138 PRIVMSG #esolangs :14[[07BoVeX14]]4 10 02https://esolangs.org/w/index.php?diff=144618&oldid=144617 5* 03B jonas 5* (+159) 10 > 1730334932 537111 PRIVMSG #esolangs :14[[07PyFuck14]]4 M10 02https://esolangs.org/w/index.php?diff=144619&oldid=144615 5* 03ShirAko 5* (+14) 10Thank you Ais523! I had to change the Hello World program again because of an edit conflict when I tried to correct it. (previously, it was Hello world! without a capital W) < 1730334933 917659 :amby!~ambylastn@ward-15-b2-v4wan-167229-cust809.vm18.cable.virginm.net QUIT :Quit: so long suckers! i rev up my motorcylce and create a huge cloud of smoke. when the cloud dissipates im lying completely dead on the pavement > 1730334976 986272 PRIVMSG #esolangs :14[[07PyFuck14]]4 M10 02https://esolangs.org/w/index.php?diff=144620&oldid=144619 5* 03ShirAko 5* (+4) 10 > 1730335052 87397 PRIVMSG #esolangs :14[[07User:ShirAko14]]4 M10 02https://esolangs.org/w/index.php?diff=144621&oldid=144497 5* 03ShirAko 5* (+81) 10 < 1730335574 496231 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :I'm wondering if there's a way to do a modified markov that's more stable. < 1730335595 109690 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Watching the (zem) hill for a while, I'm starting to think that markov overvalues beating the strongest bot on the hill. < 1730335650 720186 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I play duplicate bridge tournaments quite frequently (although usually not major ones) < 1730335677 277317 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :they often use a scoring method called "VP" where you get points for beating opponents, and more points for beating them by more, but with diminishing returns < 1730335688 792328 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I've pondered what a BF Joust hill would look like if it were scored by VP < 1730335719 406459 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(it goes the other way round, too – losing means you get less VP and losing by more still less, but again with a diminishing penalty) < 1730335728 125256 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ais523: does that involve a fixed or variable number of hands within the match? < 1730335736 89290 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: fixed < 1730335748 787239 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :can be a variable number of matches but each match itself is fixed size < 1730335769 330850 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it seems to correspond quite well to BF Joust, because that also has fixed-size matches between pairs of opponents < 1730335796 705814 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :hmm… maybe. < 1730335904 855323 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I'm pretty sure that there's some mathematical reason to get a particular amount of VP for a particular victory margin, but the guides don't tell you the formula, just a whole load of oddly specific numbers > 1730336239 946413 PRIVMSG #esolangs :14[[07PyFuck14]]4 10 02https://esolangs.org/w/index.php?diff=144622&oldid=144620 5* 03ShirAko 5* (+302) 10 > 1730336247 440226 PRIVMSG #esolangs :14[[07PyFuck14]]4 M10 02https://esolangs.org/w/index.php?diff=144623&oldid=144622 5* 03ShirAko 5* (+38) 10Final small adjustements... < 1730336608 109260 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :VP would be a nice balance between rewarding decisive wins and marginal wins, it sounds like. < 1730336633 532630 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :(Since both... do represent useful strategies.) > 1730336680 306225 PRIVMSG #esolangs :14[[07PyFuck14]]4 M10 02https://esolangs.org/w/index.php?diff=144624&oldid=144623 5* 03ShirAko 5* (-110) 10It is finally done. < 1730336726 838156 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :it's kind of different because in Bfjoust each game result is just win or lose or draw, while bridge has more different results with different values. but that might not be enough of a difference to matter for scoring. < 1730336749 790709 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :you can play win/lose/draw bridge, it's in theory my favourite way to play team games but I've never had the opportunity < 1730336783 237822 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the advantage is that it means that every board is equally valuable, rather than slam boards being worth over 10 times as much as overtrick boards < 1730336790 85460 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :how would win/lose/draw bridge? < 1730336794 79022 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :how would that work < 1730336827 917723 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it's played in teams of four players, each team sits north/south at one table and east/west at the other, you have the same cards in the same directions at each table < 1730336847 431444 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :right, so still duplicate bridge < 1730336854 707896 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and whichever team gets a higher-scoring contract wins (with penalties scoring as though they were a contract made by the other side) < 1730336910 927901 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so, e.g., if one team makes 2S+1 sitting N/S and the other makes 2H= sitting N/S, the team making 2S+1 win because that scores 140 to 2H='s 110 < 1730336943 685304 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :if a team "goes plus" (makes a contract or takes a penalty) at both tables (despite sitting in opposite directions) that wins the board automatically, obviously < 1730336954 591990 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :I do have the basic idea in mind of a "reverse markov scoring" too. < 1730336956 91873 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but normally you are comparing differently-sized plus scores < 1730336969 139013 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Where rather than beating strong bots being strongly reward, beating weak bots gets you marginal gains. < 1730336978 642961 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :But I'd need to think about how to formalize that. < 1730337049 560246 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :but if it's normalized to just win/lose/draw for each one duplicate deal, doesn't that make it so that even if you play several such duplicate deals there's too few entropy in your total score (adding up just your wins minus losses), and so there'll too often be ties for winning a tournament? < 1730337077 622913 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :because there'll be like two teams who each have the same number of wins < 1730337106 781174 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :not normally – imagine a coin-flipping tournament, the odds of a tie are fairly low even though everyone is equally skilled < 1730337122 691582 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and in practice one side will usually be more skilled than the other, and is very likely to win < 1730337145 651357 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :that's because a coin flip is much faster than a game of bridge, so you can play much more coin flips within the time that a tournament lasts < 1730337165 138670 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the other forms of scoring often make it easier for a lesser-skilled side to win through luck, because they happened to make a lucky decision on one of the few boards that matters < 1730337168 767591 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :"one side will usually be more skilled than the other" => sure, but I mean in tournaments with more than just two teams < 1730337212 4141 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :big tournaments are usually either Swiss (where ties are acceptable) or knockouts with very large numbers of boards played (in the US I think the standard is 60 board per match) < 1730337233 726785 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :I see < 1730337261 290609 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the odds of a tie in a 60-flip coin-flipping tournament are pretty low; and if you account for skill differences (effectively giving you a biased coin) the odds of a tie are much lower < 1730337388 286637 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :ooh, impatience is the first bot in a long long time to beat nyuroki on score. < 1730337392 863088 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :I should examine it closer sometime. < 1730337428 982717 :earend1!uid657395@user/utoneq QUIT :Quit: Connection closed for inactivity < 1730337484 766507 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :So, hmm. Whether a bot in BF Joust wins against another is kinda... a factor of 3 variables I'd say (estimating). General "overall power" (what hill ranking should measure), archetype matchups (e.g. Nyuroki has anti-defense, so stuff like ash should beat it), and just "noise" from exact timings and unfortunate "silver bullet" matchups. < 1730337485 658285 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :Lymia: it is a slow rush program with a flexible timer clear on a very short timer, and it moves onto the next cell when the timer expiers < 1730337488 84728 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :* expires < 1730337544 875738 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Markov overvalues silver bullet matchups vs the top of the hill. Score overvalues bots that are dominant over very low "overall power" levels at cost of its matchups vs more advanced bots. < 1730337562 15949 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :this gives it an unusual but generally pretty good speed-versus-opponent's-decoy-size relationship – against small decoys it can't out-offset it is as fast as a turtle, against larger decoys slightly slower but not by much < 1730337572 173023 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Right. :o < 1730337618 949451 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and this also gives it an obvious huge weakness against flag-defence bots, although if it notices a cell being changed away from 0 it will make sure it's zero on two consecutive cycles before moving on, so you have to defend the flag without impatience observing a 0 < 1730337639 137570 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :That explains rowdy-mate massacuring it. < 1730337652 229382 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :yes, it is expected to lose against competent flag-defenders < 1730337659 757502 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :They just weren't on the hill before. < 1730337671 535431 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I think some of them were, and they beat it even when it was submitted < 1730337677 678158 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :just not enough of them to mess up the ranking < 1730337685 816548 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :
ACTION nods.
< 1730337727 147457 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it makes up for it by being very good against front-of-flag defenders, given that it can sneak past their tripwires on one polarity and will escape locks if it doesn't see a zero < 1730337748 455438 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :That makes sense. < 1730337750 300666 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Oh, that's clever! < 1730337755 20040 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and I feel like front-of-flag defence has traditionally been better than defending on the flag < 1730337759 99699 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :It expects "true" locks where it doesn't see the flag change at all. < 1730337765 310296 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :flag zero* < 1730337772 937042 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :So it doesn't need to use something like a timer. < 1730337782 710968 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Er. < 1730337787 263959 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :That is, timer into a different clear cycle. < 1730337789 840233 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :well, it's the same timer that's used for abandoning cells that seem to be wrong-polarity decoys < 1730337830 1122 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :(Seems ash/impatience/nyuroki is the current top of hill defense/fast rush/slow rush overall?) < 1730337838 829534 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :unfortunately I think the control flow is still buggy < 1730337846 931183 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Control flow is always the biggest pain. u.u; < 1730337849 544547 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :So, understandable. < 1730337864 720660 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :impatience is slow rush < 1730337874 310466 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :in that is has a long decoy setup < 1730337880 677448 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it's just that the speed of the rush itself is fast < 1730337897 95239 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :maybe "fast rush" should be renamed "early rush" < 1730337897 511064 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Aha. < 1730337900 975502 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :
ACTION nods.
< 1730337930 482762 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :I imagine nyuroki should still be classified as slow rush, even though it's capable of abandoning it. < 1730337932 970618 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :in general I think there are two distinctly different slow/late rush strategies < 1730337951 680611 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :yes, short-tape special cases normally aren't counted when categorising bots < 1730337956 863742 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :
ACTION nods.
< 1730337967 863129 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :e.g. margins3 is unable to reach the far end of the tape if it's long enough, but it will attack if the tape looks short < 1730337974 420380 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but it's still a defence program < 1730338008 531779 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so, one slow rush strategy involves trying to out-decoy the opponent: more decoys, bigger decoys, big offsets to get past the opposing decoys < 1730338042 257694 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the other involves trying to make "enough" decoys rather than more decoys, and speed up the clear loop by avoiding fancy things like big offsets, in order to try to outrace the previous sort of slow rush strategy < 1730338090 458181 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :generally speaking it has fewer decoys, maybe starts the rush a little earlier, and clears faster against an opposing slow rush program (the tradeoff being that it can be significantly slowed by the fairly small decoys that other strategies use) < 1730338125 303686 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :(From experience fast/early rush seems to have trouble currently.) < 1730338134 502826 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and I've increasingly become a fan of the latter strategy, it has been doing very well recently and makes pokes feel like they're something that aren't usable in pure slow rush programs any more < 1730338147 554795 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :(But I could be trying the wrong things.) < 1730338157 527298 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :yes, fast rush is definitely struggling, although I feel like it's maybe always been struggling? < 1730338207 437171 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :oh interesting, lugh beats Ash. < 1730338226 61916 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I feel like the future of fast rush probably involves mixing a rush with a decoy setup, and maybe even some flag repairs < 1730338240 678603 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but it's hard to write a program like that < 1730338330 386155 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Lugh's my attempt at poke + early rush. It's not good, but... could probably be refined into something that is. < 1730338384 408001 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :Lymia: so this seems to be because it re-offsets immediately after the triplock trips, and is able to clear its own offset before ash can get back to the cell to restore the triplock < 1730338482 550045 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :most programs, if they observe the cell changing away from 0 after the timer has expired, use an anti-defense loop that doesn't have an offset, because the cell is clearly either a flag or a lock cell, and you've been there for ages already, so why would you offset? < 1730338515 493221 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but, ash is attempting to send opponents all the way around from 0 back to 0 again, giving lots of time to attack, and the offset prevents that working < 1730338712 47358 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I could possibly avoid that by using a more traditional (+)*128 style triplock, but that would have a number of other bad effects and probably make ash score worse overall < 1730338715 787849 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Wait it reoffsets the same cell. < 1730338717 411957 :fizzie!irc@selene.zem.fi PRIVMSG #esolangs :The "traditional" scoring also gives you more rewards for beating stronger opponents, by giving each opponent a "worth" (based on the raw points), and making each of your wins give you a fraction of that program's worth. It's probably more stable since it doesn't involve any fixed-point nonsense. < 1730338718 927313 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :That's a bug, lol. < 1730338721 16046 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :maybe not, though? < 1730338721 823830 :fizzie!irc@selene.zem.fi PRIVMSG #esolangs :(In the "true" traditional scoring, the fraction is 100% if you win on all tape lengths, and 0% if you tie, and linearly interpolated between them; in the "tweaked" one even the most marginal of wins gives you ~50% of that program's worth, with the argument that any kind of a win should be meaningfully better than a tie.) < 1730338786 937833 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :huh, ash does fairly well even in traditional (although it isn't near the top of the leaderboard) < 1730338796 680643 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :fizzie: that's good to know. :o < 1730338810 672146 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :given how many draws it gets, it is not very good at traditional scoring < 1730338935 489399 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Lugh shouldn't offset twice on the same cell, anyway. < 1730338942 420163 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Except its large reverse offset. < 1730338952 986425 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :If it does a traditional offset on a cell, something's fucked. < 1730338958 615682 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :cell it's already seen clear* < 1730338971 207924 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I feel like a carefully-sized re-offset may be a surprisingly simple way to beat many types of defense program < 1730339017 222690 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Ah? To defeat the push-pass-0 approach? < 1730339038 134407 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :or just timing-based locks in general < 1730339040 541061 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :
ACTION nods.
< 1730339049 898390 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the problem is, you wouldn't want to do it as a consequence of observing 0 because that means you're already on a good timing < 1730339059 309915 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :maybe it could be a good response to timer expiry < 1730339093 990775 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Doesn't switching to a different clear cycle length already mess things up on timer expiry? < 1730339098 534148 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :That's how nyuroki tries to break locks. < 1730339104 85424 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :yes, but only once < 1730339117 498418 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so a probabilistic lock might be able to lock the new timing too < 1730339122 385101 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :.. aha. < 1730339123 353919 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Right. < 1730339127 948303 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :!ztest lugh_fixed https://dl.rimin.moe/paste/lymia/lugh_1q845r2xf5w9ygslx2vq7ma7f952lzbzb0g9l6y48nr394z82c9i.bf < 1730339128 502518 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I remember writing a program that changed polarity every 620ish cycles in order to eventually try all possible timings and hit the gap in probabilistic locks < 1730339130 516418 :zemhill!bfjoust@selene.zem.fi PRIVMSG #esolangs :Lymia.lugh_fixed: points 3.05, score 22.86, rank 19/47 < 1730339134 836551 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :!ztest lugh https://dl.rimin.moe/paste/lymia/lugh_1q845r2xf5w9ygslx2vq7ma7f952lzbzb0g9l6y48nr394z82c9i.bf < 1730339137 334967 :zemhill!bfjoust@selene.zem.fi PRIVMSG #esolangs :Lymia.lugh: points 2.38, score 22.75, rank 18/47 (--) < 1730339157 120092 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Did find a case where it'd reoffset unintentionally, but doesn't seem to be it. < 1730339168 395280 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :that difference in position is probably losing the mirorr? < 1730339189 952411 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :!ztest lugh https://dl.rimin.moe/paste/lymia/lugh_0cycvz4xdgzwfk48pgir6a82aqqjwdvn2phcp1fbzvlfs09j0653.bf < 1730339192 345100 :zemhill!bfjoust@selene.zem.fi PRIVMSG #esolangs :Lymia.lugh: points -0.26, score 19.92, rank 24/47 (-6) < 1730339194 318545 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :testing programs that are already on the hill is a little awkward because of the mirror matches, bug fixes normally cause a program to lose the mirror by making it very slightly slower < 1730339212 707380 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Yeah, it goes down a lot if you fix that bug. < 1730339217 183558 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Probs becuase the bug was screwing over ash. < 1730339222 545004 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :that would make sense < 1730339226 70142 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :arguably this is not a bug < 1730339233 416591 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :all sorts of behaviour that looks like bugs will beat specific programs < 1730339262 708093 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :e.g. you can get a huge advantage against growth2 by doing a rule of 8 and attacking a cell that can't possibly be the flag < 1730339293 342114 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :because it tries to detect the first cell you clear, and start 9 spaces away from there < 1730339357 917589 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but that's clearly a bug, so why would programs do that? (and when I've experimented, doing so loses more against other programs than it gains against growth2, so it isn't a worthwhile strategy unless growth2-alikes are dominating the hill) < 1730339634 731903 :zzo38!~zzo38@host-24-207-52-143.public.eastlink.ca PRIVMSG #esolangs :I think now I had managed to implement 32-bit floating points into ASN.1 DER, although it uses IEEE 754 instead of using the C library functions for that, so might not work on computers that do not have IEEE 754. < 1730339710 576877 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :recently I wrote a program that calculates buffer sizes using floats by reading raw bytes from their in-memory representation, in a way that can lead to out-of-bounds reads if the floats aren't IEEE 754 < 1730339736 845948 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it's basically the fast inverse square root trick, except for calculating the number of digits in an integer, instead < 1730339764 137764 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I'm not expecting it to lead to problems but maybe I should add some sort of runtime check to ensure that the floats are formatted as expected < 1730339800 349263 :zzo38!~zzo38@host-24-207-52-143.public.eastlink.ca PRIVMSG #esolangs :What program is that? < 1730339825 577327 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it's a compiler for a language that might or might not be an esolang < 1730339829 742979 :zzo38!~zzo38@host-24-207-52-143.public.eastlink.ca PRIVMSG #esolangs :The documentation for my program does mention that the asn1_encode_float function will not work correctly if the C "float" type is not 32-bit IEEE 754 format. < 1730339891 767352 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :which is intended for writing compilers that don't fully understand their input and are just translating syntax in one language to syntax of the same shape in another language directly, without attempting to figure out what the code means < 1730339919 608209 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :zzo38: libecb has functions to convert floating point values to or from the common IEEE 754 formats, you can use those < 1730339961 187583 :FreeFull!~freefull@46.205.206.114.nat.ftth.dynamic.t-mobile.pl QUIT :Ping timeout: 252 seconds < 1730339993 530720 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ais523: you can avoid the out-of-bounds reads at least with something like static_assert(sizeof(float) == sizeof(uint32_t)) < 1730340006 807272 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :oh, I have a static assert that float is 4 bytes long < 1730340032 614738 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :that's not the problem, though – I'm using this to calculate the number of bytes it takes to express an integer in ASCII and then blindly writing into the resulting buffer < 1730340043 203554 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ah < 1730340051 810762 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so if the result is low it leads to an out-of-bounds write later on < 1730340053 364995 :zzo38!~zzo38@host-24-207-52-143.public.eastlink.ca PRIVMSG #esolangs :I don't know what is libecb, but I am not intending to add dependencies other than the C standard library, although some GNU functions may be used (and one part of the program (for sorting items in a set) uses GNU nested functions) < 1730340068 976167 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :zzo38: http://software.schmorp.de/pkg/libecb.html < 1730340079 964603 :FreeFull!~freefull@46.205.206.114.nat.ftth.dynamic.t-mobile.pl JOIN #esolangs FreeFull :FreeFull < 1730340093 227833 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(if the result is high it causes the program's output to be wrong, but doesn't lead to UB) < 1730340101 202281 :zzo38!~zzo38@host-24-207-52-143.public.eastlink.ca PRIVMSG #esolangs :Is the ISO 2022 also related to the same program you were doing, or different program? < 1730340108 491248 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :different program < 1730340134 480658 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the compiler-generator works with raw bytes and doesn't handle character encodings at all < 1730340165 248145 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :zzo38: it consists of just one not very long header file so it's not too hard to add as a dependency, and you can even try to slice it to keep only the parts that you need for this program, because it has a free enough license < 1730340282 73393 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ais523: IIRC the J interpreter used to have a bug like this, not because of wrong floating-point format I mean, but a bug in a function that turns an integer to a sequence of digits but sometimes it returns one fewer or one more digit than needed (I don't remember which) < 1730340299 960317 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :it's documented but I think it's still a bug < 1730340371 845503 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I went and iterated over all 4294967296 int32_t values to make sure the lengths were correct, and have added a test that tests a representative subset (including all the values that are expected to be awkward) so that I can quickly rerun it on a new computer or if I make changes to the code < 1730340428 392758 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :that's good, it's just much harder to do with doubles < 1730340434 392007 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :(or with two float parameters) < 1730340445 374740 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :also I really should report that floating-point bug in qemu < 1730340507 223911 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :now I am reminded of the floating-point bug in the Wii Virtual Console which made it possible to complete Super Mario 64 without ever pressing the A button < 1730340537 208649 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :is that the one about the rising and falling water level? < 1730340556 193495 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :not water level, there are platforms which rise and fall out of lava < 1730340585 617277 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ok < 1730340588 488117 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but the Wii Virtual Console rounds towards 0 (as opposed to the N64 which rounds to nearest) and the rounding errors accumulate to make the platforms gradually and very slowly rise upwards, because they start at a negative height value < 1730340632 567526 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it takes several days before they get to a point that allows you to get past the otherwise unsolved spot in the level, but they get there eventually and you can stand on them in the process < 1730340653 320895 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :that's funny < 1730340837 63389 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Thinking a little about a better hill scoring algorithm, I think a property comes to mind: < 1730340860 949245 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Copies of weak programs should not change the hill much (and by implication, many weak implementations of similar strategies should not change the hill much) < 1730340866 219475 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Bonus if this can also be achieved for stronger programs. < 1730340897 837770 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I wonder if this runs into Arrow's Theorem at some point < 1730340931 657188 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :that's exactly what I thought, not quite Arrow's theorem, but just impossible combination of desirable properties of the scoring < 1730340963 890544 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I don't think it's exactly Arrow's Theorem either < 1730341003 207844 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :although it reminds me a lot of Condorcet voting, in that the main piece of information we have is which programs beat which when they are compared pairwise < 1730341035 124520 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Can still make a best try. < 1730341070 341655 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :An idea that comes to mind is just eliminating the worst program and then rescoring until you end up with a hill of one. I'm not sure I like the implications of that, though. < 1730341076 912761 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :as such, a hill-scoring algorithm is in effect a Condorcet tiebreak, isn't it? so maybe Arrow's theorem does actually apply directly < 1730341079 538881 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :(Which, is in fact, drawing on voting and such.) < 1730341204 358291 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :if we have an election we want to find the winner of, we do it as follows: for each pair of candidates, treat them as BF Joust programs for which the head-to-head score is based on which of them was preferred by more voters; then score the BF Joust hill; the program that wins is the winner of the election < 1730341260 20694 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :Arrow's theorem says that this method of determining an election has to fail to have at least one of the desirable properties, and that implies the hill scoring algorithm must also fail to have at least one of the desirable properties < 1730341403 182503 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ais523: excuse me, who are the voters for the Bfjoust elections in this analogy? Arrow's theorem depends on that the voters are symmetric, i.e. they have equal votes, and there's more than one voter. < 1730341469 530760 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Intuitively speaking: The value of a bot for scoring should be halved when it's duplicated. < 1730341479 696328 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :However, they should have equal score themselves... < 1730341494 48270 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: it's the other way round, the BF Joust hill is created from a set of voters and preferences via treating each candidate as a program, and one program beating another if more voters rank that candidate above the other than vice versa < 1730341521 338074 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :i.e. we are not treating BF Joust as an election, but rather showing that a hill-scoring algorithm could be used to create an election-scoring algorithm via treating the election as a hill < 1730341551 527399 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ah < 1730341653 548672 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :so in the election that you're starting from, voters are choosing their preference between each undordered pair of two candidates? < 1730341697 543668 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :or is it some more usual form of election? < 1730341761 808100 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: it's sufficient to just have them rank the candidates, then calculate their preference between unordered pairs by looking at which is higher in the ranking < 1730341834 272568 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :I think at least part of the problem here is that the bfjoust scoring algorithm can and probably will allow ties, which Arrow's theorem forbids (otherwise you'd just use an election method that always gives a tie unless the votes are unanimous) > 1730341836 565922 PRIVMSG #esolangs :14[[07PythOwO14]]4 M10 02https://esolangs.org/w/index.php?diff=144625&oldid=144294 5* 03RaiseAfloppaFan3925 5* (+0) 10TwT I forgot that pythowo has while loops lol < 1730341891 500717 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :but that needn't be the most serious problem > 1730341976 936057 PRIVMSG #esolangs :14[[07PythOwO14]]4 M10 02https://esolangs.org/w/index.php?diff=144626&oldid=144625 5* 03RaiseAfloppaFan3925 5* (+30) 10i fowgot to fix the twuwuth machine code again < 1730342050 977731 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :First proposal that comes to mind: Use an underlying "simple" scoring method. At each step, eliminate the worst bot, then distribute its score to the remaining bots based on win count. Repeat until all bots are accounted for. Final score for each bot is the number of points it had when it was eliminated. < 1730342085 144442 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Can't think of any clean theoretical basis for this, but... may work pretty okay in practice. Will have to try it out. < 1730342135 422220 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ok, what I said earlier about the voters being equal is wrong, Arrow's theorem works with a much weaker assumption than that < 1730342201 993042 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Duplicate bots "should" all be eliminated around the same time because they win and lose against the same bots. A duplicate bot should harm its duplicates more than other bots, in fact, because they're taking their score from the same bots. < 1730342227 114482 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Then, once it's passed to bots that are higher on the hill, they should recieve about the same amount "gathered" from bots lower on the hill. > 1730342282 303195 PRIVMSG #esolangs :14[[07914]]4 N10 02https://esolangs.org/w/index.php?oldid=144627 5* 03Fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 5* (+4863) 10Created page with "'''9''' is an [[esolang]] designed by [[User:Fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff]] with the goal of compiling to [[90]]. As such, it cannot perform infinite loops, but has bounded loop > 1730342529 945468 PRIVMSG #esolangs :14[[07914]]4 10 02https://esolangs.org/w/index.php?diff=144628&oldid=144627 5* 03Fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 5* (+319) 10 > 1730342547 890433 PRIVMSG #esolangs :14[[07User:Fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff14]]4 10 02https://esolangs.org/w/index.php?diff=144629&oldid=143862 5* 03Fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 5* (+7) 10 < 1730342554 557840 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Eeh. Still not sure about it thinking it through. Maybe traditional scoring is "good enough" with the value system. Adjust it so ties are 0.5 wins, maybe? < 1730342580 94503 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Markov scoring starts to feel like a mistake to me, because it's so unstable in extreme circumstances (and slightly unstable in more normal circumstances.) > 1730342632 28489 PRIVMSG #esolangs :14[[07914]]4 10 02https://esolangs.org/w/index.php?diff=144630&oldid=144628 5* 03Fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 5* (+6) 10/* Transforming this into 90 */ > 1730342643 74405 PRIVMSG #esolangs :14[[07914]]4 10 02https://esolangs.org/w/index.php?diff=144631&oldid=144630 5* 03Fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 5* (+5) 10/* Transforming this into 90 */ > 1730342659 384642 PRIVMSG #esolangs :14[[07914]]4 10 02https://esolangs.org/w/index.php?diff=144632&oldid=144631 5* 03Fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 5* (-15) 10/* Transforming this into 90 */ > 1730342695 721654 PRIVMSG #esolangs :14[[07914]]4 10 02https://esolangs.org/w/index.php?diff=144633&oldid=144632 5* 03Fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 5* (+47) 10/* Transforming this into 90 */ > 1730342702 693052 PRIVMSG #esolangs :14[[07914]]4 10 02https://esolangs.org/w/index.php?diff=144634&oldid=144633 5* 03Fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 5* (-2) 10/* Transforming this into 90 */ > 1730342716 427144 PRIVMSG #esolangs :14[[07914]]4 10 02https://esolangs.org/w/index.php?diff=144635&oldid=144634 5* 03Fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 5* (+0) 10/* Transforming this into 90 */ < 1730342761 601888 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I am not sure why you would need a macro system for 90? < 1730342765 260670 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(re: wiki edits) < 1730342794 393043 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :unlike most languages, it is not going to let you make more powerful programs > 1730342993 666708 PRIVMSG #esolangs :14[[07914]]4 10 02https://esolangs.org/w/index.php?diff=144636&oldid=144635 5* 03Fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 5* (+197) 10/* Example Program */ < 1730343091 353633 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Tweaked traditional (of the scoring methods on zemhill) seems "good enough" thinking about it. < 1730343136 560725 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :I wonder why it punishes ash so hard? < 1730343167 690749 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :ash draws a lot, and has many incredibly narrow wins < 1730343168 107959 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :(... why the FUCK does lugh go to #4 on iterative traditional) > 1730343194 496476 PRIVMSG #esolangs :14[[07PythOwO14]]4 M10 02https://esolangs.org/w/index.php?diff=144637&oldid=144626 5* 03RaiseAfloppaFan3925 5* (+124) 10TwT i forgot that input is actually inpwt also that one true was supposed to be twue < 1730343198 927359 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :markov scoring lets it exploit the incredibly narrow wins to shoot up the hill, most scoring methods don't let it do that < 1730343376 5884 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :fwiw, even traditional scoring breaks with a bot that beats everything – you can clear the hill by submitting the bot multiple times < 1730343388 405360 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(an exploit which IIRC was actualy used once) < 1730343395 28624 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Yeah. < 1730343399 813110 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :That exploits hill size rather than the scoring though. < 1730343426 898493 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it's been a while since we had an omni-winner < 1730343439 84229 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :I can put one on the hill right now if I can dig out the code. < 1730343439 910322 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs ::P < 1730343455 1245 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the most recent handwritten may have been omnipotence, and that was special-cased to beat two bots it couldn't beat otherwise < 1730343466 457391 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :
ACTION nods.
< 1730343470 993760 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Do you think it's still possible? < 1730343481 816418 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :handwritten without special cases? yes but very difficult < 1730343491 773447 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :
ACTION nods.
< 1730343502 170930 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :IIRC nyuroki2 came close, but still was a few bots short. < 1730343513 368134 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :impatience is very close, but has a clear weakness that will be very difficult to fix < 1730343527 295165 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and, well, it wouldn't really be the same program if you fixed it < 1730343534 562361 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :(Open question is: Should narrow wins count for as much as they do in Markov?) < 1730343556 179216 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I like margins-ish programs too much, so for me, yes – I'm not sure whether it's healthy, though < 1730343560 847120 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :(IMO.... hrm.) < 1730343569 654718 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Yes, but with the provision that the wins aren't unstable to mild tuning. < 1730343572 399617 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :if a program always wins tape length 10 and draws everything else, shoud it be a top winner? < 1730343580 699477 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :yes, assuming stability < 1730343590 513815 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Yeah, that's also my thought. < 1730343607 186528 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :ooh, I just realised you could probably control for stability – delay programs by 1, 2, 3, etc. cycles before starting and see if the result is still the same < 1730343614 233242 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :I was thinking the exact same thing. < 1730343622 925924 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :This was the thought process that led to it, though. < 1730343632 795196 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Oh, well, no, that idea is different. < 1730343644 76414 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Mine was just adding the delayed programs as "configurations". < 1730343653 377732 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Similar to tape length + polarity. < 1730343669 978259 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :cycle advantage -2,-1,0,1,2 < 1730343673 874477 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :well, even if not identical, the ideas are pretty similar < 1730343678 976309 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :
ACTION nods.
< 1730343701 267295 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I feel like your omniwinner program could probably detect cycle advantage too, though? < 1730343715 536169 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :there would be more cases to check but it would still conceptually work the same way < 1730343761 267391 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :interestingly, there are a couple of matches on the hill which come down to a few cycles in a flag race, but consistently (the same program always wins by a few cycles even if you change the tape length) < 1730343778 442732 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I forget exactly which matches it is, but IIRC (and I might not have done!) one of quintopia's programs was involved < 1730343800 477577 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so despite being close in terms of flag timing, they aren't close in terms of match results < 1730343852 817264 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :oh, this reminds me, I also thought of a way to detect near-duplicate programs: you take the match result against each opponent and configuration, and also the length of time the result took to achieve < 1730343868 76936 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and two programs are considered similar if the results and time-to-results are similar < 1730343994 509739 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Oh, length as a side channel is pretty clever. < 1730344001 530384 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :hills could perhaps use that as a method of preventing multiple similar programs coexisting on the hill (if two programs are similar you keep only the one that has better scores against other programs, ignoring the head-to-head matchup) < 1730344047 375833 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Cycle advantage can also be negated by synchronization. < 1730344059 436657 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :one nice thing about length-to-victory is that a) it's rather correlated with strategy and b) it makes it possible to tell two programs apart even if they both beat most of the field < 1730344061 961022 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :But I imagine that falls apart on very short tapes. < 1730344109 293393 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Another possible "stability" thing. < 1730344111 914115 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Is flag height. < 1730344121 897644 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Adjust the flag height -10, -5, 0, 5, 10 or something. < 1730344144 149788 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :for flag-defenders? < 1730344151 908003 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :No, just generally for stablizing timings. < 1730344165 756107 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Well, yeah. < 1730344170 938299 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :It's mostly relevant for flag defenders now that I think about it. < 1730344180 796395 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :that is going to have a disproportionate impact on vibrators and turtles, and a randomizing effect mostly only on flag-defenders < 1730344200 928457 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :(An extreme configuration option may also be cell size) < 1730344206 476763 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :(256, 254, 252, 250) < 1730344222 731514 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :(But I think this screws up existing programs far too much to be viable.) < 1730344224 657123 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :lots of locks and shudders are critically dependent on cell size < 1730344229 181235 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Yeah. < 1730344253 147043 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :256 being a power of 2 has major strategic implications, defensive programs could look quite different in height-255 BF Joust, for example < 1730344271 459143 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it doesn't matter so much for attackers, except when they're trying to beat defenders < 1730344289 841676 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Do you think synchronization+tripwires would negate the stability from cycle advantage as a configuration too much? < 1730344317 125011 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :no – constantly checked tripwires are a thing occasionally, but they're rare < 1730344344 229426 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :cycle advantage can change the probability of sneaking past an occasionally checked tripwire < 1730344346 835751 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Yeah, that makes sense. < 1730344362 126693 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :I might experiment with introducing cycle advantage and see what the matchups look like. < 1730344364 184438 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :also, tripwires are more commonly behind the lock cell than in front nowadays < 1730344366 554246 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :What'd be a good test bot there? < 1730344384 539301 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :ash < 1730344445 717209 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it has a lot of timing-dependent matchups, but is designed so that they mostly average out – lots of matches have a 25% win rate and 75% draw rate, normally with the wins showing up on alternate tape lengths of one polarity because that's what hits the timing that lets it win < 1730344464 230143 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and a tripwire behind the lock cell, although it isn't checked very often < 1730344500 948538 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :omnipotence is also interesting for this sort of thing because it's an entirely unsynchronized defence program, the only time it reads the tape is during the poke < 1730344558 94885 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :-3 to 3 might be a good range as well. < 1730344588 192008 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :mist is probably also somewhat timing-dependent in some matchups, although I'm less familiar with how it works < 1730344608 751618 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :although mist *does* have a constantly checked tripwire < 1730344615 445972 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :The bots I've made should be fairly timing resiliant, since... they don't really use precise/etc mechanisms. < 1730344626 677651 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :I'm not great at that kinda coding. < 1730344638 499661 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :(Would like to try and make a defense bot at some point, but. Haven't yet.) < 1730344641 991245 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :although I'm OK at that kind-of coding I kind-of hate doing it < 1730344673 958795 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :anticipation2 has fallen off the hill, that was something of an extreme example in precise timing measurement with tripwires < 1730344725 446775 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Wait, it actually got killed? < 1730344727 186164 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Did not expect that. < 1730344749 637626 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :!ztest anticipation2 http://ais523.me.uk/esolangs/bfjoust/codu-archive/fb826add7501-ais523_anticipation2.txt < 1730344749 924654 :zemhill!bfjoust@selene.zem.fi PRIVMSG #esolangs :Lymia.anticipation2: points -4.40, score 15.12, rank 40/47 < 1730344759 837658 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Geez, it holds up worse than I thought. < 1730344775 256275 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it is over 10 years old at this point < 1730344798 814975 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :although, so is omnipotence and it is surviving much better < 1730344826 343606 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :anticipation2 can be easily beaten using an anti-vibration loop that's a timer clear, and its strategy has no way to avoid that < 1730344840 130153 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(although, people normally don't put timer clears in their anti-vibration loops) < 1730344907 486090 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :amusingly, it also lost to the sample program because it needs the opponent to have at least one of anti-shudder, a wiggle, or an offset, otherwise it leaves cells faster than it's possible to detect < 1730344988 62600 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :oh, also its "backup" defence strategy only works against integer-speed clear loops, and I have been consistently using non-integer clear loops against programs detected as defence programs for many years now < 1730345067 346972 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :non-integer clear loops? < 1730345094 580061 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :my current standard is [-[+.++]] < 1730345099 724893 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :this adjusts the cell by 3 every 5 cycles < 1730345117 436897 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Aha. < 1730345131 82660 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :will zero a cell eventually if the opponent isn't there, and typically even if the opponent is there < 1730345151 909783 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :I've been relying more on 7-cycle clears, on the theory that it's the prime number that's one too high and too ridicilous for defense programs to try. < 1730345156 904129 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :also 129 is divisible by 3 so this will zero an unattended flag the first time through < 1730345178 404729 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(assuming it didn't get adjusted to stop turtles) < 1730345270 1395 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I feel like it's important to have an anti-shudder that can always clear an unattended cell – sometimes programs end up in their antishudder by mistake (e.g. due to clearing a cell while the opponent is setting a decoy in it) and it's very embarrassing if they end up locking themselves on a cell that the opponent is leaving unchanged < 1730345288 481338 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :which rules out the old-fashioned +--+ (which I'm not sure ever worked particularly well) < 1730345376 886400 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Yeah, that makes sense. < 1730345380 231988 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Hmm. < 1730345397 266934 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :I think this should be incontrovertial when it comes to BFJoust scoring, though: < 1730345449 594301 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Should winning +42 games be twice as valuable as winning +21 < 1730345460 155432 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :... and I think the answer is "no". < 1730345468 37501 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I also think the answer is no < 1730345519 998245 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :one big advantage of the Markov hill is that it makes it more valuable to try to shift the breakpoint in cases where one program wins short tapes and the other wins long tapes < 1730345545 544131 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :like, one program is winning tape lengths from 18 upwards, that's much better than winning tape lengths from 22 upwards < 1730345560 235695 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but that's a relatively small difference in terms of absolute score < 1730345640 702366 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :nyuroki is particularly affected by this when playing against poke programs – against a good poke program it can't consistently win on the entire range of tape lengths, but that's OK because it can win large enough subsets of tape lengths in the ranges that are favourable to it < 1730345678 152450 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :if the range of tape lengths were expanded, then the pokes would become better relative to nyuroki because they generally win the very long tapes < 1730345783 227615 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(I should clarify here to pokes that use the poke to set more decoys on large tapes, as opposed to pokes like lugh which set the same number of decoys regardless of poke distance) < 1730346133 84461 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Main problem with tape count is that it does break a lot of existing programs. < 1730346147 93336 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :e.g. nyuroki's codegen uses tape length as an end point to make the program length, uh. Reasonable. < 1730346158 433509 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :yep < 1730346171 919451 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :some of my older programs have a special case to never go beyond tape length 30 regardless of circumstances < 1730346198 504016 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :in theory impatience would be slightly improved by adding that special case, although most of my other programs can't go beyond the opponent's flag anyway < 1730346233 51598 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and "lock and full-tape clear" strategies naturally end at a particular tape length rather than continuing to clear forever < 1730346239 817070 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :(I wonder if a smaller minimum tape would be nice as well, though. Something like 5-40) < 1730346251 690656 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :(It'd probably change the game too much.) < 1730346260 623923 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I have been seriously considering 8-32 for my Lua Joust-inspired BF Joust derivative < 1730346289 442288 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I think changing the low end matters more than changing the high end, but I don't want to make early rush even weaker than it already is, so giving it a few more short tapes to play with may help < 1730346331 754363 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :this has the advantage of a) being nice round powers of 2 and b) meaning there are 50 matches in a set, meaning that the score of one bot against another can be expressed as an integer percentage (e.g. 49 losses and 1 tie is a 1% win rate, treating draws as half a win) < 1730346440 62321 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I have the derivative mostly designed in broad details (you get one unbounded counter, and one marker you can set on a tape cell you've been to – you can test counter value, distance from marker, or distance from own flag in zero time, and set marker or change counter in zero time, plus the usual wait/move/adjust/test commands that take a cycle – apart from that you have a finite state machine but limited space) < 1730346514 91463 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and am currently planning to make it a 2D language in which tests turn 90° for "different value" or go on straight for "same value", but programs have to be written in a fairly small playfield and don't get abbreviations < 1730346582 961421 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :most of the standard BF Joust tactics can be written in this without abbrevations – it's sufficient for pokes, defensive locks with full tape clears, timer clears, anticipation-like synchronization, etc., but without being TC < 1730346617 502396 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(in fact, it has decidable halting, which would make it possible to run an "infinitely long match" or to determine whether a match was locked up and doesn't need to be simulated out to the cycle limit) < 1730346636 596172 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :ah, "deadlock" is the term I was looking for, I think < 1730346638 188550 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Interesting. < 1730346665 271262 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :On the generation side, it'd be amendable to gradient descent probably, which.... interesting. < 1730346666 523692 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it's also sufficient to write nyuroki without the macro system, assuming there's room for three clear loops (and there should be) < 1730346707 442026 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :I'd consider if there's a good alternative to the 2D aspect, just for reasons of "not making coding bots too difficult". < 1730346725 510360 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :well I was thinking about making a GUI < 1730346766 641494 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :leaning into the computer-game-like aspects of BF Joust a bit more, maybe even making a game that people outside the esolang community might want to play < 1730346773 686398 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Huh. < 1730346776 884674 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I am probably overly ambitious :-D < 1730346816 962064 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :still, I have fun thinking about what the ideal would look like even if I'm unlikely to find time to program it < 1730346822 173793 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :I'd actually consider a fairly large playfield, fwiw. < 1730346829 281084 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Fairly large relative to a reasonable screen size, anyway. < 1730346857 624778 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I think ¼ of the screen is about right, and have mostly been wondering what size the cells should be to make that work < 1730346879 11972 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :that way, you would be able to have a game viewer which showed the bots' thinking in the bottom-left and bottom-right, and the tape at the top < 1730346904 984158 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :complete with cartoonish blindfolded robots desperately feeling around for flags < 1730346934 231616 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :My reasoning here is that... it's only recently been that we've had most major bots use some kinda of repetition/codegen to make up for BF's ... inadequacy in expressiveness. < 1730346934 310823 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :¼ here being half horizontally and half vertically < 1730346974 605910 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :So, likely BFJoust's "very high level" (as in, future hills) expressiveness is much higher than the simple to descirbe but technically long bots we have right now. < 1730346999 166773 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :So some wiggle room for complex strategies that are mainly possible using more powerful control flow seems like a good idea. < 1730347009 547935 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :100x100 or so, maybe. < 1730347011 24338 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :my main concern with Lua Joust is that it's too easy to make programs act unpredictably and kill off most defensive programs < 1730347044 998189 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :(Maybe even lean into the problem being the lack of a crossover operation rather than bounded playfield size?) < 1730347065 702145 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I was planning to allow crossovers, and banning them probably won't do what you want < 1730347071 52151 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Yeah, maybe. < 1730347084 384189 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :people would be able to duplicate parts of the program using the extra space, for example < 1730347114 714798 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I feel like lock-based defense is in serious trouble at the moment because it is too easy to break the locks < 1730347129 580161 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :I'm not sure it can be reasonably preserved even in 2D. < 1730347201 720416 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :well, one of my goals defining this language was to help make a lock-and-full-tape-clear concise to write, so that you could write it even if you had a small space, whereas flexible timer clears are not easy to write in this subset and take a lot more space < 1730347225 951016 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :you can do inflexible timer clears just fine, but that may leave an exploitable window, etc. < 1730347315 295449 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Is the key point of a flexible timer clear its early return? < 1730347321 245517 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :looking for lock-and-clear-based programs on the current scoreboard (as opposed to other styles of defense), the top scorers are omnipotence at 13 and quicklock at 23 (preparation is at 16 but it abandons the lock to attack, as it doesn't have enough free cycles in the lock to reach the far end of the tape) < 1730347351 984702 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :there are a few things it can do over an inflexible timer clear, although some of them are BF-specific advantages < 1730347376 701208 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but a big one is that you can vary the clear loop details from cell to cell, meaning that it's pointless for opponents to try to learn how your clear loop works and take advantage of that < 1730347408 312312 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :for example, impatience's timer gets longer and offset gets smaller as it clears more cells < 1730347437 965704 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Fwiw, Nyuroki doesn't really vary from clear to clear (in a significant way), it just says "you have to special case or die". < 1730347494 441511 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :when I discovered the flexible timer clear I thought BF Joust was dead, in that it would invalidate all defensive strategies < 1730347500 829571 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :The heart of it is that it tries a 2-cycle for 2000 cycles, then switches to a 7-cycle anti-vibration clear. If it observes zero two times, it bails. This should be very brief in the 2D language, and leave plenty of room for more complexity. < 1730347506 242547 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it turns out it didn't, but it has made traditional locks mostly obsolete < 1730347521 332732 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :yes, Nyuroki is the sort of thing I wanted to allow < 1730347526 285730 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :I may not fully understand flexible clear. Is it just about changing the details of the clear from cell to cell? < 1730347586 721475 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the major difference from inflexible is that you are in a different section of the program from one cell to the next, meaning that you can do all the usual fanciness like checking if a cell is 0 before offsetting it, and that also lets you change whatever details you like from one cell to the next < 1730347604 706591 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Right. < 1730347616 459429 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :So Nyuroki uses the same structure, but doesn't exploit the full nastiness possible. < 1730347621 904564 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :That explains it. < 1730347635 801308 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :anticipation2 was designed to exploit the inflexibility of inflexible timer clears by learning the offset and cycle length and locking them in the antivibration (or tricking them off the tape) < 1730347655 460703 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :For what it's worth, if the problem is changing the details of cycle, you could just... < 1730347660 473945 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but against a flexible timer clear that doesn't work < 1730347660 512315 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Make 3 clear cycles, then loop them. < 1730347667 262094 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :In 2D. < 1730347676 990977 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :It's more brief than a flexible timer clear but has a similar effect. < 1730347680 634230 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :yes – this sort of thing is why I wanted limited space < 1730347693 754685 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so you'd have to choose between that, and, e.g., a full set of short-tape special cases < 1730347722 401271 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I can even imagine different "weight categories" of bots that have different bounding box sizes for the progra < 1730347724 642176 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :* program < 1730347747 336266 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Hmm. < 1730347805 541337 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :(Nyuroki uses the "open slot" for complex code flow without exponential code size to do a forcable early return rather than a flexible timer clear, basically.) < 1730347828 259526 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :(I don't believe but could be wrong that its code structure is not amendable to being combined with a flexible timer clear.) < 1730347836 568653 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :(I believe but could be wrong*) < 1730347856 437028 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :I'd have to see that to know what I think of it overall, honestly. < 1730347858 614640 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :It sounds viable. < 1730347895 680112 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :I'd maybe just mostly advise that the "recommended" playfield size be on the order of maybe 1.5x-2.5x the code size needed to express the largest (fair) bot high on the hill. < 1730347916 344342 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I'm inclined to agree but am not sure what you mean by "fair"? < 1730347924 502624 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Bot that isn't using its code size maliciously. < 1730347937 324123 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :(for some subjective definition of "stuff that could invalidate strategies entirely") < 1730347941 824387 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :ah, so not full of special cases or the like < 1730347945 250586 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Yeah. < 1730347961 332834 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :fwiw, I feel like program size has been dropping dramatically recently < 1730347979 773717 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :The Kolmogorov complexity faster than the program size, I'm sure. < 1730347986 232603 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :
ACTION nods.
< 1730347987 882295 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :ash and impatience were both written with no code generation / editing tools other than copy-and-paste and find-and-replace < 1730348063 912205 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :out of the last 8 winners, 2 are IRC one-liners, which seems quite close to the historical proportion past the early days < 1730348077 191592 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Was probably mostly defense that was breaching it. < 1730348102 712403 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :I use code generation mainly for the sake of being able to easily iterate on bots that have the same "behavior" repeated in lots of places. < 1730348111 117938 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Rather than to generate bots that would be impractical to write by hand one way or another. < 1730348137 204466 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :my code-generated bots generally use repetition for different poke lengths or measured timings < 1730348277 593157 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :(I've never really seen the point to a true flexible timer clear, for what it's worth, maybe because there's enough other tactics that kill the lock-and-clear kind of bot.) < 1730348302 848370 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :(Since using the best possible timer clear whenever possible is obviously a very good approach vs anything that isn't a lock.) < 1730348310 637300 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :(And varying it just for the sake of varying it could just result in you being too slow.) < 1730348329 654664 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :oh, the other really big advantage to flexible is that the timer resets with every cell < 1730348353 151649 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :with inflexible, it's shared between all the cells, so you have to have a very long timer in order to ensure that you don't switch strategy while you aren't actually being locked < 1730348407 20514 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Riiight. < 1730348576 391366 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but no, I agree – inflexible is usually good enough and it's what I use in most of my programs, unless I need a flexible timer clear for some reason (e.g. impatience doesn't work without one) < 1730348589 195316 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Nyuroki has a single one of the "flexible clear features" used on purpose then, namely resetting the timer. < 1730348597 868440 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :yep < 1730348602 754696 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :But it doesn't do anything else because... uh. The clear loop works. < 1730348605 29573 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Why change it. -w- < 1730348627 777486 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :The 2D approach (or something simliar in 1D with very limited program size?) makes sense for specifically punishing very different clear loops. < 1730348633 315533 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Rather than ones that are somewhat advanced in normal BF Joust. < 1730348637 121368 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I feel like the ability to change up the clear loop is mostly important against theoretical anti-defence programs, rather than actual ones < 1730348654 514578 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :err, theoretical defence programs < 1730348678 615281 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :basically only anticipation/anticipation2 ever tried anything to exploit inflexible timers and I don't think they did it very effectively < 1730349022 486145 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :I overall like the idea here. < 1730349043 161507 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Thinking through programs I've analyzed/wrote, it's specifically punishing Kolmogorov complexity rather than advanced tactics, per se. < 1730349103 414119 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :It also has a easy story for why only certain operations "pass the turn" (per se): they affect the shared tape. < 1730349107 708624 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :(or check it) < 1730349124 79379 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :It's especially punishing for special cases, which... < 1730349128 912332 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Honestly: good. < 1730349276 826688 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :I'll probably still write an auto-router that turns text-based code into warriors, but that's because personal preferences at work, rather than "needed due to flaws in the underlying system". < 1730349633 984504 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :I get what you mean with state machine earlier too. Program size scales with number of "distinct behaviors" effectively, which... is a good property. < 1730350178 965269 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :ais523: hmm. I think that once you get past the idea that a defense program can 100% beat any "reasonable" offense, the motive to do "theoretically sound" defenses like anticipation/anticipation2 represented goes down, and the probabilistic approaches to e.g. defense look a lot more attractive. < 1730350207 15523 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :And once you start looking into those, the possible design space explodes. < 1730350273 895858 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :There's stuff that died, sure, but it seems the more the meta "develops" right now, the more rock paper scissors triangles start revealing themselves. < 1730350332 280578 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :The silver bullets don't exist. So, structurally killing off special casing seems a win. < 1730350383 421101 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :yes < 1730350452 343598 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :BF Joust has more of a sweeper-wall tangle than a rock-paper-scissors triangle, but that's probably to its advantage – competitive Pokémon's sweeper-wall relationship is one of the best things about that game < 1730350500 613127 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(in Pokémon, physical walls beat physical sweepers which beat mixed walls which beat mixed sweepers; if two sweepers fight the faster wins, if two walls fight things get weird and it can take a while) < 1730350517 927971 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :
ACTION nods.
< 1730350528 594259 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but if the sweepers start fighting over speed to beat each other they become less good at fighting the walls, where speed doesn't matter < 1730350545 943963 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :this is surprisingly reminiscent of BF Joust, although the concepts don't match up exactly < 1730350551 449959 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :It is. < 1730350611 795167 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :this is by far not the only generalised rock-paper-scissors relationship in Pokémon, which is a game completely full of them, but it's the most interesting IMO < 1730350619 438376 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :(In Pokemon, the most defensive teams also run a single one of the nastiest wallbreaker they can find, lol. Which is also reminicent of BF Joust) < 1730350700 86514 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :yes – although back when I played, my anti-stall Pokémon was often a wall tuned to beat other walls rather than an offensive wallbreaker < 1730350761 990577 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :would be nice if one existed right now. v.v; < 1730350762 985508 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :
ACTION nods.
< 1730350796 723137 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I like exploiting opponents using predictable teambuilding – I got a lot of wins back in generation 4 by running both Flamethrower and Ice Beam on Blissey < 1730350822 439839 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :because many of the most common Blissey switchins were 4× weak to one of those moves and would get OHKOed < 1730350855 283118 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :once you'd OHKOed them, the opponents generally assumed they could get a setup turn with the other, because no ways Blissey is running *both* of the elemental offensive moves, right? < 1730350918 118383 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :sometimes I ran this together with Psych Up, which is not theoretically correct but was hilarious and came up surprisingly often (Calm Mind is a better alternative for the same slot, though, being almost as good in most of those cases and better in general) < 1730351029 917919 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Tbh, the most exploitable thing right now is the near-total lack of mixed attackers. < 1730351077 599056 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I went and had a look at the early SV meta, which was amazingly broken in a lot of different ways, but haven't had a look at it now that it's settled down < 1730351103 870205 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Iron Valiant is the only mixed attacker in OU. < 1730351118 164172 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but that's a good point, I can't think of good Pokémon that are able to run mixed sets (there are some that can run either physical or special but generally have reasons why you can't mix them) < 1730351177 692253 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I should at least check the banlist to see what sort of wreckage Game Freak's lack of balancing for singles left behind < 1730351202 175469 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :If you want to go stall, Clodsire+Corviknight alone can mess up half the meta, lol. < 1730351822 447977 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :git pull on zemhill is going to take forever isn't it < 1730352023 64514 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it depends on how often you do it – but git does have techniques for accelerating pulls of repos that haven't been pulled for ages < 1730352037 700532 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it doesn't have to download the commits one at a time, so cloning an old repository isn't as bad as it might seem < 1730352242 220625 :zzo38!~zzo38@host-24-207-52-143.public.eastlink.ca PRIVMSG #esolangs :I would want to implement a pokemon battle simulator in C, as a library that can be called by another program; with help from others too hopefully < 1730352594 600533 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :ais523: https://dl.rimin.moe/paste/lymia/results-with-delay_0qx9bjg2nrfrksx19shgam347w5n0hhjriqgdhafpxd9spkghygx.txt < 1730352604 238799 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Here's a raw dump of results on current zemhill with the delay configuration added. < 1730352612 331403 :zzo38!~zzo38@host-24-207-52-143.public.eastlink.ca PRIVMSG #esolangs :I had also written about pokemon (and some other games) in a subpage in esolang wiki, hopefully you know if the brief description is good enough < 1730352807 556889 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Definitely feels like a continuation of the same matchup set, but more resiliant against timing weirdness. < 1730352869 756712 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the delay seems to mostly not matter with most programs, which is what I'd expect < 1730352898 310282 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Seems worth it for the ones where it is, at least. < 1730352903 836359 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :finnel versus synanceia is a clear pattern of timing mattering – it changes the single-game results but doesn't significantly change the match results < 1730352949 586101 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :rowdy versus quicklock has some significant score differences based on timing details, though < 1730352972 641386 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :rowdy versus growth2, too < 1730353016 115274 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Yeah, some bots seem more vulnerable to it than others. < 1730353021 633463 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :oddly with that one, some delay-polarities are more drawish, and some are less drawish but who wins depends on polarity < 1730353027 999133 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :* delay-parities < 1730353068 945542 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :It does look like an overall good change just eyeing it. < 1730353081 41394 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :A good 5-10% of the matches seem impacted enough that this reduces the amount finetuning matters. < 1730353117 793064 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :ais523.slowpoke.bfjoust vs web.ais523_ash.bfjoust < 1730353121 181822 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Another one. < 1730353148 631486 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :lugh versus margins3 seems to be one where it has a significant impact on the match result < 1730353177 241779 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :lugh is always winning but there are significant differences in the margin < 1730353189 416497 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :yeaaah < 1730353201 598692 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :There's in fact the odd-even patterns I expected. < 1730353207 262145 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Which may make it worth it to extend to -3 to 3. < 1730353234 76155 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :margins3 is primarily a shudder program, it makes sense that that is timing-dependent < 1730353267 441508 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Good timing "poliarity" gets you 4/7 advantagous positions instead of 3/5. < 1730353273 851523 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Slightly more consistent. < 1730353276 796128 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :oh, lugh versus Sookie is interesting, lugh wins almost 100% of the time on one delay but more like 50% on the other 4 < 1730353315 524374 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :this makes sense because the Sookie lock (which inspired ash's, which has the same property) is probabilistic and breaks 25% of the time against 2-cycle clears < 1730353395 123433 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :https://dl.rimin.moe/paste/lymia/results-with-delay_1pw1k76cw0kwih3ckljqlya15awyjk7bdfsbzlnbfi3z23wq99rx.txt < 1730353416 17176 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :meanwhile, quicklock is very stable to this disruption because it has a timing tripwire – the only significant changes are against a passive defender, which make it leave its tripwire < 1730353416 763268 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Does help the Sookie matchup be more consistent. < 1730353424 627317 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :2/7 rather than 1/5. < 1730353473 596787 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I think this was a worthwhile experiment – the results are not surprising, but that's usual with experiments < 1730353498 311366 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :I'd call this on the edge of worth implementing, tbh. < 1730353508 391905 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :OK, a super-significant difference: hippo_ballerina versus synanceia < 1730353539 469833 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :synanceia always wins short tapes, and delay parity makes the difference between the longer tapes being hippo_ballerina wins or draws < 1730353573 998981 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so it changes the match winner, and there's a difference of 34 points between the two delay parities < 1730353583 659186 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :I wonder if it'd be worth it to do this, and *delete* the 0 polarity difference. < 1730353595 720961 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Eh, probs not. < 1730353610 205852 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :I wish there was a way to make this 50/50 < 1730353612 792348 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :In cases where it matters. < 1730353645 395562 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :impatience versus jackal2 is intriguing, it looks kind-of like on tape length 12, that one cycle is determining a flag race < 1730353654 148940 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I should check that game in the breakdown < 1730353668 268421 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :err, the game viewer < 1730353730 551854 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :⚐2 <00 03 0A 09 02 FF FD FF FD 00 00 >00 ⚐2 (impatience, versus jackal2 delayed 1 cycle) < 1730353746 177373 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :on polarity-inverted tape length 12 < 1730353876 550086 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :impatience versus xurtle looks similar, but your results for that don't match egojsout's, one of them must be parsing one of the programs differently < 1730354108 773862 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Running a test hill with a basic scoring. < 1730354116 714140 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :ais523: this is a modified gearlance. < 1730354128 490476 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :monolith versus atom is weird < 1730354170 662707 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it looks vaguely period-3-ish but doesn't repeat exactly < 1730354383 323423 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :omnipotence versus optimism is a very significant exact period-3, which makes some amount of sense because omnipotence has an unsynchronized lock < 1730354387 823047 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :https://dl.rimin.moe/paste/lymia/results-with-delay_1z77xhrpdx4hx211njfl4cfczafzcs8gmh6cp2fisa55rcds7w6y.txt < 1730354393 146583 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Here's a complete dump with a score chart at the very bottom. < 1730354433 457053 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :(first number is score with delays, second number is score without delays) < 1730354494 67711 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Some significant winners and losers: space_hotel gains a lot. slag loses a bit. omnipotence and margins 3 wins a bit. preparation gets a massive buff. < 1730354540 86462 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :omnipotence versus MV has some "a program falls off the tape on the second cycle of its opponent's flag being zero" cases, which both egojsout and gearlance treat as draws < 1730354582 509080 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :(So, I do use gearlance here, but I can't guarentee identical behavior) < 1730354595 841090 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :(Since it does have some small fixes, and it's modified for reentrancy) < 1730354601 727118 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :(And generally being hooked up to Rust code.) < 1730354633 882 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :If I were making a new hill, I'd consider this worth implementing as an additional "dimension" anyway. < 1730354666 315819 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I will consider it if I implement my new version < 1730354681 928438 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :
ACTION nods.
< 1730354716 535778 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I am wondering if preparation doing much better is a consequence of people (perhaps unintentionally) constant-tweaking against it – the notable thing about that program is that it's critically dependent on a probabilistic lock < 1730354717 31556 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :It makes timing-dependent matchups closer to a tie. < 1730354729 712475 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so most of its matchups are somewhat timing-dependent < 1730354738 700659 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :(or, rather, the stable point.) < 1730354743 268764 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the extra dimension throws off the tweaking < 1730354751 461017 :Sgeo!~Sgeo@user/sgeo QUIT :Read error: Connection reset by peer < 1730354759 842218 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :That is probable. < 1730354802 276345 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :So, here's a fun thing: You could probably score wins that aren't stable to timing as less valuable. < 1730354807 940696 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :oh, preparation versus Sookie is one of the largest differences, and I did have some suspicion that Sookie was overfitted < 1730354862 535736 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Eeh. I don't think that'd help. Just punishes timing dependant bots. < 1730354889 188751 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :slowpoke versus ash is very weird < 1730354910 414912 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :might need more than 7 runs of that to figure out the pattern < 1730354999 352796 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :salpynx.nana.bfjoust vs salpynx.synanceia.bfjoust?? < 1730355002 549218 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Are those two copies? < 1730355031 13544 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :No just weird < 1730355099 878387 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :they're significantly different, synanceia is the most timing-unstable program on the hill < 1730355107 878276 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :whereas nana is a lot more stable < 1730355195 348864 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :(I think for a hill that uses this configuration method) < 1730355207 81077 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :(Rather than the >>> <<< as the default display for detailed matchup information) < 1730355222 88319 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :(Instead a heatmap of how often the program wins on each tape length, with a button to click it for more details) < 1730355229 949422 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :(fold polarity into the W/L from delays.) < 1730355241 274550 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :space_hotel versus Sookie is pretty > 1730355275 971955 PRIVMSG #esolangs :14[[07S.B.M.F.B14]]4 10 02https://esolangs.org/w/index.php?diff=144638&oldid=144598 5* 03Ractangle 5* (-241) 10/* Examples */ < 1730355281 438931 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :That matchup's a mess lol < 1730355299 594799 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I suspected Sookie would be fairly unstable, I'm looking at its matches now < 1730355309 218334 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(it's a little inconvenient because it comes last alphabetically) < 1730355436 716243 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I don't think growth2 actually benefits much from the delay compensation, it does well regardless in traditional scoring < 1730355446 196425 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :yeouch < 1730355449 878061 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Sookie gets detroyed scorewise. < 1730355452 504296 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Definitely overfitted. < 1730355486 998651 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :4.002 -> 0.159 < 1730355552 159101 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :heh, Sookie turns out to be on a bad timing against rowdy, but rowdy was submitted after it was so that makes sense < 1730355579 715076 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :ouch, that also gets wrecked. < 1730355588 423263 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it's on a good timing against lugh, that might be part of what causes it to lose points when compensating for timing < 1730355616 214377 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :a good timing against margins (the original), too < 1730355629 355538 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and margins3 as well < 1730355661 89330 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Tbh, this does seem to help the bots that (from what I've seen of them) deserve to be helped. And in general, bring some life to defensive bots (afaik, what the bots do) < 1730355673 186405 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :And nuke overfitted stuff lol. < 1730355674 73606 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :slowpoke seems to be the most unstable of the Sookie matchups I've checked so far < 1730355690 15323 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :well, you're just giving them another dimension to overfit in :-) < 1730355695 409731 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :That's true. < 1730355717 568769 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :It should make overfitting harder unless people somehow manage to detect delay though, lol. < 1730355736 350342 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Kinda like polarity. < 1730355796 395528 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :meanwhile, unstable_atom seems to be more stable than salpynx probably intended < 1730355823 105849 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :only a few of its matchups change significantly – one of those is against omnipotence, but it was submitted with a bad timing for that matchup, which is the opposite of overfitting > 1730355836 416665 PRIVMSG #esolangs :14[[07Esolang:Sandbox14]]4 10 02https://esolangs.org/w/index.php?diff=144639&oldid=144529 5* 03Iddi01 5* (+2748) 10T H E. C R A Z I E S T. T E S T. I N. H I S T O R Y. A N D. F O R E V E R. W I L L. B E. < 1730355842 881071 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :This does feel like a natural extension to polarity. Tuning for timings vs bots is something people do, and this makes that tuning less important. < 1730355885 671005 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :hmm, now I am wondering what happens if, instead of delaying at the start, you delay the first time the programs are on the same cell (or cross each other) < 1730355902 626088 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Would be a lot harder to implement. < 1730355908 678227 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :or, no < 1730355914 439967 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Since right now, the delay is just adding "..." < 1730355918 999950 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :that mathematically can't make any difference to delaying at the start, can it? :-D < 1730355936 443639 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Only in narrow edge cases, I think. < 1730355941 665862 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :I did consider a "rolling" delay. > 1730355945 386995 PRIVMSG #esolangs :14[[07Esolang:Sandbox14]]4 M10 02https://esolangs.org/w/index.php?diff=144640&oldid=144639 5* 03Iddi01 5* (-2747) 10Let's see if the reverted tag shows up < 1730355955 72442 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Where each program pauses once each 100 (or so) cycles at different timings. < 1730355962 135165 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :neutrino versus unstable_atom appears to be a flag race where the delay cycles matter < 1730355968 463026 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :But that might fuck up existing defense something serious. < 1730355980 235715 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :although only on high odd tape lengths and only on one polarity < 1730356060 395420 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :ooh, feature idea: distinguish between a draw (when the programs deadlock and time out) and a tie (when the programs both actively reach a victory condition simultaneously) < 1730356077 496467 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :huuh < 1730356090 279676 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :To what end? < 1730356095 735637 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :ties are generally interesting, or at least exciting to watch, and it would be good to have an easy way to spot them on the breakdown < 1730356100 85387 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :even if you'd score them the same way < 1730356141 300053 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Right. < 1730356145 465291 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(I can also see an argument for weighting points by the number of non-drawn games, i.e. only counting the games that finish on time, but if you did that tied games would still count) < 1730356200 727985 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Tbh, I am somewhat considering putting up an alternative hill to zemhill, with rules changes like this. < 1730356204 849517 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :cupnoodles versus unstable atom is a tie on tape length 10 < 1730356219 950195 :salpynx!~salpynx@161.29.22.222 PRIVMSG #esolangs :yeah, the current synanceia is doing the over fitted instability i was aiming for with unstable_atom. I was happy with the -8 swing i saw on syn earlier. Sookie, and i think hippo_ballerina are others i noticed that would swing significantly up and down < 1730356230 724061 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but random ties on, say, 26 would be much more interesting < 1730356245 227691 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :I can set up the framework for that, tbh. < 1730356251 687543 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Tracing cycle count is basically free. < 1730356257 151674 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :And getting more information out of it is also basically free. < 1730356273 157661 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :IIRC hippo_ballerina's strategy doesn't make much sense, I was just randomly combining strategies until I found something that would stick on the hill < 1730356311 795223 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :That is also kinda what Nyuroki does, but that's clearly pretty stable on the hill. < 1730356315 259083 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Or, well, was. < 1730356330 750086 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :I imagine hippo is... < 1730356333 939445 :salpynx!~salpynx@161.29.22.222 PRIVMSG #esolangs :that is kinda the space i have been exploring too :) < 1730356337 769426 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :More just lots of special cases? < 1730356383 275459 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I don't think it's special cases, but I also can't remember how it works < 1730356405 873976 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Hmm. Imma think about alternative scoring systems later. < 1730356411 426633 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :I think... overall I prefer traditional over markov. < 1730356415 568906 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :But could maybe improve on both. < 1730356489 266983 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it looks like – stealth clear, when you find a large decoy set decoys behind you, inflexible timer clear < 1730356508 284274 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Is there a compelling reason to treat "total wins over bot" as distinct from "total score vs bot"? < 1730356526 928714 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :That is, make it so that going 21-21-0 is different from going 0-0-42? < 1730356633 649347 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :I don't feel like there's a good reason to treat tying twice as different from winning once and losing once. If it was originally meant to nerf defense, well, uh. < 1730356639 262683 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Defense is clearly not what needs a nerf. < 1730356643 275122 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I can see an argument that, say, 5-0-5 should be treated as more than half as valuable as 10-0-0 < 1730356650 909059 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Huh. < 1730356652 173395 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Interesting. < 1730356680 749178 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :or, well, 8-0-8 as worth more than 12-4-0 < 1730356680 885720 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :It'd be more like 10-0-10 vs 15-5-0, right? < 1730356685 948624 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :right < 1730356713 17892 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Right. < 1730356734 265345 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it conceptually feels like preventing a program ever beating you, and beating it sometimes, is a fairly dominating performance < 1730356758 336789 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Mathemtically hard to represent, though. < 1730356768 484948 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Except maybe by completely omitting ties/timeouts from the calculation. < 1730356781 122409 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :i.e. ties revert to the overall performance across the match. < 1730356829 355850 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :yes (you would need to special-case the situation where all lengths/polarities/delays were timeouts but it's clear what to do there) < 1730356843 319742 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Huh, that actually doesn't sound too bad. < 1730356849 995107 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :that case isn't so unlikely, either, it happens in the passive defender mirror match < 1730356907 998891 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Would benefit programs like margins3 for the most part. < 1730356918 868023 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Though, uh, it might makes its scores fairly unstable against programs that narrowly take a few games from it. < 1730356926 796640 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :yes, that's a reason not to score like that < 1730356950 844731 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I feel like margins3's time in the sun is setting, too – it is too easy to beat nowadays < 1730356958 767666 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :margins3 vs ash < 1730356965 577451 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Ash has a fairly narrow win > 1730357140 190442 PRIVMSG #esolangs :14[[07User:Iddi01/Sandbox14]]4 N10 02https://esolangs.org/w/index.php?oldid=144641 5* 03Iddi01 5* (+21249) 10This is the actual version, was blocked automatically when attempted in the sandbox < 1730357156 615192 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Hmm. Treating ties as 50% the overall winrate seems fairly sane, though. < 1730357189 884834 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Combining that with a simpler scoring method like tweaked traditional could well get something like markov in terms of overall kinds of bots it encourges < 1730357196 487231 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Without the instability. > 1730357474 167621 PRIVMSG #esolangs :14[[07Esolang:Sandbox14]]4 10 02https://esolangs.org/w/index.php?diff=144642&oldid=144640 5* 03Ais523 5* (-1) 10clean up a left-over non-ASCII character imitating ASCII (please don't make me add a filter against these, it would have enough false positives to potentially cause problems for other wiki users) < 1730357561 856164 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :I'm thinking a bit about the idea of reversing the "value" mechanism of traditional scoring. < 1730357576 816816 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Where each program has a fixed value that is divided proportionally to the programs that win against it. < 1730357637 733156 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Not sure this is meaningfully different. < 1730357670 594981 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :if it isn't too hard to implement, you could find out < 1730358032 279150 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :It shouldn't be. < 1730358088 482864 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :This is pretty similar to a single step of markov evaluation. < 1730358467 393100 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :This is in many ways the non-iter variant of markov (which.... is frankly overengineered.) < 1730358553 472689 :tromp!~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl JOIN #esolangs * :Textual User < 1730359031 352827 :iddi01!~iddi01@2604:9cc0:14:8d60:d5b0:dacd:a37a:e880 JOIN #esolangs * :[https://web.libera.chat] iddi01 < 1730359139 785558 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :iddi01: your user sandbox triggers more "this page couldn't be rendered properly due to exceeding limits of the wiki" warnings than I've ever seen on a single page before, and my browser struggles to load it < 1730359184 876127 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :as such, assuming the test is complete now, I'm planning to delete it < 1730359243 912553 :iddi01!~iddi01@2604:9cc0:14:8d60:d5b0:dacd:a37a:e880 PRIVMSG #esolangs :Blanking would be preferred, so people could view the test if they wish to get an idea of how crazy tests can get. < 1730359262 587154 :iddi01!~iddi01@2604:9cc0:14:8d60:d5b0:dacd:a37a:e880 PRIVMSG #esolangs :(from the page history) < 1730359310 996715 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :blanking could be reasonable < 1730359319 979944 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Alright. Have an unmodified traditional scoring working. < 1730359337 819385 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I was having some thoughts about the semi-serious language list, and the featured article thing on the main page < 1730359391 282022 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I was wondering whether instead of "featured article", it should be "random esolang" and link to one of the pages on the SSLL at random, restricted to only languages with an implementation (so that casual visitors get to try it out) < 1730359396 536612 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but that would mean writing blurbs for all of them < 1730359457 516323 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I was also wondering whether the SSLL should be made into the primary language list, with the existing language list either kept as a backup or deleted in favour of Category:Languages, although it would probably need to be renamed in that case and I'm not sure what it should be called instead < 1730359551 789200 :iddi01!~iddi01@2604:9cc0:14:8d60:d5b0:dacd:a37a:e880 PRIVMSG #esolangs :for the featured article, i'll crosspost my suggestion from Talk:Main_Page, "Add the rule that, when at least 2 people other than the language's creator (actually 3, the first being the one proposing the language) agree on that a language should be featured (which they may say at the talk page, on IRC, or anywhere else) and no one disagrees within < 1730359552 282300 :iddi01!~iddi01@2604:9cc0:14:8d60:d5b0:dacd:a37a:e880 PRIVMSG #esolangs :a month since that happened, it becomes featured. This will ensure that the featured language is still changing in 'admin scarcity times' like this. What do you think?" < 1730359593 871524 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :one big problem with the featured language is that if it's going to stay for a while, it needs a really high-quality article and we don't have many like that < 1730359625 253432 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I also fear that it'd lead to newly designed languages which haven't really been checked by anyone else by the creator being featured too often < 1730359691 744124 :iddi01!~iddi01@2604:9cc0:14:8d60:d5b0:dacd:a37a:e880 PRIVMSG #esolangs :But there would also be few cases where 3 people agree on the same language to become featured < 1730359775 462466 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I guess the situation is – there are some languages which have a good enough page to be featured, and there are some languages which have enough interest/programs/implementations to be featured, and there isn't a lot of overlap < 1730359859 2845 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :also, the lack of admins makes the featured language process hard to use because it is basically forcing me into a decision, but as a prolific esolang creator (and being involved with several languages that might be worthy of featuring) it is hard for me to make a decision due to potential bias issues – it is unclear whether I can fairly judge my esolangs against other people's, and even if I can, people might think I'm biased < 1730359896 395175 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(I mostly wasn't involved in the process being created – I was there but I think it was mostly other admins' decisions) < 1730359946 903727 :iddi01!~iddi01@2604:9cc0:14:8d60:d5b0:dacd:a37a:e880 PRIVMSG #esolangs :And that's exactly why we should focus on consensus instead of admin decision < 1730360021 387663 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :https://pastebin.com/sTuDcZy4 < 1730360029 535014 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Some examples of traditional scoring variants. < 1730360146 970208 :iddi01!~iddi01@2604:9cc0:14:8d60:d5b0:dacd:a37a:e880 PRIVMSG #esolangs :It's really fun to watch people rediscover all those strategies: https://codegolf.stackexchange.com/questions/36645/brainfedbotsforbattling-a-brainf-tournament < 1730360174 900979 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :!ztest original_nyuroki https://raw.githubusercontent.com/Lymia/JoustExt/refs/heads/master/examples/nyuroki.bf < 1730360175 224058 :zemhill!bfjoust@selene.zem.fi PRIVMSG #esolangs :Lymia.original_nyuroki: points -5.90, score 14.89, rank 42/47 < 1730360215 645350 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :!ztest original_nyuroki_but_not_really https://raw.githubusercontent.com/Lymia/JoustExt/refs/heads/master/examples/nyuroki-esoteric.bf < 1730360215 981744 :zemhill!bfjoust@selene.zem.fi PRIVMSG #esolangs :Lymia.original_nyuroki_but_not_really: points 15.86, score 42.24, rank 1/47 < 1730360222 948448 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :jesus what < 1730360237 209249 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :OG power I guess. < 1730360261 245924 :iddi01!~iddi01@2604:9cc0:14:8d60:d5b0:dacd:a37a:e880 PRIVMSG #esolangs :nyuroki4 ;) < 1730360344 53177 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :By markov score, nyuroki (the original first version that landed first on zemhill) is the best program I have across every bot ever submitted to the original esohill or the new zemhill, lol. < 1730360360 874067 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Less fitting to hill, probs. < 1730360692 677065 :Lord_of_Life_!~Lord@user/lord-of-life/x-2819915 JOIN #esolangs Lord_of_Life :Lord < 1730360709 446669 :Lord_of_Life!~Lord@user/lord-of-life/x-2819915 QUIT :Ping timeout: 246 seconds < 1730360773 468504 :Lord_of_Life_!~Lord@user/lord-of-life/x-2819915 NICK :Lord_of_Life < 1730360776 946918 :craigo!~craigo@user/craigo JOIN #esolangs craigo :realname < 1730360930 657622 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Hmm... Ash definitely deserves to win I think, is a start to my tests here. < 1730361149 888185 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :But why Ash and not Mist, Mist is also fairly drawish. < 1730361151 986609 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :And I'd say the answer is: Ash clearly has a way better raw score than Mist. < 1730361256 408678 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :ais523: here's an interesting question for iterative methods. < 1730361266 422571 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Is there a compelling reason to look for the fixed point rather than a reasonable number of iterations? < 1730361284 390051 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :(Arbitarily chosen) < 1730363016 900524 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :... Hrm. Overall, I think the "ideal" scoring may be iterative tweaked traditional rather than markov. But I'd need to test how unstable it is over time. u.u; < 1730363129 212024 :ais523!~ais523@user/ais523 PRIVMSG #esolangs : Is there a compelling reason to look for the fixed point rather than a reasonable number of iterations? ← if the iterations converge, they converge on the fixed point, so it's a natural stopping point; if they don't, that's a good reason to pick the fixed point rather than stopping at some arbitrary point on the attractor < 1730363196 316310 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :I'm just wondering if for practical scoring purposes, a fixed (and small) number of iterations would be "good enough" but less vulnerable to being distorted in degenerate cases. < 1730363256 360392 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :(Did the experiments on "reverse" scoring, it's... viable, but isn't different enough from raw score unless I screwed up the implementation.) < 1730363291 594437 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :(Difference's probably bigger on larger hills with a lot of garbage though.) < 1730364453 596780 :tromp!~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl QUIT :Quit: My iMac has gone to sleep. ZZZzzz… < 1730365012 910929 :tromp!~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl JOIN #esolangs * :Textual User < 1730365558 196958 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :one thing you could do is a combination where there's a main scoring system that determines the placing on the hill, but also a few other scoring systems such that there are a few slots reserved on the hill for jousters that perform well in an alternative, so you keep the 40 highest main scoring programs plus the 4 highest alternative scoring programs and 4 highest other alternative scoring program but < 1730365564 206332 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :sort the whole lot by the main score. eg. you could have an alternative that disfavors draws, so that even if defenders turn out to be too powerful, there'll still always be four attacker programs on the hill that and program will have to try to beat, etc. < 1730365635 856411 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :kind of like when a sports world championship takes the best athlete from each country if the reach a lower threshold than the large number of top athletes that come mostly from the US and China < 1730365650 317544 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :only without the politics associated > 1730365876 868061 PRIVMSG #esolangs :14[[07Stakc14]]4 10 02https://esolangs.org/w/index.php?diff=144643&oldid=144592 5* 03ChuckEsoteric08 5* (+28) 10/* Documentation */ < 1730365887 336723 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :I mean there's still the politics of discussing what kind of hill you want, just not the non-sports politics where even though you just want to organize sports you have to decide whether Kosovo is a real country and no matter how you decide at least a quarter of the world will hate you and possibly boycott your competition and all that nonsense < 1730365997 72720 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :I guess they could do some multi-score hills like this in other sports too as long as the sport has pairwise matches between teams like football or duplicate bridge, rather than a ranked performance between individual competitors like weightlifting or swimming < 1730366132 927378 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :so you could have a basketball hill that includes 2 teams who are the best at scoring 3 point goals plus the 6 other best teams according to traditional score, score the hill according to traditional score < 1730366182 584236 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :or a football championship that includes 2 teams with the best cheerleading performance plus 6 other teams best in football < 1730366237 136257 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :what do you do if the alternative scoring systems choose bots that already scored well enough on the main scoring system? < 1730366238 552036 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :that way if some of your audience likes to watch 3 pointers or cheerleading you sell more tickets to them, especially to groups of friends where one person watches the football/basketball and the other watches for 3 pointers or cheerleading < 1730366290 561527 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I do like the idea (for BF Joust, not football) if a good set of details can be worked out < 1730366304 510134 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ais523: I assume you'd choose in advance a sequence of the multiset of scores, and for picking the hill you iterate on the sequence and add to the hill the best remaining team according to that score < 1730366351 71794 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :I'd probably put the alternative scores first so that they only matter if the bots scoring best on normal scores aren't good at them < 1730366403 48497 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :None of the scoring systems are different enough (it seems) that high scoring candidates in any system are likely to die. < 1730366408 339494 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Unless they're extraordinarily different. < 1730366473 636021 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :right, something ilke margins3 or ash which scores very well in Markov tends to be pinned to the middle of the leaderboard in traditional, but the middle is not the bottom so they're at little risk of falling < 1730366661 124138 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :one thing that real sports do is when the big prestigous tournament invites competitors who perform well in any of the smaller local competitions, or perhaps by your second or third best score among those smaller competitions so you need to participate and perform well on multiple of them but don't get much advantage for traveling to a lot of them. plus sometimes they give a free pass for the champion < 1730366667 387430 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :in the previous iteration of the big prestigeous competition. but I don't think this applies too well in bfjoust, unless you want multiple less important hills and programs automatically submitted to each of them. < 1730366681 607509 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :This is what I do in my evolver, but that's a bit of a special case. < 1730366700 22737 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :The multiple less important hills is for preventing a complete collapse of diversity and not much more. < 1730366802 816511 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :you could even use auxiliary scoring systems for which you need to run more underlying games, such as one that cares about games with a few turns of delay like you suggested above, or a scoring system that only looks at games with shorter tapes and one that only looks at games on longer tapes < 1730366821 149545 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :or one that weighs medium length tapes higher < 1730366860 231793 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :you could even have more radical changes than those < 1730367177 343255 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :whoa, you're thinking of a bfjoust variant where the code space is fungeoid but the data space is traditional bfjoust except for the one extra counter register? wow < 1730367211 326277 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ais523: I'd what modulus are you planning for the cells in the bfjoust arena? I feel like the current 256 is traditional and might not be the best < 1730367248 328929 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :256 being a power of two has some interesting implications for defence programs < 1730367277 762726 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it might be interesting to experiment with 240 (divisible by 2, 3, 5) but I am not at all sure that that is better < 1730367402 965163 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :“would make it possible to run an ‘infinitely long match’” => it might take too long time though because a program could iterate over all 28-digit integers or so with the digits in the tape positions against a goldfish. which is probably still better than what's theoretically possible in chess or arimaa with no 50 turn rule and draw only on repetition of board state, but bad enough that you < 1730367408 954495 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :can't wait for that long < 1730367426 947735 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :I was thinking mostly of a smaller modulus like 128 < 1730367449 797160 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :because it might speed games up in number of turns < 1730367508 745350 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :oh – one thing to bear in mind is that the modulus size compared to tape length is important for defenders, which need to be able to reach the other side of the tape, do some clearing, and get back before the cell is cleared < 1730367527 845564 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :that's the primary reason I made the tape shorter when introducing the modern rules – in the original rules it was really long < 1730367545 768246 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :I see < 1730367604 912711 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the "both bots are in clear loops, clearing decoys" situation should be fairly easy to optimise if you wanted to, although I'm not sure any impls actually do that < 1730367617 659750 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :“making a game that people outside the esolang community might want to play” => if that's the goal then why fungeoid code space? < 1730367642 735578 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and that would make cell size mostly irrelevant in terms of simulation speed < 1730367655 66692 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: because most programming languages designed for non-programmers are 2D < 1730367691 755885 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and most games about programming find 2D more interesting – it fits onto the screen better and gives more interesting routing problems than goto statements and labels do < 1730367703 223072 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :huh < 1730367727 858655 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :writing a loop by drawing an actual loop into the codespace is very natural for non-programmers, while and goto are a bit harder to learn < 1730367794 796109 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :although, the way you make this work visually is to have the connections between commands drawn out like flowcharts or conveyor belts, rather than being implicit like they are in Befunge < 1730367796 327876 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :are they 2D in a fungeoid sense? I don't recall many such games about programming, other than shapez and openttd and factorio, and the last two only in ways where they weren't designed as programming games but people discovered accidental programmable structures in them < 1730367814 375595 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :to be clear factorio *has* a programmable part built in, but that part isn't 2d < 1730367831 358606 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :the 2d one is making boolean circuits using belts or that sort of thing < 1730367875 494217 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :so I wonder what programming games you mean < 1730367884 325740 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :hmm < 1730367892 674058 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :"complete with cartoonish blindfolded robots desperately feeling around for flags" hehe < 1730367910 592985 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :I probably just don't play or watch many programming games though < 1730367920 247738 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs : the "both bots are in clear loops, clearing decoys" situation should be fairly easy to optimise if you wanted to, although I'm not sure any impls actually do that < 1730367927 912732 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :well I haven't for a couple of decades, it's possible that the style has changed < 1730367944 845911 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :Cost/benefit there is whether the checks to see that's happening will save more time than is saved. < 1730367966 142550 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :yes – although I expect it to < 1730367978 330433 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :that was one of the first optimisations in ratiofall, and one of the easiest to understand < 1730367990 262457 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(ratiofall = optimising The Waterfall Model interpreter) < 1730368033 321596 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it's a situation that frequently happens and you're skipping forwards a substantial proportion of 512 cycles < 1730368070 961666 :tromp!~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl QUIT :Quit: My iMac has gone to sleep. ZZZzzz… < 1730368076 175474 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :you can make the optimisation better by waiting for the bots to cross positions, then simulating them individually until they win, fall, or move back behind the crossing position < 1730368112 255507 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :that increases the chance that optimisations will apply and allows bigger skips, and there's quite a large proportion of duels where after the bots cross, they never cross back < 1730368174 781184 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :I am planning on making oxygenlance a pure rust implementation (based on chainlance), so. < 1730368186 658152 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :There is room to implement some advanced optimizations that gearlance wouldn't have. < 1730368219 198669 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :hmm, what if the code is only kind of 2D, not a fungeoid but imitates an old style computer where the instructions are stored on a magnetic disk/cylinder with a separate head for each track, so control flow always goes downwards wrapping around a fixed height code space, but you have a goto instruction to jump onto any track, and conditional skip instructions < 1730368263 531000 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :that's not for what you're saying about helping non-esoprogrammers with 2D programming games, just a general idea < 1730368353 249821 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: low-control-flow esolangs feel like that sometimes, Advance The Wheel! is somewhat reminiscent of that < 1730368379 627700 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :though there's two variants of this, one where the drums of the two jousters are synchronized with one step of the drum each turn, and one where the drums aren't synchronized and there are instructions that don't take a turn, like you might have free nop or control flow, but also a one-turn nop and one-turn cell increase decrease zero-test < 1730368386 788170 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :although instead of being able to write the tracks arbitrarily, they're all polyglots induced by different wheel positions < 1730368537 977734 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :(for extra old style the drum would store information in a mechanical way rather than magnetic) < 1730368569 254649 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :hmm, that makes me realise that Advance The Wheel! might be quite suitable to implement in a mechanical computer < 1730368594 352854 :baldibacak!~baldibaca@151.250.10.250 JOIN #esolangs * :[https://web.libera.chat] baldibacak < 1730368702 223640 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :"blindfolded robots" => and the program makes a fixed choice of one of about thirty different characters, each of which have a small difference like an extra instruction or two that they have access to, plus a variant of that character that is cosmetic only, and you need to register and attain a top 20 place with a character to unlock its shiny variant < 1730368795 80128 :iddi01!~iddi01@2604:9cc0:14:8d60:d5b0:dacd:a37a:e880 PRIVMSG #esolangs :sorry, heavily delayed response (half an hour late, scroll up to the point in time), but regarding multiple BF joust hills, i think the first step is to resurrect the egojoust hill, also so that the loads of "Trace and animation" links in the strategies pages would work again. < 1730368858 606418 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :also each game is played to two won stocks, most of the values on the tape are kept throughout but the value of the two flags and two more cells next to them and the position of the jousting heads are reset, and the programs have four starting positions in the code space depending on which stock it is starting < 1730368873 146516 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :well, we can't exactly host things on GregorR's website if the owner isn't around to maintain it – the better approach would be to reconstruct the links elsewhere, but that would mean we'd need to reimplement the animation feature because zemhill doesn't have a way to link to the feature there < 1730368909 105985 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :sorry I'm getting a bit silly here < 1730369004 162240 :salpynx!~salpynx@161.29.22.222 QUIT :Quit: Leaving > 1730369541 500294 PRIVMSG #esolangs :14[[07Assemblyfuck14]]4 10 02https://esolangs.org/w/index.php?diff=144644&oldid=75073 5* 03Baldibacak 5* (+177) 10 > 1730369774 526436 PRIVMSG #esolangs :14[[07Ecliptica14]]4 10 02https://esolangs.org/w/index.php?diff=144645&oldid=144537 5* 03Baldibacak 5* (+9) 10 < 1730369848 472726 :X-Scale!~X-Scale@89.214.114.182 JOIN #esolangs X-Scale :[https://web.libera.chat] X-Scale < 1730370143 551978 :amby!~ambylastn@ward-15-b2-v4wan-167229-cust809.vm18.cable.virginm.net JOIN #esolangs amby :realname < 1730370620 597976 :fizzie!irc@selene.zem.fi PRIVMSG #esolangs :I could add an URL syntax for custom programs to https://zem.fi/bfjoust/game/ I guess. Maybe something that just encodes the code in the URL; the wiki strategy examples are short enough for that. It's the same viewer, and you can already type stuff in the textboxes, there just isn't a way to put the code in the link, and/or to make it pre-open a specific tape length/polarity. < 1730370928 426664 :ais523!~ais523@user/ais523 QUIT :Quit: quit < 1730372190 914206 :iddi01!~iddi01@2604:9cc0:14:8d60:d5b0:dacd:a37a:e880 PRIVMSG #esolangs :^echo !zjoust clock >>>+<+<+>[(+)*29(-)*30<-[<(+++-++-+)*-1]+>(+)*30(-)*29<-[<(+++-++-+)*-1]+>]<[(+)*65(>)*8[+[--[(-)*122(-.)*11(<)*9(+++-++-+)*-1]]](<)*9(+++-++-+)*-1]<(+++-++-+)*-1 what follows is due to the design of the fungоt echo command < 1730372190 994747 :fungot!~fungot@2a01:4b00:82bb:1341::a PRIVMSG #esolangs :!zjoust clock >>>+<+<+>[(+)*29(-)*30<-[<(+++-++-+)*-1]+>(+)*30(-)*29<-[<(+++-++-+)*-1]+>]<[(+)*65(>)*8[+[--[(-)*122(-.)*11(<)*9(+++-++-+)*-1]]](<)*9(+++-++-+)*-1]<(+++-++-+)*-1 what follows is due to the des ... < 1730372192 38986 :zemhill!bfjoust@selene.zem.fi PRIVMSG #esolangs :fungot.clock: points -2.02, score 17.33, rank 30/47 < 1730372192 643257 :fungot!~fungot@2a01:4b00:82bb:1341::a PRIVMSG #esolangs :zemhill: that'd be awesomely meta.) the namestring is not portable, even from some who don't like me < 1730372261 363941 :X-Scale!~X-Scale@89.214.114.182 QUIT :Ping timeout: 256 seconds > 1730372555 829470 PRIVMSG #esolangs :14[[07Talk:PyFuck14]]4 N10 02https://esolangs.org/w/index.php?oldid=144646 5* 03None1 5* (+667) 10Created page with "==8 characters for interpreting any code== On the fewest character for turing completeness question on codegolf stackexchange, there's an answer that shows Python only needs 8 characters to interpret any Python code: exc('%0), there is a link in the answer to a repo na < 1730373545 658825 :earend1!uid657395@user/utoneq JOIN #esolangs zut :zut < 1730373802 84438 :iddi01!~iddi01@2604:9cc0:14:8d60:d5b0:dacd:a37a:e880 QUIT :Quit: Client closed < 1730373867 772715 :earend1!uid657395@user/utoneq NICK :we11en < 1730373994 146975 :we11en!uid657395@user/utoneq NICK :earend1 > 1730374386 724001 PRIVMSG #esolangs :14[[07Ecliptica14]]4 10 02https://esolangs.org/w/index.php?diff=144647&oldid=144645 5* 03Baldibacak 5* (+24) 10 < 1730374976 57452 :earend1!uid657395@user/utoneq PRIVMSG #esolangs :join #cc > 1730375199 272633 PRIVMSG #esolangs :14[[07Talk:PyFuck14]]4 10 02https://esolangs.org/w/index.php?diff=144648&oldid=144646 5* 03ShirAko 5* (+323) 10/* 8 characters for interpreting any code */ < 1730376899 352641 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu JOIN #esolangs b_jonas :[https://web.libera.chat] wib_jonas < 1730377914 691171 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :re featured language, yes, bias is the problem, in particular Underload has a decent article written about it, but with you being the only active admin it can only be featured if fizzie is willing to make the decision < 1730377971 147 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :as for one of multiple languages shown randomly on the front page, I think that only works if there is only a small pool of featured language descriptions from which the front page rolls one < 1730378275 354648 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :if you want to make sure that programs can't be overfitted then you'll probably have to add so many variations (rather than just the 21*2 current) that it's impossible to run all of them, and choose from them randomly or pseudorandomly when the hill is evaluated. for example, there could be a new instruction that behaves randomly each time it's < 1730378275 854953 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :executed, or each jouster has a small probability to pause for a turn after each instruction executed, or something like that. < 1730378324 160098 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :probably shouldn't be just a delay so that programs can be written that actively branch differently depending on the random outcome < 1730378548 351959 :wWwwW!~wWwwW@94.147.203.75 JOIN #esolangs * :[https://web.libera.chat] wWwwW > 1730378665 242321 PRIVMSG #esolangs :14[[07User:ChuckEsoteric08/Interpreters14]]4 10 02https://esolangs.org/w/index.php?diff=144649&oldid=121661 5* 03ChuckEsoteric08 5* (+1) 10/* (binary) brainfuck in CDILOI */ < 1730378814 433567 :amby!~ambylastn@ward-15-b2-v4wan-167229-cust809.vm18.cable.virginm.net QUIT :Ping timeout: 276 seconds > 1730379053 741014 PRIVMSG #esolangs :14[[07User:ChuckEsoteric08/Interpreters14]]4 10 02https://esolangs.org/w/index.php?diff=144650&oldid=144649 5* 03ChuckEsoteric08 5* (+0) 10/* (binary) brainfuck in CDILOI */ fixed > 1730379556 37921 PRIVMSG #esolangs :14[[07User:ChuckEsoteric08/Interpreters14]]4 10 02https://esolangs.org/w/index.php?diff=144651&oldid=144650 5* 03ChuckEsoteric08 5* (+1543) 10 > 1730379694 508871 PRIVMSG #esolangs :14[[07Yayimhere-like esolang14]]4 10 02https://esolangs.org/w/index.php?diff=144652&oldid=140903 5* 03Ractangle 5* (-114) 10/* Looping counter */ > 1730379739 987464 PRIVMSG #esolangs :14[[07Yayimhere-like esolang14]]4 10 02https://esolangs.org/w/index.php?diff=144653&oldid=144652 5* 03Ractangle 5* (-10) 10/* syntax */ > 1730379744 601815 PRIVMSG #esolangs :14[[07SHITS14]]4 10 02https://esolangs.org/w/index.php?diff=144654&oldid=122570 5* 03ChuckEsoteric08 5* (+1463) 10/* Interpreter */ > 1730379909 771513 PRIVMSG #esolangs :14[[07Yayimhere-like esolang14]]4 10 02https://esolangs.org/w/index.php?diff=144655&oldid=144653 5* 03Ractangle 5* (+0) 10/* syntax */ < 1730380073 476991 :amby!~ambylastn@94.119.64.8 JOIN #esolangs amby :realname < 1730380213 701449 :amby!~ambylastn@94.119.64.8 QUIT :Client Quit > 1730380773 261430 PRIVMSG #esolangs :14[[07EsoInterpreters14]]4 10 02https://esolangs.org/w/index.php?diff=144656&oldid=141374 5* 03ChuckEsoteric08 5* (+2539) 10/* Main table */ Added SHITS in CDILOI > 1730380917 149021 PRIVMSG #esolangs :14[[07PyFuck (kuangkzh)14]]4 N10 02https://esolangs.org/w/index.php?oldid=144657 5* 03None1 5* (+577) 10Created page with "'''PyFuck''' is an esolang invented by [https://github.com/kuangkzh GitHub user kuangkzh] in 2022 (according to the edit time of codegolf stackexchange answer and GitHub repo) that uses only 8 characters: exc('%x), but it can run any Python program. > 1730380935 289109 PRIVMSG #esolangs :14[[07EsoInterpreters14]]4 10 02https://esolangs.org/w/index.php?diff=144658&oldid=144656 5* 03ChuckEsoteric08 5* (-1) 10 > 1730380966 797703 PRIVMSG #esolangs :14[[07Special:Log/move14]]4 move10 02 5* 03None1 5* 10moved [[02PyFuck10]] to [[PyFuck (ShirAko)]] > 1730380966 813771 PRIVMSG #esolangs :14[[07Special:Log/move14]]4 move10 02 5* 03None1 5* 10moved [[02Talk:PyFuck10]] to [[Talk:PyFuck (ShirAko)]] > 1730381060 925890 PRIVMSG #esolangs :14[[07PyFuck14]]4 10 02https://esolangs.org/w/index.php?diff=144663&oldid=144660 5* 03None1 5* (+152) 10Removed redirect to [[PyFuck (ShirAko)]] > 1730381087 129924 PRIVMSG #esolangs :14[[07PyStr14]]4 N10 02https://esolangs.org/w/index.php?oldid=144664 5* 03None1 5* (+30) 10Redirected page to [[PyFuck (ShirAko)]] > 1730381128 160833 PRIVMSG #esolangs :14[[07PyFuck (kuangkzh)14]]4 10 02https://esolangs.org/w/index.php?diff=144665&oldid=144657 5* 03None1 5* (+38) 10 > 1730381155 608211 PRIVMSG #esolangs :14[[07PyFuck (kuangkzh)14]]4 10 02https://esolangs.org/w/index.php?diff=144666&oldid=144665 5* 03None1 5* (+43) 10 > 1730381174 147132 PRIVMSG #esolangs :14[[07PyFuck (ShirAko)14]]4 10 02https://esolangs.org/w/index.php?diff=144667&oldid=144659 5* 03None1 5* (+44) 10 < 1730381270 222944 :baldibacak!~baldibaca@151.250.10.250 QUIT :Quit: Client closed > 1730381314 833543 PRIVMSG #esolangs :14[[07Talk:PyFuck (ShirAko)14]]4 10 02https://esolangs.org/w/index.php?diff=144668&oldid=144661 5* 03None1 5* (+415) 10/* 8 characters for interpreting any code */ > 1730381579 311556 PRIVMSG #esolangs :14[[07Language list14]]4 M10 02https://esolangs.org/w/index.php?diff=144669&oldid=144570 5* 03None1 5* (+10) 10/* P */ > 1730381603 366758 PRIVMSG #esolangs :14[[07Language list14]]4 10 02https://esolangs.org/w/index.php?diff=144670&oldid=144669 5* 03None1 5* (+24) 10/* P */ > 1730381630 873042 PRIVMSG #esolangs :14[[07Hello world program in esoteric languages (N-S)14]]4 10 02https://esolangs.org/w/index.php?diff=144671&oldid=144612 5* 03None1 5* (+10) 10/* PyFuck */ > 1730381645 992253 PRIVMSG #esolangs :14[[07Hello world program in esoteric languages (N-S)14]]4 10 02https://esolangs.org/w/index.php?diff=144672&oldid=144671 5* 03None1 5* (+10) 10/* PyFuck (ShirAko) */ > 1730381674 836336 PRIVMSG #esolangs :14[[07PyChr14]]4 10 02https://esolangs.org/w/index.php?diff=144673&oldid=144616 5* 03None1 5* (+10) 10/* See also */ > 1730381812 932024 PRIVMSG #esolangs :14[[07JSFuck14]]4 10 02https://esolangs.org/w/index.php?diff=144674&oldid=144564 5* 03None1 5* (+52) 10/* External resources */ > 1730382236 275734 PRIVMSG #esolangs :14[[07Special:Log/upload14]]4 overwrite10 02 5* 03None1 5* 10uploaded a new version of "[[02File:Brainfuck stegfuck.png10]]": the brainfuck logo taken from daniel b cristofani's brainfuck page had no license with it so it is not public domain after all. any admin who sees this please delete the original image, new image is a screenshot of the title of the brainfuck page in esolang > 1730382404 947411 PRIVMSG #esolangs :14[[07Special:Log/upload14]]4 overwrite10 02 5* 03None1 5* 10uploaded a new version of "[[02File:Ternlsb bf.png10]]": the brainfuck logo taken from daniel b cristofani's brainfuck page had no license with it so it is not public domain after all. any admin who sees this please delete the original image, new image is a screenshot of the title of the brainfuck page in esolangs wiki < 1730382876 517639 :chiselfuse!~chiselfus@user/chiselfuse QUIT :Remote host closed the connection < 1730382895 413149 :chiselfuse!~chiselfus@user/chiselfuse JOIN #esolangs chiselfuse :chiselfuse < 1730384066 960813 :Sgeo!~Sgeo@user/sgeo JOIN #esolangs Sgeo :realname < 1730385508 477478 :X-Scale!~X-Scale@89.214.123.189 JOIN #esolangs X-Scale :[https://web.libera.chat] X-Scale > 1730387818 79901 PRIVMSG #esolangs :14[[07C-fuck14]]4 10 02https://esolangs.org/w/index.php?diff=144677&oldid=144600 5* 03Baldibacak 5* (-864) 10Blanked the page < 1730388510 26755 :earend1!uid657395@user/utoneq QUIT :Quit: Connection closed for inactivity > 1730388812 891603 PRIVMSG #esolangs :14[[07PyFuck (kuangkzh)14]]4 10 02https://esolangs.org/w/index.php?diff=144678&oldid=144666 5* 03ShirAko 5* (+366) 10Added Hello World as an external ressource (100MB) > 1730388866 722316 PRIVMSG #esolangs :14[[07Special:Log/move14]]4 move10 02 5* 03ShirAko 5* 10moved [[02PyFuck (ShirAko)10]] to [[PyFuck (shirAko)]]: Misspelled title > 1730388866 741709 PRIVMSG #esolangs :14[[07Special:Log/move14]]4 move10 02 5* 03ShirAko 5* 10moved [[02Talk:PyFuck (ShirAko)10]] to [[Talk:PyFuck (shirAko)]]: Misspelled title > 1730388897 225084 PRIVMSG #esolangs :14[[07PyFuck14]]4 10 02https://esolangs.org/w/index.php?diff=144683&oldid=144663 5* 03ShirAko 5* (+0) 10 > 1730388915 23578 PRIVMSG #esolangs :14[[07User:ShirAko14]]4 10 02https://esolangs.org/w/index.php?diff=144684&oldid=144621 5* 03ShirAko 5* (+136) 10 > 1730389078 511416 PRIVMSG #esolangs :14[[07Hello world program in esoteric languages (N-S)14]]4 M10 02https://esolangs.org/w/index.php?diff=144685&oldid=144672 5* 03ShirAko 5* (+210) 10Added hello world for PyFuck (kuangkzh) < 1730389080 350987 :baldibacak!~baldibaca@151.250.10.250 JOIN #esolangs * :[https://web.libera.chat] baldibacak < 1730389839 351560 :wWwwW!~wWwwW@94.147.203.75 QUIT :Ping timeout: 256 seconds < 1730392104 586536 :baldibacak!~baldibaca@151.250.10.250 PRIVMSG #esolangs :hi > 1730392335 792852 PRIVMSG #esolangs :14[[07Special:Log/delete14]]4 delete10 02 5* 03Ais523 5* 10deleted "[[02File:Brainfuck stegfuck.png10]]": Deleted old revision 20241031134356!Brainfuck_stegfuck.png: Copyright violation: this version of the image was a derivative of a non-public-domain image (the updated version is not based on it) > 1730392359 110298 PRIVMSG #esolangs :14[[07Special:Log/delete14]]4 delete10 02 5* 03Ais523 5* 10deleted "[[02File:Ternlsb bf.png10]]": Deleted old revision 20241031134644!Ternlsb_bf.png: Copyright violation: this version of the image was a derivative of a non-public-domain image (the updated version is not based on it) > 1730392475 404741 PRIVMSG #esolangs :14[[07PyFuck (kuangkzh)14]]4 10 02https://esolangs.org/w/index.php?diff=144686&oldid=144678 5* 03Ais523 5* (+0) 10fix definition of the language: the original author said that that the language allows `0` (and the previously written specification had `x` twice, likely a typo) < 1730392632 40572 :Lord_of_Life!~Lord@user/lord-of-life/x-2819915 QUIT :Excess Flood < 1730392744 275547 :Lord_of_Life!~Lord@user/lord-of-life/x-2819915 JOIN #esolangs Lord_of_Life :Lord > 1730394044 263476 PRIVMSG #esolangs :14[[0710 114]]4 10 02https://esolangs.org/w/index.php?diff=144687&oldid=144596 5* 03Baldibacak 5* (-68) 10fixed compiler ignoring first character on input > 1730394058 541927 PRIVMSG #esolangs :14[[0710 114]]4 10 02https://esolangs.org/w/index.php?diff=144688&oldid=144687 5* 03Baldibacak 5* (-1) 10removed accidently added dot at the start of the program < 1730394488 875686 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu QUIT :Quit: Client closed > 1730395025 486238 PRIVMSG #esolangs :14[[07ABPLWNL14]]4 10 02https://esolangs.org/w/index.php?diff=144689&oldid=144109 5* 03Ractangle 5* (-32) 10/* Commands */ > 1730395165 772284 PRIVMSG #esolangs :14[[07ABPLWNL14]]4 10 02https://esolangs.org/w/index.php?diff=144690&oldid=144689 5* 03Ractangle 5* (-1) 10/* Hello World program */ > 1730396035 423313 PRIVMSG #esolangs :14[[07ABPLWNL14]]4 10 02https://esolangs.org/w/index.php?diff=144691&oldid=144690 5* 03Ractangle 5* (+3) 10/* Interpreter and Compiler */ < 1730396949 112320 :FireFly!~firefly@glowbum/gluehwuermchen/firefly QUIT :Ping timeout: 248 seconds < 1730397060 497306 :X-Scale!~X-Scale@89.214.123.189 QUIT :Quit: Client closed < 1730397074 381548 :FireFly!~firefly@glowbum/gluehwuermchen/firefly JOIN #esolangs FireFly :firefly > 1730398258 372955 PRIVMSG #esolangs :14[[07User:ChuckEsoteric08/Interpreters14]]4 10 02https://esolangs.org/w/index.php?diff=144692&oldid=144651 5* 03ChuckEsoteric08 5* (+2) 10/* Bitwise Cyclic Tag in CDILOI */ < 1730398400 470341 :X-Scale!~X-Scale@89.214.123.189 JOIN #esolangs X-Scale :[https://web.libera.chat] X-Scale > 1730400182 900658 PRIVMSG #esolangs :14[[07STRTRAN14]]4 10 02https://esolangs.org/w/index.php?diff=144693&oldid=144148 5* 03Froginstarch 5* (+3) 10/* Concatenation */ > 1730400197 461261 PRIVMSG #esolangs :14[[07STRTRAN14]]4 M10 02https://esolangs.org/w/index.php?diff=144694&oldid=144693 5* 03Froginstarch 5* (+3) 10/* Replacing */ > 1730400485 505916 PRIVMSG #esolangs :14[[07Yayimhere-like esolang14]]4 10 02https://esolangs.org/w/index.php?diff=144695&oldid=144655 5* 03Ractangle 5* (+0) 10 > 1730400532 943960 PRIVMSG #esolangs :14[[07Yayimhere-like esolang14]]4 10 02https://esolangs.org/w/index.php?diff=144696&oldid=144695 5* 03Ractangle 5* (+2) 10/* Truth-machine */ < 1730400560 659364 :Franciman!~Franciman@mx1.fracta.dev QUIT :Remote host closed the connection > 1730400673 250649 PRIVMSG #esolangs :14[[07Ecliptica14]]4 10 02https://esolangs.org/w/index.php?diff=144697&oldid=144647 5* 03Baldibacak 5* (+7) 10in newest version of compiler and interpreter r command is changed < 1730400814 281262 :tromp!~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl JOIN #esolangs * :Textual User < 1730401029 361898 :molson__!~molson@2001-48F8-704A-446-9B42-CDD3-9397-1B8B-dynamic.midco.net JOIN #esolangs molson :realname < 1730401033 182972 :molson_!~molson@172-103-21-94-dynamic.midco.net QUIT :Ping timeout: 252 seconds > 1730401138 474358 PRIVMSG #esolangs :14[[07Ecliptica14]]4 10 02https://esolangs.org/w/index.php?diff=144698&oldid=144697 5* 03Ractangle 5* (-39) 10/* Commands */ < 1730401582 626803 :Artea!~Lufia@artea.pt QUIT :Quit: ZNC 1.9.1 - https://znc.in < 1730401696 628342 :visilii_!~visilii@46.61.242.137 QUIT :Ping timeout: 244 seconds < 1730401714 539120 :visilii!~visilii@85.172.77.90 JOIN #esolangs * :ZNC - https://znc.in < 1730402568 880311 :tromp!~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl QUIT :Quit: My iMac has gone to sleep. ZZZzzz… < 1730402815 167210 :perlbot!~perlbot@perlbot/bot/simcop2387/perlbot QUIT :Read error: Connection reset by peer < 1730402817 571125 :simcop2387!~simcop238@perlbot/patrician/simcop2387 QUIT :Read error: Connection reset by peer < 1730403103 876972 :perlbot!~perlbot@perlbot/bot/simcop2387/perlbot JOIN #esolangs perlbot :ZNC - https://znc.in < 1730403184 387340 :simcop2387!~simcop238@perlbot/patrician/simcop2387 JOIN #esolangs simcop2387 :ZNC - https://znc.in > 1730404359 743712 PRIVMSG #esolangs :14[[07SWCE14]]4 10 02https://esolangs.org/w/index.php?diff=144699&oldid=144449 5* 03Ractangle 5* (+0) 10 > 1730404397 251611 PRIVMSG #esolangs :14[[07ASCII14]]4 10 02https://esolangs.org/w/index.php?diff=144700&oldid=97993 5* 03Ractangle 5* (+10) 10/* See also */ > 1730404478 799278 PRIVMSG #esolangs :14[[07LSCEF14]]4 10 02https://esolangs.org/w/index.php?diff=144701&oldid=78850 5* 03Ractangle 5* (+10) 10/* See also */ > 1730404536 376890 PRIVMSG #esolangs :14[[07SWCE14]]4 10 02https://esolangs.org/w/index.php?diff=144702&oldid=144699 5* 03Ractangle 5* (+64) 10 > 1730404598 506518 PRIVMSG #esolangs :14[[07SWCE14]]4 10 02https://esolangs.org/w/index.php?diff=144703&oldid=144702 5* 03Ractangle 5* (-20) 10 > 1730404610 884272 PRIVMSG #esolangs :14[[07SWCE14]]4 10 02https://esolangs.org/w/index.php?diff=144704&oldid=144703 5* 03Ractangle 5* (-44) 10 > 1730404939 83265 PRIVMSG #esolangs :14[[07Yayimhere-like esolang14]]4 10 02https://esolangs.org/w/index.php?diff=144705&oldid=144696 5* 03Ractangle 5* (-33) 10/* syntax */ < 1730404944 373896 :molson__!~molson@2001-48F8-704A-446-9B42-CDD3-9397-1B8B-dynamic.midco.net QUIT :Ping timeout: 276 seconds > 1730405020 969749 PRIVMSG #esolangs :14[[07Yayimhere-like esolang14]]4 10 02https://esolangs.org/w/index.php?diff=144706&oldid=144705 5* 03Ractangle 5* (-5) 10/* syntax */ < 1730405031 88528 :molson!~molson@2001-48F8-704A-446-2F81-D7E8-19E-DB39-dynamic.midco.net JOIN #esolangs molson :realname > 1730405218 744680 PRIVMSG #esolangs :14[[07SWCE14]]4 10 02https://esolangs.org/w/index.php?diff=144707&oldid=144704 5* 03Ractangle 5* (+33) 10/* Charecter table */ < 1730406455 70335 :Lymia!lymia@ayame.servers.aura.moe PRIVMSG #esolangs :iddi01: Why are you crediting bots to fungot? :) < 1730406455 338693 :fungot!~fungot@2a01:4b00:82bb:1341::a PRIVMSG #esolangs :Lymia: name ' math' is not defined, but never turned anything in. so you get that, > 1730407041 533712 PRIVMSG #esolangs :14[[07Talk:414]]4 10 02https://esolangs.org/w/index.php?diff=144708&oldid=140992 5* 03ChuckEsoteric08 5* (+468) 10 > 1730408065 771544 PRIVMSG #esolangs :14[[07914]]4 M10 02https://esolangs.org/w/index.php?diff=144709&oldid=144636 5* 03PythonshellDebugwindow 5* (+41) 10Categories > 1730408087 157913 PRIVMSG #esolangs :14[[079014]]4 M10 02https://esolangs.org/w/index.php?diff=144710&oldid=144316 5* 03PythonshellDebugwindow 5* (+22) 10See also > 1730408286 800175 PRIVMSG #esolangs :14[[07Suc14]]4 M10 02https://esolangs.org/w/index.php?diff=144711&oldid=120765 5* 03PythonshellDebugwindow 5* (+27) 10See also > 1730408324 117176 PRIVMSG #esolangs :14[[07Suc14]]4 M10 02https://esolangs.org/w/index.php?diff=144712&oldid=144711 5* 03PythonshellDebugwindow 5* (+23) 10/* See also */ Category > 1730408349 701922 PRIVMSG #esolangs :14[[07Sucks14]]4 M10 02https://esolangs.org/w/index.php?diff=144713&oldid=144565 5* 03PythonshellDebugwindow 5* (+39) 10Categories < 1730408529 957900 :molson!~molson@2001-48F8-704A-446-2F81-D7E8-19E-DB39-dynamic.midco.net QUIT :Ping timeout: 248 seconds > 1730409137 889956 PRIVMSG #esolangs :14[[07Definitely unusable14]]4 10 02https://esolangs.org/w/index.php?diff=144714&oldid=125116 5* 03Ractangle 5* (-98) 10Hopefully this helps > 1730409956 750168 PRIVMSG #esolangs :14[[07Definitely unusable14]]4 M10 02https://esolangs.org/w/index.php?diff=144715&oldid=144714 5* 03PythonshellDebugwindow 5* (+98) 10Undo revision [[Special:Diff/144714|144714]] by [[Special:Contributions/Ractangle|Ractangle]] ([[User talk:Ractangle|talk]]): missing the joke < 1730410167 110159 :molson!~molson@2001-48F8-704A-446-F547-A54E-21B8-C3E5-dynamic.midco.net JOIN #esolangs molson :realname < 1730410219 285059 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :fungot: The most important theorem in BF Joust is < 1730410219 427324 :fungot!~fungot@2a01:4b00:82bb:1341::a PRIVMSG #esolangs :korvo: nah, we don't need a mirror < 1730410363 839780 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :fungot: which direction of mirror? one that swaps the polarity, or one that swaps the two jousters? < 1730410363 969963 :fungot!~fungot@2a01:4b00:82bb:1341::a PRIVMSG #esolangs :b_jonas: i go to bed!" < 1730410401 114176 :tromp!~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl JOIN #esolangs * :Textual User < 1730410972 933801 :salpynx!~salpynx@161.29.22.222 JOIN #esolangs salpynx :realname < 1730412604 120563 :FreeFull!~freefull@46.205.206.114.nat.ftth.dynamic.t-mobile.pl QUIT : < 1730412949 923166 :FreeFull!~freefull@46.205.206.114.nat.ftth.dynamic.t-mobile.pl JOIN #esolangs FreeFull :FreeFull < 1730414282 930798 :tromp!~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl QUIT :Quit: My iMac has gone to sleep. ZZZzzz… < 1730415158 919024 :ais523!~ais523@user/ais523 JOIN #esolangs ais523 :(this is obviously not my real name) < 1730415624 23077 :baldibacak!~baldibaca@151.250.10.250 PRIVMSG #esolangs :a < 1730417060 634499 :int-e!~noone@int-e.eu PRIVMSG #esolangs :b_jonas: Hmm odd question because I've been watching somebody play Factorio. Would you be able to build belts like this? https://int-e.eu/~bf3/tmp/fq.png (the idea would be merging 8 yellow belts into 4 red ones, loading each output from both sides) < 1730417107 369782 :X-Scale!~X-Scale@89.214.123.189 QUIT :Ping timeout: 256 seconds < 1730417298 941017 :craigo!~craigo@user/craigo QUIT :Ping timeout: 252 seconds < 1730418094 997310 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :int-e: you can marge two yellow belts into four red belts and do that four times. you can't do it with the exact geometry that you're showing because of how belts work in factorio: you always place belt pieces in just one of four cardinal orientations, and they're normally a straight belt piece, the belt piece Y only behaves as a curved belt piece only as long there's another belt piece (or underground < 1730418100 973957 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :belt or splitter or the ghost of any of these) X such that Y is in front of X and X is on the side of Y. < 1730418173 718265 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :and that too only if there's no belt piece (or underground or splitter or ghost of one) behind Y. < 1730418175 211982 :int-e!~noone@int-e.eu PRIVMSG #esolangs :b_jonas: okay, so no lose incoming turns. cool < 1730418195 209894 :int-e!~noone@int-e.eu PRIVMSG #esolangs :I guess I could try the demo. Surely it has belts... < 1730418201 710068 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :correct < 1730418220 484816 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :but be careful, it's an addictive game < 1730418231 821264 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :try the demo only if you have years of free time to play the game < 1730418267 974272 :int-e!~noone@int-e.eu PRIVMSG #esolangs :s/lose/loose/ (meh) < 1730418375 309926 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :also currently and in the next month or so I'm only willing to discuss factrio in very limited ways because the expansion dropped and I need time to experience it alone before I look at other players' games < 1730418448 303522 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :but before and after that I do discuss it a lot, mostly on several Factorio-related Discord servers < 1730418473 621706 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :I would do so here too but nobody else seemed to be playing the game < 1730418495 742147 :int-e!~noone@int-e.eu PRIVMSG #esolangs :I am kind of trying to stay away. < 1730418548 769634 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :you could play Mindustry, it's less addictive < 1730418586 586808 :int-e!~noone@int-e.eu PRIVMSG #esolangs :But I have seen some spoilers that you don't want to hear about. But this question seemed basic enough (and probably not changed from 1.x.) :) < 1730418618 873003 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :the belt physics of Mindustry is more frustrating in some ways -- but that's kind of cheating with words, because in Factorio the belt physics is mostly fine but the belt+inserter physics can be very frustrating < 1730418637 658348 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :they're frustrating in different ways though < 1730418707 572324 :int-e!~noone@int-e.eu PRIVMSG #esolangs :uh-oh, Mindustry is name-your-own price on itch < 1730418745 133615 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :in Mindustry the frustration is that there are things that should be simple but are hard to build a reliable construction for, especially if you want it to be simple, most notably a full throughput priority merge of two belts; while in Factorio the frustration is more that the actual throughput of belt+inserter constructions can be *very* unpredictable and appear to depend on the phase of the moon < 1730418766 434846 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :int-e: Mindustry is both that and also free in source code form < 1730418781 731414 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :(plus I think there's a Steam version) < 1730418789 564482 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :(but why would you want that instead of itch.io) < 1730418879 78419 :int-e!~noone@int-e.eu PRIVMSG #esolangs :Yeah I /try/ to avoid Steam but it's not always possible. Also Valve has been surprisingly non-evil *so far*. That could easily change. < 1730418899 674620 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :of course shapez.io also doesn't have reliable priority merges, which is annoying sometimes < 1730418968 837091 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :I wish the small mergers and splitters in shapez.io were priority, with the merge preferring straight input and the split preferring curved output, because you still have the balancer if you want an even merge or split so it wouldn't lose power < 1730419143 256446 :int-e!~noone@int-e.eu PRIVMSG #esolangs :Hmm. I guess that would give you more compact overflow protection. < 1730419198 370113 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :in shapez.io I mostly wanted priority merge to have belts into the hub that prioritize the freeplay shape but bring fixed shapes (glue or one of the three upgrade shapes) in between