csh
/
y.st.
ответвлено от y.st./y.st.


			
				
					
						
						
							123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338
							<?xml version="1.0" encoding="utf-8"?>
<!--
                                                                                     
 h       t     t                ::       /     /                     t             / 
 h       t     t                ::      //    //                     t            // 
 h     ttttt ttttt ppppp sssss         //    //  y   y       sssss ttttt         //  
 hhhh    t     t   p   p s            //    //   y   y       s       t          //   
 h  hh   t     t   ppppp sssss       //    //    yyyyy       sssss   t         //    
 h   h   t     t   p         s  ::   /     /         y  ..       s   t    ..   /     
 h   h   t     t   p     sssss  ::   /     /     yyyyy  ..   sssss   t    ..   /     
                                                                                     
	<https://y.st./>
	Copyright © 2017 Alex Yst <mailto:copyright@y.st>

	This program is free software: you can redistribute it and/or modify
	it under the terms of the GNU General Public License as published by
	the Free Software Foundation, either version 3 of the License, or
	(at your option) any later version.

	This program is distributed in the hope that it will be useful,
	but WITHOUT ANY WARRANTY; without even the implied warranty of
	MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
	GNU General Public License for more details.

	You should have received a copy of the GNU General Public License
	along with this program. If not, see <https://www.gnu.org./licenses/>.
-->
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
	<head>
		<base href="https://y.st./en/weblog/2017/06-June/10.xhtml" />
		<title>So many ideas, so little time to implement them &lt;https://y.st./en/weblog/2017/06-June/10.xhtml&gt;</title>
		<link rel="icon" type="image/png" href="/link/CC_BY-SA_4.0/y.st./icon.png" />
		<link rel="stylesheet" type="text/css" href="/link/basic.css" />
		<link rel="stylesheet" type="text/css" href="/link/site-specific.css" />
		<script type="text/javascript" src="/script/javascript.js" />
		<meta name="viewport" content="width=device-width" />
	</head>
	<body>
		<nav>
			<p>
				<a href="/en/">Home</a> |
				<a href="/en/a/about.xhtml">About</a> |
				<a href="/en/a/contact.xhtml">Contact</a> |
				<a href="/a/canary.txt">Canary</a> |
				<a href="/en/URI_research/"><abbr title="Uniform Resource Identifier">URI</abbr> research</a> |
				<a href="/en/opinion/">Opinions</a> |
				<a href="/en/coursework/">Coursework</a> |
				<a href="/en/law/">Law</a> |
				<a href="/en/a/links.xhtml">Links</a> |
				<a href="/en/weblog/2017/06-June/10.xhtml.asc">{this page}.asc</a>
			</p>
			<hr/>
			<p>
				Weblog index:
				<a href="/en/weblog/"><abbr title="American Standard Code for Information Interchange">ASCII</abbr> calendars</a> |
				<a href="/en/weblog/index_ol_ascending.xhtml">Ascending list</a> |
				<a href="/en/weblog/index_ol_descending.xhtml">Descending list</a>
			</p>
			<hr/>
			<p>
				Jump to entry:
				<a href="/en/weblog/2015/03-March/07.xhtml">&lt;&lt;First</a>
				<a rel="prev" href="/en/weblog/2017/06-June/09.xhtml">&lt;Previous</a>
				<a rel="next" href="/en/weblog/2017/06-June/11.xhtml">Next&gt;</a>
				<a href="/en/weblog/latest.xhtml">Latest&gt;&gt;</a>
			</p>
			<hr/>
		</nav>
		<header>
			<h1>So many ideas, so little time to implement them</h1>
			<p>Day 00826: Saturday, 2017 June 10</p>
		</header>
<section id="general">
	<h2>General news</h2>
	<p>
		My mother and I planned to meet up today and tomorrow, but it looks like they changed their plans on me.
		No worries though, I woke up too early and am kind of tired, anyway.
	</p>
	<p>
		I considered adding support in <code>minequest</code> for nodes that drop absolutely nothing.
		There are strange chests in <code>glooptest</code> that are spawned during mapgen, but when harvested, drop nothing.
		Being able to see how many of these chests you&apos;d found would be nice.
		However, when I coded up the beginnings of support for this kind of stat tracking, I saw the only things tracked in Minetest Game were both kinds of fire and all bad crops.
		So ... while miners get their success tracked, the main thing tracked for above-ground players would be their farming failures.
		As for fire, putting out permanent flames is no accomplishment.
		I suppose acting as a firefighter and putting out the other type of fire could be positive, but it&apos;d be better to just not start those kinds of fires.
		Anyway, this doesn&apos;t bode well for arbitrary-drop-list-length support.
		Now, in addition to having a complete inability to reliably display such drops on the stats page, I need to deal with the fact that zero-item drops are usually not a positive thing to track.
		My new, compact design doesn&apos;t fit well with arbitrarily-long lists of items, either.
		Worry for space was already a concern before I crunched everything together.
	</p>
	<p>
		While messing around between coding things, I found an item-duplication bug.
		If you dig the node under a grass node, two grass items fall instead of one.
		I thought it was a bug in Minetest.
		The only mods I had running was <code>minestats</code> and a mod I put random debugging code in, neither of which should introduce that sort of thing.
		I disabled them both to be sure though.
		I was wrong!
		<code>minestats</code> was doing it!
		Ugh.
		It seems that when the node supporting an attached node, such as grass or a torch, is removed, the <code>minetest.get_node_drops()</code> function is called on the attached node.
		However, there&apos;s no digger, so <code>minetest.handle_node_drops()</code> is never called.
		In <code>minetest.get_node_drops()</code>, I set an extra key containing the dug node&apos;s name to be used by <code>minetest.handle_node_drops()</code>, then <code>minetest.handle_node_drops()</code> removes it.
		This allows me to get ahold of the node name, the drops, and the player object all at once, as there&apos;s no callbacks that actually allow me to have all this information at once.
		I found a way to pull off what I need though.
		I added a space and a zero to the end of the node name when adding it to the drops.
		That way, Minetest will interpret it as an empty stack while my code can simply ignore the quantity.
	</p>
	<p>
		I had a flash of inspiration as to how to add some surface elements to <code>minestats</code> in an otherwise vanilla instance of Minetest Game.
		What if dropped nodes are irrelevant?
		What if a counted mineral can be acquired even if the node drops it along with other nodes?
		This has two implications.
		First, it would allow farm crops to be countable when they drop their crop as opposed to their seed, even if they drop the seed also.
		Second, as the drop counted isn&apos;t the full drop of the node, it begs the question of if the dug node is even relevant.
		Should I merge the counts of dropped items dropped by different nodes?
		Should I count a drop of three of the same item as the same as three drops of one of that same item?
		Logic tells me yes.
		My passion tells me no.
		I like having the node display by the drop in the menu.
		If the node is unknown or if multiple nodes have that same drop, I can&apos;t have that any more.
		Even more so, I don&apos;t like the idea that when a node drops a variable number of something, the numbers should simply be added together.
		I like knowing not only how many of the item I&apos;ve collected, but also home many of the node I&apos;ve dug and at what frequency I get each number of drops.
		But is keeping that separated out inconsistent with counting only part of the drop to begin with?
		I&apos;m not sure.
		I programmed the beginnings of support for the itemised version of this, and it spammed the stats page with various cotton and wheat plant stages.
		Two plants, multiplied by eight stages, multiplied by two drop levels (one or two of the crop).
		That&apos;s thirty-two of what is basically only two plants.
		It seems quite a bit excessive, and yet, each one of those nodes is important for game play to farmers.
		In other words, the problem is in my mod, not <code>farming</code>.
		In the case of farming, I don&apos;t mind merging the drops.
		Farm plants are renewable, which means what I care about is the total number acquired, not where they came from.
		On the other hand, minerals are <strong>*not*</strong> renewable, so I care about drop rates.
		If there&apos;s only so much of the material, I want to know exactly how much I&apos;m getting gypped!
		Furthermore, if I merge the drops and ignore what node they come from, there are only two farming drops and eight mineral drops in Minetest Game.
		Honestly, <code>minestats</code> is still skewed in favour of miners.
	</p>
	<p>
		I ran out of time to program, but I did a lot of thinking about <code>minestats</code> today.
		I came to a realisation: it&apos;s no wonder I&apos;ve been failing to find a way to capture surface nodes to log.
		There are three main sets of nodes.
		There are the nodes underground.
		These nodes are often finite in quantity, but with how large the underground is, there&apos;s plenty of them.
		Then, there&apos;s the renewable surface nodes.
		These nodes can be created in mass, but it takes time.
		Rarest of all, we have the finite surface nodes.
		Most people think these are the most common nodes, but they&apos;re only on the surface and the surface is so thin.
		For the most part, these nodes just get moved around, not used up, though you could waste desert stone to make stone picks or something.
		Anyway, this second type of node, the renewable surface nodes, typically take the form of plants.
		A key part of their renewability though is the fact that they leave behind something that can be placed in the world, something that will change into several nodes, which will once again leave behind something so the cycle can continue.
		I&apos;ve been ruling out nodes that drop more nodes.
		Anti-node-dropping is anti-renewal though!
		I don&apos;t need to detect against node-dropping or multi-item-dropping, I just need to detect in favour of craft-item-dropping.
		It&apos;s worth noting though that while this allows me to log farm plants, it puts the logging of saplings and seeds so far out of reach that it&apos;s not even worth continuing to attempt to log them at all.
		Farm plants will have to be enough.
	</p>
	<p>
		I started in my mind reevaluating the way I classified nodes for consideration.
		When I use the term &quot;mineral&quot; in Minetest, I&apos;m not referring to metals and stones.
		I&apos;m referring to nodes that drop a single craft item instead of themselves.
		I just call them minerals because most of them represent things you&apos;d actually call minerals in the real world.
		I came up with two new terms to describe the phenomenons I was now trying to measure.
		First are the hybrid minerals.
		These drop not only the craft item that a true mineral would drop, but also a node.
		The craft item should be logged and the node ignored.
		Second, we have the compound minerals.
		These minerals drop multiple craft items.
		Each can be logged separately, though we don&apos;t have a good way to measure them as a single drop just yet.
		Later in the day, I realised that compound minerals were just a subclass of hybrid minerals, just mixed with other minerals and not a regular node.
	</p>
	<p>
		I&apos;ve been planning to put plants on a separate page if I could figure out how to log them for as long as I&apos;ve been trying to include plants at all.
		Additionally, as I&apos;ll have to leave the node data out for the plants, they won&apos;t fit the format for the minerals page.
		The only way to include them is to either leave off the nodes for all logged items or put the plants elsewhere.
		It&apos;s far too cool having the mineral nodes display, so I&apos;m not removing that feature.
		At this point, my main motivation for continuing to try to log plant-harvesting has been to try to balance the mod and make it less biased against surface-dwellers.
		I&apos;m a complete mole, but not everyone is.
		Now that I&apos;m so close, I started thinking about what I&apos;m going to do about the separate menu pages.
		If I make the starting page, before switching, be the mineral page, it makes the plants seem less important.
		I don&apos;t want to make the plants seem like second-class harvestables though.
		If I do the reverse, I make the minerals seem less important.
		What to I do for fair treatment?
		I found a solution though.
		When choosing the stats tab, the page automatically chosen to start at will be determined by the player&apos;s elevation.
		When underground, the mineral page will be the default.
		When near or above the surface, plants will take precedence.
		Additionally, I thought about the inclusion of node data for minerals but not plants.
		Is that fair?
		Game-play-wise, it makes sense.
		The default game defines eight different plant nodes for each of the two crops.
		Logging all that separately will result in a stats page people won&apos;t enjoy because it looks far too itemised and redundant.
		However, can we justify this in a way that isn&apos;t specific to Minetest Game; a way that is subgame-agnostic?
		It turns out we can!
		The mineral nodes only drop one thing, so we can see a direct conversion from one state to another.
		However, with the plants, part of the plant becomes the crop and another becomes the seed.
		We can&apos;t see which part becomes which, so we can&apos;t separate it out.
		We can&apos;t show a before state, as we don&apos;t know the before state of the pure item, not entangle with the other item.
		We don&apos;t have to keep them itemised either, as the pure before state of each is probably the same, but the node is different because the crop is mixed with something else, so it looks different.
		In the case of plants, it&apos;s mixed with a different stage of the organism.
		I think I&apos;ve found the true purpose of <code>minestats</code>: to log the dropping of non-nodes when digging nodes.
		With this more clear goal in mind, I think I&apos;ll end up with better results than I&apos;ve been getting.
	</p>
	<p>
		With the problems of <code>minestats</code> seemingly solved, I turned my attention to <code>minequest</code>.
		Now, I had four plants to choose from in addition to the eight minerals.
		Do I make <code>minequest</code> default to use plants for some bonus slots?
		That seems like a good idea.
		But which minerals do I remove from the default line-up?
		Or do I have more than eight bonus slots?
		Do I have two slots for each plant, as each plant can drop either one or two of its crop, so there are two stats for each?
		While it would balance out the bonus slots by having half be for surface nodes and half for subterranean nodes, I decided against this plan. It might&apos;ve worked for the original design of <code>minequest</code>, but in its current, more dynamic state, it would result in two slots with the same available bonuses.
		That&apos;s needlessly boring.
		Should I randomise the default slots, using all available minerals and mineral hybrids, based on the world seed?
		At first, I liked this idea.
		It seemed to remove the hard-coded connection between <code>minequest</code> and Minetest Game, but that was only a ruse.
		<code>minequest</code> has to add the default bonuses for the items from Minetest Game, so it&apos;s already got to be hard-coded to know about minerals from it.
		The default bonus slots should therefore actually be thought out.
		I decided the likely minerals to leave out will be flint and gold.
		Just like having multiple bonus slots that take the same bonus-giving items would be boring, flint and gold have the least amount of bonus options, so they&apos;re the least fun.
	</p>
	<p>
		I thought about the bonus items wheat and cotton would have at their disposal.
		Wheat is kind of limited, but it&apos;s got a few option.
		Cotton though, can be crafted into a multitude of coloured wools (as wool comes from cotton in Minetest, not animals).
		Each colour would do something different.
		After a bit though, I realised that cotton would only have access to the white wool node.
		The other colours of wool are crafted using group-based craft recipes.
		<code>minequest</code> ignores those.
		Originally, this was a bug, but it became a feature later.
		I left out group compatibility in the craft-chain-detection because I didn&apos;t like the idea that a bonus item might be crafted without the mineral that powers its bonus.
		For example, a vessel shelf is crafted from six wood and three vessels, vessels being items in the <code>vessel</code> group.
		Vessels can be made from steel, but they can also be instead made from glass.
		If the shelf is made without steel, why should it work with the iron bonus slot?
		Since it&apos;s not possible to tell which items were made with or without iron, only those that <strong>*could have been*</strong>, the way to play it safe would be to disable this group-based detection.
		But now, giving options for surface-dwellers seemed to depend on adding group support.
		I thought about it more, and came to a conclusion I&apos;d missed before.
		Group-based recipes are dynamic, but the logic behind ignoring them doesn&apos;t make sense.
		Someone could define two recipes for crafting a single item; one that includes a mineral and one that doesn&apos;t.
		Unless I&apos;m going to rule out those items too, it makes no sense to ignore group-based crafting.
		Like with the <code>lapis</code> mod and gravel treatment, consistency dictates that I must add this feature.
	</p>
	<p>
		I&apos;ll probably have almost no time to code any of this tomorrow, but maybe I&apos;ll get a chunk of it done the next day.
	</p>
	<p>
		The purple-veined dandelions I got at the food giveaway yesterday looked like they wouldn&apos;t keep too long, so I sliced them up to use in soup.
		What&apos;s the proper way to prepare dandelion?
		I have no idea, and I didn&apos;t look it up; I just boild them with everything else.
		I also sliced up the rest of my green onions, as they looked like they would be spoiled beyond th epoint of usability soon.
		I&apos;d originally planned to use the kale for the soup instead of dandelions, but the kale looks like it has quite a bit of shelf life.
		I have so many carrots right now, so I chopped some up and threw them in too.
		Most of them are carrots I bought myself, and after visiting the food place, I kind of with I&apos;d waited for carrots.
		I threw in nutritional yeast, bullion, soy milk, water, rice, and fake meat ...
		I hoped it&apos;d come out well.
		It didn&apos;t.
		This soup is outright nasty.
		It&apos;s only the dandelions themselves that are so horrid though; the rest of the soup&apos;s perfectly fine.
		I&apos;m convinced that either I don&apos;t like dandelions (I can&apos;t remember ever eating them before) or I&apos;ve prepared them completely wrong.
		In any case, I don&apos;t plan to get dandelions again any time soon.
		After work, I added almost a full bottle of oregano, some fake cheese that I&apos;d planned to use for sandwiches, more nutritional yeast, and some lemon dill seasoning, all in hopes of making this soup more tolerable by drowning out the dandelions.
		I refused to just throw the soup away; I&apos;m going to eat it no matter what it takes to get it down.
		I&apos;m kind of sad to lose that fake cheese though, I almost never buy that stuff, and can&apos;t really afford to buy more now.
		Thankfully, I was able to make the soup decent.
		The dandelions are no longer so terrible, so ... bitter, I guess would be the best way I can describe them.
		I think the oregano was the most likely to be the key.
		I&apos;m not a big user of spices usually though, so if I need to keep a pantry full of oregano to make dandelions edible, I shouldn&apos;t keep dandelions in my refrigerator.
	</p>
	<p>
		I may or may not have mentioned it, but I got ahold of a bed frame a while back.
		It&apos;s one of those small, collapsible, metal frames with the wheels.
		I think it&apos;s only twin-sized though, and without the bed slats, the thing&apos;s useless for now.
		I&apos;ve repeatedly stepped on it over the past month or so, and every time, it hurts.
		I try to avoid it, but sometimes I forget.
		Today, I managed to gouge my heel pretty good on it though.
		Up until today, I hadn&apos;t actually injured myself.
		I&apos;ve left the bed frame where it&apos;s been out of lack of another place to put it, but now, I made sure to <strong>*find*</strong> a place to put it.
		It&apos;s not the best place, but I&apos;ve stashed it, upright, in the closet with the water heater.
	</p>
	<p>
		My <a href="/a/canary.txt">canary</a> still sings the tune of freedom and transparency.
	</p>
</section>
<section id="dreams">
	<h2>Dream journal</h2>
	<p>
		I dreamed I was sitting on my bike, with my bike locked to a bike rack.
		I forget what I was doing, but I wasn&apos;t planning on moving any time soon.
		A thief ran up with a pair of bolt cutters, asked if I minded if they stole my bike, and cut the lock.
		They seemed to think their presence would either scare me away or startle me off my bike so they could take it, and when it didn&apos;t, they ran off without the bike to steal other things.
		Instead, I was mostly shocked, so I stayed put for a few moments while I took in the scene.
		Looking around, there were several thieves, all part of the same group, taking anything that wasn&apos;t nailed down.
		I was afraid, but also defensive of my bike, and glad I didn&apos;t leave it unattended.
		With nothing binding the bike to the rack any more, I rode the bike away as quickly as I could, frequently checking behind me to see if I was being pursued.
		I wasn&apos;t.
		The thieves weren&apos;t interested in me, or so I thought.
	</p>
	<p>
		I ended up with Cyrus somehow, and the bike was no longer with me.
		Random people seemed to want to get ahold of us, but were trying to act unsuspicious.
		I didn&apos;t buy it though, and we ran.
		The thieves nearly caught up with us, but then they made the mistake of talking to the other people that wanted us and asking about us.
		The apparent leader of the combined group, one of the non-&quot;thieves&quot;, told them off for their idiocy in blowing the cover of the non-&quot;thieves&quot;, and motioned in our direction.
		We&apos;d seen the whole thing.
		It appeared they were part of some normally-stealthy government agency that wanted us, but this wan&apos;t explicitly stated.
		They managed to back us into a corner, and we had no where to run.
	</p>
	<p>
		At this point, I came to two realisations.
		First, this was a dream.
		I could do whatever I pleased.
		Second, I had to protect Cyrus.
		I guess I didn&apos;t fully comprehend the fact that this was a dream after all, as I thought Cyrus and the danger we were in were real.
		I let out an energy blast from my hands, burning into disintegration half of our pursuers.
		I hit hat many due to their close proximity.
		I let out a second blast, nearly frying a small child that had come up on us, but I stopped the energy mid-air and dissipated it.
		This was a dream, and I could do whatever I felt like.
		I then let out a third energy blast and disintegrated the other half of our pursuers, again, able to hit them all because they were crowded around us.
		I felt a little bad about the killing (again, I only seemed to <strong>*partly*</strong> realise this was a dream), but I knew I&apos;d done what I had to.
	</p>
</section>
		<hr/>
		<p>
			Copyright © 2017 Alex Yst;
			You may modify and/or redistribute this document under the terms of the <a rel="license" href="/license/gpl-3.0-standalone.xhtml"><abbr title="GNU&apos;s Not Unix">GNU</abbr> <abbr title="General Public License version Three or later">GPLv3+</abbr></a>.
			If for some reason you would prefer to modify and/or distribute this document under other free copyleft terms, please ask me via email.
			My address is in the source comments near the top of this document.
			This license also applies to embedded content such as images.
			For more information on that, see <a href="/en/a/licensing.xhtml">licensing</a>.
		</p>
		<p>
			<abbr title="World Wide Web Consortium">W3C</abbr> standards are important.
			This document conforms to the <a href="https://validator.w3.org./nu/?doc=https%3A%2F%2Fy.st.%2Fen%2Fweblog%2F2017%2F06-June%2F10.xhtml"><abbr title="Extensible Hypertext Markup Language">XHTML</abbr> 5.1</a> specification and uses style sheets that conform to the <a href="http://jigsaw.w3.org./css-validator/validator?uri=https%3A%2F%2Fy.st.%2Fen%2Fweblog%2F2017%2F06-June%2F10.xhtml"><abbr title="Cascading Style Sheets">CSS</abbr>3</a> specification.
		</p>
	</body>
</html>