These are chat archives for PrismarineJS/minecraft-data

7th
Nov 2015
Romain Beaumont
@rom1504
Nov 07 2015 00:06
Gjum: hmm what do they look like ?
aren't they part of that internationalization file we agreed to put in mcdata ?
Gjum
@Gjum
Nov 07 2015 00:14
rom1504, the achievement text is in there, yes, but I mean the actual things you have to do to get them
Romain Beaumont
@rom1504
Nov 07 2015 00:15
ah
yeah I think so
that data would probably have to be written manually though I guess ?
Gjum
@Gjum
Nov 07 2015 00:16
probably
well there's http://minecraft.gamepedia.com/Achievement#List_of_achievements but it's prose, not really in a useful uniform data format
many are "pick up a certain item", but there's also stuff like visit all biomes which is hard to do in json
Romain Beaumont
@rom1504
Nov 07 2015 00:19
well if it is to be used by a program, we'd have to find a way to express that
Gjum
@Gjum
Nov 07 2015 00:25
there would need to be a uniform way to query the game, so you can get a player's position's biome and keep track of them between continuous checks or being able to hook into that condition as an event
Romain Beaumont
@rom1504
Nov 07 2015 00:28
hmm
that's possible in mineflayer for example
but in the json I think it would probably be something like {"position":{"in":{"every":"biome"}}} or something
Gjum
@Gjum
Nov 07 2015 00:30
yeah that'd be possible, sure, but would anyone implement it completely
Romain Beaumont
@rom1504
Nov 07 2015 00:33
well that was just an example, there probably is a more appropriate way to represent these achievements
but I think this is related to my graph of tasks thing
Gjum
@Gjum
Nov 07 2015 00:34
exactly
Romain Beaumont
@rom1504
Nov 07 2015 00:34
achievements would only be useful for bots that try to play the game
oh and servers
but I guess mojang hardcode it for servers
well, that doesn't mean we have to
Gjum
@Gjum
Nov 07 2015 00:35
achievement conditions are pretty much the same as the pre/post conditions of the task tree nodes
yeah, for vanilla it makes sense to express them in code
Romain Beaumont
@rom1504
Nov 07 2015 00:35
yeah
it's coherent with the recent of vanilla code (a class for every little thing), I don't know if it makes sense :p
Gjum
@Gjum
Nov 07 2015 00:37
so do you think it'd be useful to create a knowledge db for that task tree?
Romain Beaumont
@rom1504
Nov 07 2015 00:37
anyway, yeah I think it would be a good test to see if our tasks (tree) are complete enough to try to express achievements
Gjum
@Gjum
Nov 07 2015 00:37
yup
Romain Beaumont
@rom1504
Nov 07 2015 00:38
Gjum: I don't know exactly how that graph would be represented
it's probably not needed to have a graph engine (~kb) for it though
I don't think it'll be very big
Gjum
@Gjum
Nov 07 2015 00:39
that depends how abstract we can get it
Romain Beaumont
@rom1504
Nov 07 2015 00:40
well, maybe graph algorithm would be useful though, but not general stuff like what's in triplestore
Gjum
@Gjum
Nov 07 2015 00:40
recipes have many nearly-duplicate entries
Romain Beaumont
@rom1504
Nov 07 2015 00:41
yeah I don't know. I think the best way to have some more clues into what structure we would need is to try to express some tasks
so we can see the difficulties and all
Gjum
@Gjum
Nov 07 2015 00:42
I did that a while back when thinking about spock's async tasks
you need expressions for states (pre/post) and activities (to get from precondition to postcondition)
smelting an item from your inventory would be a start for example
or mining a block (with your active tool for now) and picking it up
these already involve querying the player and the world, variation over time, error handling, sub-activities
Romain Beaumont
@rom1504
Nov 07 2015 00:48
yes, I think knowing what an "expression for a state" is and what an "activity" is, is the important part
in rbot I have "conditions" which are these "state"
Gjum
@Gjum
Nov 07 2015 00:49
yeah
Romain Beaumont
@rom1504
Nov 07 2015 00:49
and a achieve <condition>
conditions are "at <position>" "have <number> <nameItem>" "close of <blockName>
Gjum
@Gjum
Nov 07 2015 00:49
and the activities are code or sequences of activities right?
I guess that means it didn't work
ah nevermind
activities are "actions"
I can define actions from other actions
but the problem with that
is I manually define these actions from other actions (in rbot code)
it would be better if it could make a path of activities from a state A to a state C passing by a state B
Gjum
@Gjum
Nov 07 2015 00:53
well ideally you have atomic actions in code and all other actions are sequences of actions and condition checks
Romain Beaumont
@rom1504
Nov 07 2015 00:54
well that's what rbot is currently basically
Gjum
@Gjum
Nov 07 2015 00:54
hm
Romain Beaumont
@rom1504
Nov 07 2015 00:54
but "sequences of actions and condition checks
"
== coding
Gjum
@Gjum
Nov 07 2015 00:54
yep
I just realized :D
Romain Beaumont
@rom1504
Nov 07 2015 00:55
soon you need loop and whatever
and that's getting far from the initial idea ^^
Gjum
@Gjum
Nov 07 2015 00:55
well you cant get around atomic actions, but the pre/postconditions of these could be used for automatic resolving and action chaining
Romain Beaumont
@rom1504
Nov 07 2015 00:56
yes that's what I'd like
and that means expressing pre/postconditions in a computable way
whatever that means
I did only a few condition in rbot, and already I needed to parameterize them
questions : is that okay ? how do you combine parameterized conditions/states ?
(for example have <number> <nameItem> )
Gjum
@Gjum
Nov 07 2015 00:58
make the parameters flexible enough, so a very specific param value gets matched by a more unspecific one
Romain Beaumont
@rom1504
Nov 07 2015 01:01
yeah that would be nice, but I think this need example, to know if that works
it's hard to think about this in general
Gjum
@Gjum
Nov 07 2015 01:01
you can only craft stairs in fours, so if you need one stair, the crafting recipe should still match
Romain Beaumont
@rom1504
Nov 07 2015 01:02
I think we could make a "fake evaluator" that would combine atomic actions, but just print them, not actually execute them
Gjum
@Gjum
Nov 07 2015 01:02
yeah as a start
I think taking a closer look at shrdlu would be beneficial
because that's essentially the same
Romain Beaumont
@rom1504
Nov 07 2015 01:03
it's easier to check what it predicts is correct. I remember I've been testing rbot by following him underground while he was mining, and it wasn't the most convenient thing to do ^^
Gjum
@Gjum
Nov 07 2015 01:03
except we have tons of atomic actions and shrdlu just had "pick up block" and "drop block"
yeah having tests early is always useful
Romain Beaumont
@rom1504
Nov 07 2015 01:04
hmm I don't think there is any information about shrdlu, but as they say in the article, the evolution of that is Cyc, or stuff like opencog or nars
well that's for systems, maybe there are research article about that
Gjum
@Gjum
Nov 07 2015 01:05
well shrdlu was simple, so it would probably be easier to grasp and expand on
and I remember reading at least something about the semi-natural language parsing part of shrdlu
so there should be some material on the tree stuff too
Romain Beaumont
@rom1504
Nov 07 2015 01:09
yeah I guess
Romain Beaumont
@rom1504
Nov 07 2015 01:20
interesting
ah prolog
Gjum
@Gjum
Nov 07 2015 01:25
those automatic theorem provers just match pre/postconditions and completely ignore the action part
Romain Beaumont
@rom1504
Nov 07 2015 01:34
do we need to care about the action part ?
we just need to be able to identify it, but what else ?
ah, except if we want to compute duration and cost and such stuff
but it's not necesarrily needed to go inside the action for that
Gjum
@Gjum
Nov 07 2015 01:39
cost could be part of the condition
Gjum
@Gjum
Nov 07 2015 02:03
what we are constructing sounds like Situation Calculus: https://en.wikipedia.org/wiki/Situation_calculus#The_frame_problem
Romain Beaumont
@rom1504
Nov 07 2015 02:47
that looks like it indeed