Time  Nick         Message
00:19 sapier1      https://github.com/celeron55/minetest/pull/383 -- This pull request is essential to take player <-> mob interaction to a new level plz review
00:23 PilzAdam     maybe it would be better to just add minetest.show_forspec_to_player(playername, formspec)
00:23 sapier1      would this be linked to a detached inventory?
00:24 PilzAdam     you can always show detached inventories in formspec, if you mean this
00:24 RealBadAngel thexyz, could you merge bugfixes to my code in formspec? https://github.com/celeron55/minetest/pull/382
00:25 sapier1      nice ... didn't know that I'm gonna have a try if only showing a formspec is enough
00:25 PilzAdam     https://github.com/celeron55/minetest/blob/master/doc/lua_api.txt#L763
00:26 thexyz       RealBadAngel: later, better ask  darkrose or  PilzAdam now (it's 4:30am here)
00:27 RealBadAngel sure
00:27 RealBadAngel PilzAdam, can you?
00:27 PilzAdam     umm, its 1:30 AM here ;-)
00:27 RealBadAngel same as here ;)
00:28 RealBadAngel those are fixes to my own code
00:32 RealBadAngel btw as a comment for c55's intentional stuff in cave generator: http://realbadangel.pl/clouds1.png
00:34 RealBadAngel thats why im plain against it. its fucked up
00:35 sapier1      @PilzAdam I'm gona change It as requested
02:13 sapier1      @PilzAdam are you sure the pull request is updated?
02:14 PilzAdam     it has a commit form 21 minutes ago
02:14 sapier1      strange now its correct ...
02:15 VanessaE     fwiw I show it being 18 minutes into the *future*
02:15 sapier1      ok lets see if this is ok the problem I was talking about in minetest was lua only as soon as using detached inventories correct they work correct with this changes too
02:16 PilzAdam     sapier1, why do you add create_detached_fromspec()?
02:16 PilzAdam     why not just pass the formspec string to show_fromspec()?
02:16 sapier1      to reduce number of bytes transfered
02:17 PilzAdam     can you always create detached formspecs?
02:17 sapier1      formspecs sometimes get really big
02:17 sapier1      I think so do you have an idea where this isn't possible?
02:17 PilzAdam     typo: line 893 of init.lua
02:18 PilzAdam     just asking if you have to create them on startup
02:18 PilzAdam     s/init.lua/lua-api.txt
02:18 sapier1      no you may create them anytime
02:19 sapier1      if you reuse a name it's updated ... same as for detached inventories
02:19 PilzAdam     missing ":" in 895 & 896 of lua-api.txt
02:21 sapier1      I assumed formspecs do not change very often so doing it same way as inventories seemd to be reasonable to me
06:51 celeron55    i think formspecs should be just sent directly like PilzAdam noted
06:52 celeron55    there's no reason not to
06:52 celeron55    it will make a very simple implementation
07:34 hmmmm        you know this is so kludgy the way i have it set up.. maybe the ServerEnvironment should have the EmergeManager
07:35 hmmmm        celeron, can you explain to me what the "environment" is?
07:35 hmmmm        i think i'm going to change this to make the mapgens on the EmergeManager ctor
07:37 hmmmm        actually i can't do that, the lua api is run before the server environment is created
07:37 hmmmm        what was your logic behind doing that?
07:41 hmmmm        you know what, i don't think it even matters anymore since i made the decision to make it not configurable from lua
07:42 hmmmm        ServerEnvironment's ctor will create EmergeManager, but i don't really know if it should be a member of Server or ServerEnvironment
07:54 celeron55    the environment is the game's state
07:55 hmmmm        maybe what i have is appropriate, then
07:55 celeron55    or, to speak in an OOP way, it's the game
07:56 celeron55    i don't know if something that dynamically fetches stuff to be included in the game should be a part of the game or part of... the things that run the game
07:57 celeron55    if such is put in the environment, then where is the limit?
10:44 sapier       hello, is there any reason why inv reference in on_move of a detached inventory is a different value than invref returned on create of detached inventory?
13:40 PilzAdam     This post http://minetest.net/forum/viewtopic.php?pid=61211#p61211 says that the attachment bug isnt completly fixed
14:14 celeron55    how so? the official 0.4.4 release has the bug
14:14 celeron55    and the fix was client-side
14:15 celeron55    hmm... actually, if falling nodes are affected, then there is something wrong on the server side
14:16 celeron55    i guess content_sao.* needs to be looked through
14:20 RealBadAngel hi
14:21 RealBadAngel can anyone merge fixes to my code? https://github.com/celeron55/minetest/pull/382
14:24 thexyz       what does it fix?
14:25 RealBadAngel item_image method
14:26 thexyz       how about being more precise?)
14:26 RealBadAngel It fixes some missing code in implementation of formspec's item_image method.
14:27 thexyz       so, it was not working before, right?
14:27 RealBadAngel yes
14:28 thexyz       fine
14:29 RealBadAngel i havent noticed the missing part (strange since i had that on my local copy) because i wasnt using it
14:29 RealBadAngel just Muvebic tried to use it and ask me to fix it
14:31 kaeza        PilzAdam: how can I find the *exact* MT version I have? i.e including the date?
14:34 thexyz       RealBadAngel: pushed
14:34 RealBadAngel thx
14:36 RealBadAngel i will have later on today another pull to the treegen. adding new turtle commands, with selectable angles
14:36 thexyz       ok
14:36 thexyz       but don't break windows builds that time, plz
14:36 sapier       is https://github.com/celeron55/minetest/pull/383 in shape to be merged?
14:37 RealBadAngel thexyz, im  tryin to learn from my lessons
14:37 sapier       it adds triggering display of formspec via lua
14:37 thexyz       sapier: that change affects networking, better cast celeron55 here
14:38 thexyz       from what I see you didn't modify PROTOCOL_VERSION
14:38 thexyz       RealBadAngel: fine
14:39 RealBadAngel thexyz, one more thing, according to yesterdays debate on cave gen. have you seen already this: http://realbadangel.pl/clouds1.png ?
14:40 thexyz       no, I haven't
14:41 RealBadAngel just click and comment
14:41 sapier       yes changes are additions client will still work with older servers as well as client will ignore messages from newer servers ... I didn't know when protocol version needs to be changed
14:45 RealBadAngel thexyz, and?
14:46 thexyz       I see, that should be fixed
14:46 thexyz       let me check logs
14:47 RealBadAngel i agree. but c55 said that was intentional, and im plain against mapgen at all
14:47 thexyz       http://irc.minetest.ru/minetest-dev/2013-01-01#i_2773098
14:49 RealBadAngel i agree to make holes in the montains
14:49 RealBadAngel but not in outer space for christ sake
14:50 RealBadAngel no matter how high will you go dozens of caves will generate around you
14:51 thexyz       I mean, better discuss it with hmmmm
14:51 thexyz       not with me
14:51 RealBadAngel hmmm said he wont touch cave gen
14:51 RealBadAngel hes doin mapgen and goin to move cavegen to its own file
14:53 thexyz       then just wait for new mapgen
14:53 RealBadAngel yup, but the cave gen will be still broken then
14:53 sapier       can anyone tell me if doing a compatible proctocol change requires increasing PROTOCOL_VERSION too?
14:54 RealBadAngel i proposed just some fine tuning, not revolutions
14:54 thexyz       though that can make maps inconsistent (if part of cave is already generated)
14:55 RealBadAngel small pain in some map parts
14:55 RealBadAngel and great speed up overall
14:55 RealBadAngel anyway, with new mapgen all will be forced to make new maps
14:56 RealBadAngel all the ore generation mods will change
14:56 RealBadAngel plants, trees
14:58 RealBadAngel why to cry over some non regular caves?
14:58 RealBadAngel wait, in fact BELOW ground level nothin will change
14:59 iqualfragile new mapgen? awsome!
14:59 iqualfragile (is there some code already?
14:59 iqualfragile )
14:59 RealBadAngel https://github.com/kwolekr/minetest
14:59 RealBadAngel you can test it out
15:00 RealBadAngel some stuff works alredy, some not
15:01 sapier       is everything moved to lua a year ago moveing back to core atm?
15:02 iqualfragile what are the improvements over the old mapgen?
15:02 PilzAdam     its modifyable by Lua
15:02 thexyz       sapier: why do you think so?
15:02 PilzAdam     (see minimal mapgen.lua)
15:02 PilzAdam     (or init.lua, dunno)
15:02 sapier       it's only my impression of last two weeks that's why I'm asking
15:03 sapier       and of course in that case I'd probably rewrite mobf in c++ ... would be much faster :)
15:04 sapier       although 1.9x series of mobf is quite performant ... except the spawners
15:04 RealBadAngel IMHO you should. and make it fully configurable from Lua
15:05 iqualfragile yeah, but only if its added to default
15:05 RealBadAngel all time consuming and repetitive calulations done within the core
15:06 RealBadAngel Lua just to config it
15:06 sapier       It's far to much work to do it at once if doing so this would be step by ste e.g. c++ify spawners first ... movement generators ..
15:06 iqualfragile or: add a pathfinding-routine to the engine, that would be usefull
15:06 sapier       if you do require time consuming calculations for mobs you're doing something wrong ;-)
15:06 RealBadAngel simple example, Lua needed 2-3 seconds on my box to spawn a big tree
15:07 sapier       yes pathfinding would be a use case for lua too
15:07 RealBadAngel in c++ its nearly instant
15:07 sapier       you do handle thousands of nodes for a tree ... when does a mob require to touch that many nodes?
15:07 RealBadAngel when i replaced default trees with L-system ones, i just played with them
15:08 RealBadAngel with no lags
15:08 RealBadAngel btw, technic from today on uses L-system tree for Rubber Tree
15:08 sapier       doing a c++ call from lua is a nightmare so switching to c++ for small calculations most likely will result in performance degrading instead of increasing
15:09 RealBadAngel http://realbadangel.pl/rubber_trees.png
15:09 RealBadAngel sapier, i can help you with that
15:10 RealBadAngel ive added already some stuff to scriptapi.cpp
15:10 sapier       @RealBadAngel I'm skilled in c++ too, it's not a matter of skills it's a matter of decision what's worth to be in c++ and what ain't
15:11 RealBadAngel time consuming -> c++
15:11 sapier       ok so we need configurable spawners
15:11 sapier       that's by far most time consuming task
15:12 sapier       I've removed any abm based spawner from mobf and got from lag level "not playable" to "no lag at all"
15:12 iqualfragile and its a question of overhead
15:12 RealBadAngel ABM's are not workin right
15:13 RealBadAngel one badly wrote ABM can destroy whole system
15:13 sapier       but first  https://github.com/celeron55/minetest/pull/383 should be reviewed and added :-)
15:13 RealBadAngel in fact, is able to DISABLE ABM's
15:14 RealBadAngel you can do a test, make an ABM and inside it infinite loop
15:14 sapier       abm's sometimes aren't way to do it ... e.g. spawn birds in air ... that abm is a performance killer
15:15 sapier       I've abms running < 3ms but for what I require them to do they need to be called far to often
15:16 RealBadAngel make your own pseudo abm handler
15:16 RealBadAngel based on dtime
15:16 sapier       I've found a solution capable for the moment but having a spawning mechanism to configure in core would be far better ;-)
15:18 RealBadAngel c55 wrote somethin yesterday, lemme find it
15:20 RealBadAngel http://pastebin.com/q7GaMPJG
15:21 RealBadAngel ive cut a part ;)
15:23 RealBadAngel http://irc.minetest.ru/minetest-dev/2013-01-01#i_2772669
15:23 sapier       tztz ...
15:23 RealBadAngel better read here
15:24 sapier       .. couple of hours to add mobs ... with respect to celeron that'd be very very simple mobs
15:24 * PilzAdam   points at simple mobs mod
15:25 sapier       as name tells it "simple" ... ;-)
15:25 sapier       btw simple as in copy n paste each mob ... i hate copy n paste
15:25 RealBadAngel simple or not, i dont really what plain sprite has to do with creativity
15:25 RealBadAngel *understand
15:26 RealBadAngel easier to create, or what?
15:27 sapier       If ppl would have a look at doc they'd know how simple creating a mob in mof is ... it's even less work as socalled "simple mobs"
15:27 RealBadAngel just make a fully workin implementation
15:28 sapier       yes there were performance issues ... because of spawning
15:28 RealBadAngel and show it works
15:28 sapier       it's already done in lua ... and it'd be a blueprint for c++ implementation as its written like c++ code
15:28 RealBadAngel so did i with trees
15:29 sapier       probably that c++ style is why others don't like mobf
15:29 iqualfragile rotatable hitboxes would be usefull
15:29 RealBadAngel Lua version was not usable, just a proof of concept
15:29 sapier       yea thats a big issue with mobs
15:30 RealBadAngel i had even to rewrite in Lua some methods aviable in irrlicht core
15:30 sapier       mobf is usable I run it at 1 core 512MB ram @2.1Ghz without any lag
15:30 sapier       was lot's of work to find out where performance vanished but it's done
15:30 RealBadAngel which was plain stupid
15:31 sapier       true ;-)
15:31 sapier       who is celeron56? :-)
15:38 serengeor    sapier, celeron55++
15:38 RealBadAngel new year, new celeron ;)
15:39 sapier       :-) hmm ok my client makes sapier to sapier1 at reconnect too ... probably it'd make it to sapier2 if i was sapier1
15:44 iqualfragile celeron55: do you live in oulu?
15:48 sapier       btw problem with rotating collisionboxes is missing collision handling for non axis aligned or non block shaped boxes
15:49 iqualfragile hmm… i think another perlin-noise-map would be usefull: pressure
15:49 iqualfragile (for caves and airstuff)
15:50 sapier       but pressure ain't a random value?
15:54 iqualfragile no, its a perlin-value!
15:54 iqualfragile & biomes need a skycolor or skycolorramp atribute
15:54 sapier       i thought perlin is just some sort of random like value
15:55 iqualfragile it is, but its awsome, too
15:55 iqualfragile what else would you make pressure dependent on?
16:05 sapier       hmm distance to non solid ground weighted by xz and y direction
16:06 sapier       asof xz distance being 20% if presure value while y is 80%
16:06 sapier       just a suggestion for numbers
16:08 celeron55    iqualfragile: depends on why you ask
16:08 iqualfragile i have met someone from there last summer
16:08 iqualfragile & why is there a celeron56?
16:10 sapier       @celeron55 any chance to get this https://github.com/celeron55/minetest/pull/383 merged? If adding servermessage requires proctocol version change even for complatible changes I'll fix this asap.
16:11 celeron55    sapier: i already commented that
16:12 celeron55    08:57:39 < celeron55> i think formspecs should be just sent directly like  PilzAdam noted
16:12 celeron55    08:57:45 < celeron55> there's no reason not to
16:12 celeron55    08:57:55 < celeron55> it will make a very simple implementation
16:12 sapier       I don't think so ... but I'll change either as I do need formspec support
16:13 sapier       you know this gonna result in lots of memory operations?
17:11 sapier       another try: https://github.com/celeron55/minetest/pull/384 -> removed detached formspec support, updated protocol version
17:14 celeron55    sapier: "showDetachedInv: couldn't find player"
17:15 celeron55    also, you changed an error message in get_item_callback to be specific to detached inventories while it is a generic function
17:16 celeron55    the std::string* thing is silly but it's indeed necessary because of the union
17:17 celeron55    you should add a comment to it so it's clear
17:18 sapier       ok I changed that error message because it wasn't unique and you couldn't determine where it was originating from. I'll change the typo and rebase
17:18 sapier       but if you don't like it I change it back
17:19 celeron55    change the three things i said
17:19 celeron55    or, well, 1) change, 2) change back and 3) add
17:19 sapier       i do
17:24 celeron55    the PROTOCOL_VERSION change probably behaves well enough now - when a 0.4.4 client connects to current server, it will work otherwise but it will receive a warning message in chat; all other cases work normally
17:25 celeron55    (and, of course, in that case the formspec won't show up)
17:25 celeron55    sapier: add a space after the comma in mminetest.show_formspec(playername,formspec)
17:25 celeron55    -m
17:26 sapier       added .. true client still can connect to old servers I checked that
17:33 celeron55    hmm
17:34 celeron55    what happens if you show a formspec when one is already showing
17:34 celeron55    it should be possible to update it, but that will do something... odd
17:35 sapier       hmm ... good question ... I'm gonna try what happens
17:35 celeron55    game.cpp should somehow see that a FormspecFormSource exists, and update it there
17:35 celeron55    also, don't use a string pointer in FormspecFormSource, you already have a memory leak in there because of it
17:36 celeron55    (IFormSource exists exactly for that - to be able to update the formspec that is already showing up on screen)
17:37 celeron55    i think you could add an std::string variable inside the_game and pass and store a reference to it in FormspecFormSource
17:37 celeron55    so then you can... umm...
17:37 celeron55    get more problems!
17:37 sapier       guiformspec is somehow complicated :-)
17:38 sapier       there are so many ways to get same thing ...
17:39 celeron55    the FormspecFormSource needs to set the variable in the_game to "" when it is destructed, so then the code that launches a formspec with a FormspecFormSource can check that if it is "", then launch a new one, otherwise just change the variable (so that FormspecFormSource gets the updated value via the variable reference it has)
17:39 sapier       I don't see a memory leak by now where is it?
17:39 celeron55    hmm, no, there isn't any
17:39 celeron55    didn't see that you actually had a proper destructor in there 8)
17:40 celeron55    did you understand what i said or do i need to do it myself? (not that big a task)
17:41 sapier       :-) there was a memory leak around this place in former pull request .. no I don't understand but I think I'll find out
17:42 hmmmm        just wondering, why isn't environment metadata loaded in ServerEnvironment's constructor?
17:42 celeron55    the end result will be weird but will work very well
17:43 celeron55    hmmmm: where is it loaded?
17:43 hmmmm        after the object's been created, in the Server ctor
17:43 hmmmm        kind of struck me as odd
17:44 celeron55    is there an example of a similar thing done in an other way somewhere
17:44 celeron55    or why do you ask
17:44 hmmmm        well map meta is loaded in ServerMap::ServerMap, so you'd expect env meta to be loaded in ServerEnvironment::ServerEnvironment, that's all
17:45 hmmmm        it's not a problem
17:45 hmmmm        tbh what i have right now isn't a problem either, it just strikes me as being kludgy
17:47 celeron55    i don't really know how that should be; altough i can see that as it currently is, the environment doesn't have to store a yet-another copy of the world location
17:48 celeron55    these days i generally think serialization shouldn't be part of the object that is serialized, but it's completely backwards to how minetest is constructed 8)
17:49 celeron55    what is more important is having a consistent way of doing it
17:52 celeron55    the fact that things are dynamically loaded, saved and unloaded makes it hard to make reasonably structured code
17:54 celeron55    there would need to be an abstracted backend for the storage of everything, which... well, i wonder if anyone has time and skill for designing anything like that
17:55 celeron55    it's again one of those "oh hey, let's recode half of minetest for no visible benefit" thins
17:55 celeron55    things*
17:59 sapier       yes but one of those maintenance things saving lots of work when summarizing  all that small saves on future work
18:00 celeron55    maybe, but a rewrite of everythin easily ends up being just an another kind of mess
18:00 celeron55    +g
18:00 celeron55    it needs to be done well too
18:01 sapier       yes if rewrite is done by someone not having experience from first write, outcome most likely won't be better at all
18:02 sapier       I'm testing what happens on update while formspec still shown prior pushing new version
18:16 sapier       @celeron ok I've checked it's updating formspec correctly if called while formspec shown. I hope I understood what you wanted me to do in the_game
18:20 thexyz       >sapier merged commit 5d18dc3 into celeron55:master from sapier:simple_luaformspec 10 minutes ago
18:20 thexyz       how?
18:20 hmmmm        things don't need a rewrite
18:21 hmmmm        it'll probably turn out down the line that your new abstraction didn't really make things much easier
18:21 thexyz       oh, wait, you merged 0 commits, seems legit
18:22 hmmmm        alright so the order of events i changed this to is:  create BiomeDefManager, load biomes from lua, then ServerMap's ctor writes the MapgenParams which the EmergeManager takes as a parameter and creates the Mapgen objects with
18:23 hmmmm        indeed it's probably best that i don't create the BiomeDefManager along with the EmergeManager since they are separate entities, it just so happens that it's useful to have a biomedef associated with the emergemanager
18:24 sapier       @thexyz I don't know I updated my branch only
18:37 celeron55    looks like github bugged somehow
18:37 sapier       hmm i'm rechecking if there's updated what I intended to update
18:38 celeron55    your branch looks good otherwise, but you really should get rid of the heap-allocated std::string in there
18:38 celeron55    it's totally unnecessary
18:38 celeron55    just make it a non-pointer
18:52 sapier       ok ... changed and checked
18:58 celeron55    sapier: pushed to c55/master
18:59 celeron55    wait a second
18:59 sapier       whats wrong?
18:59 celeron55    changed the commit message a bit 8)
18:59 celeron55    now it's good
18:59 sapier       I see :) .. thx now I can releas my all new trader mob :-)
19:04 celeron55    changed the version to 0.4.4-d1 so people have something to call it
19:04 celeron55    (PROTOCOL_VERSIONs are kind of hard to remember...)
19:06 sapier       true :-) a marker is good in such cases
19:51 sapier       is there any chance to add a unique inventory id to invref?
19:52 celeron55    unique in what context
19:55 sapier       create_detached_inventory returns a different invref as passed to callbacks
19:56 celeron55    yes, invref is just a reference to a real inventory
19:57 celeron55    so you need a way to compare invrefs to each other?
19:57 celeron55    why
19:58 sapier       my trader creates a different detached inventory for any mob created
19:58 sapier       functions called on_move ... are same for everyone
19:58 sapier       so those functions need a way to decide which entity they are linked
19:58 sapier       atm I'm doing this by using a list
19:59 sapier       adding an item with a unique name
19:59 sapier       it works but it's a hack
20:01 celeron55    hmm, so you essentially want server instance global ids... lua shouldn't see any ids though, because they aren't world-persistent; it should be able to compare the invrefs
20:04 celeron55    what if there was InvRef:get_location()
20:05 celeron55    that would return a similar thing that minetest.get_inventory takes as a parameter
20:05 sapier       detached_inventorys are already created by name probably this may be used?
20:05 sapier       invref->get_name() for example
20:05 celeron55    minetest.get_inventory(location) -> InvRef
20:05 celeron55    ^ location = eg. {type="player", name="celeron55"} {type="node", pos={x=, y=, z=}} {type="detached", name="creative"}
20:06 celeron55    i think InvRef:get_location() -> eg. {type="player", name="celeron55"} {type="node", pos={x=, y=, z=}} {type="detached", name="creative"} is the trivial solution
20:07 sapier       is it possible to compare those invrefs to those supplied to on_move ?
20:07 celeron55    because that location is what an invref actually stores
20:07 sapier       InvRef:get_location() is good
20:14 celeron55    i'll make that shortly
20:33 celeron55    sapier: try this http://paste.dy.fi/u3N/plain
20:45 sapier       @celeron55 you're missing  "method(InvRef, get_location)," but after adding it's working fine (at least for detached inventorys)
20:48 celeron55    hmm, i guess i'll make it never return null but rather {type="undefined"}
20:48 celeron55    easier to handle in scripts
20:53 celeron55    it's there
20:54 sapier       thanks
21:04 * PilzAdam   points at 2 commits: https://github.com/PilzAdam/minetest/commits/random_stuff
21:09 celeron55    why is damage_flash an s32
21:09 celeron55    it should be float
21:10 PilzAdam     why?
21:10 celeron55    to not lose timing precision
21:10 celeron55    for example, try to run the game now so that dtime is less than 10ms
21:10 celeron55    the red will stay on the screen continuously
21:11 PilzAdam     ok
21:14 celeron55    was there a patch somewhere that will make the camera tilt rather than flash something on the screen?
21:16 PilzAdam     fixed
21:17 PilzAdam     IIRC Jeija has a patch for that
21:17 PilzAdam     but it was buggy
21:21 thexyz       https://github.com/minetest/minetest/commit/9f02e3395e0df8896a65604fb1b8b79b2b7b9584
21:21 celeron55    can thexyz test those PilzAdam's things, i i'm going to sleep in a short time
21:21 thexyz       it doesn't work well when you're damaged continuously (like in lava)
21:21 celeron55    -i
21:25 PilzAdam     mapgen_sapling doesnt exist so this change wont work
21:27 PilzAdam     fixed
21:29 PilzAdam     thexyz, could you review this 2 commits?
21:30 thexyz       sure
21:38 thexyz       PilzAdam: damage flash doesn't work perfect, some times screen blinks with red instead of slowly fading out (probably related to getting damaged multiple times)
21:42 PilzAdam     thexyz, repull
21:43 PilzAdam     I changed it so the damage_flash is decreased after drawing so negativ values cant be passed to the drawing method
21:45 thexyz       it'd be better for you to rebase after review and before pushing to main repo so I can easily see changes
21:45 thexyz       ok, testing this one
21:47 thexyz       seems fine