Minetest logo

IRC log for #minetest-dev, 2013-04-21

| Channels | #minetest-dev index | Today | | Google Search | Plaintext

All times shown according to UTC.

Time Nick Message
00:00 celeron55 rarkenin wrote this: http://dev.minetest.net/Rarkenin/Proposal_System
00:01 Jordach joined #minetest-dev
00:01 StrayBytes Just as heads-up, instead of rarkenin I now use StrayBytes on IRC.
00:03 Jordach RealBadAngel, are you making connected textures
00:04 RealBadAngel Jordach, not really, im makin glass nodes that autoconnects to form surfaces
00:04 StrayBytes Comments on the proposal proposal?
00:05 hmmmm have you proposed the proposal system under the new proposal system?
00:06 StrayBytes Not yes, since the proposal proposal is still a proposal, and not policy yet.
00:06 hmmmm realbadangel, for now i think what we can do is just make it a config option.... we should call it solid_glass perhaps?
00:06 hmmmm we'll deal with the drawtype thing later because i'm sure right away people would appreciate that
00:07 RealBadAngel im adding now scratches to glass surfaces
00:07 hmmmm ahhhhhh
00:07 RealBadAngel about the name, im not sure
00:07 RealBadAngel maybe some other ideas?
00:08 hmmmm dunno, but i agree with you on not liking the scratches or streaks or whatever those are
00:08 Jordach RealBadAngel, i'd consider calling it: connectable blocks
00:08 hmmmm :3
00:08 RealBadAngel Jordach, this affects only glasslike nodes
00:08 RealBadAngel it is very specific
00:08 VanessaE hmmmm: I consider them equivalent to the streaks normally used to suggest glass in cartoons and technical drawings
00:08 hmmmm maybe someday we'll be able to expand this idea
00:09 Jordach RealBadAngel, some blocks such as bookcases would benefit from such
00:09 hmmmm and then procedurally generate a texture for each face of the connected blocks
00:09 Jordach because they never magically end do they
00:09 hmmmm vanessa, same here
00:09 VanessaE (if we had proper alpha support, I'd be drawing them as a mild, subtle glare, like a reflection or some kind)
00:09 hmmmm indeed
00:09 hmmmm see, that's another thing i'd like to do, proper alpha support
00:09 Jordach like irrlicht will ever support that
00:10 StrayBytes That's a start towardnice graphics...
00:10 Exio i would like reflection
00:10 hmmmm so many things, so little time
00:10 Exio but i have no f* idea how to code it :D
00:10 celeron55 StrayBytes: it does have the problem of possibly being prone to heavy compromises in game content / mechanics which lead to zero innovation
00:10 hmmmm see
00:10 Jordach hmmmm, focus a one at a time agenda
00:10 hmmmm people who want these things and use irrlicht just expand irrlicht
00:10 hmmmm (like Build A World for instance)
00:10 StrayBytes That's a fair point.
00:11 hmmmm i don't think it'd be horrible if one of us adds it to irrlicht and have minetest support it that way
00:11 celeron55 StrayBytes: as for the engine, it could work; i think the proposal proposal is somewhat unclear on how actual code is accepted or rejected
00:11 StrayBytes I'll work on clearing that up soon.
00:12 celeron55 i'm not sure if this differs at all in practice from what we have now, though
00:13 hmmmm just reading that thread now... "Hmmm designed it, he can fix it. Just like we are being asked to implement our own colored lighting."  <---- i did not design it, that was blue42u
00:13 hmmmm i just polished it up a lot
00:13 hmmmm again, i am NOT interested in maintaining the lua hud
00:14 celeron55 i answered it there already, you have no need to repeat the discussion in here :P
00:14 hmmmm responsibility creep at its finest
00:14 celeron55 everybody knows the facts except mauvebic
00:16 StrayBytes Proposal updated a bit.
00:17 hmmmm so hold on a minute, minecraft has colored lighting?
00:17 StrayBytes And it's a wiki for a reason, feel free to submit edits.
00:17 celeron55 hmmmm: i think it doesn't
00:17 hmmmm figured as much... these people are full of shit
00:17 celeron55 it has similar coloring of light as MT has, except that MT does it right
00:17 celeron55 8)
00:18 hmmmm it's easier to add into minecraft because their MapNode structure is already 8 bytes and they don't use much of it from what i understand
00:18 VanessaE so tell me something:
00:18 hmmmm still a gross hack though
00:19 VanessaE why the apparent opposition to adding two more bytes per exotically-colored node?
00:19 hmmmm i have a feeling this is going to end with me putting my own things off to the side again and adding hardware lighting support and doing colored lighting properly
00:19 VanessaE (when a node already takes a few dozen bytes anyway I mean)
00:19 hmmmm two more bytes?
00:19 hmmmm and no, it doesn't take "a few dozen bytes"
00:19 hmmmm it's 4
00:20 celeron55 "per exotically-colored node"
00:20 celeron55 you can't add something to some nodes only
00:20 celeron55 the node structure is static for each node
00:21 Exio it is just 2 bytes, we already have 42cores cpus and 64gb of ram!!!!!111! </user>
00:21 RealBadAngel http://i.imgur.com/tNkUdKT.png
00:21 celeron55 it's not as much about 2 bytes than about the 20 bytes that adding stuff without serious consideration will lead to
00:22 hmmmm i assume you did that by making a separate connected glass node?
00:22 VanessaE hmmmm: each node takes four bytes in the map/network?
00:22 hmmmm less, because of compression, but in memory yes it takes 4 bytes
00:22 celeron55 over network and on disk much less because they are compressed, but laoded into RAM they are 4
00:22 StrayBytes Are packets culled/grouped before being sent out?
00:23 StrayBytes It seems like there's a ton of overhead for the many small packets which are used in client-server interaction.
00:23 hmmmm there seems to be a bunch of misconceptions about all this
00:23 hmmmm i wonder if i should bother explaining exactly what's going on in the forums
00:23 RealBadAngel hmmmm, scratches are visible only if neighbour node is air or water
00:23 VanessaE it seems like there should be a lot more than that, but I'll take your word for it.  Still, two more bytes and only applied to nodes that have exotic light shouldn't be very heavy in practice.
00:23 celeron55 also on average a MapBlock's mesh takes multiple times the space of the nodes in it, but the problem here really isn't clients but servers
00:24 Exio i just added a rand in that "function" where they say they add that stuff
00:24 Exio and saw it blink
00:24 Jordach RealBadAngel, that looks like nodeboxy glass
00:24 Jordach nice.
00:24 Exio i know how to implement it now, now?
00:24 hmmmm huh, add what stuff?
00:24 celeron55 StrayBytes: the MT protocol basically sucks all-around, that isn't a particularly large problem 8)
00:24 hmmmm yeah, celeron, you really overengineered the protocol
00:24 Exio hmmmm: the "colored lighting" in the mapblock_mesh
00:25 hmmmm those things are best left to the tier below application
00:25 Exio what maudevic (i can't recall his nick) did for changing/tweaking the colors
00:25 StrayBytes Maybe it's time to rework the protocol from near-scratch, first on paper before diving into code?
00:25 Jordach mauvebic*
00:25 hmmmm oh
00:25 hmmmm mauvebic didn't really do anything of substance there
00:25 hmmmm he just changed some colors around
00:25 Exio i was being sarcastic
00:25 Exio he only changed that and now he is saying that is the "way" to implement that
00:25 hmmmm :|
00:25 celeron55 StrayBytes: a new TCP based protocol would probably be a good idea, if somebody has the time to design and implement such
00:26 StrayBytes I could try to design it, but I suck at C++.
00:26 StrayBytes I've done a lot with transmission of data, though, at this level and lower levels as well.
00:26 Jordach or we could implement a more p2p protocol where chat isnt sent to the server exept / commands
00:27 celeron55 and in fact there's probably not much at all to design; just send the current stuff in a TCP stream
00:27 StrayBytes And block sends could live in the cloud. No servers at all.
00:27 StrayBytes And in-game-currency is real bitcoin.
00:27 StrayBytes :P
00:27 [Ristovski] joined #minetest-dev
00:28 celeron55 i once thought after a workday that i could implement some kind of a REST/HTTP voxel server that would do nothing else, and then announce it and wait for somebody to make some part of a client for it 8)
00:30 Exio well, a random thing, what do you think about https://github.com/minetest/minetest/pull/653?
00:30 hmmmm oh
00:31 Exio it is not "compatible" with the actual code, but hm
00:31 VanessaE I thought that was already in.  Obviously not.
00:31 hmmmm yeah you don't need to do that with the HUD api now
00:31 hmmmm just set the crosshair_alpha=0
00:31 hmmmm and then place your image in the hud api in the center
00:32 Exio is it possible to 'apply colors' to that?
00:32 Exio i mean, a white-crosshair-image with a blue/whatever/line, plus you being able to changing that in the client
00:32 hmmmm you can do all that yeah
00:32 celeron55 lua hud is kind of not fully useful for that
00:33 hmmmm why, because it can't be centered?
00:33 StrayBytes I'll take a few weeks to think and plan out a TCP-based protocol, not that it would necessarily be implemented.
00:33 celeron55 part of the idea of the custom crosshair is that the player can set any crosshair that he wants on his local client
00:33 hmmmm if the mods had access to each clients' dimensions, they can do all that on their own and more
00:33 hmmmm oh.
00:33 hmmmm alright, i'll add an image override then
00:33 celeron55 but dunno
00:33 StrayBytes The server could be used for TCP holepunching reasons, fallback to UDP holepunch, and fall bakc to relaying via the server
00:34 Exio hmmmm: how do you make the client "colorize" some luahud image?
00:34 celeron55 StrayBytes: in minetest, the server is authoritative of most things and none of other clients simulate other client's worlds, so that is kind of far fetched
00:35 hmmmm the client?  you can't
00:35 Exio hm
00:36 StrayBytes No, what I'm thinking is that player movement and interaction could be done over p2p so the server doesn't have to relay it all.
00:36 celeron55 StrayBytes: i think the (quite humble) goal for it should be just to make a simple protocol that works because TCP works well
00:37 StrayBytes Yeah, I probably went too far.
00:37 StrayBytes But hey, can't I imagine a lag-free world?
00:37 kaeza misc: a ^tint[R,G,B,A] tex transform or smth like that would be useful, at least to reduce the amount of textures in mods like unified(dyes|bricks), coloredwoods, etc
00:37 Exio you can imagine whatever you want
00:39 hmmmm kaeza, that fits in with my colorlike drawtype
00:39 StrayBytes I'm thinking someday chunks could hop between players so the server would simply keep the clients up to date with simple changes and worry more about the important stuff.
00:39 celeron55 i do think we should work towards making minetest a bit more network protocol agnostic
00:39 hmmmm which hasn't been coded yet
00:39 RealBadAngel http://i.imgur.com/sr48Fwh.png
00:39 RealBadAngel looks almost good imho
00:39 hmmmm what's still wrong with it?
00:39 VanessaE almost?
00:39 VanessaE it looks very good
00:39 StrayBytes It would be shortest-path problem all over again :/
00:39 VanessaE one thing:  don't put blank pixels in the frame.  that makes it look like ass
00:40 VanessaE :)
00:40 RealBadAngel me?
00:40 RealBadAngel thats default texture
00:40 VanessaE I assumed.
00:41 celeron55 it's not a frame, it's just the edge of bare glass!
00:41 VanessaE oh I see what's "wrong", the backside streaks are still visible.
00:41 VanessaE celeron55: maybe not, but to most people I'm sure it looks like a frame.
00:41 VanessaE and it *still* looks like ass :D
00:42 StrayBytes http://dev.minetest.net/Rarkenin/Draft_TCP_network_protocol
00:42 StrayBytes I'll work on it when I can.
00:42 StrayBytes Which means, unfortunately, not at the moment,
00:43 StrayBytes Do you think TCP holepunch could be implemented?
00:43 celeron55 StrayBytes: please leave out all p2p and other unnecessary things, especially if you can't implement it - nobody will have time or interest to actually make it
00:44 StrayBytes OK.
00:44 StrayBytes I'll just stick to basics.
00:44 StrayBytes Thoughif I ever learn C++, that may be my goal for improvement.
00:44 celeron55 make it the most KISS thing you have ever done
00:45 StrayBytes Understood.
00:45 StrayBytes I'll try to keep as much of the existing stuff in place/
00:45 celeron55 i do predict you have too little knowledge of MT's serialization things to make anything final though (which makes me think you even starting that is kind of odd, but anyways)
00:46 StrayBytes I've actually already partially reimplemented part of the serialization in PHP for a bot that I ended up abandoning due to time constraints/
00:47 celeron55 also i think just sending "message id" + "data length" + "data" triples will work just fine, so the only thing to define is how many bits to use for each :D
00:48 StrayBytes Staying in UDP? Or are you talking about TCP already?
00:48 celeron55 i mean, that'd be just putting the current UDP packets as messages with ids in the TCP stream
00:49 celeron55 do you think there would be need for anything else?
00:49 StrayBytes Packet aggregation would be very important when it won't cause more delay for time-sensetive packets.
00:49 celeron55 of course clean up stuff all-around, but generally otherwise
00:50 celeron55 doesn't common TCP implementations do somewhat reasonable amount of that automatically?
00:50 StrayBytes Why would we need message ids in the first place? TCP is already ordered, and length is enough as long as the code doesn't accidentally lose track of the data.
00:51 celeron55 StrayBytes: id = message name, or command or whatever you'd call it
00:51 StrayBytes Oh, I thought you were referring to packet ids.
00:51 celeron55 the title of the data, see clientserver.h
00:51 StrayBytes I'm aware. I just had the terminology backwards.
00:52 celeron55 i think they're called commands in the current implementation
00:53 EduardeCalibal joined #minetest-dev
00:54 hmmmm [08:47 PM] <celeron55> also i think just sending "message id" + "data length" + "data" triples will work just fine, so the only thing to define is how many bits to use for each :D      indeed, sounds like a protocol i worked on for quite some time, except it started each packet with a sanity byte in the header:)
00:54 hmmmm well that's sufficient for a TCP protocol anyway
00:54 StrayBytes I'm thinking that the magic numbers should only be sent at the start of a session.
00:55 hmmmm magic numbers?
00:56 hmmmm anyway how about this: 1 byte for the packet id, 3 bytes for the length
00:56 hmmmm in that order
00:56 StrayBytes 0x4f457403 arethe magic numbers.
00:57 hmmmm erm where is that?
00:57 StrayBytes clientserver.h line 110
00:57 StrayBytes Used at the start of each old packet.
00:57 hmmmm ew
00:57 StrayBytes Now should be at the beginning of a session.
00:57 hmmmm also that number looks odd, can't really read it
00:58 StrayBytes Should long packets be split by IP fragmentation, or should we use application-level chunking?
00:58 hmmmm if you're going to put a magic number in, it ought to mean something
00:58 hmmmm i vote for 'mine' or the like
00:58 hmmmm application level chunking obviously
00:58 hmmmm here's how it should work:
00:59 Jordach *yawn*
00:59 hmmmm retrieve header, see the data length, expect that many bytes and don't trigger any packet handlers before all the bytes arrive
00:59 StrayBytes I'm thinking any non-time-sensetive packets are queued until either they've waited a certain amount oftime, a time-sensetive packet is due to be sent, or the queue reaches a certain size. Then they're sent as one to minimize overhead.
00:59 VanessaE three bytes for a packet length...isn't that a bit excessive?
00:59 hmmmm vanessae, from what i understand, packets can already be larger than 65536 in minetest
01:00 hmmmm or am i mistaken?
01:00 StrayBytes What about having packet length be preset for the commands for which that can be done?
01:00 VanessaE hmmmm: I would hope not given the average TCP packet is only ~1500 bytes.....shouldn't a new protocol consider that?
01:00 hmmmm StrayBytes, that adds a lot more complication...
01:00 hmmmm besides, if you're using TCP, it's assumed that your packet isn't very time sensitive in the first place :p
01:00 VanessaE (I know we aren't using TCP now, just saying)
01:01 hmmmm erm
01:01 hmmmm 1500 bytes is the frame size
01:01 StrayBytes What about making a TCP=UDP hybrid?
01:01 hmmmm and that's below our application level
01:01 hmmmm TCP/UDP hybrid?  that's what the current protocol already is
01:02 VanessaE hmmmm: well even when that's the case, a 64k packet is a recipe for horribly latency issues, I think
01:02 StrayBytes Where's the TCP already in use? Just outsourced to cURL for media ftching, IIRC.
01:02 VanessaE s/ly/le/
01:02 Deivan joined #minetest-dev
01:03 hmmmm vanessae, no you're not understanding, we send them as they are sent, not all in 65536 byte batches
01:03 VanessaE OH
01:03 VanessaE ok
01:03 hmmmm it's just that the maximum size could be that
01:03 hmmmm straybytes, yeah, TCP is just used for those things.  my idea is that we use TCP for bulk transfers too, such as mapblock transfers
01:04 StrayBytes A lot of Minetest's packets are horribly small. Not culling them is a true recipe for lag.
01:04 StrayBytes Mapblocks, that's a start.
01:04 VanessaE StrayBytes: I think I'd be careful to distinguish lag from latency (even though one will cause the other)
01:04 hmmmm i know i'm probably getting annoying with using starcraft as an example but it's very well done
01:04 StrayBytes *latency then.
01:05 hmmmm starcraft buffers up all the packets to be sent in 250ms intervals
01:05 VanessaE hmmmm: so?  if they did it right, they did it right - so let that program be MT's role model
01:05 VanessaE (so to speak)
01:05 Jordach for the networking part
01:05 VanessaE Jordach: natch
01:06 StrayBytes That's what I was thinking, except a time-sensetive packet can force the current buffer to be sent.
01:06 hmmmm sounds fair enough
01:06 Jordach go look at red eclipses, or openarena's networking code: they are flawless
01:06 Jordach and highly polished
01:06 Exio if a FPS doesn't have that plus a lot of client-side prediction
01:07 Exio it can't be called an actual FPS ;)
01:07 StrayBytes We'd want to set TCP_NODELAY if we're going to do our own packet culling.
01:07 hmmmm it'd be more helpful if someone just told us the gist of what they do rather than having us readin git all
01:07 hmmmm oh, no....
01:07 hmmmm don't disable the nagle
01:07 hmmmm seriously for that stuff we use udp, for bulk transfers we use tcp
01:09 VanessaE Jordach: how hard do you think it would it be to port openarena's networking model to MT?
01:09 Jordach depends on the programmer's networking skill
01:09 hmmmm we don't need their networking model at all
01:10 Jordach hmmmm, most isps dont like people uploading tcp afaik
01:10 hmmmm ....
01:10 hmmmm that's stupid
01:10 VanessaE Jordach: so I can't send files to my website? um....
01:10 Jordach hmmmm, torrenting is tcp
01:10 hmmmm and
01:10 VanessaE (I'm pretty sure rsync operates over TCP)
01:10 hmmmm practically everything else uses tcp
01:10 VanessaE exactly.
01:10 Jordach hmmmm, you do realise that tcp is a realy bad ide
01:10 Jordach idea*
01:10 hmmmm i do?
01:11 hmmmm you don't have any idea of what you're talking about, sorry
01:11 hmmmm TCP is great
01:11 hmmmm there's nothing wrong with TCP
01:11 Jordach because: isp willt think youre torrenting
01:11 VanessaE Jordach: you misunderstand.
01:11 hmmmm torrenting happens at the application level
01:11 VanessaE torrents may use TCP, but so does *everything* else nearly.
01:11 hmmmm everything you can possibly think of uses TCP
01:12 hmmmm websites, IRC, email, chat programs, etc.
01:12 VanessaE Jordach: the issue isn't what underlying protocol you use - it's what you DO with it.  MT isn't going to be opening hundreds of inbound/outbound connections from a single machine.
01:12 hmmmm by your logic, your ISP thinks you're torrenting right now by using IRC
01:12 Jordach hmmmm, maybe
01:12 hmmmm sit back and think about that for a moment
01:12 Jordach but then again these days
01:12 hmmmm "these days" what?
01:12 hmmmm everything uses TCP
01:12 Jordach youre isp is paranoid about anything you do
01:12 hmmmm and it's not going anywhere
01:13 VanessaE Jordach: simple solution (not suitable for MT):  SSL.
01:13 Jordach VanessaE, does it look like every website has https?
01:13 hmmmm i'm telling YOU as an expert on the topic that merely using a TCP connection does not flag anything as being a torrent
01:14 hmmmm i am not going to speak of this silly topic any further, go educate yourself by reading things on the internet if you still don't believe me for whatever reason
01:14 VanessaE Jordach: any website that values the security of their transmitted data uses https or ssl or some other method of encryption.
01:14 Jordach youre still going to get slowed down by the isp mechanically.
01:14 VanessaE mechanically?  wtf?
01:15 Jordach VanessaE, someof them have computers to limit your usage
01:15 Jordach despite being unlimited
01:16 VanessaE Jordach: an average MT server only draws between 1kB/sec and 10 kB/sec per user that's playing.  you're honestly trying to say that pushing 200 kB/sec (for 20 users, which is around half what my particular connection is capable of btw) is gonna get you flagged as an abusive customer?
01:17 Jordach VanessaE, depends on the time of length it happens for
01:17 Jordach isps will jump to conclusions based on high bandwitdh usage
01:17 VanessaE yeah, and you're not going to be pushing that sort of speed 24/7.
01:17 VanessaE you
01:17 VanessaE you're being paranoid now.
01:17 VanessaE put away your torrent client.
01:17 Jordach VanessaE, im not torrenting
01:18 Jordach my uncle runs a server, and he gets buffered by his isp despite being 100mb fibre
01:19 VanessaE buffered?  or throttled?
01:19 Jordach throttled.
01:19 Jordach yet he only uses a 1/10th of full power
01:20 VanessaE 1/10 full power = 10 mbps = a constant 1 MByte/sec stream.  THAT could get flagged as abusive especially if he's paying only for a "home" connection.
01:20 Jordach VanessaE, he runs a small home based server farm
01:21 Jordach 6 nodes in total
01:21 EduardeCalibal joined #minetest-dev
01:21 VanessaE that's why he's getting throttled.  DUH
01:22 Jordach that;s why he makes the cash to pay for the 100mb line
01:22 Jordach most isps lie when they say about your speed
01:22 Jordach and i dont trust speedtest.net
01:23 Jordach i swear they use UDP
01:23 VanessaE el wrong-o.
01:24 VanessaE NO ONE uses UDP for anything serious except for MT and maybe some old voice chat programs
01:24 Jordach VanessaE, 10kb/s up on http, 0.7mb speedtest.net
01:24 VanessaE literally 99% of everything going across the Internet is TCP-based.
01:24 VanessaE there's a reason the root protocol is called TCP/IP.
01:24 Jordach bull.
01:24 VanessaE no bull.
01:25 hmmmm this is an unproductive conversation
01:25 VanessaE agreed.
01:25 Jordach i know all current generation video games consoles are udp
01:25 hmmmm jordach is denying simple truths about how the internet works and it has nothing to do with minetest development
01:25 StrayBytes Why don't we just have all players run dedicated fibre lines between them and the server? :P
01:25 hmmmm should probably stop spamming the channel
01:25 hmmmm what if i started going around and telling people that the water they drink is actually H4O2 and not H2O
01:26 StrayBytes It's all DHMO anyway.
01:26 hmmmm "only 10% of water is H2O actually, the water company mechanically limits you if you use H2O"
01:26 VanessaE Oh G*D anything but DHMO!  BAN IT!
01:27 Jordach hmmmm, there are many people who would believe that
01:27 kahrl joined #minetest-dev
01:27 VanessaE hmmmm: ok, the description for water in the default game shall be renamed to "DHMO Source" et.al :D
01:27 hmmmm lol
01:27 StrayBytes I got my swim team tovote on not using DHMO during practices. Go figure.
01:27 VanessaE StrayBytes: no shit?
01:27 StrayBytes Really.
01:27 VanessaE *facepalm*
01:27 StrayBytes That's how stupid everyone is.
01:27 kahrl speedtest is unrealistically fast because isps prioritize traffic to and from there
01:28 kahrl not because of UDP or TCP
01:28 VanessaE ah, the prodigal son returns
01:28 StrayBytes And to consider I am on that team...
01:28 * StrayBytes shudders
01:28 StrayBytes Now can we get back on topic?
01:28 VanessaE no. :)
01:28 StrayBytes "Chit-chat goes to #minetest.¨¨
01:29 StrayBytes Yeah... I love for these people to jump in off the starting block and land on tiled, rock-hard, rock-dry pool bottom.
01:29 Jordach kahrl, its their little way of lying to the customer
01:31 VanessaE Jordach: ok ok enough of this subject.
01:31 * VanessaE hands StrayBytes a spatula so he can spread those umlauts downward into full quote marks.
01:31 Exio is there any typedef for core::rect<s32>?
01:32 Exio nevermind
01:34 kahrl a protocol idea: someone mentioned leaving out the size field for small fixed commands, maybe the server could send a map<u16, u16> from command ids to command lengths (after TOCLIENT_INIT)
01:35 kahrl commands that aren't included in this map are dynamic and need a size field
01:36 kahrl it would obviously be better than hardcoding the commands lengths in the server and client
01:36 hmmmm a size field is practically nothing in comparison to the beefy header that's already sent
01:36 hmmmm aggregating commands would be better
01:36 kahrl there would be no need for the header in the TCP stream
01:37 hmmmm except for the command id
01:37 hmmmm you can do that, sure, i don't really think it'll help much though
01:38 kahrl even the UDP header can be reduced, a lot of the stuff (like pings, split packets and so on) can probably be moved to the TCP side
01:40 Exio - https://github.com/EXio4/minetest/commit/b5e7d9bd419f96706006247ff6c74d2c34317061
01:44 Pentium44 joined #minetest-dev
01:44 Pentium44 joined #minetest-dev
01:47 ecube_ joined #minetest-dev
01:47 Deivan joined #minetest-dev
02:03 hmmmm alright
02:03 hmmmm i should tell you guys what i've been up to
02:03 hmmmm so what i've been working on primarily is the caves
02:03 Jordach watching ponies?
02:03 EduardeCalibal joined #minetest-dev
02:04 hmmmm what i accomplished was making caves into its own self-contained class and it makes many things neater, and i divided up the pieces of the code into neat functions
02:05 hmmmm defineCave() was removed, what it does is implemented in the constructor
02:05 hmmmm to define your own defineCave(), then, you need to define your new constructor, override generateCaves(), and make sure it uses your derived cave class
02:05 hmmmm some other obvious benefits to this is that you can override each individual piece of the cave code
02:06 hmmmm it's easier to understand
02:06 hmmmm etc.
02:06 hmmmm unfortunately i can't do much with code reuse
02:07 hmmmm the cave class is named "CaveV6" which shall not be modified functionally (if you want to use it in your own mapgen, you need to make a derived class from it)
02:07 hmmmm modifying cave generation means modifying the terrain features, which is not allowed for v6
02:09 hmmmm however, for the V7 cave system, i am modifying V6 much more extensively and it doesn't seem like i can just override a couple functions to get the cleanness and functionality i want
02:10 hmmmm an unfortunate side effect of this is, effectively, having to duplicate what seems like a lot of functionality (but not code)
02:10 hmmmm before i start committing things, how many people believe i should move this off into its own file, cavegen.cpp (like dungeongen.cpp)?
02:11 Jordach yeah
03:33 VanessaE joined #minetest-dev
04:25 hmmmm uhh, interesting?
04:25 hmmmm i kinda figured the caves didn't match up 100% after i did this
04:26 hmmmm i seemed to have fixed the walled-in-cave problem somehow
04:26 Exio walled-in-cave?
04:26 hmmmm s/seemed/seem/
04:26 hmmmm yeah, up against a chunk boundary, you'll sometimes get a solid, flat wall of stone where you'd expect the other half of the cave hole
04:27 Exio ah
04:27 hmmmm this walled in cave problem isn't the same as the one that i completely understand that happens when multithreading is enabled
05:06 hmmmm https://github.com/kwolekr/minetest/commit/03868ff8e1bcdcc831b8bd845b8ea7961f7ea1c8
06:03 salamanderrake joined #minetest-dev
06:25 proller joined #minetest-dev
06:30 ImQ009 joined #minetest-dev
06:35 ShadowNinja joined #minetest-dev
07:01 Guest43496 joined #minetest-dev
08:17 iqualfragile joined #minetest-dev
08:30 Zeg9 joined #minetest-dev
09:32 darkrose joined #minetest-dev
09:34 Jordach joined #minetest-dev
09:37 VanessaE joined #minetest-dev
09:41 iqualfragile i know that the average minetest server does not have such problems but: when the uptime is high
09:43 iqualfragile it does not show a sane uptime on join anymore but sth like 1.71587e+06
09:45 Jordach 1.71587e+06 is just sanely compressing the amount of time to a smaller number.
09:48 PilzAdam joined #minetest-dev
09:49 iqualfragile but 1.71587e+06 does just not look good
09:51 sfan5 1.71587e+06 equals 1715870  so thats just stupid
09:51 VanessaE *nod*
09:51 iqualfragile is the uptime in minutes?
09:52 VanessaE don't use scientific notation at all (seconds, btw)
09:52 VanessaE expand it to minutes, hours, days, etc.
09:52 iqualfragile yeah, that fits
09:52 iqualfragile because that are only 20 days of uptime
09:53 iqualfragile and its allready _realy_ outdated… minetest develops too fast
09:53 VanessaE I was about to say...20 days old, you may as well be running 0.3.x
09:53 VanessaE :)
09:54 iqualfragile but i can still connect with git clients
10:01 Jordach at least were developing and not being still
10:02 iqualfragile that was ironic
10:02 Jordach like Minecraft most of the time
10:10 Jordach left #minetest-dev
10:36 Jordach2 joined #minetest-dev
10:40 Jordach2 joined #minetest-dev
10:41 celeron55 >minetest develops too fast
10:41 celeron55 some people say exactly the opposite
10:42 darkrose joined #minetest-dev
10:42 darkrose joined #minetest-dev
11:09 Deivan joined #minetest-dev
11:37 iqualfragile joined #minetest-dev
12:02 Deivan I have a big amount of the "teleport incident" here...
12:02 Deivan When my char is teleported to the "(inf, 0,0)" or similar position...  :-/
12:07 Deivan About the new api, now is possible change a texture at running time?
12:10 Jordach joined #minetest-dev
12:26 sfan5 Deivan: i also experienced the teleport bug
12:28 Deivan Is strange, don't happen in the minimal game, only in my main game...  I experienced 5 times in 20 minutes...
12:28 Deivan :-o
12:28 sfan5 it happend to me once on jordachs server
12:29 Deivan :-/
12:29 Deivan Well, I have RL work to do...
12:29 Deivan Someone is writing a FAQ to the API?
12:29 Deivan I think is very necessary. :)
12:29 Deivan Well, cya.  AFK
12:40 PilzAdam joined #minetest-dev
12:51 darkrose joined #minetest-dev
12:51 darkrose joined #minetest-dev
13:01 Jordach joined #minetest-dev
13:02 Jordach joined #minetest-dev
13:16 NotAidan joined #minetest-dev
13:56 jojoa1997|Tablet joined #minetest-dev
13:57 sapier joined #minetest-dev
13:57 jojoa1997|Tablet i am just wondering if allowing ingame texture switching will ever be on the todo list?
13:57 sapier https://github.com/minetest/minetest/pull/673 reduce cpu power required to get free object id
13:58 sapier maybe this reduces object duplication problem too
14:01 celeron55 "reducing" a bug is exactly what one does not want to do; it is not fixing but will rather make fixing harder
14:01 celeron55 disclaimer: i don't know what this duplication problem you are talking is about
14:02 IceCraft joined #minetest-dev
14:03 IceCraft joined #minetest-dev
14:05 sapier it's not reducing the bug its removing a silly search algorithm starting at index 1 to get a new id everytime
14:06 sapier after looking at 200 objects for object 201 it'll look for 201 objects for object 202 ...
14:08 sapier new algorithm takes next free id thus reusing id's only after 65k have been used thus if the duplication was result of id collision (not prooven to be) this bug would be reduced
14:10 IceCraft joined #minetest-dev
14:10 sapier so if you don't want to fix a bug because this may reduce frequency of another bug to happen this shouldn't be added
14:15 celeron55 i am not arguing against the algorithm
14:16 celeron55 i am arguing about the questionable secondary benefits you seem to advertise it to have
14:17 sapier sometimes I feel making anythin right isn't possible if I don't tell possible side effects I get blamed for not telling if I tell I get blamed for not fixing the other thing ;-)
14:19 sapier but true I was looking for the duplication glitch when discovering this slow oid generation algorithm ... if I find out why objects are duplicated I'll fix that one too :-)
14:25 Calinou joined #minetest-dev
14:27 hmmmm joined #minetest-dev
14:31 RealBadAngel hi hmmmm
14:31 RealBadAngel http://i.imgur.com/AfERhKw.png
14:32 RealBadAngel here's where i am atm
14:34 hmmmm awesome
14:35 RealBadAngel ive decided not to replace current drawtype but add new one
14:35 RealBadAngel glasslike_framed
14:36 RealBadAngel so if you want framed glass, you can craft it with some glass and sticks for example
14:36 hmmmm sounds good
14:36 sapier duplication still happens with improved id handling so you don't have to worry about a partly bugfix
14:37 RealBadAngel this way we have old and new drawtype
14:37 RealBadAngel and new extra content
14:38 hmmmm oh my god
14:38 hmmmm seriously?  that's how new items were added?
14:38 sapier are you talking to me hmmmm?
14:38 hmmmm why is it that so many things in minetest iterate over several thousands of items in order to accomplish something
14:39 hmmmm i wonder how much more of this type of code there is hiding
14:39 sapier yes I was astonished too maybe this didn't matter while there were next to no objects I have about 100 atm
14:39 sapier singleplayer
14:39 hmmmm hrm
14:40 hmmmm your optimization helps but still isn't ideal
14:40 hmmmm what if we used a bitmap for this
14:40 sapier driving with my monotail about 50 blocks results in unloading 90 and reloading them when driving back ... while those objects are loaded sometimes my cart is duplicated
14:41 sapier I don't know how a bitmap would be any faster?
14:41 hmmmm it'd be 64, 128, or 256 times faster
14:41 sapier oh to check if it's free
14:42 hmmmm also
14:42 hmmmm maybe skip lists would work
14:43 sapier lot of things can be improved but you may add additional overhead, I'n not sure how optimized stl already is
14:44 sapier atm regular case will be 1 find operation to get a new id
14:45 sapier way better than before where common case was number of objects +1 find :-)
14:46 sapier I've got about 20 carts by now ... and have only crafted 1
15:06 hmmmm ridges are tough to deal with :(
15:07 hmmmm i'm just screwing around underground in v7, and now i have grass growing inside of caverns.. :(
15:07 thexyz you can as well use stack, fill it with 65536 elements, pop IDs from it when you need a new ID, push ID to it back when it's freed
15:08 hmmmm that's pretty much how my skip list would work except it's a list instead of a stack and you don't need to add thousands of elements
15:09 thexyz isn't skip list O(log n)?
15:09 thexyz average
15:09 hmmmm perhaps O(1)....
15:09 hmmmm i wouldn't recommend something that i knew was log n
15:10 hmmmm the only way things get to be log n is if they deal with a tree structure
15:10 hmmmm welp
15:10 thexyz well, according to both my knowledge and wikipedia it's O(log N)
15:10 hmmmm nevermind
15:10 thexyz or maybe you're talking about something else
15:10 hmmmm i was
15:11 hmmmm hrmmm
15:12 hmmmm i am not finding the data structure i am thinking of on wikipedia
15:12 thexyz what is it capable of?
15:12 hmmmm not sure
15:12 hmmmm let me just describe it;
15:13 troller joined #minetest-dev
15:15 hmmmm you have a linked list of free IDs, every time you get a new ID you grab the first ID from the top of the list and then increment the lower bound of that link.  when you go to free it, you just add that ID into the gap where it should be in order, if the ID you're re-adding to the free list connects the adjacent links, then you merge it all into one link
15:15 hmmmm hm
15:15 hmmmm that probably wasn't clear at all
15:16 sapier current algorithm is O(1) for normal case and O(n) for worst case
15:16 hmmmm wait, actually, is it necessary for new IDs to be the numerically lowest free ID?
15:16 sapier no it isn't
15:17 thexyz how's that different from what I was suggesting?
15:17 hmmmm then WTF, this is trivial
15:17 sapier my solution is already trivial ;-)
15:17 hmmmm thexyz, it's different because you suggested we fill a stack with several thousands of elements, here i am making them number ranges stored in links
15:17 thexyz oh, I see
15:18 hmmmm well if sapier says his is already decent, i guess that's good enough for me
15:18 * hmmmm is curious about what his algorithm is called
15:18 Jordach cant you use binary flags
15:18 Jordach if one is free, make it usable
15:18 hmmmm a bitmap?  yes, i suggested that
15:18 hmmmm but it's still O(n) average case
15:18 sapier it's taking next id everytime checking if it's free in case there is some long time object beeing present after 65k objects have been created it'll have to skip it
15:19 sapier no
15:19 sapier my suggestion is O(1) in average case
15:19 hmmmm i was responding to jordach just now
15:19 sapier sorry
15:19 thexyz sapier's is actually O(n) worst case
15:19 thexyz well, not like it matters
15:19 Jordach hmmmm, common sensically, you would ensure any empty slots would have their ram freed
15:19 Jordach and ready to be used at any time
15:20 sapier yes O(n) in case there have been 65k objects and only recently used object has been freed
15:20 hmmmm yes, that's called a 'naive' way
15:20 hmmmm we are not naive people though, we're more clever than that
15:20 hmmmm so common sense isn't good enough
15:20 thexyz hmmmm: the problem is "you just add that ID into the gap where it should be in order", if I got this correctly, it's O(n)
15:20 sapier sorry using any overcomplicated way just to make it complicated sounds insane to me
15:21 hmmmm ah yeah, thexyz, that is true, freeing would take O(n)...
15:21 thexyz non-asymptotically sapier's modification is sane enough
15:21 thexyz I guess we should just put it in
15:21 thexyz and forget about IDs for a while
15:22 hmmmm sapier, I mean in reference to what jordach was just saying.. what was already being used is indeed the naive way to get a free number like that, your version is not complicated, but it isn't the naive solution
15:22 sapier oh I see ... I'd even call the old method "the stupid way" ;)
15:23 hmmmm naive is just a kinder way of saying stupid
15:23 Jordach a even simpler approach would be a 2d array, where the flag is stored in the second array co-ordinate
15:23 Jordach and have the id as the first
15:23 sapier jordach keeping multiple data structures in sync isn't simple :-)
15:23 hmmmm and i don't even see how that'd work
15:24 sapier creating a bitmap marking used ids ... still I assume keeping this in sync is way more risky than any benefit we would get of it
15:25 hmmmm why do programs use ~/.cache and not /tmp
15:25 hmmmm ugh
15:26 thexyz > $XDG_CACHE_HOME defines the base directory relative to which user specific non-essential data files should be stored. If $XDG_CACHE_HOME is either not set or empty, a default equal to $HOME/.cache should be used.
15:26 thexyz standards!
15:27 sapier "standards are linke women ... the other one is always better :-)" ... not quite sure who did say this
15:28 proller joined #minetest-dev
15:40 sapier LOL "infostream<<"ServerEnv: WARNING: Performing hack #83274"
15:40 sapier does anyone know what hack #83274 actually does? :-)
15:40 Exio seems legit, 83274 hacks in MT source
15:40 Exio sapier: 1/0=2!
15:41 sapier seams someone tried to fix this problem and made it worse :-)
15:49 troller joined #minetest-dev
15:51 proller joined #minetest-dev
15:51 Jordach joined #minetest-dev
15:58 Jordach2 joined #minetest-dev
16:05 hmmmm [screams internally]
16:06 WInterspoon joined #minetest-dev
16:06 Jordach2 btw, WInterspoon is LandMine
16:06 WInterspoon goood goood
16:06 WInterspoon booo hooo
16:06 Jordach2 thexyz, ^
16:06 WInterspoon whats wrong kangaroo fucker? cant handle your own?
16:07 WInterspoon was kicked by thexyz: WInterspoon
16:07 Jordach2 thexyz, keep operator engaged, he'll be back
16:07 Jordach^2 nick change again to avoid discovery
16:08 thexyz who's that?
16:08 sapier << wonders what hmmmm discovered
16:08 thexyz oh, I see
16:09 hmmmm god damn caves overcomplicate everything
16:10 sapier strange ... someone thought it'd be a good idea to make "insert" remove something in case of id is 0 :-/
16:10 hmmmm the thing i'm experiencing is also a bug in mapgen v6
16:11 hmmmm except it's more noticable and annoying here because i just place grass and not grow it
16:11 hmmmm oh my god.
16:11 hmmmm so annoying.
16:12 hmmmm all of our problems would be fixed if we steal a bit from the mapnode structure somewhere and reserve it for "was this placed by caves?"
16:12 hmmmm but i'm avoiding that
16:12 sapier btw is luahud merged to an extent starting update of scriptapi split makes sense?
16:12 celeron55 that's not a good idea because there are many things like caves that might need similar flags
16:13 celeron55 or, i predict there can be
16:13 hmmmm luahud is completely merged
16:13 sapier or someone digging ceiling off a cave
16:13 celeron55 yes, do the update now; nobody is working on any scriptapi stuff at the moment
16:13 celeron55 and get it ready before somebody starts to
16:13 sapier ok then I'm gonna start to update the split changeset
16:14 sapier adding a folder for scriptapi is common consens?
16:14 hmmmm yes and modapi too
16:15 sapier ok just wanted to be sure
16:15 hmmmm well this sucks
16:16 hmmmm it is literally impossible to differentiate between air placed by a cave and air placed by 3d noise when carving ridges
16:16 hmmmm i can solve this by adding a check if below water level, but that's so hackish...
16:19 hmmmm well, having dirt underneath underwater ridges is something people probably won't miss, and it certainly is better than having bits of grass inside of lava caves
16:22 Jordach joined #minetest-dev
16:24 hmmmm neat, naturally occuring obsidian
16:32 BlockMen joined #minetest-dev
16:32 proller joined #minetest-dev
16:40 BlockMen i think i found a bug in HUD api: when i use 'player:hud_change(hudid, "text", "whatever") ' it shows no effect. changing the color works fine 'player:hud_change(hudid, number, 0xFFFFFF)'
16:41 BlockMen *"number"
16:45 hmmmm uh oh
16:45 hmmmm erm for the time being, encase that parameter in {}
16:45 hmmmm thank you
16:49 celeron55 that has been reported a couple of times i believe
16:51 BlockMen celeron55, where?
16:51 BlockMen hmmmm, you mean here or at my code?
16:52 hmmmm nevermind, i'll push a fix within the next couple of minutes
16:53 BlockMen hmmmm, ok, thx
16:56 hmmmm https://github.com/minetest/minetest/commit/14ba94ad6a0e2176106af08e41d99ad81b03e9e4
17:03 StrayBytes joined #minetest-dev
17:12 BlockMen hmmmm, works fine. thx
17:18 PilzAdam celeron55, what happened to the "community release" thread?
17:30 proller joined #minetest-dev
17:37 emptty joined #minetest-dev
17:44 thexyz PilzAdam: it's trashed
17:44 thexyz no idea who did that
17:45 hmmmm could've been celeron, he didn't like that thread too much
17:46 thexyz > tl;dr: mito551/minetest is a liberal experimental fork, where your commits are much more likely to be added than in minetest/minetest
17:46 thexyz well, initially minetest/minetest was aimed to be "a liberal experimental fork, where your commits are much more likely to be added than in celeron55/minetest"
17:46 Calinou thexyz: I trashed it, because these kinds of dicussion make us look like 4channers
17:47 Calinou feel free to put it back if you want
17:47 Calinou don't forget at how new players will look at us.
17:47 thexyz oh yes
17:47 thexyz let's suppose it hit bump limit
17:47 thexyz with all those shitty meme faces
17:48 Calinou people started using memes in that thread already
17:48 Calinou :P
17:48 thexyz so, did mauvebic burn out?
17:49 RealBadAngel i doubt it, hes too addicted
17:51 BlockMen Calinou, on the other side discussions like that are typical for a community
17:53 Exio just a random thing, about -delta, why not redirecting it to here?
17:54 StrayBytes joined #minetest-dev
17:54 sfan5 good idea
17:54 hmmmm i know this is off-topic, but it's simply amazing how much it helped to make dungeons have more rooms and some bigger rooms
17:54 sfan5 -delta feels like dead
17:55 hmmmm freakin' epic
17:55 Exio just +if #minetest-dev mlock and "work done" in that - just saying
17:59 celeron55 i don't approve censorship of things like that thread
17:59 celeron55 locking it is fine, but putting it in trash isn't a good thing
18:00 sfan5 I moved it back and closed it
18:02 hmmmm i guess the underlying problem is that we call it community-based development but it's really not
18:02 celeron55 free speech gives a better chance for disagreeing people to fix things that auhtorities can't fix
18:02 celeron55 it's better in the long run; if we just plain suck, then it's better that we get put out of power by a fork
18:02 celeron55 not depending on however unlikely it might seem
18:02 PilzAdam hmmmm, depends how you define community
18:03 hmmmm other FOSS projects aren't afraid to come out and just say "the <X> team"
18:03 hmmmm i think it's because of how minetest development is advertised to be completely open, people expect to poop on a .diff and have us merge it
18:03 hmmmm "can you come up with a reason why it SHOULDN'T be added?"
18:04 celeron55 uhm
18:04 hmmmm oh how many times do i hear that
18:04 celeron55 can you point at any official page that says anything about being completely open or something like that?
18:04 hmmmm and then look at other projects, where people are actually grateful to the developers and not resentful like the community is to us
18:04 hmmmm official page?  no, i can't
18:06 celeron55 then we can't do much about it and we'll just let it be - it's worth mentioning that outside contributions are taken in at a steady-ish pace anyway
18:06 celeron55 as long as the pace isn't 0, we don't have a large problem
18:07 emptty joined #minetest-dev
18:08 hmmmm so i guess the best we can do is discourage people from using the phrase "community based"
18:09 kaeza joined #minetest-dev
18:09 hmmmm i know i'm guilty of saying that a few times, but i won't anymore
18:09 celeron55 upstream development is not particularly community driven, because of practical reasons; i think it should be kind of obvious though
18:10 celeron55 nevertheless i think it is unfair that the people complaining most also will do the least for making things the way they see best
18:11 hmmmm there seems to be a lot of information about colored lighting in particular... i was toying with the idea of completely explaining what would have to be done precisely and why it's bad and all other things, but then i remembered they probably don't care and/or aren't technical minded enough to understand
18:11 PilzAdam "This is the first completely community-made release" – http://c55.me/blog/?p=1436
18:11 hmmmm s/information/misinformation/
18:12 celeron55 it's way more community-made from the standpoint of how previous releases were made
18:12 Exio PilzAdam: community-made = not-99%commits-by-celeron55
18:12 hmmmm hahh
18:12 hmmmm >Thanks c55 for kicking off this project. It is great to see a productive online community like this.
18:12 hmmmm "yeah, look at how horrible he is, he ruined minetest!"
18:12 celeron55 it just seems that for some people "community" means "random people" rather than "people who can be relied on making stuff that is good for the project"
18:13 hmmmm oh, i misread that
18:13 hmmmm for some reason i thought it said thanks for kicking c55 off this project
18:14 BlockMen i think the main problem is, that they dont accept that someone (or a few ppl) have to give the whole thing a direction. if everone put in everthing it just crashes...
18:14 celeron55 the blog comments are always interesting, the people who talk there tend to be different than those who talk on the forum, or in IRC
18:14 PilzAdam BlockMen ++
18:15 EduardeCalibal joined #minetest-dev
18:16 celeron55 i do think the core team could be more transparent in what direction it is taking and what modders can expect from their mods being taken upstream and so
18:16 PilzAdam I see 2 communities here (or "groups" would be a better name): devs and players
18:16 celeron55 i see three: in addition to those, modders are a really strong one
18:16 sapier and dev's rarely play at all ;-)
18:17 hmmmm why on earth do we develop minetest
18:17 PilzAdam modders are inbetween the players and devs
18:17 hmmmm this makes no sense
18:17 hmmmm we never play the game
18:17 Jordach i think everyone should have a break
18:17 hmmmm we don't get any money off of it
18:17 hmmmm it's super time consuming
18:17 celeron55 maybe stop developing for a month or so and see what people think? 8)
18:17 hmmmm the pull requests would be in the stratosphere
18:17 Jordach i think the devs are just too wound up about things
18:18 sapier I don't have any idea hmmmm ;-)
18:18 celeron55 they already are, that's not much of a concern
18:18 Exio celeron55: 50% of the stuff will get ported to lua
18:18 Jordach Exio, they said that about oregen
18:18 Jordach did it?
18:18 hmmmm oregon
18:18 hmmmm every time i see that, that's what i think of
18:18 BlockMen im absolutly against a break. minetest is going to be really popular. i a break would throw minetest kinda back
18:19 hmmmm using the name "oregen" implies that it's something bigger than it really is
18:19 PilzAdam people of the player community tend to "attack" the core dev that is doing stuff ATM
18:19 PilzAdam remembet the shitstorm about lava, or obisidian?
18:19 PilzAdam *remember
18:19 celeron55 it's a bit like most teenagers hate their parents
18:19 BlockMen lol
18:19 Exio hahaha
18:20 celeron55 or much like
18:20 hmmmm 2edgy4me
18:20 BlockMen PilzAdam, but that are just a few ppl who do that. i think the main part of the community is ok with the current way of development
18:21 PilzAdam BlockMen, the main part of the actual players isnt on the forum, IRC or somewhere else
18:21 celeron55 but really, the atmosphere on this channel is fine, and also the modders are doing fine, and players are too; then just some people start some kind of wars in unreasonable ways
18:21 thexyz those who are ok are usually silent
18:21 PilzAdam so we can only guess what they want
18:22 celeron55 thexyz: that is very true and should be understood by everyone
18:22 sapier does anyone understand why a activeobjects data is stored in the mapblock where it originally spawned? if that block gets unloaded objects static data is stored while object itself may still active
18:23 sapier this if this object finaly gets unloaded it will be duplicated
18:23 celeron55 sapier: the design there is that the static version is always stored somewhere
18:23 celeron55 and it should work so that when the block in which the active object is unloaded, it will load the old block, erase it from there and write it to the new one
18:24 celeron55 because if the static data is removed for the time when it is active, any crash would delete the object completely
18:24 sapier so it's either duplicate or loose :-/ there has to be a better way
18:24 celeron55 s/in which the active object is unloaded/in which the active object is is unloaded/
18:25 celeron55 sapier: there's no duplicate in the way i said
18:25 celeron55 if it works
18:25 celeron55 i guess it doesn't work in the current implementation
18:26 sapier no it doesn't seam to work my current working hypothesis is a block where static data really is stored can't be loaded for some reason this objects static data isn't deleted -> duplication
18:27 celeron55 maybe it has broken in some of the emergethread/whatever stuff
18:27 sapier sorry missing some , in this sentence
18:28 sapier I'm gona try to move static data to block where object is on the fly ... imho not best solution but worth a try
18:29 celeron55 what kind of items have even been reported to be duplicated?
18:29 sapier any moving entity
18:29 celeron55 ok; that makes sense
18:31 Jordach i have had that bug
18:31 Jordach i dropped a mese pick and i got two
18:31 sapier feels like the faster an entity moves the more likely to be duplicated as well as the more lag the more duplication too
18:33 PilzAdam unrelated: someone should fix the not loading entities bug
18:34 sapier define "not loading entities"?
18:34 PilzAdam you move away from one, then come back and it isnt there
18:35 sapier sometimes I feel I'm the only one fixing the strange bugs while all others only add new bugs(features) ;-)
18:35 PilzAdam move away again and come back some times and it sometimes appears, sometimes not
18:36 sapier that one :-)
18:36 sapier if I find it while looking for the other one I wont tell anyone :-)
18:37 Ukrainian_Reaper joined #minetest-dev
18:38 BlockMen i have a question: wouldnt it make sense to change the current way of adding mods? if i want use a mod at build aswell in minetest i have to store it 2 times.
18:39 BlockMen it would be better to make it like at textures, so "global" using
18:39 kaeza joined #minetest-dev
18:39 Jordach "global" mods would be nice
18:40 BlockMen and after watching a few videos of mintest newbies i noticed that there are a few who had problems with the game selection, and then with the mods too
18:43 sapier isn't that what common mods are for?
18:43 PilzAdam sapier, no
18:43 PilzAdam common mods are for game creators
18:44 sapier still you could use it that way
18:44 PilzAdam no, not really
18:44 BlockMen sapier, but then the mods folder is senseless
18:45 kaeza I think this would be useful for that https://github.com/minetest/minetest/pull/599
18:46 kaeza I don't know about the implementation, but the basuc udea is good IMHO
18:46 PilzAdam no, common mods are something completly different
18:46 kaeza -u+i
18:47 PilzAdam just add something like mods/all/ for game independent mods
18:47 kaeza in fact, I was thinking about something like what c55 suggested in that pull
18:47 BlockMen PilzAdam, that would be enough i gues
18:47 BlockMen *guess
18:48 PilzAdam why do people still not get the idea of common?
18:50 kaeza PilzAdam, can you explain exactly what is the idea behind common?
18:50 PilzAdam it contains mods, that games can load
18:51 PilzAdam so a copy of "default" in all games is not needed
18:51 StrayBytes I request a channel op in #minetgest
18:54 emptty joined #minetest-dev
18:55 kaeza PilzAdam, what #599 proposes is to add more "common mod dirs" (or rather, the ability to "import" mods from any game)
18:57 kaeza some people (imcluding myself) do not like modifying things like minetest_game and common
18:57 PilzAdam yes, people shouldnt do that
18:58 PilzAdam common mods are just for game creators, to not copy mods from the default game(s)
18:59 proller joined #minetest-dev
19:11 kaeza joined #minetest-dev
19:11 john_minetest joined #minetest-dev
19:14 celeron55 installing mods is kind of hard for newbies now though
19:14 celeron55 i mean
19:14 celeron55 i actually didn't even think of this aspect
19:15 celeron55 there is only mods/minetest pre-created, but if they use some other game they need to put them into mods/build or so
19:16 PilzAdam IMO we should install all mods simply in mods/ and they are for all games
19:16 kaeza maybe in mods/all
19:16 PilzAdam if people want the for some games only, they can disable them in the GUI
19:16 hmmmm erm celeron, just curious, is it possible that emergePlayer is called before map is generated when starting a new map?
19:16 hmmmm actually it's not just possible, it's the only way that it can happen
19:16 celeron55 hmmmm: umm... i think that is the common case especially in singleplayer
19:16 hmmmm ..which explains why findSpawnPos() never freaking works
19:17 kaeza also, a recurring problem in mods, is that people who download from github get a "foomod-master" dir, while the game expects "foomod"
19:18 PilzAdam kaeza, the -master can be ignored by the engine
19:18 kaeza can the game just ignore the "-master"/whatever part?
19:18 hmmmm don't you see?  no spot it looks at will ever be good because it's always content_ignore because it hasn't even been generated yet
19:18 kaeza ah
19:18 celeron55 ignoring it isn't implemented
19:18 PilzAdam someone just needs to code it
19:18 hmmmm so it _always_ iterates 1000 times and it _always_ gives up on a good spot
19:18 celeron55 hmmmm: i don't know, just fix it :P
19:19 hmmmm this is the true cause of the spawning too high bug
19:19 celeron55 no need to find anyone to blame
19:19 hmmmm but the thing is, it can't work by design
19:19 celeron55 it probably originally had some code for loading blocks for it or so
19:19 hmmmm unless you'd like it to just guess
19:20 hmmmm what?  it didn't
19:20 celeron55 i mean, that code comes from the very original versions of MT
19:20 celeron55 it's way older than your work here
19:20 hmmmm it uses Map::getNodeNoEx() which calls getBlockNoCreateNoEx()
19:20 hmmmm so it's never created
19:20 celeron55 do you insist that i go look up on some 2010 versions to see what they did?
19:20 hmmmm no....
19:20 celeron55 or shall we rather be productive
19:21 hmmmm i'm just saying that it's likely that it never really worked properly in the first place unless you modified Map::getNodeNoEx() within the time that it did work and then stopped working
19:22 celeron55 i'm not going to say anything about likeliness without actually looking up stuff
19:24 celeron55 i will say that it has probably been broken for a long time
19:24 celeron55 (which is obvious)
19:24 hmmmm yeah because people were blaming it on me for a time
19:25 hmmmm anyway what i figure i'll do is if it returns content_ignore, i'll assume that the current point is good to spawn at since nobody evidently built there yet or otherwise modified the land
19:29 hmmmm oh i'm sorry
19:29 hmmmm it was my fault
19:30 hmmmm i have selective vision it seems
19:38 john_minetest left #minetest-dev
19:39 hmmmm https://github.com/minetest/minetest/commit/daddd3770663655c3723ff9a4f4aba6010b1645c
19:41 salamanderrake joined #minetest-dev
19:42 PilzAdam finally
19:44 Exio :D
19:50 hmmmm well pilzadam, there are two very long-time bugs that were fixed like you wanted to see... black trees, spawning too high
19:50 hmmmm the thing is, this doesn't happen all the time because there was a reason why they weren't fixed quickly
20:18 serengeor joined #minetest-dev
20:23 StrayBytes joined #minetest-dev
20:41 EduardeCalibal joined #minetest-dev
20:53 emptty PilzAdam: do you plan to tag your mods repos at some point or you prefer to go with a rolling release? (just out of curiosity)
20:54 PilzAdam I prefer rolling release
20:54 PilzAdam I dont work on most mods anymore
20:54 PilzAdam so I mostly push bugfixes
20:54 jojoa1997|Tablet joined #minetest-dev
20:54 PilzAdam (or random suggestions by users)
20:55 emptty someone should implement a popularity contest in minetest, where the usage of some given mods is reported to a server that can run stats
20:56 emptty something like http://qa.debian.org/popcon.php?package=minetest
20:57 iqualfragile joined #minetest-dev
20:58 BlockMen left #minetest-dev
21:02 sapier1 joined #minetest-dev
21:11 Guest56729 joined #minetest-dev
21:22 RealBadAngel http://i.imgur.com/5d6sNvO.jpg
21:22 jojoa1997|Tablet nice
21:23 proller btw ubuntu prescie - minetest                                    0.3.1+dfsg-2
21:25 iqualfragile proller: yeah, thats a *bit* outdated but there is a ppa
21:25 iqualfragile -.- … i guess you already knew that
21:26 proller yes, 2-3 years old soft is normal for ubuntu and debian 8)
21:26 emptty this will propagate from debian automatically. I was too late for the last round of integration, so minetest will not be uptodate for the next stable of ubuntu (nor for the one of debian)
21:26 emptty but only servers are using the stable versions
21:27 emptty most debian users are on the rolling release (testing)
21:27 Exio hey, i'm on squeeze, still! :P
21:27 emptty and minetest will migrate as soon as the next stable comes out
21:27 emptty Exio: this explains why you feel the need to install some soft from the source :-P
21:28 Exio (being annoying other time to the core devs) what about https://github.com/minetest/minetest/pull/657 - https://github.com/minetest/minetest/issues/517 ?
21:29 Exio emptty: hm, :P
21:42 Tracerneo joined #minetest-dev
21:42 Tracerneo Hi
21:43 emptty I tried to install a mod in /usr/share/games/minetest/mods under linux; it gets detected and can be activated, but the textures are not found when starting the game
21:43 emptty it seems that only the lua is found in this location
21:48 Exio any op?
21:52 OWNSyouAll joined #minetest-dev
22:07 kaeza joined #minetest-dev
22:09 sapier1 https://github.com/minetest/minetest/pull/674
22:09 PilzAdam sapier1, capital letter at the beginning of commit messages
22:09 sapier1 this seams to fix duplication glitch too, at least did now dupplication happen since I aded it but I don't understand why
22:13 sapier1 so if someone understands why I'm really curious about it
22:27 kaeza joined #minetest-dev
22:31 salamanderrake joined #minetest-dev
22:44 VanessaE who cares about capital letters in a commit message?
22:44 sapier1 PilzAdam ;-)
22:44 VanessaE evidently ;)
22:45 sapier1 it'd be great if someone tested this changeset I'm not sure if it's only working in my case as I don't completely understand it ... the comment in there didn't help either
23:02 VanessaE joined #minetest-dev
23:10 sapier1 left #minetest-dev
23:20 dexter0 joined #minetest-dev

| Channels | #minetest-dev index | Today | | Google Search | Plaintext