| Time |
Nick |
Message |
| 00:48 |
|
EvergreenTree joined #minetest-dev |
| 00:58 |
E4xoi |
hmmmm: i fail to see your argument against making the code use more OOP features! you know, those features are there for using it! |
| 00:59 |
hmmmm |
??? |
| 01:12 |
|
iqualfragile joined #minetest-dev |
| 01:36 |
|
Weedy joined #minetest-dev |
| 01:49 |
|
us`0gb joined #minetest-dev |
| 02:21 |
|
BrandonReese joined #minetest-dev |
| 03:37 |
|
kaeza joined #minetest-dev |
| 04:28 |
RealBadAngel |
hi |
| 04:29 |
RealBadAngel |
hmmmm, here? |
| 04:29 |
hmmmm |
??? |
| 04:30 |
RealBadAngel |
have you tested shaders commit? |
| 04:31 |
hmmmm |
no |
| 04:31 |
hmmmm |
i haven't run minetest in over 2 weeks |
| 04:31 |
|
ImQ009 joined #minetest-dev |
| 04:31 |
RealBadAngel |
why so? |
| 04:32 |
hmmmm |
just haven't been doing anything minetest related for a while |
| 04:32 |
RealBadAngel |
so you have now opportunity to do something, go test the shaders ;) |
| 04:33 |
RealBadAngel |
i really would like to get them merged at least |
| 04:33 |
hmmmm |
oh |
| 04:33 |
hmmmm |
i'll check them out in time |
| 04:34 |
hmmmm |
what do other people say about it? |
| 04:34 |
RealBadAngel |
im pretty advanced with another stage and im blocked with previous commit |
| 04:35 |
RealBadAngel |
it works flawlessly for whoever tried them |
| 04:35 |
RealBadAngel |
i got no error feedback at all since a week or two |
| 04:36 |
hmmmm |
sounds pretty cool |
| 04:36 |
RealBadAngel |
sapier, vanessae, nore have tested it |
| 04:38 |
RealBadAngel |
this one was mainly glsl commit, now im in core again, rebuilding shader.cpp and dynamic mesh (and shaders) loading |
| 04:38 |
RealBadAngel |
and i cant mix those two |
| 04:40 |
RealBadAngel |
next commit will move shaders generation from runtime to startup only, unite shaders for terrain, allow other shaders for sky, water and postprocess |
| 04:41 |
RealBadAngel |
with what i have already done in shader and mapblock_mesh, my box runs with shaders significantly faster |
| 04:49 |
RealBadAngel |
but, back to #1117, title doesnt say it all. this commit is loaded with more stuff |
| 04:49 |
ShadowBot |
https://github.com/minetest/minetest/issues/1117 -- Normal maps generation on the fly. by RealBadAngel |
| 04:51 |
RealBadAngel |
it also have bugfix that fixes issue with shaders turning all black on some gpus (nore and sokomine were unable to run shaders at all before) |
| 04:51 |
RealBadAngel |
parallax mapping with slope information implemented |
| 04:52 |
RealBadAngel |
overriding normal maps, see https://forum.minetest.net/viewtopic.php?id=8714 |
| 04:53 |
RealBadAngel |
and some speedup fixes in general |
| 04:53 |
RealBadAngel |
also it has basics for sun/lighsources calculations |
| 04:54 |
RealBadAngel |
so, imho its already worth a few separate commits |
| 04:56 |
RealBadAngel |
and to tease you more, you wont get this before it got merged ;) https://www.youtube.com/watch?v=sc3R16QASBY |
| 04:58 |
RealBadAngel |
this will become possible when im done with current work |
| 06:29 |
|
proller joined #minetest-dev |
| 06:39 |
|
smoke_fumus joined #minetest-dev |
| 06:58 |
|
ImQ009 joined #minetest-dev |
| 08:18 |
|
celeron55 joined #minetest-dev |
| 08:58 |
|
darkrose joined #minetest-dev |
| 09:33 |
|
tomreyn joined #minetest-dev |
| 09:43 |
|
ImQ009 joined #minetest-dev |
| 09:44 |
|
Hiradur joined #minetest-dev |
| 09:50 |
|
rsiska joined #minetest-dev |
| 10:29 |
|
n joined #minetest-dev |
| 10:29 |
|
proller joined #minetest-dev |
| 10:35 |
|
ImQ009 joined #minetest-dev |
| 11:07 |
|
grrk-bzzt joined #minetest-dev |
| 11:30 |
|
proller joined #minetest-dev |
| 11:33 |
|
restcoser joined #minetest-dev |
| 11:40 |
|
Megaf joined #minetest-dev |
| 12:44 |
|
PenguinDad joined #minetest-dev |
| 12:48 |
|
CheapSeth joined #minetest-dev |
| 12:49 |
CheapSeth |
Hi |
| 12:58 |
celeron55 |
can someone change the thing 1 described here on minetest.net? if not this will serve as a todo item for me after work: https://forum.minetest.net/viewtopic.php?id=8566 |
| 13:07 |
|
Hiradur joined #minetest-dev |
| 13:08 |
|
hmmmm joined #minetest-dev |
| 13:11 |
|
Hiradur joined #minetest-dev |
| 13:12 |
sfan5 |
celeron55: done |
| 13:18 |
|
SmugLeaf joined #minetest-dev |
| 13:18 |
|
SmugLeaf joined #minetest-dev |
| 13:18 |
|
ImQ009 joined #minetest-dev |
| 13:21 |
|
Zeitgeist_ joined #minetest-dev |
| 13:39 |
|
EvergreenTree joined #minetest-dev |
| 13:48 |
|
kaeza joined #minetest-dev |
| 13:52 |
|
Zeitgeist_ joined #minetest-dev |
| 13:52 |
|
Zeitgeist_ joined #minetest-dev |
| 14:02 |
|
spillz joined #minetest-dev |
| 14:04 |
spillz |
@celeron: have you looked at Ubuntu's PPA recipes? just set up an auto import from github to launchpad (that includes the debian stuff) and then you get auto amd64 and i 386 build for all supported Ubuntu versions. you can set up one for stable and one for nightly |
| 14:05 |
|
Hiradur joined #minetest-dev |
| 14:05 |
celeron55 |
spillz: looked at what? |
| 14:05 |
celeron55 |
i'm not interested at all in maintaining that ubuntu stuff |
| 14:05 |
celeron55 |
i'm every day hoping some ubuntu person will take it and maintain it |
| 14:05 |
celeron55 |
and rename it to minetest |
| 14:06 |
celeron55 |
everyone in here hates it 8) |
| 14:07 |
spillz |
Maybe i will set something up then. where are the debian files? |
| 14:07 |
celeron55 |
they're in some obscure bazaar repository in launchpad |
| 14:07 |
celeron55 |
are they publicly visible? i'd guess they are |
| 14:07 |
celeron55 |
i can give you membership to the PPA if you want to do stuff |
| 14:09 |
spillz |
Mostly all I am going to do is setup a recipe then hopefully Noone has to worry about it (so long as they keep the debian stuff up to date) |
| 14:09 |
celeron55 |
but there already is a stable and daily recipe |
| 14:09 |
celeron55 |
how does it differ from that |
| 14:10 |
celeron55 |
some random guy set it up years ago and then left |
| 14:11 |
celeron55 |
we've been able to keep it working altough probably not up to any kind of actual ubuntu or debian standards |
| 14:11 |
celeron55 |
this one, i mean https://launchpad.net/~minetestdevs/+archive/stable |
| 14:24 |
|
PilzAdam joined #minetest-dev |
| 14:30 |
|
spillz joined #minetest-dev |
| 14:31 |
spillz |
Sorry - didn't realize that was already based on a recipe because some Ubuntu's aren't being updated, specifically 13.04 and 14.04 (i have machines running both of these) |
| 14:33 |
spillz |
You already have a debian maintainer right? (i have no interest in being involved in that anal retentive process) |
| 14:34 |
spillz |
Probably a good idea to rename minetestc55 to minetest. That way the new one cleanly replaces the one in the official ubuntu repos. |
| 14:37 |
celeron55 |
it's not trivial to rename it because there are reference to the name inside of itself |
| 14:37 |
celeron55 |
and also the autoimports are set up by the launchpad staff and something might break, no idea |
| 14:38 |
celeron55 |
someone should spam the ubuntu and debian maintainers with emails as long as is needed for them to take that to themselves |
| 14:38 |
celeron55 |
and fix it |
| 14:38 |
celeron55 |
references* |
| 14:39 |
spillz |
But it's only the recipe that's weirdly named right? the package in the official ubuntu repo is called minetest |
| 14:40 |
spillz |
*recipe, meant ppa |
| 14:40 |
celeron55 |
you seem so interested about it that how about you request membership and i allow you to take care of it 8) |
| 14:40 |
celeron55 |
i probably hate it more than you |
| 14:40 |
|
CheapSeth joined #minetest-dev |
| 14:42 |
celeron55 |
in any case, i have no contacts to any distro maintainer whatsoever; any and all of those are working independently (and it seems like independently of each other too) |
| 14:42 |
spillz |
If I can... let me think about it.at least I can see all of the recipe stuff now. |
| 14:43 |
celeron55 |
if you log in there, you get a button that allows you to spam me with an email asking me to click a link, and then you get to change anything you want there |
| 14:43 |
spillz |
The whole maintainer thing is just weird. so often just who has nothing to do with the project, just apparently good at compiling shit. |
| 14:44 |
spillz |
Just *someone who |
| 14:44 |
celeron55 |
yeah it's just random; they also randomly stop updating and then users come to us asking why isn't it updated |
| 14:47 |
celeron55 |
unrelated: |
| 14:47 |
celeron55 |
i think the forceloading api and implementation is bad and should be at least declared unstable |
| 14:48 |
celeron55 |
i started replying to this thread and started looking at what the situation currently is and i can't recommend the api to anyone; it's just too crappy: https://forum.minetest.net/viewtopic.php?pid=133824#p133824 |
| 14:49 |
celeron55 |
so now i'm probably going to recommend using a voxel manipulator until it's made somehow sane |
| 14:49 |
spillz |
Why is it that more of the world is not in client memory (network overhead?) |
| 14:50 |
CiaranG |
The thing he's talking about here.... https://forum.minetest.net/viewtopic.php?pid=133679#p133679 |
| 14:50 |
CiaranG |
is caused by the unloaded blocks bug I fixed recently |
| 14:51 |
spillz |
*client, mean server |
| 14:52 |
celeron55 |
CiaranG: it is fully caused by it? |
| 14:53 |
CiaranG |
Yes |
| 14:54 |
CiaranG |
I've seen that lots of times, with my own carts mod |
| 14:54 |
CiaranG |
That's why I fixed it |
| 14:54 |
celeron55 |
my reply: https://forum.minetest.net/viewtopic.php?pid=133883#p133883 |
| 14:55 |
CiaranG |
I'm not sure force loading or voxelmanip would help anyway - the server things the block is active, so it won't try to load it again. It's a race condition. |
| 14:56 |
CiaranG |
s/things/thinks/ |
| 14:59 |
celeron55 |
hmm |
| 14:59 |
celeron55 |
the voxelmanip will help because it doesn't care about that active block stuff |
| 14:59 |
celeron55 |
the forceloading cares and thus might not work, yes |
| 15:08 |
|
E4xoi joined #minetest-dev |
| 15:11 |
|
spillz joined #minetest-dev |
| 15:13 |
sfan5 |
celeron55: why don't we have something like this? https://gist.github.com/sfan5/9586533#file-minetest-patch |
| 15:40 |
celeron55 |
it's not good like that |
| 15:41 |
celeron55 |
that's an asynchronous call without any kind of callback or indication of when the result is loaded |
| 15:41 |
celeron55 |
oh well, i guess polling get_node kind of works |
| 15:41 |
celeron55 |
get_node_or_nil* |
| 15:55 |
|
Jordach joined #minetest-dev |
| 16:15 |
|
iqualfragile joined #minetest-dev |
| 16:21 |
|
spillz joined #minetest-dev |
| 16:26 |
|
darkrose joined #minetest-dev |
| 16:27 |
|
NakedFury joined #minetest-dev |
| 16:31 |
|
salamanderrake joined #minetest-dev |
| 16:35 |
|
Hiradur joined #minetest-dev |
| 16:40 |
|
Garmine joined #minetest-dev |
| 16:49 |
us`0gb |
proller: I was told you were the one to ask about the Minetest protocol. It's based on UDP, right? And does it have a name? MTP, perhaps? |
| 16:49 |
|
Calinou joined #minetest-dev |
| 16:49 |
proller |
why me? |
| 16:50 |
proller |
udp |
| 16:50 |
proller |
wtfp ;) |
| 16:50 |
us`0gb |
I don't know why you. I was pointed in your direction. |
| 16:51 |
us`0gb |
WTFP? Is that our final answer? I'm going to try to implement SERV records. |
| 16:55 |
|
e1z0 joined #minetest-dev |
| 16:57 |
|
e1z0 joined #minetest-dev |
| 16:59 |
spillz |
Meant to ask this yesterday... What do you guys think of this? https://forum.minetest.net/viewtopic.php?id=8730 |
| 16:59 |
spillz |
Is the intention to merge in a c++ mapper to replace the python? |
| 16:59 |
sfan5 |
yes |
| 16:59 |
sfan5 |
I think it would make more sense if you would help me with my cpp mapper :-) |
| 17:00 |
sfan5 |
https://github.com/sfan5/minetest-mapper-cpp |
| 17:00 |
|
OldCoder joined #minetest-dev |
| 17:00 |
spillz |
c++ hurts my head more. maybe... |
| 17:01 |
sfan5 |
c++ isn't that hard |
| 17:01 |
CiaranG |
spillz: Love the cross-sections :) |
| 17:02 |
spillz |
Not hard, just more of a context switch. I help a bit with Code::Blocks IDE which is mostly C++ but mostly just added stuff for working with python |
| 17:03 |
spillz |
@Clarian: thx. The code to do that is kind of clunky. would want something more elegant for the cpp version |
| 17:05 |
proller |
us`0gb, for name ask celeron55 |
| 17:06 |
us`0gb |
celeron55: What is the Minetest protocol called? MTP? WTFP? |
| 17:08 |
spillz |
For cpp mapper I think it would be good to reuse engine code for the db interface. (sfan, i think you said that would necessitate some extra includes, but one way to handle would be to have a minetest dll/so for common components for client/server/mapper) |
| 17:09 |
proller |
maybe include mapper to MT? |
| 17:09 |
proller |
server can save images on block save |
| 17:11 |
proller |
and future - serve this images and player positions from embended http server |
| 17:11 |
proller |
^ realtime map ready |
| 17:12 |
spillz |
But the server usually only loads bits of map on demand from client and as far as i can tell doesn't keep that much in memory. I think the mapper has different requirements. |
| 17:13 |
proller |
server can serve images of unloaded areas from disk |
| 17:14 |
|
darkrose joined #minetest-dev |
| 17:14 |
|
darkrose joined #minetest-dev |
| 17:17 |
|
Hiradur joined #minetest-dev |
| 17:19 |
|
sapier joined #minetest-dev |
| 17:20 |
sfan5 |
spillz: the db interface my cpp mapper has is similar to the engines interface |
| 17:24 |
spillz |
sure, but better for maintainability if same. |
| 17:28 |
spillz |
Have you had issue where lookup of db coordinates by x, y, z using the decodeBlockPos and its inverse return the wrong thing? I was having some issue with python equivalents and found it safer to cache the raw id. |
| 17:29 |
sfan5 |
no |
| 17:30 |
spillz |
It came up more with cross sections. maybe unrelated bug in my changes... |
| 17:38 |
celeron55 |
us`0gb: if you want to have a short name for the minetest protocol, call it mtgp (minetest game protocol) because mtp is "media transfer protocol" |
| 17:39 |
sfan5 |
in contrast to mtp mtgp actually works well |
| 17:50 |
celeron55 |
us`0gb: also, who told you that you should ask anything about the protocol from proller? that doesn't make any sense |
| 17:50 |
|
spillz joined #minetest-dev |
| 17:51 |
us`0gb |
celeron55: I forget who told me. It was via PM and I don't know how to pull up the chat record unless I already know who I was chatting with. |
| 17:52 |
us`0gb |
Thanks for the info! I'll work on implementing SERV records soon. I hope. |
| 17:53 |
us`0gb |
Actually ... I might be able to find the record in my file tree. |
| 17:54 |
us`0gb |
celeron55: Sokomine told me to ask proller. |
| 17:54 |
sapier |
what do you want to use the protocol fore us'0gb? |
| 17:55 |
us`0gb |
sapier: I want to implement DNS SERV records, so example.net (Minetest) doesn't have to run at the same IP address as example.net (Apache). |
| 17:56 |
us`0gb |
To do that by the books, I need the protocol name. |
| 17:56 |
sapier |
oh I see :-) |
| 17:59 |
us`0gb |
It will fall back to using A records as it does now if the SERV records are not present. Anyone not needing this feature will not need to make any changes to their setup. |
| 18:02 |
|
Amaz joined #minetest-dev |
| 18:26 |
|
spillz joined #minetest-dev |
| 18:54 |
|
nore joined #minetest-dev |
| 19:24 |
|
sapier joined #minetest-dev |
| 19:29 |
sapier |
https://github.com/sapier/minetest/tree/android_3 http://animalsmod.comuf.com/downloads/Minetest-debug.apk now users should be able to respawn on android clients too |
| 19:29 |
|
sapier left #minetest-dev |
| 19:56 |
|
werwerwer_ joined #minetest-dev |
| 19:58 |
ShadowNinja |
hmmmm: Because we don't have fixed-width format specifiers and long long is C99-only. It's also much easier to read. |
| 20:07 |
|
NakedFury joined #minetest-dev |
| 20:10 |
ShadowNinja |
RealBadAngel: I tried your shaders patch. It works pretty well. |
| 20:26 |
|
proller joined #minetest-dev |
| 20:26 |
|
s joined #minetest-dev |
| 20:33 |
|
EvergreenTree joined #minetest-dev |
| 20:33 |
|
EvergreenTree_ joined #minetest-dev |
| 20:33 |
|
EvergreenTree__ joined #minetest-dev |
| 20:54 |
|
rsiska joined #minetest-dev |
| 21:15 |
|
spillz joined #minetest-dev |
| 21:27 |
hmmmm |
SHadowNinja, yeah I realized that when I saw the commit you reverted earlier on. that's totally fine. |
| 21:29 |
hmmmm |
I just wanted to make sure it wasn't a commit that only changes style instead of functionality. those kinds of commits are no good. whenever somebody makes a commit like that, it's akin to pissing on top of somebody else's dirt mound, and exclaiming "MY STYLE > URS" |
| 21:43 |
|
iqualfragile_ joined #minetest-dev |
| 21:53 |
RealBadAngel |
ShadowNinja, hmmmm so can we get that patch merged ? |
| 21:53 |
hmmmm |
sure |
| 22:01 |
|
ShadowNinja joined #minetest-dev |
| 22:22 |
RealBadAngel |
ShadowNinja, ok with you too? |
| 22:24 |
ShadowNinja |
RealBadAngel: Yep. |
| 22:24 |
RealBadAngel |
ok, will check if its still safe to merge and will push it tonight |
| 22:29 |
ShadowNinja |
RealBadAngel: It applied over my copy, which is very recent. |
| 22:30 |
RealBadAngel |
checkin once more wont hurt ;) |
| 22:31 |
RealBadAngel |
btw, some1 should code colors for labels, same as for text_area |
| 22:31 |
ShadowNinja |
Better yet: Just rewrite the formspec. |
| 22:31 |
RealBadAngel |
oh cmon, not again ;) |
| 22:32 |
ShadowNinja |
Here's what I came up with in terms of design: http://pastebin.ubuntu.com/7127731/ |
| 22:35 |
RealBadAngel |
basically a table instead of strings, yes? |
| 22:41 |
ShadowNinja |
I'll merge #1180 in a minute if there are no objections. |
| 22:41 |
ShadowNinja |
RealBadAngel: Yes. |
| 22:41 |
ShadowBot |
ShadowNinja: Error: ProcessTimeoutError: Process #564 (for String.re) aborted due to timeout. |
| 22:41 |
ShadowNinja |
Grrr. |
| 22:44 |
|
iqualfragile joined #minetest-dev |
| 22:45 |
ShadowNinja |
https://github.com/minetest/minetest/pull/1180 -- Add a midpoint function to the vector helpers |
| 22:46 |
celeron55 |
ShadowNinja: why midpoint? |
| 22:46 |
celeron55 |
why not eg. interpolate? |
| 22:46 |
celeron55 |
thus allowing the caller to say what factor to use instead your fixed 0.5 |
| 22:47 |
celeron55 |
i strongly oppose midpoint; it's not any kind of common practice for vector implementations |
| 22:48 |
celeron55 |
but i'm fine with interpolate |
| 22:51 |
Jordach |
celeron55, or use midpoint to modify the interpol |
| 22:51 |
|
EvergreenTree joined #minetest-dev |
| 22:53 |
ShadowNinja |
celeron55: Good idea. CiaranG: ^ |
| 23:04 |
CiaranG |
Well it's definitely a common practice, otherwise I wouldn't be calling it in 20 different places already |
| 23:04 |
CiaranG |
But yeah, interpolate would be more flexible. I'll change it to that. |
| 23:08 |
CiaranG |
If we're being picky, that whole thing should not be called vector, it should be called vec3d, because it doesn't handle any other kind of vector ;) |
| 23:08 |
CiaranG |
How does ShadowBot manage to interpret 1180 as 564 anyway? |
| 23:09 |
celeron55 |
it's a process id |
| 23:09 |
CiaranG |
Oh, lol |
| 23:10 |
CiaranG |
Didn't actually read the message |
| 23:10 |
ShadowNinja |
Fox for #1158: http://ix.io/bbU |
| 23:10 |
ShadowBot |
https://github.com/minetest/minetest/issues/1158 -- Some warning during compilation |
| 23:11 |
ShadowNinja |
Fix* |
| 23:12 |
CiaranG |
So you can do things with this interpolate that are not really interpolating (e.g. by giving it -0.5, or 1.5) - happy with that? |
| 23:16 |
ShadowNinja |
That seems fine. |
| 23:20 |
celeron55 |
of course; then it's just extrapolating 8) |
| 23:23 |
kahrl |
vector.interpolate_or_extrapolate_depending_on_the_value_of_lambda |
| 23:24 |
celeron55 |
_also_works_as_midpoint_if_value_is_half |
| 23:24 |
ShadowNinja |
CiaranG: getlastcollisionresult <-- This is too squashed. It should be something like get_last_collision_result. |
| 23:26 |
celeron55 |
what |
| 23:26 |
celeron55 |
https://github.com/CiaranG/minetest/commit/8a70b8f737d6aad44179416e4c2c5e6683df3c01 |
| 23:26 |
celeron55 |
why change the returned value to be a parameter? |
| 23:27 |
celeron55 |
that makes zero sense |
| 23:27 |
ShadowNinja |
celeron55: It returns a stack variable by reference. |
| 23:28 |
kahrl |
ShadowNinja: where do you see the reference? |
| 23:28 |
ShadowNinja |
+local |
| 23:28 |
celeron55 |
and? |
| 23:28 |
celeron55 |
of course it does |
| 23:28 |
ShadowNinja |
Hmmm, copies it then. |
| 23:29 |
celeron55 |
result should always be returned if possible, it makes better and more understandable code |
| 23:30 |
celeron55 |
the C antipattern of never returning anything else than stuff that you would use exceptions for in C++ doesn't belong here |
| 23:31 |
CiaranG |
So if you return it as a value, it has to make a copy of the whole thing |
| 23:31 |
CiaranG |
Including the vector within it |
| 23:32 |
celeron55 |
the whole thing, which is like 10 bytes? |
| 23:34 |
celeron55 |
also even if you would do it that way, why in hell are you removing the constructor |
| 23:34 |
CiaranG |
And then (because the caller is saving it elsewhere) it would have to make a third copy of it |
| 23:34 |
CiaranG |
That's just silly. If it's 10 bytes (it's more) or 1000 bytes, why not just put it where it's going in the first place |
| 23:36 |
celeron55 |
if you can make code that is more reliable and less prone to errors, you should |
| 23:37 |
celeron55 |
and more readable |
| 23:37 |
celeron55 |
in any case i'm still waiting for an explanation of removing the constructor of a C++ struct that contains uninitialized values |
| 23:38 |
celeron55 |
that previously had a constructor |
| 23:39 |
celeron55 |
and have you noticed that the thing your commit message refers to is a minor part of the contents of the commit, the larger part not being mentioned at all |
| 23:42 |
CiaranG |
What is the larger part? |
| 23:43 |
celeron55 |
the larger part is reworking the collisionMoveSimple interface |
| 23:43 |
CiaranG |
Seriously? |
| 23:45 |
|
us`0gb joined #minetest-dev |
| 23:45 |
CiaranG |
Slightly changing the semantics of how the value is returned is the major part of the commit, and the feature it adds is the minor part. |
| 23:45 |
CiaranG |
ok |
| 23:46 |
celeron55 |
it is, because it's not a strict dependency and consists of a lot of changed lines |
| 23:46 |
celeron55 |
in any case, i'm still waiting for an explanation of removing the constructor |
| 23:47 |
CiaranG |
It would have to be duplicated, in order to allow the in-place collisionResult member to be reset |
| 23:47 |
celeron55 |
and you are sure that removing it won't cause bugs that will annoy people in the future? i wouldn't |
| 23:49 |
celeron55 |
you don't need to duplicate anything if you just call reset() in the constructor |
| 23:49 |
CiaranG |
I guess so, yeah |
| 23:50 |
celeron55 |
also, it would be best to move the &result to be within the other output references at the end; generally inputs are first, outputs last |
| 23:50 |
CiaranG |
They are, but the last parameters are optional |
| 23:51 |
celeron55 |
hmm, well whatever then |
| 23:51 |
CiaranG |
Inserting it at some random point in the middle didn't seem sensible |
| 23:55 |
CiaranG |
So the only thing I would change is the constructor/reset thing, which you are absolutely right about |
| 23:56 |
CiaranG |
(and the squashed nature of 'getlastcollisionresult' - which was supposed to be consistent with the other get... functions on the luaentity api, which are also squashed) |
| 23:56 |
celeron55 |
there are like 2 other squashed names like that |
| 23:56 |
celeron55 |
everything else is not |
| 23:56 |
celeron55 |
grep get_ doc/lua_api.txt |
| 23:57 |
CiaranG |
all of them except two (on the luaentity) |
| 23:57 |
celeron55 |
it should be the long version anyway |
| 23:58 |
CiaranG |
yeah |
| 23:59 |
celeron55 |
then there is one thing: it should be commented somewhere that that interface shouldn't be used for checking collision events but only static collision state |
| 23:59 |
celeron55 |
for collision events there should be an entity member function called by the engine |
