The planetary model of software development.
Intro. If you've not been following along, Eulora is a shockingly successfuli reality simulator that has already delivered very important practical results, and will no doubt continue to shape human understanding of the digital environment for many decades to come.
Those lofty points aside, a major part of the player's daily life is automation, much like in any other research lab. Large piles of experimental data are required to chart a profitable path through the murky waters of Eulora ; and once such a path is charted even larger piles of work will have to go into actually realising that knowledge - for what use is it to discover a way to realise a 0.35% profit on an economic cycle if you don't then proceed to actually go through the cycle and actually realise that profit ?
Since it's not practical to do the millions of clicks involved in even moderate operations by hand ; and since Minigame (MPEx:S.MG, Eulora's publisher) implements a very enlightened policy with regards to bottingii ; and since Eulora's vibrant community is composed almost exclusively of intelligent, IT-literate folks, it then follows that there exists an open source general purpose platform bot. It's called Foxybot, and it recently celebrated its one year aniversary!
The problem with it being, of course, that it does not work. Exactly like cars, which do not work - because they break down occasionally, not to mention they need fuel ; exactly like airplanes, which don't go through water nor outer space ; exactly like bridges, which can't be moved ; exactly like any other bit of human industry or application of technology Foxybot does not work because it does what it does rather than what you wanted it to do.
mircea_popescu And in daily miner's frustration, leave bot running, it "loses" table in inventoryiii at try 100, spends the next 2540 tries "not finding it" and there we go.
diana_coman Weird, mine went fine the whole night, 3400 tries. Even found an sbiv ord bhv.
mircea_popescu Aaand it just did it again. 99th explore, lost table, 4k explores sat in spot did jack shit. I simply can not explore anymore, it NEVER works. It just leaves table in inv and sits there.
diana_coman Well, you can always go *without* a table if that is the thing that annoys most.
mircea_popescu No, because w/o a table I'm guaranteed to stop in say 100 tries anyway because weight. ~7k clicks - wasted since yest, I'm running at 0.3% capacity over here.
diana_coman Basically the only real solution to this is to make the bot a bit brighter to actually search the inventory for the right table.
mircea_popescu Could just use the first...
diana_coman Uhm, no. That will just give you a different thing to complain about, lol.
mircea_popescu What, "don't be an idiot and keep all other tables in last slots" ?
diana_coman Because at some point you'll get stuff in inv and then an old table will become "first" and then complain.
mircea_popescu I keep all my other tables in the absolute last slots anyway.
diana_coman Oh, you mean if they are all very last slots then if inv gets full it will segfault anyway, so yeah.
diana_coman Mmk, will look for the smallest patch. I suppose that is the root cause there: pretty much nothing is actually reliable so poor bot is kind of trying as best it can. Anyways, will cook up something.
mircea_popescu Yeah this'll have to be fixed eventually. Whole client is written in this "fuck you, click again" Windows persepective. It needs to be a lot more like the linux kernel : either it's done or it's not done and you know which it was.
shinohai pidof craftable1.
diana_coman shinohai, laugh or cry but the same damn table has an entirely new id each time it moves from inventory to world and the other way around. See this table on my back? Abracadabra now it's a whole NEW table on the ground!!
[after a time]
diana_coman mircea_popescu and anyone struggling with the bot getting jammed on not finding table in inventory: in botactivity.cpp, method ExploreActivity: DoDropTable() replace the line " worldHandler::DropFromSlot(tableSlot, 1);" with "worldHandler::ExecCmd(csString("/drop Craft-Table"));". This means the bot will always drop A craft-table, hopefully the right one (obv, keeping only one table in inventory ensures it drops the right one; keeping all *other* tables on the very last slots in inventory gives you a good chance that it always drops the one you want rather than a different one, but no guarantees). Should be line 556 in src/client/foxybot/botactivity.cpp that you need to replace there.
mircea_popescu Ah ty. Will need recompile yes ?
mircea_popescu Aite Ima try this later an' report. Can I just ftjam or do I have to reconfiugure ?
diana_coman Ftjam is enough.
mircea_popescu Well im back in! Seems to be working.
diana_coman Good then.
mircea_popescu It's not dropping off the first table.
diana_coman Ahem, as I was saying "drop" is not reliable.
mircea_popescu It's dropping off the LAST one. This was some havoc lol.vi
diana_coman Ahahahaha. So move everything to the first slots then? TBH I would not even guarantee that it is *always* the last one.
mircea_popescu It's not. It's not the fiurst, it's noit the last, it's not the first he touched, nore the last he touched. It's... random. Motherfucker.
diana_coman Welcome to the wonders of the planeshift code. Now you know *why* the poor bot was trying to keep track of where *the table* actually is
mircea_popescu I got an idea though. Might work with single table.vii
diana_coman That for sure, yes. If you have only one table in inv, it should always work. Kind of "hey, cut a leg and then this car will move you about faster" but myeah.viii
mircea_popescu So Ima move all these shits into other types of containers. Hey, if this solves my stuck problems im happy because it really kills my production.
[after a time]
mircea_popescu Bot seems to be working ok in the new formulation.
[after more time]
mircea_popescu Well now it just decided to stop putting keys in claims, so still wasted half the time.ix At least not 99.7% like last time.
diana_coman Lags WILL mess it up to some extent, no decision involved though, lol.
[after some time]
mircea_popescu So after all the work "fixing" Foxybot, it's altoghether not clear any improvement was had. The main point is that the bot is still not working when I wake up, just as it wasn't before. With the fix it evidently worked longer, which is an advantage, but it also worked wastefully, which is to say i have >50 enums it never exploited, like 100k ECux worth. Which is better ? Total toss-up I guess. Very fucking frustrating
diana_coman Sucks. Not sure what the bot can do though, it sends the right things in right order; things get delayed/lost.
mircea_popescu I guess the only thing it can do is make a queue, an executor AND a checker.
diana_coman That's why I was a bit weary of powering it through everything: because usually when something goes wrong, powering through means only that you will end up wasting stuff. Remaking the client basically works, I agree.
mircea_popescu Myeah. Anyway, wrt the keys : could it be made to DROP them like the table, instead of putting them in ? Or even better, could it also do a /drop tiny key every step ?
diana_coman Sure, why not, especially now that the keys have different names so you don't end up dropping an ord key. Add for instance after that line you added last time another one with the command for dropping a tiny.
mircea_popescu Yeah totally, will do this. Becomes unsafe to carry tiny keys, meaning it's a very kludge, but I don't and I need a fix here.
diana_coman So worldHandler::ExecCmd(csString("/drop Tiny Claim Key"));
mircea_popescu Yup ty. This is actually great, because it fixes what was definitely a specific problem (tiny key choke). I'm curious if it can find anything now. Anyway. 300 tools, one stack lbn, 1k cft, altered bot mark III deployed. Will report moar.
shinohai Good luck!
diana_coman Hm, I'd run out of 1k cft with waaay less than 300 tools. Then again: what q are those tools of yours?
mircea_popescu 10-11k durability. Anyway, if it exhausts the cft stock without a hitch I'm entirely happy, it's like 2 days' worth. But so far this has been beautiful - the bot lost the supply of tiny keys from the prev failure, I didn't have to click like an idiot myself :D
* mircea_popescu has just realised that this fix is actually pretty dangerous. Before - if you sent it mining without cft/lbn, it'd eventually choke on keys and stop. But enums stack, you can end up wasting all the tools you got and ending up with a pile of unusable enums.
diana_coman Aha. Bot design is a very interesting thing.
mircea_popescu Yeah srsly. I'm half considering adding a stop condition for no lbn / no cft. In the end this thing is organically evolving under industrial pressure very far away from any sort of sensible design. Perhaps informative as to the destructive forces applying to software generally.
diana_coman Well, that's how it usually happens, yes.
mircea_popescu It's understood that planets can not be arbitrarily close to the star, because the changing attraction force (it stays the same modulus, but changes direction, which IS a change and which therefore DOES deliver mechanical work), the same thing that keeps the Earth's core motlen, are strong enough to tear them apart. It's starting to look to me as if software is in the same situation, every distinct item gravitating against the Sun of practice.
diana_coman More like applying to open source as it were because you are changing your own version but essentially I have the option to see what people need/what changes they make/how it works and then incorporate it into a more reasonable design at next update if needed.
mircea_popescu But the design can not be reasonable for fundamental reasons which happen to be exactly those stated by Godel. And I wouldn't advise running this AB Mk 3 if one's a noob. it's very finely tuned to my particular needs.
diana_coman Yeah, it's not the sort of thing I would *add* /deploy as update for sure. FWIW as experience: this structure of the bot which is quite sane still is actually at least the 2nd total re-write basically. Not because I started with an insane structure but because the first one got totally messed up when confronted with practice basically.
mircea_popescu I recall.
diana_coman So no, it's not that it can't be held sane, it's only that it is VERY expensive basically. Because yeah, it's totally possible you end up needing some 3rd rewrite and so on.
So how's this for a planetary model of software development : there's an absolute origin of the space. The quality of the design of any given piece of software is inversely proportional to the distance from the origin - the further out it is, the kludgier. Centered in the very origin, there's a star, its mass a function of the practical utility of the software in question - useless software has very tiny stars.
This model then allows us to make some predictions :
- If the utility is very slight, the planet can aim to grow larger than the star, and accrete it. This prediction is confirmed by practice - there do indeed exist software projects which attempt to subsume their very faint utility.
- If the utility is moderate, worse designs will overpower better designs, which will implode due to gravitational forces. This prediction is confirmed by practice - it's what happened to lisp according to more than one expert.
- There exists a closest-safe distance from origin, given by the specific resistance of materials (ie, hardware, programming languages and other meta-tools), wherein the software presents as a molten core surrounded by a solid crust. Should such a planet move closer to the origin, through a rationalization of its design, it will thereby implode. This prediction is confirmed by practice - it's what happened to Naggum's SGML.
- Planets in the closest-safe band will outperform planets further out (because more rational design) as well as planets further in (because gravitational forces exceed the crystal bond and tear the planet apart). This is why linux exists still, and how C came to be.
- If the utility is significant, no software solution can be produced - all items that are far enough from the star to survive its pull are too far from the origin to make any sort of sense - their design is too dysfunctional for them to work at all. This prediction is confirmed by sad, sad practice.
How about that!———
- I suppose it depends on what your idea of success is.
If you're the mercenary type and think success = money, then a Grimy Toolkit sold on auction Sunday for 10 mn ECu, which is 0.1 BTC or about $65. This isn't by any means a record, just happens to be the most recent example.
If you're the corporate type that despises human life and so think success = man-hours in aggregate, then Eulora stands at 42`780 aggregate play-hours to date, which puts it firmly in the top 1% of all games ever released.
If you're the Elliot type and imagine success = individual fixation, then Eulora reported 221 hours monthly average gameplay over its entire playerbase back in 2015, and 4.75 hours monthly average (2.5 median) for the least active half of its population in 2016.
If however you're the cat-v.org type and imagine you and your online clique are the gatekeepers of success, then there's not much worth saying - enjoy the delusion while it lasts ; I'm sure you, like every other delusionist to date have a scapegoat at the ready for when the bubble bursts. [↩]
- The discussion is scattered through the monthly reports as well as irc logs, with the gist being that the only reason a game publisher has to fear or dislike bots is that they're trying to publish a broken game and defraud the general public into paying to use it, much on the lines of Microsoft and its Windows abomination. [↩]
- Sometimes lag may cause a command to fail. The bot asks for the table to be dropped from inventory to the ground, this fails to happen, and so the table stays in its inventory. For intricate reasons that have to do with the extant codebase, the bot can't simply identify this failure mode and remedy it, so it panicks that "its table is gone".
The whole reason the bot even wants to drop the table is because it's "cheating" - normally players can't move if overweight. However, if they put all the heavy stuff in a craft table and drop it on the ground they can then move a little ways, pick it up again, drop it further off and move a little more and so forth. This is called table-walking, and is extremely useful for miners, because it meshes very well with the activity of mining in the first place - which is very much move a little, try finding something, move a little more - and because it allows the carrying of huge loads such as on occasion result from very rich veins.
This also means that failure to drop a table means failure to move (as the character is still overweight) and subsequently failure to mine (as you can't explore twice in the same spot), which means that once it fails to drop the table, it's pretty much fucked, until a human operator comes to its rescue.
It should perhaps be noted here that throughout September we were offering 0.01 BTC an hour (which is US-level minimum wage, it should be pointed out) to any and all comers on an Internet forum which pretends to have 894`074 members.
About a dozen or so of these supposed almost-million members did manage to generate a PGP key for themselves and therefore play the game (0.0013%, if you like percentages), but none of them took less than half a day to do so, notwithstanding it's a ten minute task. Some particularly amusing outliers spent weeks dicking around the wide open gates of open source software. Apparently doing anything whatsover is really really hard for the chickens composing the general population - they're good enough at cycling through what they've always done forever, but entirely incapable of establishing a novel course of action. Also apparently, Internet numbers are lies - 894k members my foot. But we kinda knew that already.
Of this dozen, not one managed to discover by their own lights that no, you don't have to drag materials in small chunks to town. Of that same dozen, not one managed to find the matter being discussed openly in the logs and on the wiki, notwithstanding that they were repeatedly asked to review both. Apparently there's no fate worse than having to read, according to the general-population-chicken (except perhaps having to think, of course).
They did get frustrated with their inability to achieve efficiency, obviously. And they lashed out. Obviously. They never did nor ever would have, for dear life and all that's holy and dear on Earth, ever, no matter what, review their own behaviour or the writs available.
A couple of them even lunged at the obvious hole of just cycling through PGP signatures for the bitcent prize, rather than actually earn in game. Because, again, the chickens that compose the general population are good enough at cycling through what they've always done, and would so cycle forever, but are otherwise entirely incapable of establishing a novel course of action.
This is why the world is choking. This is why "America" needs to be made great again. It all has absolutely nothing to do with "carbon" or with "resources" or anything else. The only thing making human economy, and human society, and human life altogether unsustainable is that out of 894 thousand "people" a dozen may actually try doing something with themselves. They'll do a very poor job of it, and the couple among them bereft of ethics will not manage to significantly improve the standing of the group.
The problem is that after a couple of centuries of tolerant policies we find ourselves so covered in subhuman gunk, so far submerged under a tide of excrement that one has to sift through a million names to find a dozen that are marginally not qualified to do a simple task. Of the seven billion sacks of flesh polluting the Earth, a few hundred maybe have any business being here whatsoever.
That's the only problem, and it needs a solution imperatively. Preferably, a final solution. [↩]
- Small Branch. [↩]
- Bare Handed, ie, not using any tools. Because yes, Eulora allows you to do anything by yourself. [↩]
- Annoying as all fuck, made a mess of my things! [↩]
- You see ? This. This right here is what makes me better than the spurious billion. This right here is what makes you better, or doesn't. Do you have it ?
This is all that matters - if you don't have this, if you don't do this, you have no business here. Go kill yourself. Now. Today. You're extra, and you're in the way. [↩]
- She has a point - I'm changing the software to bake into it assumptions that are particular. [↩]
- Whenever you find a resource, a claim stick appears in the world, which is locked, and you receive the key. The keys don't stack, so if you find 80 resources, you have 80 keys. The bot puts the keys of claims it ate inside the claim - which creates an interesting niche for noobs, because the keys decay into LBN after a while, so they could just follow a bot miner and pick out the keys to sell the LBN later.
However, if the "put key in claim" thing fails (like the drop table thing fails) then you end up loading the inventory with keys and eventually the client crashes. [↩]
- The ECu, ie Eulora Copper, is equal one satoshi. [↩]