| Time |
Nick |
Message |
| 00:33 |
|
diemartin joined #minetest-dev |
| 01:25 |
|
diemartin joined #minetest-dev |
| 01:37 |
|
Wayward_Tab joined #minetest-dev |
| 03:08 |
|
kaeza joined #minetest-dev |
| 03:12 |
|
Fritigern joined #minetest-dev |
| 03:32 |
yh1986 |
hmmmmã€est31: the basic cause of all-red graphics with shaders(android) is that "vVertexColor" in file "COGLES2Solid.vsh", r is actually |
| 03:34 |
|
Hunterz joined #minetest-dev |
| 03:35 |
|
Fritigern joined #minetest-dev |
| 03:35 |
yh1986 |
'r' is actually day light, 'g' is actually night light, 'b' is actually light source. |
| 03:38 |
yh1986 |
the shaders for android is uncompleted compared to the shaders in pc, |
| 03:40 |
|
kaeza joined #minetest-dev |
| 03:49 |
|
FR^4 joined #minetest-dev |
| 03:56 |
|
FR^4 joined #minetest-dev |
| 04:06 |
|
FR^4 joined #minetest-dev |
| 04:14 |
|
Fritigern joined #minetest-dev |
| 04:29 |
|
Fritigern joined #minetest-dev |
| 04:32 |
|
Fritigern joined #minetest-dev |
| 04:38 |
|
Fritigern joined #minetest-dev |
| 04:58 |
|
OldCoder joined #minetest-dev |
| 05:39 |
|
Wayward_Tab joined #minetest-dev |
| 05:47 |
|
Hunterz joined #minetest-dev |
| 05:50 |
|
Wayward_Tab joined #minetest-dev |
| 06:21 |
|
Robert_Zenz joined #minetest-dev |
| 06:35 |
|
jin_xi joined #minetest-dev |
| 06:36 |
hmmmm |
https://github.com/kwolekr/minetest/commit/656575b59d4f0d67452cca7409c9064f690f038c |
| 06:40 |
|
kaeza joined #minetest-dev |
| 06:41 |
|
TheWild joined #minetest-dev |
| 06:44 |
|
selat joined #minetest-dev |
| 06:46 |
|
TheWild left #minetest-dev |
| 06:47 |
|
kilbith joined #minetest-dev |
| 06:56 |
hmmmm |
https://github.com/kwolekr/minetest/commit/b246812455737b2d0337dec905ba0256adefd105 |
| 07:06 |
|
nore joined #minetest-dev |
| 07:08 |
|
Calinou joined #minetest-dev |
| 07:08 |
Etzos |
Can someone take a look at https://github.com/minetest/minetest/pull/2679 ? The bug seems to prevent the game from running. |
| 07:09 |
|
kaeza joined #minetest-dev |
| 07:22 |
|
leat3 joined #minetest-dev |
| 07:32 |
|
leat3 joined #minetest-dev |
| 07:42 |
|
leat3 joined #minetest-dev |
| 07:47 |
kilbith |
hmmm, updated MT today and it refuses to run now : http://pastie.org/10175243 |
| 07:50 |
Etzos |
Already reported in issue #2678. I found and fixed the error in PR 2679. |
| 07:50 |
ShadowBot |
https://github.com/minetest/minetest/issues/2678 -- ugly server crash on, "hud_add" d720fd5 builtin/game/statbars.lua:49: in function initialize_builtin_statbars |
| 07:50 |
kilbith |
nore, you can check it please ? |
| 07:52 |
nore |
the code looks fine, but I haven't tested it yet |
| 07:58 |
nore |
Ok, confirmed the bug, and checked that the fix works |
| 07:58 |
nore |
I'll merge it, since it is very high priority |
| 07:59 |
nore |
and the fix is simple enough |
| 07:59 |
kilbith |
thanks nore |
| 08:00 |
|
Yepoleb_ joined #minetest-dev |
| 08:20 |
|
ShadowBot joined #minetest-dev |
| 08:51 |
|
OldCoder joined #minetest-dev |
| 09:24 |
|
chchjesus joined #minetest-dev |
| 09:25 |
|
Megaf joined #minetest-dev |
| 09:26 |
|
Calinou joined #minetest-dev |
| 09:26 |
|
rubenwardy joined #minetest-dev |
| 09:43 |
|
leat3 joined #minetest-dev |
| 09:49 |
|
OldCoder joined #minetest-dev |
| 09:56 |
|
leat3 joined #minetest-dev |
| 10:06 |
|
leat3 joined #minetest-dev |
| 10:17 |
|
leat3 joined #minetest-dev |
| 10:31 |
|
yh1986 joined #minetest-dev |
| 10:46 |
|
yh1986 joined #minetest-dev |
| 11:02 |
|
yh1986 joined #minetest-dev |
| 11:35 |
|
kilbith joined #minetest-dev |
| 12:12 |
|
yh1986 joined #minetest-dev |
| 12:17 |
|
Calinou joined #minetest-dev |
| 12:37 |
|
ElectronLibre joined #minetest-dev |
| 12:38 |
|
proller joined #minetest-dev |
| 12:39 |
|
err404 joined #minetest-dev |
| 13:38 |
|
err404 joined #minetest-dev |
| 13:51 |
|
AnotherBrick joined #minetest-dev |
| 13:54 |
|
proller joined #minetest-dev |
| 14:02 |
|
Taoki joined #minetest-dev |
| 14:44 |
|
hmmmm joined #minetest-dev |
| 15:05 |
|
est31 joined #minetest-dev |
| 15:10 |
|
FR^2 joined #minetest-dev |
| 15:26 |
est31 |
about https://github.com/minetest/minetest/commit/b246812455737b2d0337dec905ba0256adefd105 |
| 15:27 |
est31 |
hmmmm, perhaps add an option to completely omit identation? |
| 15:27 |
est31 |
right now having zero means to use single tabs |
| 15:28 |
est31 |
perhaps make zero mean have no identation, and -1 means to use single tabs |
| 15:28 |
hmmmm |
does it really matter |
| 15:28 |
est31 |
no |
| 15:29 |
* est31 |
should do those srp cleanups to do more higher prio work |
| 15:30 |
est31 |
what are your plans for client side modding running hmmmm? |
| 15:30 |
VanessaE |
ShadowNinja: that change needs to wait for 0.5 imho. we can't be breaking shit so readily. |
| 15:30 |
hmmmm |
i don't know but i have a lot of stuff to do |
| 15:32 |
est31 |
VanessaE, the security patch or the patch to make mods non-global ? |
| 15:32 |
VanessaE |
est31: the non-global opne |
| 15:32 |
VanessaE |
one* |
| 15:32 |
hmmmm |
are we really going to call it 0.5.0 |
| 15:32 |
VanessaE |
the security patch at least already has enough side-work ahead of it to stop it breaking mods more or less. |
| 15:33 |
VanessaE |
hmmmm: well whatever we call it, though 0.5 makes about as much sense as anything else (as long as it isn't 0.4.x) |
| 15:33 |
hmmmm |
it needs to be 1.0.0 if we want a chance at fixing our versioning scheme so minor version numbers actually mean minor version numbers |
| 15:34 |
VanessaE |
if a proposed patch is gonna break anything, imho it belongs in that "let's break it all" version. |
| 15:34 |
VanessaE |
1.0.0 sounds better but then we get into that discussion we had before about confusing users (1.0.0 == 1.0 in a user's mind) |
| 15:34 |
VanessaE |
(0.4.x = 4.x, etc) |
| 15:35 |
est31 |
its their problem if they can't read a 0 at the start |
| 15:35 |
VanessaE |
agreed, but if we can do something simple to prevent it in the future, why not? |
| 15:36 |
est31 |
yea therefore 1.0.0 is better than 0.5.0 |
| 15:36 |
est31 |
and with client side modding, we are ready for 1.0.0 |
| 15:36 |
VanessaE |
what happens when we reach 3.0.0? |
| 15:36 |
est31 |
then most users aren't 13 anymore and dont play minetest |
| 15:37 |
est31 |
those who played it since 0.4.* |
| 15:37 |
VanessaE |
and a whole NEW batch of 12-13 year olds comes in. |
| 15:37 |
VanessaE |
and they still see the old 0.3.x versions from time to time either by someone talking about them or some idiot repo maintainer who doesn't update, etc. |
| 15:37 |
VanessaE |
besides, it's not just kids |
| 15:38 |
VanessaE |
it's adults who do that too |
| 15:41 |
est31 |
perhaps make a poll, and let people decide |
| 15:42 |
|
Robert_Zenz joined #minetest-dev |
| 15:44 |
rom1504 |
and then name the 1.0.0 version "Hurr Durr I'm a sheep" |
| 15:45 |
kahrl |
that other voxel game even has a single version number, in some cases, referring to to three *different* versions, and I don't see much confusion about it |
| 15:45 |
kahrl |
and they certainly have their share of 13-year olds |
| 15:46 |
VanessaE |
kahrl: probably because they didn't start with a 0 :P |
| 15:46 |
est31 |
"Nyan, Nyan, I'm a Rainbow cat" |
| 15:46 |
kahrl |
they actually did |
| 15:46 |
VanessaE |
they did? |
| 15:46 |
kahrl |
but then went through the 1.* cycle three times so far :) |
| 15:47 |
VanessaE |
exactly |
| 15:47 |
kahrl |
yes, Classic |
| 15:47 |
VanessaE |
I guess the 0.x series wasn't widespread enough to matter, then |
| 15:48 |
VanessaE |
in any case it should just not have a chance to confuse users is all I'm saying |
| 15:48 |
rom1504 |
or you could go straight to 10.x to avoid any confusion and mischecking of program versions ;) ;) |
| 15:48 |
VanessaE |
rom1504: what is this, Microsoft? :P |
| 15:48 |
rom1504 |
windows yeah :D |
| 15:48 |
est31 |
release a new major version every 6 weeks |
| 15:49 |
est31 |
and start with 216 |
| 15:49 |
VanessaE |
ok now I gotta ask...why 216? :) |
| 15:49 |
est31 |
its the systemd version on ubuntu :p |
| 15:49 |
VanessaE |
oh heh |
| 15:49 |
VanessaE |
how about 4607 then? :) |
| 15:50 |
est31 |
oh sorry |
| 15:50 |
est31 |
they use already 219 |
| 15:51 |
est31 |
413 sounds nice too |
| 15:51 |
VanessaE |
heh |
| 15:51 |
celeron55 |
i don't think this 0./1. confusion thing is nearly as significant as you're making it sound like |
| 15:51 |
VanessaE |
celeron55: it's not INsignificant, though |
| 15:52 |
VanessaE |
with the number of times I've had to correct someone about the leading zero, ...well... you get the point |
| 15:52 |
celeron55 |
that doesn't mean they would be confused if the non-zero version actually did exist |
| 15:53 |
VanessaE |
you'd be surprised :) |
| 15:57 |
|
twoelk joined #minetest-dev |
| 16:01 |
|
rubenwardy joined #minetest-dev |
| 16:21 |
hmmmm |
:) |
| 16:22 |
hmmmm |
I managed to delete 60 lines of code last night |
| 16:22 |
hmmmm |
oftentimes, the most productive kind of changes are when you're able to remove code |
| 16:28 |
|
proller joined #minetest-dev |
| 16:35 |
ShadowNinja |
VanessaE: The namespace patch is completely non-breaking. |
| 16:37 |
ShadowNinja |
What mods should do is return their namespace in addition to seting the global and recomment that anyone using their API switches. After waiting a reasonable amount of time for people to update their API usage the global can be removed. |
| 16:37 |
|
leat3 joined #minetest-dev |
| 16:39 |
ShadowNinja |
(you could of course immediately switch completely and break compat, but that's the mod's fault) |
| 16:40 |
est31 |
for me its change for the sake of change, nothing more |
| 16:42 |
|
rubenwardy joined #minetest-dev |
| 16:44 |
VanessaE |
ShadowNinja: ok. |
| 16:51 |
|
leat3 joined #minetest-dev |
| 17:00 |
|
leat3 joined #minetest-dev |
| 17:05 |
hmmmm |
hey est31, are we waiting on anything for the SRP pull request?? |
| 17:07 |
|
Krock joined #minetest-dev |
| 17:07 |
est31 |
yes me cleaning up csrp-gmp |
| 17:07 |
est31 |
I'm on it right now hmmmm |
| 17:07 |
|
MinetestForFun joined #minetest-dev |
| 17:07 |
est31 |
but yes it got a bit stalled |
| 17:08 |
est31 |
so my plan is to merge the code, but first not enable it because the packets are not finalized |
| 17:08 |
hmmmm |
oh |
| 17:08 |
hmmmm |
in any case I was wondering what m_authstate was |
| 17:08 |
hmmmm |
you never explained the meaning behind that variable |
| 17:08 |
est31 |
m_authstate is more an enum |
| 17:08 |
hmmmm |
but it's an integer... |
| 17:09 |
est31 |
yes because we have to be generic from auth mech to auth mech |
| 17:09 |
est31 |
this is where a class based model would make some profits, I admit. |
| 17:10 |
hmmmm |
well I think I should clarify on my rant about over-structuring code |
| 17:10 |
hmmmm |
the overstructuring is very bad in things that are small and should be small |
| 17:10 |
|
leat3 joined #minetest-dev |
| 17:11 |
hmmmm |
but when you have a certain amount of internal mechanism state, and then several methods which have behaviors differing on the type of mechanism, it's kind of a good idea to have the whole base class/derived class thing there |
| 17:11 |
hmmmm |
it's natural here |
| 17:11 |
hmmmm |
whereas it wouldn't make sense to have drawtypes as a base class/derived class kind of setup |
| 17:12 |
hmmmm |
it has to do with the amount of overhead justifying the additional structure |
| 17:14 |
|
selat joined #minetest-dev |
| 17:14 |
est31 |
what would the class based model cover? |
| 17:15 |
hmmmm |
well first, the base class would be AuthMechanism or AuthMethod (the latter rolls off the tounge easier since it's only 3 syllables) |
| 17:15 |
|
TheWild joined #minetest-dev |
| 17:15 |
|
jin_xi joined #minetest-dev |
| 17:15 |
hmmmm |
this would basically abstract away each time you have if (authmechanism == AUTH_MECHANISM_THING) { ... |
| 17:16 |
hmmmm |
in any case you certainly don't need to do this, i'm just saying it would make sense here |
| 17:20 |
jin_xi |
heyho if you like removing code, someone please review/help with the particles stuff. |
| 17:20 |
jin_xi |
ie see if the approach taken is plausible at all or if a different approach is needed, like subclassing (particlesystem)scenenode |
| 17:21 |
jin_xi |
comments about style and capitalizations not needed at this point, and it needs to be said at all |
| 17:22 |
jin_xi |
...shoulda been ...and its kinda sad it needs to be said |
| 17:41 |
|
leat3 joined #minetest-dev |
| 17:45 |
rubenwardy |
Code style is important for maintainability. |
| 17:48 |
est31 |
man what I dont understand is how this stuff works |
| 17:48 |
est31 |
I mean valgrind sais everything was freed |
| 17:48 |
est31 |
but I cant find the call where it was freed |
| 17:48 |
est31 |
I mean its just not there |
| 17:49 |
est31 |
ahhh |
| 17:49 |
est31 |
dammit I found where |
| 17:50 |
est31 |
it was an array with a specified length inside a struct |
| 18:26 |
est31 |
hmmmm, what do you think, should I remove that unsigned char stuff too? |
| 18:26 |
est31 |
and make it char only? |
| 18:27 |
hmmmm |
if it's a "buffer" containing some kind of "data", it should be a void * |
| 18:27 |
est31 |
ok |
| 18:27 |
hmmmm |
if it's actually being interpreted as individual bytes, then that's an implementation-specific detail and the cast should be inside of the function |
| 18:27 |
hmmmm |
i.e. |
| 18:28 |
hmmmm |
void *memcpy(void *dst, const void *src, size_t len) { |
| 18:28 |
hmmmm |
const uint8_t *s = (const uint8_t *s)src; |
| 18:28 |
hmmmm |
then do all your operations on s |
| 18:29 |
hmmmm |
yes, that will be optimized away, so it's not like you're saving anything for using the parameter directly |
| 18:29 |
hmmmm |
to add to that, whenever there's a length parameter of some kind, use size_t. not int. please for the love of god, use size_t |
| 18:29 |
hmmmm |
this is what size_t was created for |
| 18:30 |
hmmmm |
it is part of the official C89 standard |
| 18:30 |
|
crazyR_ joined #minetest-dev |
| 18:30 |
|
crazyR_ joined #minetest-dev |
| 18:30 |
hmmmm |
I see scrappily coded interfaces that take char * and int for a buffer and frankly it's annoying for several reasons |
| 18:31 |
est31 |
whats best for writing data? |
| 18:31 |
hmmmm |
the biggest being that you have to add extra things like casts or unsigned-to-signed conversions that really aren't appropriate in the first place, just to stop compiler warnings/errors |
| 18:31 |
est31 |
void ** ? |
| 18:31 |
hmmmm |
what do you mean |
| 18:32 |
est31 |
I mean the method should return something |
| 18:32 |
est31 |
but in c you have only one thing to return |
| 18:32 |
est31 |
so you have to pass an argument |
| 18:32 |
est31 |
which type should that be? |
| 18:32 |
hmmmm |
prefer to not allocate memory for the caller unless what you're returning is variable length |
| 18:33 |
hmmmm |
i don't know man, this all comes down to nuance and it's quite subtle |
| 18:33 |
hmmmm |
it mostly comes down to experience in seeing which kinds of interfaces work and which don't in terms of amount of friction generated when using it |
| 18:33 |
est31 |
yea |
| 18:34 |
hmmmm |
but if you have to add casts everywhere just to use the damn API, there's a sure sign the interface sucks |
| 18:36 |
hmmmm |
that being said, generally when returning a new value, then no, void * is not a good choice |
| 18:37 |
hmmmm |
the idea behind void * as input parameters (and even output parameters when the buffer is user-provided) is flexibility |
| 18:38 |
hmmmm |
when you, the interface, allocates and returns some kind of thing, it's usually best to have this in a pre-defined format. the user is going to have to know this anyway to delete it if they're using C++ new[] and delete[] operators. |
| 18:38 |
est31 |
you cant delete[] something that has been malloced |
| 18:38 |
hmmmm |
of course |
| 18:39 |
hmmmm |
but the user shouldn't ever be calling delete[] or free() directly on your library's output |
| 18:39 |
hmmmm |
you have that srp_free() function or whatever, correct? only use that |
| 18:39 |
est31 |
yes |
| 18:40 |
|
Hijiri joined #minetest-dev |
| 18:40 |
|
Hunterz joined #minetest-dev |
| 18:53 |
est31 |
error: invalid conversion from ‘void*’ to ‘char*’ |
| 18:53 |
est31 |
Do I really have to cast after malloc? |
| 18:54 |
hmmmm |
i have no context whatsoever |
| 18:54 |
est31 |
I have a variable of type char* |
| 18:54 |
hmmmm |
why not just pastebin the code? http://fpaste.org/ |
| 18:54 |
est31 |
then I'm assigning that variable = malloc(uvlen); |
| 18:54 |
hmmmm |
oh yes |
| 18:54 |
hmmmm |
with C++, casting rules slightly changed |
| 18:55 |
hmmmm |
you cannot implicitly convert void * to any pointer type any longer, so casting the result of malloc() is necessary |
| 18:55 |
hmmmm |
however you can still implicitly convert any pointer type TO void... thankfully |
| 18:56 |
* est31 |
wonders why there are separate char and void types altogether |
| 18:56 |
hmmmm |
in traditional C, there was no void keyword |
| 18:56 |
hmmmm |
malloc returned char *, memcpy took char *, everything was char |
| 18:57 |
est31 |
that sounds very good |
| 18:57 |
hmmmm |
but that didn't work because on some platforms, the sizes of pointers to different types were different, which made this conversion impossible |
| 18:58 |
hmmmm |
and even if they were all the same size, you'd have to do all this nonsensical casting |
| 18:58 |
hmmmm |
so in ANSI C, void * was defined to be a pointer that can fit any data pointer type |
| 18:58 |
hmmmm |
this way you can have code like: |
| 18:59 |
hmmmm |
unsigned long hash[5]; SHA1_Finalize(&context, hash); ... just as well as unsigned char hash[20]; |
| 18:59 |
hmmmm |
you wouldn't need to cast the input parameter |
| 19:00 |
hmmmm |
likewise, it made constructs like: int *foobar = malloc(50 * sizeof(int)); /*allocate 50 ints*/ free(foobar); |
| 19:00 |
hmmmm |
possible |
| 19:01 |
est31 |
ok that sounds good |
| 19:01 |
hmmmm |
you don't care what the type of pointer is to. it's just a pointer to SOME kind of data |
| 19:01 |
hmmmm |
until you actually start to use this data |
| 19:02 |
hmmmm |
get it? |
| 19:02 |
est31 |
yes |
| 19:03 |
est31 |
so why did c++ make this stricter again? |
| 19:04 |
hmmmm |
because there are some CS types who blindly believe that less implicit type conversions necessarily make the language 'safer' |
| 19:05 |
hmmmm |
it only made it half-way stricter: void * -> type * conversions cannot be implicit, but type * -> void * still can |
| 19:06 |
hmmmm |
even if they made both conversion directions explicit-only, void * would still not only have value, but be necessary |
| 19:06 |
hmmmm |
because there's that problem where pointer sizes might differ |
| 19:06 |
hmmmm |
take for example the Cray 1 |
| 19:06 |
hmmmm |
ints were stored in a different part of memory than chars were |
| 19:07 |
hmmmm |
they made the int storage much larger because the designers figured they would be using more integer types in computation than characters for text, and they had different address spaces altogether |
| 19:07 |
hmmmm |
so sizeof(int *) > sizeof(char *), believe it or not! |
| 19:08 |
est31 |
lol |
| 19:08 |
hmmmm |
the traditional C compiler with no void * fails here, because malloc() returned a char * |
| 19:08 |
hmmmm |
and addresses would get truncated |
| 19:08 |
hmmmm |
so they had to write an int * version of malloc |
| 19:13 |
|
rubenwardy joined #minetest-dev |
| 19:15 |
est31 |
I'm keeping the lengths int, because the buffers wont exceed 1024 MB :p |
| 19:15 |
est31 |
and its even more porting hassle |
| 19:15 |
est31 |
because I've two versions of that file |
| 19:15 |
est31 |
and the diff is small, but not non-existent |
| 19:20 |
hmmmm |
what do you mean 1024mb |
| 19:20 |
est31 |
you know, at the position where the length overflows |
| 19:20 |
hmmmm |
the max value of an int you're guaranteed is 32787 |
| 19:21 |
est31 |
even that isnt exceeded |
| 19:21 |
|
johnnyjoy joined #minetest-dev |
| 19:21 |
hmmmm |
well okay, it's YOUR library... just saying that's horrible practice |
| 19:21 |
est31 |
yea ... |
| 19:22 |
est31 |
is there any advantage to store something in unsigned char* other than char* ? |
| 19:22 |
est31 |
its horrible |
| 19:22 |
est31 |
one is char*, the other data is unsigned char* |
| 19:22 |
est31 |
and having to write unsigned bloats the code up |
| 19:25 |
|
Wayward_Tab joined #minetest-dev |
| 19:40 |
|
SudoAptGetPlay joined #minetest-dev |
| 20:13 |
|
leat4 joined #minetest-dev |
| 20:23 |
|
leat4 joined #minetest-dev |
| 20:27 |
|
crazyR_ joined #minetest-dev |
| 20:33 |
|
proller joined #minetest-dev |
| 20:35 |
hmmmm |
if its bytes you want, you should look into u8 or uint8_t |
| 20:35 |
hmmmm |
i recommend u8 because csrp can define them if they haven't been defined elsewhere |
| 20:37 |
hmmmm |
yes, there's a difference here. you want to treat the chars as plain bytes of data, but if you do any kind of operation on that character that may implictly upcast the datatype to a higher capacity one, you'll get bugs because it'll sign extend if the value is over 127 |
| 20:39 |
hmmmm |
a hilarious and subtle bug is when somebody passes a char * as a buffer for "bytes of things". one of the fields in this blob of bytes happens to be a bitfield. they do a right bitshift as part of an operation to extract a value from a byte, and unwittingly performs an arithmetic shift instead due to signedness |
| 20:39 |
hmmmm |
i've seen this particular scenario happen more than a couple times |
| 20:41 |
est31 |
oh |
| 20:42 |
hmmmm |
another one is when somebody does a hex dump on said bytes: |
| 20:42 |
hmmmm |
for (int i = 0; i != len; i++) printf("%02x ", data[i]); printf("\n"); |
| 20:42 |
hmmmm |
"why does it print out ffffff84?? for some characters" |
| 20:42 |
est31 |
shouldnt that int be a size_t? |
| 20:42 |
hmmmm |
yes |
| 20:43 |
est31 |
otherwise it will be an endless loop |
| 20:43 |
hmmmm |
i'm taking on the persona of a newb though who uses char * and int to specify a buffer |
| 20:43 |
hmmmm |
no, how would that be an endless loop? |
| 20:43 |
est31 |
because i!=len always |
| 20:43 |
est31 |
when len > maximum int |
| 20:44 |
hmmmm |
you'd get a warning for that |
| 20:44 |
hmmmm |
but yeah |
| 20:45 |
hmmmm |
est31, you should read this sometime https://www.securecoding.cert.org/confluence/display/c/CERT+C+Coding+Standard |
| 20:46 |
hmmmm |
https://www.securecoding.cert.org/confluence/pages/viewpage.action?pageId=637 |
| 20:48 |
est31 |
btw why does it print that then? |
| 20:49 |
hmmmm |
because it's signed |
| 20:49 |
hmmmm |
that's a variadic parameter so it gets promoted to an int, and thus gets a sign extension |
| 20:49 |
est31 |
ah |
| 20:49 |
hmmmm |
to fix that you'd have to explicitly cast data[i] to (unsigned char), or, you know, make data an unsigned char pointer :) |
| 20:53 |
est31 |
dammit now I'm using size_t and its segfaulting |
| 20:55 |
est31 |
how weird |
| 20:56 |
est31 |
I mean, how did it work before? |
| 20:56 |
hmmmm |
it happens |
| 20:57 |
est31 |
but know the reason now |
| 20:57 |
est31 |
thats why I asked how it worked before |
| 20:58 |
est31 |
because... it can't |
| 21:04 |
crazyR_ |
is it possible to get the info that gets sent to the serverlist withosome sort of function or namespace |
| 21:05 |
est31 |
for the client or server crazyR_? |
| 21:05 |
crazyR_ |
or maybe get the online servers list from within lua(ingame) |
| 21:05 |
crazyR_ |
server |
| 21:05 |
est31 |
there is a method to give the server list within mainmenu lua |
| 21:06 |
crazyR_ |
can you remember which method is used im currently trawling thought the code, but think i may have missed it |
| 21:06 |
est31 |
its a httprequest |
| 21:07 |
est31 |
https://github.com/minetest/minetest/blob/9527984dbcfc0a6cc7aa0470430cb6c3aa4103ba/src/serverlist.cpp#L195 |
| 21:08 |
est31 |
crazyR_, ^ |
| 21:09 |
crazyR_ |
thanks |
| 21:12 |
crazyR_ |
think it may ust be eaiser to parse the data i need from here: http://servers.minetest.net/list |
| 21:12 |
crazyR_ |
cache it for 5 mins at a time |
| 21:12 |
est31 |
you can use luasocket like the irc mod does |
| 21:12 |
est31 |
and then make an http request |
| 21:13 |
crazyR_ |
i know. thats what i use vurrently for my api system. thanks |
| 21:13 |
est31 |
what you need it for? |
| 21:13 |
crazyR_ |
just for a ingame infomation dashboard. |
| 21:15 |
crazyR_ |
hmm actually. why am i over thinking it again |
| 21:15 |
crazyR_ |
most of the inof is available via settings. others throught parsing players online etc etc. lag via the server status |
| 21:24 |
est31 |
so I think this is it |
| 21:25 |
est31 |
srp patch ready to merge, if it builds |
| 21:25 |
* est31 |
doing last test whether it works, then deactivates protocol v25 |
| 21:26 |
est31 |
it doesnt :( |
| 21:32 |
est31 |
ouch |
| 21:32 |
est31 |
current network code really has some problem |
| 21:32 |
est31 |
right now, I can send carefully crafted packets to the server to make it restart |
| 21:33 |
est31 |
This isn't the cause of my error, but an interesting side note |
| 21:36 |
est31 |
what we have to do is either catch exceptions or add some other mechanism |
| 21:36 |
est31 |
that basically does the same as the exceptions do |
| 21:36 |
|
Hijiri joined #minetest-dev |
| 21:36 |
est31 |
with explicit checks and so on |
| 21:36 |
|
ElectronLibre left #minetest-dev |
| 21:37 |
est31 |
when I have time I do a PR with the exceptions |
| 21:37 |
est31 |
later on we can do the explicit checks too |
| 21:47 |
est31 |
ok works again |
| 21:48 |
VanessaE |
has there been any movement yet on allowing backface culling to be specified as a node property? |
| 21:50 |
hmmmm |
nope |
| 21:50 |
VanessaE |
ok. |
| 21:51 |
hmmmm |
right now there's nobody working on graphics anything |
| 21:52 |
est31 |
whatever happened with RBA :( |
| 21:53 |
hmmmm |
absolutely no idea |
| 21:53 |
VanessaE |
he got too busy to mess with MT anymore. |
| 21:53 |
VanessaE |
at his day job, that is. |
| 21:53 |
hmmmm |
i want to work on the shaders |
| 21:53 |
hmmmm |
i want to work on the mapgens, i want to work on lighting |
| 21:53 |
hmmmm |
i want to work on everything but alas I can only do one thing at a time |
| 21:53 |
hmmmm |
agh |
| 23:00 |
|
Lunatrius` joined #minetest-dev |
| 23:22 |
|
chchjesus joined #minetest-dev |
| 23:31 |
|
Wayward_Tab joined #minetest-dev |
| 23:34 |
|
Hijiri joined #minetest-dev |
| 23:51 |
est31 |
hmmmm, I think #2620 can be merged now |
| 23:51 |
ShadowBot |
https://github.com/minetest/minetest/issues/2620 -- SRP based login by est31 |
| 23:55 |
|
paramat joined #minetest-dev |
| 23:55 |
est31 |
paramat, why that new PR? |
| 23:56 |
paramat |
will push trivial update soon #2680 |
| 23:56 |
ShadowBot |
https://github.com/minetest/minetest/issues/2680 -- Conf.example: Update recommended maximum cloud radius to 26 by paramat |
| 23:56 |
paramat |
further testing shows 26 is the maximum without clipping |
| 23:57 |
est31 |
ok then merge it |
| 23:57 |
est31 |
+1 |
| 23:57 |
paramat |
:) |
