Time |
Nick |
Message |
00:02 |
|
zat joined #minetest-dev |
00:05 |
|
Warr1024 joined #minetest-dev |
02:04 |
|
paramat joined #minetest-dev |
02:13 |
paramat |
hmmmm, i'd like to push this later https://github.com/minetest/minetest/pull/2831 'Mgv5/mgv7 caves: Fix sand in underground caves' |
02:19 |
|
crazyR_ joined #minetest-dev |
02:53 |
|
blaise joined #minetest-dev |
02:56 |
|
JeDa_ joined #minetest-dev |
02:56 |
VanessaE |
0 |
03:11 |
|
Player_2 joined #minetest-dev |
03:19 |
|
crazyR__ joined #minetest-dev |
03:20 |
|
zat joined #minetest-dev |
03:30 |
|
crazyR_ joined #minetest-dev |
03:49 |
|
RealBadAngel joined #minetest-dev |
04:47 |
VanessaE |
oops. |
05:03 |
|
selat joined #minetest-dev |
05:10 |
|
Hunterz joined #minetest-dev |
06:02 |
|
nore joined #minetest-dev |
06:10 |
|
Puma_rc joined #minetest-dev |
08:06 |
|
Yepoleb joined #minetest-dev |
08:27 |
RealBadAngel |
hi |
08:27 |
RealBadAngel |
just updated minimap |
08:28 |
RealBadAngel |
some style changes, cleanup and sneak+F9 to toggle minimap shape |
08:47 |
|
OldCoder joined #minetest-dev |
08:59 |
RealBadAngel |
kahrl, nore? |
09:22 |
|
Calinou joined #minetest-dev |
09:23 |
RealBadAngel |
hi Calinou, how about your exams? |
09:24 |
|
proller joined #minetest-dev |
09:25 |
Calinou |
they are done now |
09:26 |
VanessaE |
how'd they go? |
09:27 |
Calinou |
fine |
09:27 |
Calinou |
results on July 7th, 10h |
09:53 |
RealBadAngel |
can you try minimap now? |
09:55 |
Calinou |
which branch is it? |
09:56 |
RealBadAngel |
see PR |
09:56 |
RealBadAngel |
#2814 |
09:56 |
ShadowBot |
https://github.com/minetest/minetest/issues/2814 -- Add minimap feature. by RealBadAngel |
10:03 |
Calinou |
RealBadAngel, good, minimap going behind nodes appears to be fixex |
10:03 |
Calinou |
fixed |
10:03 |
|
OldCoder joined #minetest-dev |
10:04 |
RealBadAngel |
btw, try sneak+f9 |
10:06 |
Calinou |
https://lut.im/u1vAin66/ZSJYs4sz |
10:06 |
Calinou |
I tried :P |
10:06 |
Calinou |
https://lut.im/M4EqEQhu/XrVg89Hs |
10:06 |
Calinou |
the arrow is big and obnoxious |
10:07 |
Calinou |
plus, it should be white (or gray), not red |
10:07 |
Calinou |
red makes it non-neutral :/ |
10:07 |
Calinou |
(towards nearby nodes) |
10:07 |
Calinou |
RealBadAngel, also Git commits should not end with a period |
10:08 |
RealBadAngel |
this is matter of taste imho. anyway all minimap elements are textureable. you can change that to whatever you like |
10:09 |
|
twoelk joined #minetest-dev |
10:10 |
* twoelk |
thinks the red is ok. white wouldn't stand out on snow |
10:10 |
RealBadAngel |
if it was gray or white i would be hardly visible on beach and snow |
10:14 |
RealBadAngel |
Calinou, try the minimap with shaders on |
10:15 |
|
iqual joined #minetest-dev |
10:34 |
|
selat joined #minetest-dev |
10:37 |
VanessaE |
RealBadAngel: and you STILL didn't put my revised minimap texture into use :( |
11:26 |
|
iqual joined #minetest-dev |
11:34 |
RealBadAngel |
VanessaE, your texture fits HDX not default |
12:08 |
|
Darcidride joined #minetest-dev |
13:30 |
|
selat joined #minetest-dev |
13:46 |
|
est31 joined #minetest-dev |
14:05 |
|
CraigyDavi joined #minetest-dev |
14:30 |
|
Krock joined #minetest-dev |
14:33 |
|
RealBadAngel joined #minetest-dev |
15:07 |
|
CraigyDavi joined #minetest-dev |
15:19 |
|
RealBadAngel joined #minetest-dev |
15:39 |
|
troller joined #minetest-dev |
15:47 |
|
hmmmm joined #minetest-dev |
15:55 |
|
zat joined #minetest-dev |
16:18 |
|
proller joined #minetest-dev |
16:52 |
|
proller joined #minetest-dev |
17:22 |
|
proller joined #minetest-dev |
17:28 |
|
blaze joined #minetest-dev |
17:33 |
|
proller joined #minetest-dev |
17:44 |
|
rubenwardy joined #minetest-dev |
17:45 |
rubenwardy |
If someone has the time, please may they review #2094 and/or #1748 |
17:45 |
ShadowBot |
https://github.com/minetest/minetest/issues/2094 -- Fix offset being ignored by inventory bar HUD by rubenwardy |
17:45 |
ShadowBot |
https://github.com/minetest/minetest/issues/1748 -- Add lua errors to error dialog by rubenwardy |
17:45 |
rubenwardy |
#1748 only needs one more core dev +1 |
17:45 |
ShadowBot |
https://github.com/minetest/minetest/issues/1748 -- Add lua errors to error dialog by rubenwardy |
18:16 |
|
selat joined #minetest-dev |
18:20 |
|
Megaf joined #minetest-dev |
18:34 |
|
SopaXorzTaker joined #minetest-dev |
19:26 |
|
blaze joined #minetest-dev |
19:49 |
|
zat joined #minetest-dev |
19:49 |
|
cvtsx1 joined #minetest-dev |
19:51 |
|
RealBadAngel joined #minetest-dev |
19:54 |
|
troller joined #minetest-dev |
19:59 |
|
VargaD_ joined #minetest-dev |
20:01 |
|
selat joined #minetest-dev |
20:12 |
|
daswort joined #minetest-dev |
20:22 |
est31 |
wow, found a good use case for DES outside of cryptography |
20:22 |
est31 |
great xD |
20:23 |
est31 |
(I needed a function that scrambles the input reversibly) |
20:24 |
est31 |
not that the output should be non-decryptable |
20:24 |
est31 |
just needed for git hash like behaviour |
20:24 |
est31 |
you change a little on the preimage, the whole image changes |
20:32 |
* est31 |
wonders why again it was required to be reversible |
20:32 |
est31 |
ah, will just use pcgrandom |
20:34 |
est31 |
ah, /me remembers now |
20:35 |
est31 |
hmmmm, I've found a 1.9k line des implementation on the internet. Do you know any reversible function that has the above property, or can I add that one? |
20:36 |
est31 |
I'm searching for encryption or other "scramble" functions with the above property, and a block size of 64 bit |
20:37 |
est31 |
DES has a really small block size |
20:51 |
Warr1024 |
Any reason why it should be DES and not some other block cipher? |
20:52 |
est31 |
des has a block size of 64 bit |
20:52 |
Warr1024 |
so do most block ciphers before AES. |
20:52 |
Warr1024 |
64 bit blocks were the standard when they were targetted to 32-bit processors. |
20:53 |
Warr1024 |
DES has certain design features specifically intended to make it much slower in software than a dedicated hardware implementation. |
20:53 |
est31 |
ok, which one do you propose? |
20:54 |
Warr1024 |
Blowfish, on the other hand, is still considered "secure" even today (barring the 64-bit block issue) and is actually optimized for software implementation. |
20:54 |
Warr1024 |
why do you need a 64-bit block cipher? |
20:54 |
Warr1024 |
are you trying to build a reversible 64-bit hash function or something? Your use-case sounds a bit unusual... |
20:54 |
est31 |
yes |
20:54 |
est31 |
right that |
20:54 |
est31 |
I want to have a feature like git does |
20:55 |
Warr1024 |
you mean like its commit hashes? |
20:55 |
est31 |
yes |
20:55 |
Warr1024 |
do you have to worry about "security", i.e. is there any reason to fear that someone might want to intentionally exploit the system for some reason? Or are you only worried about avoiding "accidental" loss or collisions? |
20:56 |
est31 |
I'm only worried about collisions and "closenedd" |
20:56 |
est31 |
ss* |
20:56 |
Warr1024 |
closeness? |
20:57 |
est31 |
The numbers I want to feed to the function are 3 16 bit fields for a 3d position, and one counter, if there are multiple occurences of the same position |
20:57 |
Warr1024 |
oh, you're trying to replace the position hash? |
20:57 |
est31 |
no |
20:58 |
est31 |
I want to implement a new container for minetest, and the lua api |
20:58 |
est31 |
areastore |
20:58 |
Warr1024 |
ah, nice |
20:58 |
est31 |
so every area needs an id |
20:58 |
Warr1024 |
so you're looking for a function that generates a unique identifier froma 3d position... |
20:58 |
est31 |
and there are only few possible ways to find a free id |
20:58 |
|
MinetestForFun joined #minetest-dev |
20:59 |
est31 |
err I want to solve the "find a free id" problem |
20:59 |
Warr1024 |
the key problem there isn't algorithmic so much as search space. |
20:59 |
est31 |
of course, I could make it quadratic, with trying every id starting with 0 |
20:59 |
Warr1024 |
let's say you find a function that's reversible with a 1:1 mapping from the position to the key. |
20:59 |
est31 |
and then trying with a loop |
21:00 |
Warr1024 |
oh, for that, you just need a big array. |
21:00 |
Warr1024 |
Pick a random starting point |
21:00 |
Warr1024 |
and increment by 1 until you find a free one. |
21:00 |
Warr1024 |
almost any other algorithm you use will not improve on that significantly. |
21:00 |
est31 |
still quadratic in average, no? |
21:01 |
Warr1024 |
well, the key is that your array needs to be big enough |
21:01 |
Warr1024 |
i.e. overprovisioned compared to what you want to store |
21:01 |
Warr1024 |
if you have 99 out of 100 slots occupied, and want to find the one last one, you've got a good chance of having to iterate over half the thing no matter WHAT you use. |
21:01 |
est31 |
yes |
21:01 |
Warr1024 |
if you always start from 0, your long-run case will start looking like worst-case |
21:02 |
est31 |
yea |
21:02 |
Warr1024 |
starting from a random point will give you a good chance of having "gaps" available scattered throughout, so your long-term will not tend towards worst-case |
21:02 |
est31 |
thats a quite simple and efficient idea. |
21:02 |
Warr1024 |
but trying to use any hash algorithms or ciphers or whatever has the same effect as choosing a random number |
21:03 |
Warr1024 |
now, if you want to be able to do efficient *lookups* then you can use a hash algo... you've basically just rediscovered the hash table. |
21:03 |
est31 |
I have an intention with that |
21:04 |
Warr1024 |
If you're trying to build a hash table, SipHash is supposed to be a good algorithm for that. |
21:04 |
est31 |
of course, if all areas fit into the same space, its just what you described, take a c++ vector and place it in there |
21:04 |
Warr1024 |
hash tables provide good fast lookups for already-stored data, but capacity planning is tricky for them. |
21:04 |
est31 |
but I also target a setup where not every area is hold in memory |
21:04 |
est31 |
some is on the hdd |
21:04 |
Warr1024 |
in practice, structures like red-black trees often give better performance on operations like frequent inserts/removals. |
21:05 |
Warr1024 |
normally, you could store all the data on the HDD and make the ram copy act as a cache... |
21:05 |
est31 |
so the area referenced by the id can possibly be "offline". Then I need to know where it is |
21:06 |
est31 |
Warr1024, yes, I know, but take as example the minetest map. It isn't completely held in memory either. |
21:07 |
Warr1024 |
yeah, the map is written to the DB backend, and copies of chunks are held in memory as a sort of "cache" |
21:07 |
est31 |
yes right |
21:07 |
Warr1024 |
it's actually a pretty good model for how this sort of thing would be done. |
21:09 |
est31 |
I think I should tell you a bit more about the operations that data structure should have |
21:09 |
est31 |
and the usecases |
21:10 |
est31 |
the operations should be (besides storing stuff): insertArea, removeArea, getAreasForPos, getAreasinArea |
21:11 |
est31 |
and optimized against the last two operations |
21:12 |
Warr1024 |
tricky |
21:12 |
Warr1024 |
for getareasinarea, in particular |
21:12 |
est31 |
its usecases are protection mods and an area based minetest call register_on_dignore |
21:12 |
Warr1024 |
I wonder if what you really want is more like an octree index... |
21:12 |
est31 |
yes thats what I target |
21:12 |
est31 |
or plan |
21:13 |
est31 |
so the operation removeArea takes the id of the area, and removes it from the octree |
21:13 |
Warr1024 |
personally, I'd build a shitty implementation first, then test it and let people try it out, and look for performance issues based on real-world data :-) |
21:13 |
est31 |
but how does it know where to search inside the octree? |
21:14 |
Warr1024 |
What you're getting into is pretty tricky stuff, and it's hard to wrap your head around it all up front. |
21:14 |
est31 |
so I thought, lets build the position into the id, and let the remove operation traverse the octree down until it finds the entry |
21:14 |
Warr1024 |
maybe a 3d BSP would be best, though BSP's require you to choose to optimize for fewer cuts vs better balance. |
21:14 |
est31 |
then extract the area and its dimensions |
21:15 |
Warr1024 |
BSPs also may need to be partially or wholly rebuilt if an area is added, removed, or repositioned; a lot will depend on your read vs. write demand. |
21:15 |
Warr1024 |
i.e. will you be looking up area stats more or less often than people modifying them. |
21:15 |
est31 |
yup |
21:15 |
Warr1024 |
I think it's USUALLY best to optimize for few writes resulting in many reads, but I've run into odd cases where this isn't true. |
21:16 |
Warr1024 |
for instance, hash tables give the best read performance for arbitrary seeks, but compared to RB trees, they have (1) a larger memory footprint, and (2) slower insert/removal (esp if they need to be resized). |
21:16 |
est31 |
hrmm bsp sounds good |
21:16 |
est31 |
hash tables are not at all what I want here |
21:17 |
Warr1024 |
I've heard that when physicists want to do orbital calculation approximations, they separate celestial bodies into grids and instead of doing the N^2 computations for pull from each, use coarser grids for more distant things. |
21:17 |
est31 |
I have a done a "shitty" implementation as you said with a c++ vector |
21:18 |
Warr1024 |
I'm just not 100% sure how to make that adaptable. |
21:19 |
est31 |
what are RB trees |
21:21 |
Warr1024 |
red/black trees |
21:21 |
Warr1024 |
binary search trees, plus an algorithm to rebalance them periodically for better performance. |
21:24 |
|
H-H-H joined #minetest-dev |
21:35 |
est31 |
so I plan it to implement with octrees, and to mention small areas lower down, but multiple times. this way an 8 large area around the 0,0,0 position isnt checked always |
21:36 |
est31 |
and the areas get moved up and down depending on how filled the areastore is |
21:37 |
est31 |
if its time to move an area up or down, I look at how much space they fill, and take the one with the least space ofc |
21:37 |
est31 |
and for up I take the one with the most space |
22:42 |
|
RealBadAngel joined #minetest-dev |
22:42 |
RealBadAngel |
hi |
22:43 |
|
zat joined #minetest-dev |
22:52 |
VanessaE |
hey RBA |
23:17 |
RealBadAngel |
hmmmm, here? |
23:43 |
RealBadAngel |
est31, here? |
23:50 |
est31 |
RealBadAngel, whatdo you need |
23:51 |
RealBadAngel |
est31, any other comments or maybe a vote? |