| Time |
Nick |
Message |
| 00:03 |
est31 |
why exactly is "do {} while(0)" there? |
| 00:06 |
est31 |
ShadowNinja ^ |
| 00:07 |
ShadowNinja |
est31: It ensures that you add a semicolon after it. |
| 00:12 |
est31 |
ah ok |
| 00:36 |
hmmmm |
do {} while (0) is weird |
| 00:36 |
hmmmm |
if anything you should be using |
| 00:36 |
hmmmm |
#define THING(x) do { \ |
| 00:36 |
hmmmm |
macro body here \ |
| 00:37 |
hmmmm |
} while (0) |
| 00:38 |
hmmmm |
also, i believe it is a specious argument that we need the extra custom type check. |
| 00:38 |
hmmmm |
when that type becomes a field of another custom type, then we need to add yet another check |
| 00:39 |
hmmmm |
and each time we lost sight of what the actual incorrect field inside of the custom parameter is |
| 00:39 |
hmmmm |
i.e. foobar = {thing = "blah", size = {x=45, y=nil}} |
| 01:17 |
|
Hijiri joined #minetest-dev |
| 01:24 |
|
yh1986 joined #minetest-dev |
| 01:32 |
yh1986 |
rtt failed on android, i resolved |
| 01:32 |
est31 |
how did you make shaders work on android? |
| 01:35 |
yh1986 |
line 1016 "driver->setRenderTarget(0, false, true, 0);" should before line 1010 "driver->endScene();" in file "tile.cpp" |
| 01:36 |
yh1986 |
otherwise can't render to texture on android |
| 01:37 |
yh1986 |
+est31, copy assets to sdcard and change usr_path, enable es2 and shaders |
| 01:38 |
est31 |
what do you mean with "change usr_path"? |
| 01:40 |
yh1986 |
point your source path |
| 01:41 |
est31 |
yh1986, do you know git? Could you make a pull request? |
| 01:47 |
yh1986 |
currently, i work on android with oges2 and shaders, though it can work, but many things to resolve, such as skybox render etc |
| 01:47 |
est31 |
yh1986, it would be great if you could help to resolve those issues, I guess your english is bad? |
| 01:50 |
yh1986 |
yes |
| 01:51 |
est31 |
first, you should install git, read this book: http://git-scm.com/book/zh/v1 |
| 01:51 |
est31 |
then get newest minetest from https://github.com/minetest/minetest |
| 01:52 |
est31 |
From the line numbers you told me I can tell that your minetest version isn't newest |
| 01:52 |
yh1986 |
i know git, |
| 01:53 |
yh1986 |
yes, i git clone many days ago |
| 01:55 |
est31 |
It would be best if you had newest git master. Either clone again or git pull. Then make a commit with the android fix, and publish it on github |
| 02:03 |
ShadowNinja |
hmmmm: What do you mean? You want "field x/y/z" to be specified in the pos messages? |
| 02:04 |
|
kaeza joined #minetest-dev |
| 02:08 |
ShadowNinja |
D-: https://github.com/minetest/minetest/commit/4ea5a96fffb1a0300f73e97d4c85bb5c32e3786d |
| 02:09 |
ShadowNinja |
_C implies a c-string, _LOWER is shorter than _CAPITALIZED, and the other way you're less likely to use _LOWER accidentally! |
| 02:11 |
hmmmm |
we had a vote on it. |
| 02:11 |
ShadowNinja |
Also, you could rebase instead of reverting conflicts. |
| 02:12 |
ShadowNinja |
hmmmm: And it was a near-tie. |
| 02:12 |
hmmmm |
6-4??? |
| 02:12 |
ShadowNinja |
hmmmm: What's the advantage of doing it this way? |
| 02:12 |
hmmmm |
"_C implies a C-string" - maybe to you, I've never seen _C on a macro mean anything |
| 02:13 |
hmmmm |
because it doesn't make sense to optimize for a less common case |
| 02:13 |
hmmmm |
in the majority of cases you want to use the lower case string version |
| 02:13 |
kahrl |
how about _CAPS |
| 02:13 |
hmmmm |
how about we stop talking about it already :p |
| 02:14 |
hmmmm |
if you want to bother, sure |
| 02:14 |
hmmmm |
this is so silly |
| 02:14 |
ShadowNinja |
Currently perhaps, but part of that is legacy issues where the lowercase version was used when it should be uppercase. |
| 02:14 |
ShadowNinja |
kahrl: That sounds better. |
| 02:15 |
kahrl |
although it might imply all-caps |
| 02:15 |
kahrl |
dunno |
| 02:16 |
|
zat joined #minetest-dev |
| 02:23 |
hmmmm |
speaking of PROJECT_NAME |
| 02:23 |
kaeza |
how about _TITLE? (Titlecase) |
| 02:23 |
hmmmm |
misc/winresource.rc should probably be updated or something |
| 02:24 |
hmmmm |
PROJECT_NAME ".exe" |
| 02:24 |
hmmmm |
and lol @ legal trademarks |
| 02:24 |
hmmmm |
VALUE "LegalTrademarks", """Minetest"" is the property of the Minetest community, don't use it without permission!" |
| 02:24 |
hmmmm |
Don't you dare use minetest, or else! |
| 02:25 |
kaeza |
a dungeon master will eat you while you sleep! |
| 02:25 |
* kaeza |
goes back to something more important (no offense intended) |
| 02:25 |
hmmmm |
no offense taken :p |
| 03:01 |
|
book` joined #minetest-dev |
| 03:23 |
|
book` joined #minetest-dev |
| 03:29 |
|
leat3 joined #minetest-dev |
| 03:51 |
|
FR^4 joined #minetest-dev |
| 03:54 |
|
FR^4 joined #minetest-dev |
| 04:01 |
|
yh1986 joined #minetest-dev |
| 04:03 |
|
yh1986 joined #minetest-dev |
| 04:03 |
|
yh1986 joined #minetest-dev |
| 04:04 |
|
FR^4 joined #minetest-dev |
| 04:14 |
|
FR^4 joined #minetest-dev |
| 04:20 |
|
crazyR_ joined #minetest-dev |
| 05:05 |
|
Hunterz joined #minetest-dev |
| 05:26 |
|
Wayward_Tab joined #minetest-dev |
| 05:28 |
|
jin_xi joined #minetest-dev |
| 05:29 |
|
leat3 joined #minetest-dev |
| 06:00 |
|
Zeno` joined #minetest-dev |
| 06:12 |
|
cib0 joined #minetest-dev |
| 06:20 |
|
Wayward_Tab joined #minetest-dev |
| 06:23 |
sfan5 |
hmmmm: do you want Minetest.exe or what? |
| 06:24 |
|
nore joined #minetest-dev |
| 06:30 |
hmmmm |
the resource file has selective editing |
| 06:30 |
hmmmm |
some fields use PROJECT_NAME, a few others do not |
| 06:30 |
|
kaeza joined #minetest-dev |
| 06:31 |
sfan5 |
VALUE "LegalTrademarks", ""PROJECT_NAME_C" is the property of the "PROJECT_NAME_C" community, don't use it without permission!" |
| 06:31 |
sfan5 |
is probably not what we want |
| 06:50 |
|
kilbith joined #minetest-dev |
| 07:19 |
|
Darcidride joined #minetest-dev |
| 07:36 |
|
Calinou joined #minetest-dev |
| 07:48 |
|
err404 joined #minetest-dev |
| 08:00 |
|
Yepoleb_ joined #minetest-dev |
| 08:00 |
|
FR^2 joined #minetest-dev |
| 08:01 |
|
Calinou joined #minetest-dev |
| 08:25 |
|
cib0 joined #minetest-dev |
| 09:21 |
|
ElectronLibre joined #minetest-dev |
| 09:24 |
|
Megaf_ joined #minetest-dev |
| 09:49 |
|
kaeza joined #minetest-dev |
| 09:50 |
|
book` joined #minetest-dev |
| 09:55 |
|
OldCoder joined #minetest-dev |
| 10:11 |
|
book` joined #minetest-dev |
| 10:16 |
|
cib0 joined #minetest-dev |
| 10:29 |
|
proller joined #minetest-dev |
| 10:36 |
|
OldCoder joined #minetest-dev |
| 10:37 |
|
selat joined #minetest-dev |
| 10:47 |
|
OldCoder joined #minetest-dev |
| 10:51 |
|
Anchakor joined #minetest-dev |
| 10:51 |
|
kilbith joined #minetest-dev |
| 10:53 |
|
OldCoder joined #minetest-dev |
| 11:18 |
|
book` joined #minetest-dev |
| 11:23 |
|
Darcidride joined #minetest-dev |
| 11:31 |
|
ElectronLibre joined #minetest-dev |
| 11:35 |
|
OldCoder joined #minetest-dev |
| 11:38 |
|
err404 joined #minetest-dev |
| 11:47 |
|
OldCoder joined #minetest-dev |
| 11:55 |
|
book` joined #minetest-dev |
| 12:13 |
|
ElectronLibre joined #minetest-dev |
| 12:18 |
|
proller joined #minetest-dev |
| 12:41 |
|
Hunterz joined #minetest-dev |
| 12:44 |
|
err404 joined #minetest-dev |
| 12:44 |
|
book` joined #minetest-dev |
| 13:16 |
|
kaeza_ joined #minetest-dev |
| 13:28 |
|
selat joined #minetest-dev |
| 13:29 |
|
ElectronLibre joined #minetest-dev |
| 13:34 |
|
err404 joined #minetest-dev |
| 13:52 |
|
ElectronLibre joined #minetest-dev |
| 14:05 |
|
book` joined #minetest-dev |
| 14:07 |
|
proller joined #minetest-dev |
| 14:14 |
|
ElectronLibre joined #minetest-dev |
| 14:29 |
|
hmmmm joined #minetest-dev |
| 15:03 |
|
Zeno` joined #minetest-dev |
| 15:07 |
|
est31 joined #minetest-dev |
| 15:17 |
Zeno` |
ShadowNinja, you missed one: https://github.com/minetest/minetest/blob/master/src/porting_android.cpp#L46 |
| 15:18 |
Zeno` |
personally I'd change that to char argv[] = PROJECT_NAME; and the next line to main(1, (char **)&argv); |
| 15:19 |
Zeno` |
(I think the cast is necessary, but not 100% sure) |
| 15:19 |
Zeno` |
in C I don't think it would be, but C++ I think it is |
| 15:40 |
hmmmm |
I still can't understand the for (int i = 0; ...) ... for (int i = 0; ...) warning |
| 15:40 |
hmmmm |
these files are being compiled as *c++* |
| 15:41 |
hmmmm |
it was always correct under ISO C++ to contain variable scoping to the conditional's block |
| 15:42 |
hmmmm |
FWIW, I've never seen that warning before, and I am nearly certain that same exact code construct exists in other places too, not only test_random.cpp |
| 15:42 |
est31 |
perhaps its because it has been declared inside the initial clause of the for loop? |
| 15:43 |
hmmmm |
well, yes, that's the because, but the fact remains that MSVC (and apparently some oddball version of gcc??) complain about ISO C++ conformant behavior based on C89 scoping rules |
| 15:44 |
hmmmm |
i feel that it would be more correct to disable those warnings than to modify my ISO C++ conformant code |
| 15:44 |
Zeno` |
I don't understand it either |
| 15:45 |
Zeno` |
Because as hmmmm said, the scoping rules have always been that way |
| 15:46 |
Zeno` |
But, gcc does emit that warning. What the "old rules" it refers to are... I have nfi |
| 15:46 |
hmmmm |
https://github.com/kwolekr/minetest/commit/8e9efe7aaa36bb353b05370d20d696a47bfb6930 |
| 15:46 |
hmmmm |
Zeno`: old C rules |
| 15:46 |
hmmmm |
the theory goes that if it's being compiled as C++ there'd be no problem ... |
| 15:47 |
hmmmm |
is some kind of pre-standardization C++ mode enabled on gcc? |
| 15:49 |
|
cib0 joined #minetest-dev |
| 15:50 |
Zeno` |
old C rules? |
| 15:50 |
Zeno` |
C wouldn't have even compiled |
| 15:50 |
hmmmm |
right |
| 15:50 |
hmmmm |
hmm |
| 15:50 |
hmmmm |
-traditional-cpp |
| 15:51 |
Zeno` |
hmm |
| 15:51 |
Zeno` |
maybe c99 would have I'm not sure |
| 15:51 |
Zeno` |
maybe it's an old gcc bug |
| 15:51 |
est31 |
/join #gcc |
| 15:52 |
Zeno` |
OR a SoC volunteer decided to add the warning |
| 15:52 |
Zeno` |
heh |
| 15:52 |
Zeno` |
either way it's no big deal really... just a bit baffling |
| 15:55 |
hmmmm |
-traditional-cpp doesn't seem to affect it |
| 15:55 |
hmmmm |
meh |
| 15:58 |
hmmmm |
https://github.com/kwolekr/minetest/commit/8e9efe7aaa36bb353b05370d20d696a47bfb6930 |
| 15:59 |
|
kilbith joined #minetest-dev |
| 16:29 |
hmmmm |
anybody? |
| 16:36 |
est31 |
hmmmm, why make unknown now hardcoded? |
| 16:36 |
hmmmm |
it's only unknown if there is no ndef associated to that noderesolver |
| 16:37 |
hmmmm |
there can be multiple INodeDefManagers each with their own name for unknown node, so I figure this is good enough |
| 16:37 |
hmmmm |
we're going to have to hard code it somewhere, there's not really any good way around this |
| 16:38 |
est31 |
yes, but as I see it its now hardcoded at one place more? |
| 16:39 |
hmmmm |
what i'm saying is that due to the semantics involved, this is a detail that cannot be softcoded |
| 16:43 |
est31 |
yes but its a better practice to have hardcoding at only one place than hardcoding at multiple places |
| 16:43 |
|
Robert_Zenz joined #minetest-dev |
| 16:43 |
est31 |
because changing is then easier and less error prone |
| 16:43 |
hmmmm |
alright maybe you're not understanding the way i'm explaining this |
| 16:44 |
hmmmm |
the "unknown" string inside NodeResolver::getNodeName() is entirely independent of any nodedef managers |
| 16:44 |
est31 |
yes |
| 16:44 |
hmmmm |
if a nodedef manager is associated with this noderesolver, then the nodedef manager's own internal name for 'unknown' would take precedence |
| 16:45 |
est31 |
why? |
| 16:45 |
hmmmm |
so you have CNodeDefManager's CONTENT_UNKNOWN name that's "unknown", and then maybe in the future we have CoolNodeDefManager |
| 16:45 |
hmmmm |
and in CoolNodeDefManager, they want to be really cool, so CONTENT_UNKNOWN's name is "I dunno what this is lol" |
| 16:45 |
est31 |
yes |
| 16:46 |
hmmmm |
depending on which nodedef manager had been associated with this noderesolver object, it could and should differ |
| 16:46 |
est31 |
but what you did was hardcode it to "unknown" |
| 16:46 |
hmmmm |
it just so happens, by cosmic coincidence, that the default name given to an unknown node if there is no nodedef manager happens to be the same as the unknown node name in the only currently existing nodedef manager |
| 16:47 |
est31 |
ah now I get it |
| 16:47 |
est31 |
ok then |
| 16:47 |
hmmmm |
so if you change CNodeDefManager's content unknown node name, then by all means, it should NOT change the NodeResolver's internal version |
| 16:47 |
est31 |
yes |
| 16:47 |
hmmmm |
because that's just an internal detail of CNodeDefManager that we cannot be concerned about |
| 16:48 |
hmmmm |
it's completely internal to CNodeDefManager, private to NodeResolver |
| 16:48 |
est31 |
but isn't that dependent on what m_ndef currently is? |
| 16:48 |
hmmmm |
m_ndef gets set when calling INodeDefManager::pendNodeResolve() |
| 16:49 |
hmmmm |
so if you want it set to some alternative INodeDefManager, call it using a different nodedef manager object |
| 16:49 |
est31 |
yes |
| 16:49 |
hmmmm |
got it???? |
| 16:50 |
est31 |
just how is the call m_ndef->get(CONTENT_UNKNOWN).name; dependent on CNodeDefManager ? |
| 16:50 |
est31 |
I see that hardcoding "unknown" is at least as good, I just can't see how its strictly better |
| 16:51 |
hmmmm |
oh, you're saying I should use "m_ndef->get(CONTENT_UNKNOWN).name" over "return unknown_str" |
| 16:51 |
hmmmm |
I would agree, but recall that m_ndef can be NULL at any time that's called |
| 16:51 |
hmmmm |
if it's NULL, it's strictly better because this won't crash |
| 16:52 |
est31 |
yes lol |
| 16:53 |
est31 |
see my comment , otherwise it looks good |
| 16:54 |
hmmmm |
yeah I didn't bother updating the license years |
| 16:54 |
hmmmm |
we'll do it all at once sometime |
| 17:00 |
|
TheWild joined #minetest-dev |
| 17:02 |
hmmmm |
PSA to everybody: PLEASE STOP CHANGING YOUR POINTER ASTERISK STYLE MID-FUNCTION |
| 17:02 |
hmmmm |
it is so fucking infuirating to see: Foobar* foo = (Foobar *)new Foobar(); |
| 17:03 |
hmmmm |
I'm not even asking you to follow the official code style, I'm asking you to follow your own code style without changing it every 5 seconds |
| 17:16 |
Zeno` |
PSA? |
| 17:16 |
hmmmm |
public service announcement |
| 17:16 |
Zeno` |
never heard that one. I shall write it donw |
| 17:16 |
Zeno` |
down* |
| 17:19 |
|
MinetestForFun joined #minetest-dev |
| 17:20 |
|
MinetestForFun joined #minetest-dev |
| 17:21 |
Zeno` |
lol |
| 17:21 |
Zeno` |
I just realised that minetest takes longer to start up than my OS O.o |
| 17:22 |
|
cib0 joined #minetest-dev |
| 17:26 |
Megaf_ |
est31: Hi there |
| 17:36 |
|
err404 joined #minetest-dev |
| 17:46 |
|
Krock joined #minetest-dev |
| 18:31 |
hmmmm |
https://github.com/kwolekr/minetest/commit/f6ca3e9b479f4d913360a86bbdcdd793e64e93e6 |
| 18:34 |
|
Fritigern joined #minetest-dev |
| 18:45 |
|
kaeza joined #minetest-dev |
| 19:10 |
|
est31 joined #minetest-dev |
| 19:18 |
|
crazyR_ joined #minetest-dev |
| 19:18 |
|
crazyR_ joined #minetest-dev |
| 19:53 |
|
ElectronLibre joined #minetest-dev |
| 19:58 |
|
Hijiri joined #minetest-dev |
| 20:10 |
hmmmm |
nobody? |
| 20:10 |
hmmmm |
:/ |
| 20:13 |
hmmmm |
hmmm, the addition of NodeResolver to NodeDefManager inadvertantly broke the abstraction that INodeDefManager is read-only, and to write, you need an IWritableNodeDefManager |
| 20:13 |
hmmmm |
in practice this doesn't cause any problems whatsoever |
| 20:14 |
hmmmm |
but when writing unit tests it becomes apparent when you need to recycle state but the fundamental way NodeResolver works is by maintaining state elsewhere |
| 20:14 |
|
paramat joined #minetest-dev |
| 20:14 |
paramat |
useful feature hmmmmm |
| 20:14 |
hmmmm |
the technically correct thing to do here is to expose NodeResolver related methods like pendNodeResolve to IWritableNodeDefManager only |
| 20:15 |
hmmmm |
but it's not practical because you have an IWritableNodeDefManager almost nowhere |
| 20:15 |
hmmmm |
thanks paramat |
| 20:16 |
hmmmm |
so I'm wondering, what is the best way to design the NodeResolver pieces inside of INodeDefManager such that the state can be easily reset |
| 20:17 |
hmmmm |
ndef->resetNodeResolverState() would be obvious, but has the potential to be error prone if the implementation is somehow wrong |
| 20:19 |
hmmmm |
paramat: is that a "looks good to me" approval? :) |
| 20:20 |
|
leat3 joined #minetest-dev |
| 20:20 |
paramat |
i'm not much qualified to judge the implementation but the feature seems useful |
| 20:22 |
|
Wayward_Tab joined #minetest-dev |
| 20:30 |
|
leat3 joined #minetest-dev |
| 20:34 |
paramat |
hmmmm is there something about serializing a lua table schematic to .mts that changes an "ignore" node? i use "ignore" in force-placed schematics to select the nodes i don't want force-placed, but now testing a serialized schematic those selected nodes are now being force-placed as air |
| 20:35 |
hmmmm |
come to think of it, yes, it does do that |
| 20:35 |
paramat |
perhaps i should be using air with prob = 0 instead |
| 20:35 |
hmmmm |
well it should be placing air with prob = 0 |
| 20:35 |
hmmmm |
having ignore as a special 'don't place anything here' node was deprecated in the second version iirc |
| 20:36 |
hmmmm |
if you have ignore nodes in your schematic definitions, that means you're still using .mts v1 files |
| 20:36 |
paramat |
aha |
| 20:36 |
paramat |
so now "air" with prob = 0 is the thing to use? |
| 20:36 |
hmmmm |
correct |
| 20:36 |
paramat |
cool thanks |
| 20:37 |
|
ElectronLibre left #minetest-dev |
| 20:38 |
paramat |
on this subject, what's your method for maing sure tree trunks are force-placed but leaves are not, to stop chopped trunks when trees overlap? i might be able to code this myself |
| 20:39 |
hmmmm |
i don't have one |
| 20:39 |
paramat |
(making) |
| 20:39 |
hmmmm |
that's next on my list of things to implement |
| 20:40 |
paramat |
my idea was to use certain values of param1 (like 255) to enable per-node force placement, but apparently this is not good practice |
| 20:41 |
|
Amaz joined #minetest-dev |
| 20:41 |
hmmmm |
that's not doable because couldn't people want a node with a random chance of appearing to be force placed? |
| 20:42 |
paramat |
maybe |
| 20:42 |
paramat |
yeah |
| 20:42 |
hmmmm |
unless that assumption is, in fact, wrong |
| 20:43 |
paramat |
perhaps 0-127 prob not force placed, 128-255 prob force placed |
| 20:43 |
hmmmm |
yep |
| 20:43 |
paramat |
since we don't need many levels of probability, extra information can be encoded within param1 |
| 20:43 |
hmmmm |
so the top bit will be the force placement flag |
| 20:44 |
hmmmm |
and probability will be truncated to 7 bit instead |
| 20:46 |
paramat |
perhaps keep the current force placement flag also as a way to easily override for a whole schematic |
| 20:47 |
hmmmm |
that's how it would have to be implemented, yeah. |
| 20:48 |
|
pozzoni joined #minetest-dev |
| 20:55 |
hmmmm |
https://github.com/kwolekr/minetest/commit/633af58a05fb9b3ad7a0a178011f4243e5f8be2e |
| 20:55 |
hmmmm |
review requested^ |
| 20:55 |
hmmmm |
PTAL |
| 21:01 |
|
Hijiri joined #minetest-dev |
| 21:03 |
|
proller joined #minetest-dev |
| 21:07 |
|
MinetestForFun joined #minetest-dev |
| 21:16 |
|
AnotherBrick joined #minetest-dev |
| 21:19 |
|
crazyR_ joined #minetest-dev |
| 21:19 |
|
crazyR_ joined #minetest-dev |
| 21:20 |
|
Robert_Zenz joined #minetest-dev |
| 21:55 |
|
Hijiri joined #minetest-dev |
| 22:25 |
|
Wayward_Tab joined #minetest-dev |
| 22:35 |
|
paramat left #minetest-dev |
| 23:19 |
|
misprint joined #minetest-dev |
| 23:21 |
|
Hijiri joined #minetest-dev |
| 23:26 |
|
Wayward_Tab joined #minetest-dev |
| 23:51 |
|
misprint joined #minetest-dev |
