Time  Nick       Message
01:19 VanessaE   celeron55: still awake?
10:24 celeron55  https://github.com/celeron55/minetest/commit/a9d8df83d228635594b75a563a0a8d906b3b883a
10:25 celeron55  you can rollback somebody setting a forest on fire using lava.
10:25 celeron55  by a single command
10:26 celeron55  without touching what others have done at the same time or after it
10:26 thexyz     aww
10:26 thexyz     is there any examples?
10:26 celeron55  the rollback log gets a shitload of megabytes at the event of somebody doing something like that though
10:26 celeron55  (it'd compress pretty well though, but i don't care as for now)
10:27 celeron55  examples?
10:28 celeron55  make an example yourself
10:28 celeron55  it should also succesfully rollback contents of chests and signs burnt in the fire (ehm... if they burn?)
10:28 celeron55  no idea
10:33 darkrose   chests don't, signs do
10:34 celeron55  the only problem really is that fire is very CPU hungry
10:34 celeron55  rollback does nothing to server lag 8)
10:34 celeron55  (except after it is done)
10:35 celeron55  i think i have an ABM CPU limiter patch somewhere on my server's git stash pile
10:35 celeron55  i'll see if i could put that upstream
10:41 celeron55  hmm, server doesn't build
10:42 celeron55  due to some fiddling around with headers 8)
10:42 celeron55  (got rid of some more header bloat)
10:44 celeron55  now it works
12:09 celeron55  this is quite buggy still though
12:09 celeron55  or not buggy, but glitchy due to the way it works and because it still needs tunin
12:09 celeron55  +g
12:10 celeron55  it sometimes can't quite handle fire because it spreads so slow
12:11 celeron55  and i just saw it guessing the map generator's ore generation as done by a player... 8D
12:12 darkrose   it thinks players are planting ores?
12:13 celeron55  it probably found out a player did something near where the lua part of the map generator generated ores
12:13 celeron55  there is no way it can know who really has caused eg. the spread of lava or fire, so it just guesses
12:40 celeron55  i am still trying to tweak this to behave somehow sanely
12:50 celeron55  go grief c55.me:30000
12:51 jordach    :D
12:53 celeron55  and build
12:54 jordach    30001?
12:54 jordach    my bad
13:00 * darkrose may gave started a small fire
13:01 darkrose   s/gave/have/
13:37 celeron55  so let's see (i was away)
13:42 celeron55  lava is easily removed but fire doesn't go away
13:42 celeron55  much of fire tends to get removed but it isn't perfect
13:52 celeron55  i don't know why though
13:52 celeron55  then the fire catches up in no time
14:00 celeron55  as long as fire is disabled, /rollback will get rid of griefings
14:00 celeron55  and sometimes perfectly with fire too; it's just that if it leaves 2 fire nodes, they'll quickly spread to the full area again
14:02 celeron55  it would be fun to have a completely discrete system with perfect history, but this is far from it, and can't really be made into that
14:02 celeron55  also it would surely have large speed tradeoffs
14:05 jordach    this actually works well, compared to jeija's rollback mod
15:43 VanessaE   morning folks.
16:05 celeron55  maybe there should be a "massdestruct" privilege for setting fire and placing lava
16:06 celeron55  basically for everything that can spread wildly and cause much harm
16:06 celeron55  (there are no others than those currently)
16:07 jordach    water too in some aspects, if they have certain mods installed.
16:07 celeron55  no
16:07 celeron55  it can be rolled back easily
16:08 VanessaE   I like the idea.
16:08 celeron55  lava can be rolled back too, but fire is too uncontrollable
16:08 celeron55  and lava causes fire
16:09 celeron55  there is a problem though
16:09 celeron55  a griefer can place a long chain of things to move fire from legally placed lava to somewhere
16:10 celeron55  i definitely know why notch nerfed fire 8)
16:10 VanessaE   is it possible to limit the speed and distance fire can spread based on the node type it is trying to spread to?
16:11 celeron55  ehm
16:11 celeron55  that would have absolutely no point
16:11 celeron55  generally making fire to spread only a certain distance kind of would be possible, but that is what notch did i think
16:12 celeron55  a set fire has only a certain "punch" and the punch lessens at each node spread and a fire node doesn't spread when it hasn't got any anymore
16:13 celeron55  or something like that
16:13 VanessaE   that's what I was thinking
16:13 celeron55  it makes fire boring
16:13 celeron55  and pointless
16:13 celeron55  it's the same thing as not having fire
16:14 celeron55  like, what do you expect open fire to do except burn until there is nothing to burn?
16:15 VanessaE   well in the real world, some stuff takes more effort to set aflame than other stuff
16:15 celeron55  i don't understand
16:15 celeron55  why do you say that?
16:15 VanessaE   a tree trunk won't burn with the same amount of effort as, oh, grass or leaves
16:15 celeron55  WHY ARE YOU SAYING THAT?
16:15 celeron55  it does not help the *problem* in any way
16:16 celeron55  and nothing else either
16:16 VanessaE   nevermind then.  everything I say is random, etc.
16:17 celeron55  i am trying to solve a problem here
16:18 VanessaE   look, no matter what I suggest, no matter HOW detailed I get (not in this case obviously), there is always SOMETHING you don't like about my suggestions.  So why bother?
16:18 celeron55  that line was completely rubbish
16:24 VanessaE   ok fine, how about this then:  fire is set on some wooden planks.  The algorithm wants to spread to a neighboring node, let's say a tree trunk.  That fire should have to burn for a *long* time before that tree catches fire.  If the source material, the wooden planks, has a burn time of less than what it takes to set the tree trunk on fire, the fire goes out and the most that happens to the tree is maybe turning it into some
16:24 VanessaE   kind of charred node.
16:25 VanessaE   on the other hand, if the algorithm wants to catch some leaves on fire next to that wooden planks source, those should catch fire pretty quickly, in which case the fire spreads to the leaves.  The cycle repeats for each node the fire tries to spread to.
16:25 VanessaE   if source_burntime < destination_alight_time then source burns out and destination doesn't catch at all.
16:26 VanessaE   you could even get fancy and add the burntimes of all the nodes that are on fire which surround a given destination, to make it easier for it to catch fire, so a forest fire could still get started
16:26 VanessaE   but it would only continue if the trees are dense enough and would be less likely to get started in the first place.
16:27 VanessaE   provided you also let lava "cool down" as it spreads from the lava_source, such that it can't start a fire if it's far enough away from that source.
16:27 VanessaE   There.  There's your solution, or at least it's better than what we have now.
16:28 celeron55  ehm
16:28 celeron55  that does not improve the situation in any way
16:28 celeron55  a griefer has potentially infinite time to spread a fire from lava
16:28 celeron55  spread times can be _anything_
16:29 celeron55  and i do not fancy your making-fire-fancier things, they'll probably only make it slower and it is already slow enough, and it just plain isn't needed
16:30 VanessaE   fancy -> creative, adventurous, ambitious
16:30 celeron55  slow = resource hungry
16:30 VanessaE   (not "pretty" or "ornamental")
16:35 VanessaE   well at any rate, that grossly-expanded text above is equivalent "why are you saying this" line preceding it.
16:35 VanessaE   +to the
16:37 celeron55  maybe i need to check with the rollback manager who has placed the block about to catch fire and spread as a serioisly nerfed variety if the player does not have the "massdestruct" privilege
16:38 celeron55  u*
16:38 celeron55  ehm...
16:38 celeron55  that is going to be resource hungry
16:40 celeron55  i think i'm going with just making it easy to disable fire on servers
16:40 celeron55  KISS is my principle
16:43 celeron55  if somebody wants to make a fancier fire as an independent mod, i can discuss how to do it interoperably; other than that, i think this case is closed
16:46 VanessaE   on a different note, here's something else for you to reject:
16:46 VanessaE   http://minetest.net/forum/viewtopic.php?pid=34059
16:53 celeron55  three items for virtually the same thing, with absolutely no usage of groups?
16:54 celeron55  if people start making mods based on that, with making three recipes for everything for each of the containers, i'll go kill myself
16:54 VanessaE   I couldn't figure out a decent way to handle the groups in that one.
16:54 VanessaE   and the idea isn't to use all three, it's to pick just one that's appropriate for your mod.
16:55 VanessaE   unifieddyes uses the glass bottle (this is in response to you not wanting to reference an out-of-tree mod)
16:56 VanessaE   the uranium and...oh what was it, cyro?.. mods could for example use the steel bottle
16:57 celeron55  as long as you don't extend it any bit of what it currently is, i can think of it working out reasonably
16:57 VanessaE   and there are a couple of mods that need a drinking glass (one supplies some juices, presumably as a form of sustenance)
16:57 VanessaE   this is as far as I will take this mod
16:57 VanessaE   groups aside that is
16:58 celeron55  also the graphics should be final from the start, and they should be simple enough for all people to draw their things to inside of them
16:58 celeron55  the steel bottle is problematic from that viewpoint... hmm... i guess it'll get a simple label to it's side when it is filled
16:58 VanessaE   I'm not happy with the textures, but they're about the best I can come up with at that resolution.
16:59 celeron55  i think they are good enough, and by modifying them from that it might just get worse
16:59 VanessaE   right.
16:59 VanessaE   my photorealistic ones are far better, but they're 64px and not suitable for an upstream mod.
17:02 celeron55  i should make a "seal of interoperability approval by celeron55" to stamp on suitable mods
17:02 VanessaE   heh
17:02 VanessaE   Good Houskeeping, you are not ;-)
17:02 VanessaE   but I suppose that's not a bad idea either way
17:05 VanessaE   there's one problem I can see with that idea:  to use that "seal" you'll either have to send out a lot of emails to the parties whose mods you wish to stamp, or you'll have to trawl the forums and apply them yourself.
17:06 VanessaE   which would take a lot of time, something I know you're not too keen to expend.
17:07 celeron55  i browse through mod releases from time to time
17:07 celeron55  and, well, other parts of the forum too
17:09 VanessaE   yeah I know, I've seen you post recently.
17:09 VanessaE   just thinking of the added time, because now you'll have to review every recent mod on there (that you haven't evaluated already)
17:10 celeron55  well that was a 50% serious suggestion
17:10 VanessaE   well ok
17:10 celeron55  i was thinking on stamping stuff that otherwise might get competition only to make things worse
17:10 celeron55  of*
17:10 VanessaE   now that's a good idea
17:11 VanessaE   (unifieddyes gets the stamp of course ;-)  )
17:12 VanessaE   (that was supposed to be a joke.  It's funny.  Laugh.)