| Time |
Nick |
Message |
| 00:47 |
|
mos_basik_ joined #minetest-dev |
| 00:55 |
|
Taoki joined #minetest-dev |
| 01:12 |
|
mlilenium_ joined #minetest-dev |
| 01:12 |
|
mlilenium_ left #minetest-dev |
| 01:25 |
|
Zeno` joined #minetest-dev |
| 02:02 |
OldCoder |
Sokomine, see patch above |
| 02:02 |
OldCoder |
Without it, lockups occur; but are there memory leaks now? |
| 02:04 |
|
Miner_48er joined #minetest-dev |
| 02:23 |
Sokomine |
OldCoder: can't help you with that. try to talk to sapier about it. he was the last one who worked on the connection code afaik |
| 02:25 |
Zeno` |
I unofficially worked on it yesterday :3 |
| 02:34 |
OldCoder |
Oh? |
| 02:35 |
OldCoder |
Sokomine, t y. Zeno` Oh? |
| 02:35 |
Zeno` |
Well, I had a quick look at #1733 and wrote a quick hack |
| 02:35 |
ShadowBot |
https://github.com/minetest/minetest/issues/1733 -- /home/minetest/Server/src/connection.cpp:2088: virtual void* con::ConnectionReceiveThread::Thread(): Assertion 0 failed. |
| 02:36 |
Zeno` |
But then didn't make a PR because I didn't have time to test it (made a gist) |
| 02:36 |
OldCoder |
Is this connected to my issue? |
| 02:37 |
Zeno` |
I'm not sure what your issue is. I scrolled up but it must have been mentioned before I joined |
| 02:40 |
Zeno` |
What is your issue? |
| 02:56 |
OldCoder |
It is serious |
| 02:56 |
OldCoder |
Because it is a known and unfixed issue that can't be fixed the usual way |
| 02:57 |
OldCoder |
Miner*48* has found 4 or more reports of this issue |
| 02:57 |
OldCoder |
What happens is that this message starts to appear: |
| 02:57 |
OldCoder |
[ConnectionSend]: con(5/1)RE-SENDING timed-out RELIABLE to |
| 02:57 |
OldCoder |
Millions and millions of times |
| 02:57 |
OldCoder |
I added the patch indicated above in this channel |
| 02:58 |
OldCoder |
Made the problem go away for a few hours |
| 02:58 |
OldCoder |
But it is back |
| 02:58 |
Zeno` |
Can you re-paste the patch? |
| 02:58 |
OldCoder |
Yes moment |
| 02:58 |
OldCoder |
<OldCoder> Will this patch to connection.cpp cause memory leaks? |
| 02:58 |
OldCoder |
<OldCoder> k->resend_count++; |
| 02:58 |
OldCoder |
<OldCoder> + if (k->resend_count > 5) break; |
| 02:59 |
OldCoder |
I will try disabling the resends entirely 100% |
| 02:59 |
OldCoder |
[ConnectionReceive]: con(5/1)WARNING: ACKed packet not in outgoing queue |
| 03:00 |
OldCoder |
This also appears |
| 03:00 |
OldCoder |
You will see other reports of this problem online |
| 03:00 |
OldCoder |
The distressing part is that there is no way to debug or patch it as there is with a crash |
| 03:00 |
OldCoder |
|
| 03:01 |
Zeno` |
I think if you do it that first way it's going to stay in the queue and never be removed |
| 03:02 |
Zeno` |
(until k->resend_count overflows anyway) |
| 03:02 |
OldCoder |
Yes, though memory does not seem to go up |
| 03:02 |
OldCoder |
Suggestions are highly welcome |
| 03:02 |
OldCoder |
Can I somehow flush the resend queue and never resend? |
| 03:03 |
OldCoder |
I'm dealing with IRL issues and at time limits on this. Spent too much time on the new world. |
| 03:06 |
Miner_48er |
as a stop gap any ideas to kill a server if it exceeds timeout? |
| 03:09 |
OldCoder |
It may show up |
| 03:09 |
OldCoder |
I didn't test that |
| 03:09 |
OldCoder |
It prints messages but is in a hard loop I think |
| 03:10 |
OldCoder |
The patch I posted is all that I could think of |
| 03:10 |
OldCoder |
As you noticed Miner_48er this seems to be an ongoing issue |
| 03:10 |
OldCoder |
With multiple reports; though it is not proven that all causes are the samer |
| 03:10 |
OldCoder |
* same |
| 03:14 |
Miner_48er |
OldCoder the servers.minetest.net list has a ping you could adapt that to respond to this problem |
| 03:16 |
OldCoder |
I have the ping code |
| 03:16 |
OldCoder |
I suspect the server will respond |
| 03:17 |
OldCoder |
Does anybody know how to discard a packet instead of rawSend it? |
| 03:52 |
|
sol_invictus joined #minetest-dev |
| 04:49 |
|
noticeme joined #minetest-dev |
| 04:49 |
noticeme |
hello |
| 04:50 |
VanessaE |
hello |
| 04:50 |
noticeme |
I was wondering what engine does minetest use |
| 04:50 |
noticeme |
Or did you make your own? |
| 04:50 |
VanessaE |
it uses irrlicht for the rendering engine |
| 04:51 |
VanessaE |
and the actual game logic is self-made in C++ and Lua |
| 04:51 |
VanessaE |
that is, the API that does all the hard work is C++, the game content, mods etc is Lua |
| 04:51 |
noticeme |
Oh really |
| 04:51 |
VanessaE |
yes |
| 04:51 |
noticeme |
I thought that LUA integrated with C |
| 04:51 |
noticeme |
Not C++ |
| 04:52 |
Zeno` |
It is, but you can use C perfectly fine from C++ |
| 04:52 |
VanessaE |
Lua* (not LUA). I suppose it can integrate with other languages besides C++ |
| 04:53 |
noticeme |
http://www.lua.org/pil/8.2.html |
| 04:53 |
noticeme |
I have done some work with Lua |
| 04:54 |
noticeme |
That's good to know, thanks for the info |
| 05:01 |
noticeme |
So out of curiosity |
| 05:02 |
noticeme |
what is the scope of a minetest mod |
| 05:16 |
RealBadAngel |
http://pastebin.com/nJKduDUy |
| 05:16 |
RealBadAngel |
^^ and all the nodeboxes are now meshes |
| 05:18 |
RealBadAngel |
whole updateTextures in nodedef.cpp needs 15s to process all the texures, shaders and nodeboxes in case of Dreambuilder game |
| 05:20 |
RealBadAngel |
thats on my 1.8GHz box |
| 05:22 |
RealBadAngel |
then in mapblock mesh i can see timings like 10-15 times faster to add single nodebox node to mesh collector |
| 05:25 |
RealBadAngel |
btw in case of Technic game its 6s |
| 05:25 |
|
Hunterz joined #minetest-dev |
| 05:37 |
|
diemartin joined #minetest-dev |
| 05:49 |
Zeno` |
RealBadAngel, nice! |
| 06:07 |
|
SmugLeaf joined #minetest-dev |
| 06:14 |
|
chchjesus left #minetest-dev |
| 06:15 |
|
chchjesus joined #minetest-dev |
| 06:52 |
|
rickmcfarley joined #minetest-dev |
| 07:01 |
|
kilbith joined #minetest-dev |
| 07:13 |
|
ImQ009 joined #minetest-dev |
| 07:27 |
|
Miner_48er joined #minetest-dev |
| 08:18 |
|
celeron55 joined #minetest-dev |
| 08:26 |
|
FR^2 joined #minetest-dev |
| 08:29 |
|
darkrose joined #minetest-dev |
| 08:40 |
|
celeron55 joined #minetest-dev |
| 08:41 |
|
Amaz joined #minetest-dev |
| 08:58 |
|
mos_basik_ joined #minetest-dev |
| 09:08 |
|
celeron55 joined #minetest-dev |
| 11:00 |
|
ImQ009 joined #minetest-dev |
| 11:10 |
|
chchjesus__ joined #minetest-dev |
| 11:34 |
|
proller joined #minetest-dev |
| 12:20 |
|
PenguinDad joined #minetest-dev |
| 12:29 |
|
GhostDoge joined #minetest-dev |
| 12:38 |
|
chchjesus joined #minetest-dev |
| 12:51 |
|
AnotherBrick joined #minetest-dev |
| 12:57 |
|
Dragonop joined #minetest-dev |
| 12:58 |
Dragonop |
Hi! |
| 13:01 |
|
Dragonop_ joined #minetest-dev |
| 13:17 |
|
rickmcfarley joined #minetest-dev |
| 13:47 |
|
chchjesus__ joined #minetest-dev |
| 13:52 |
|
Dragonop joined #minetest-dev |
| 14:22 |
|
zat joined #minetest-dev |
| 14:49 |
OldCoder |
Suggestions for the RE-SEND RELIABLE lockup will be much appreciated |
| 14:50 |
OldCoder |
It is a known issue and has been locking up a world for days. I posted one possible patch above. Zeno` has been kind enough to offer another. |
| 14:50 |
OldCoder |
This is possibly the most serious issue I've encountered with Minetest |
| 14:50 |
OldCoder |
One can work around crashes, but lockups that just hang are a significant problem |
| 14:51 |
OldCoder |
I am willing to work on the code if it is possible to be given clues |
| 14:51 |
OldCoder |
|
| 14:51 |
* OldCoder |
wants to take the "RELIABLE" packets and throw them away. Advice on how to discard them is requested. |
| 14:51 |
OldCoder |
|
| 15:13 |
|
proller joined #minetest-dev |
| 15:26 |
|
SudoAptGetPlay joined #minetest-dev |
| 15:43 |
|
NakedFury joined #minetest-dev |
| 15:46 |
|
proller joined #minetest-dev |
| 16:03 |
|
Megaf joined #minetest-dev |
| 16:09 |
|
EvergreenTree joined #minetest-dev |
| 16:10 |
|
Calinou joined #minetest-dev |
| 16:19 |
|
rubenwardy joined #minetest-dev |
| 16:37 |
|
zat joined #minetest-dev |
| 16:42 |
|
SudoAptGetPlay left #minetest-dev |
| 16:50 |
|
iqualfragile joined #minetest-dev |
| 17:05 |
|
rubenwardy joined #minetest-dev |
| 17:07 |
|
Krock joined #minetest-dev |
| 17:47 |
|
mos_basik joined #minetest-dev |
| 17:47 |
|
mos_basik joined #minetest-dev |
| 18:31 |
|
GrimKriegor joined #minetest-dev |
| 18:36 |
|
kaeza joined #minetest-dev |
| 18:47 |
|
kaeza joined #minetest-dev |
| 19:01 |
|
kaeza joined #minetest-dev |
| 19:03 |
rubenwardy |
<andre_pl> is there currrently any effort towards supporting 'charging' tools. the most obvious usage being bows, but basically anything that you hold the button to power up, then release to 'fire' |
| 19:03 |
|
alexxs joined #minetest-dev |
| 19:05 |
|
andre_pl joined #minetest-dev |
| 19:10 |
|
alexxs joined #minetest-dev |
| 19:28 |
|
FR^2 joined #minetest-dev |
| 19:51 |
|
Miner_48er joined #minetest-dev |
| 20:03 |
|
mos_basik_ joined #minetest-dev |
| 20:04 |
|
mos_basik_ joined #minetest-dev |
| 20:15 |
|
kilbith joined #minetest-dev |
| 20:43 |
|
kilbith joined #minetest-dev |
| 21:32 |
|
Mirmic joined #minetest-dev |
| 21:49 |
|
kaeza joined #minetest-dev |
| 21:58 |
|
kahrl joined #minetest-dev |
| 21:58 |
|
NakedFury joined #minetest-dev |
| 21:58 |
kahrl |
rubenwardy: not that I know of |
| 22:00 |
VanessaE |
kahrl: someone asked me about that same thing the other day, particularly about being able to modify the wielded mesh so that you could appear to "draw back" the bow before releasing it |
| 22:01 |
kahrl |
I suppose the way to do it would be the same way texture animations work |
| 22:02 |
kahrl |
have multiple frames in the wield image and pick one based on how long the tool has been charged |
| 22:02 |
kaeza |
or implement proper models as wielditems <_< |
| 22:03 |
kahrl |
that'd make it hard for texture pack makers that aren't well versed in blender (most aren't) |
| 22:08 |
kahrl |
in MC, charging a bow does 3 things: 1. the wield image changes over time, 2. the wield scale changes and the position of the wield mesh wiggles a bit, 3. the camera fov decreases over time |
| 22:09 |
kahrl |
I wonder how all that could be abstracted into a generic enough Lua API |
| 22:10 |
VanessaE |
kahrl: being able to specify a mesh as a wield item for a start |
| 22:10 |
VanessaE |
and being able to say something like set_wield_frame(n) |
| 22:10 |
VanessaE |
to select frame n of the animation |
| 22:10 |
kahrl |
that sounds extremely laggy |
| 22:10 |
VanessaE |
I know |
| 22:10 |
VanessaE |
but so is anything else in minetest that affects the client from the server, e.g. mobs |
| 22:11 |
VanessaE |
nothing says it can't be done on the client when client-side Lua is implemented. |
| 22:11 |
kahrl |
when(TM) :P |
| 22:11 |
VanessaE |
s/when/if by some miracle/ |
| 22:11 |
VanessaE |
:) |
| 22:20 |
|
Anchakor_ joined #minetest-dev |
| 22:33 |
|
Anchakor_ joined #minetest-dev |
| 22:36 |
|
kaeza joined #minetest-dev |
| 22:48 |
|
Sokomine joined #minetest-dev |
| 23:34 |
|
proller joined #minetest-dev |
| 23:40 |
|
mos_basik_ joined #minetest-dev |
| 23:42 |
|
proller joined #minetest-dev |
| 23:44 |
|
iqualfragile joined #minetest-dev |
| 23:56 |
|
dhasenan joined #minetest-dev |
