| Time |
Nick |
Message |
| 00:02 |
|
jin_xi_ joined #minetest-dev |
| 00:02 |
|
sfan5 joined #minetest-dev |
| 00:02 |
|
celeron55 joined #minetest-dev |
| 00:06 |
|
crazyR_ joined #minetest-dev |
| 00:06 |
|
waressearcher2 joined #minetest-dev |
| 00:06 |
|
sofar joined #minetest-dev |
| 00:06 |
|
VanessaE joined #minetest-dev |
| 00:06 |
|
book` joined #minetest-dev |
| 00:06 |
|
kahrl joined #minetest-dev |
| 00:07 |
|
Kray joined #minetest-dev |
| 00:07 |
|
Ritchie joined #minetest-dev |
| 00:07 |
|
Robby joined #minetest-dev |
| 00:08 |
|
Fritigern joined #minetest-dev |
| 00:08 |
|
Puma_rc joined #minetest-dev |
| 00:08 |
|
Icedream joined #minetest-dev |
| 00:09 |
|
Warr1024 joined #minetest-dev |
| 00:12 |
|
Garth joined #minetest-dev |
| 00:12 |
|
proller joined #minetest-dev |
| 00:12 |
|
DFeniks joined #minetest-dev |
| 00:12 |
|
ekem joined #minetest-dev |
| 00:12 |
|
Eivel joined #minetest-dev |
| 00:12 |
|
neti_netwalker joined #minetest-dev |
| 00:13 |
|
Miner_48er joined #minetest-dev |
| 00:13 |
|
zat joined #minetest-dev |
| 00:13 |
|
Brains joined #minetest-dev |
| 00:13 |
|
Anchakor joined #minetest-dev |
| 00:13 |
|
janakas joined #minetest-dev |
| 00:13 |
|
enesbil joined #minetest-dev |
| 00:13 |
|
Ardonel joined #minetest-dev |
| 00:13 |
|
hmmmm joined #minetest-dev |
| 00:13 |
|
Soni joined #minetest-dev |
| 00:13 |
|
gentoobro joined #minetest-dev |
| 00:13 |
|
younishd joined #minetest-dev |
| 00:13 |
|
Guest61682 joined #minetest-dev |
| 00:13 |
|
nanepiwo joined #minetest-dev |
| 00:13 |
|
Hijiri joined #minetest-dev |
| 00:13 |
|
eeew joined #minetest-dev |
| 00:13 |
|
johnnyjoy joined #minetest-dev |
| 00:13 |
|
pozzoni joined #minetest-dev |
| 00:14 |
|
Megaf_ joined #minetest-dev |
| 00:14 |
|
VargaD joined #minetest-dev |
| 00:14 |
|
JohannesG joined #minetest-dev |
| 00:14 |
|
thatgraemeguy joined #minetest-dev |
| 00:14 |
|
leat joined #minetest-dev |
| 00:14 |
|
misprint joined #minetest-dev |
| 00:14 |
|
exio4 joined #minetest-dev |
| 00:14 |
|
_tutima joined #minetest-dev |
| 00:14 |
|
Danek joined #minetest-dev |
| 00:17 |
|
dzho joined #minetest-dev |
| 00:17 |
|
rom1504 joined #minetest-dev |
| 00:17 |
|
Lunatrius joined #minetest-dev |
| 00:17 |
|
AnotherBrick joined #minetest-dev |
| 00:17 |
|
Wayward_One joined #minetest-dev |
| 00:18 |
|
cheapie joined #minetest-dev |
| 00:18 |
|
exoplanet joined #minetest-dev |
| 00:18 |
|
ShadowBot joined #minetest-dev |
| 00:18 |
|
Taoki joined #minetest-dev |
| 00:18 |
|
VirusJones joined #minetest-dev |
| 00:18 |
|
ShadowNinja joined #minetest-dev |
| 00:25 |
|
GreenDimond joined #minetest-dev |
| 00:25 |
|
GreenDimond joined #minetest-dev |
| 00:31 |
|
OldCoder joined #minetest-dev |
| 03:51 |
|
ShadowBot joined #minetest-dev |
| 03:51 |
|
ShadowBot joined #minetest-dev |
| 04:20 |
|
Player2 joined #minetest-dev |
| 05:30 |
|
Player2 joined #minetest-dev |
| 05:39 |
|
Hunterz joined #minetest-dev |
| 06:51 |
|
kaeza joined #minetest-dev |
| 06:58 |
|
diemartin joined #minetest-dev |
| 07:03 |
|
Darcidride joined #minetest-dev |
| 07:18 |
OldCoder |
hmmmm, just FYI; heart patient reports message stream is 0.4.13 only. We will debug. |
| 07:19 |
hmmmm |
just disable the message for now |
| 07:19 |
hmmmm |
I'm kind of busy at the moment |
| 07:19 |
OldCoder |
hmmmm, see above. You are asked for zero. This is FYI. |
| 07:19 |
OldCoder |
We will debug and report additional clues for such time as this issue may be in the queue. |
| 07:19 |
hmmmm |
I sort of doubt you're going to get anywhere to be 100% honest |
| 07:19 |
hmmmm |
I'll give you a hint though |
| 07:20 |
OldCoder |
Go on |
| 07:20 |
OldCoder |
I estimate odds at 20% myself |
| 07:20 |
OldCoder |
So what? |
| 07:20 |
* OldCoder |
awaits hint |
| 07:20 |
hmmmm |
take a look at server.cpp:835-850 |
| 07:20 |
hmmmm |
that's where AOMs are composed |
| 07:20 |
OldCoder |
I have an adult player who loves the game and needs it. He will help. We will see what goes through that block. |
| 07:21 |
OldCoder |
For tonight, this is all: He only sees the problem with a 0.4.13 client |
| 07:21 |
OldCoder |
That is clearly a clue. You mentioned 0.4.10; so this may be multiple issues. |
| 07:21 |
hmmmm |
the issue is pretty clear |
| 07:21 |
OldCoder |
Oh? |
| 07:22 |
hmmmm |
minetest clients are sometimes being sent bogus packets from the server that are active object messages |
| 07:22 |
* OldCoder |
listens |
| 07:22 |
OldCoder |
And the cause of an endless stream of these? |
| 07:22 |
OldCoder |
Not known, right? |
| 07:22 |
hmmmm |
it wasn't an endless stream when I was looking into it |
| 07:22 |
hmmmm |
it was like one brief instance and never again for a while |
| 07:22 |
OldCoder |
It is now for me. This is therefore useful and interesting. We will report back. |
| 07:23 |
hmmmm |
anyway |
| 07:23 |
OldCoder |
Endless means interesting, no? Thank you. All for now. |
| 07:23 |
hmmmm |
active object messages have a 2 byte length prefix and then the message payload |
| 07:23 |
* OldCoder |
listens |
| 07:23 |
hmmmm |
this is the thing that's a bogus value, and then of course there is like 1 more byte after that corrupted length prefix |
| 07:24 |
hmmmm |
compare active object message length while being sent to what's being received |
| 07:24 |
hmmmm |
that way you can narrow down where the problem begins |
| 07:24 |
hmmmm |
good luck |
| 07:24 |
OldCoder |
I seem to have nodes that trigger this continuously. If I identify them and do that, possibly progress. |
| 07:24 |
OldCoder |
If not, no harm done. All right; that is all. |
| 07:24 |
OldCoder |
|
| 07:33 |
|
nrzkt joined #minetest-dev |
| 07:33 |
hmmmm |
why do you keep sending blank lines |
| 07:41 |
OldCoder |
hmmmm, Hi. I explained this 2 years ago. There are 3 logical purposes: #1 paragraph breaks #2 polite acknowledgments #3 announcement of presence. It is odd that everybody does not do this. |
| 07:41 |
ShadowBot |
https://github.com/minetest/minetest/issues/1 -- GlowStone code by anonymousAwesome |
| 07:41 |
ShadowBot |
https://github.com/minetest/minetest/issues/2 -- Burned wood |
| 07:41 |
ShadowBot |
https://github.com/minetest/minetest/issues/3 -- Furnace segfault |
| 07:42 |
hmmmm |
that's because people don't usually write a novel on irc |
| 07:43 |
OldCoder |
hmmmm, point is irrelevant. Paragraph breaks are readable regardless of novel. Plus there are 2 other reasons, aren't there? And this is not really core dev discussion. |
| 07:43 |
OldCoder |
Speaking of which, answer to error message issue... |
| 07:44 |
OldCoder |
Seems to be that player had too many cobble nodes right on top of light sources. So we don't know the root fix needed but vaporizing cobble seems to have ended the messages. |
| 07:44 |
OldCoder |
|
| 07:46 |
|
Amaz joined #minetest-dev |
| 08:37 |
|
jin_xi joined #minetest-dev |
| 08:52 |
|
julienrat joined #minetest-dev |
| 08:52 |
|
julienrat left #minetest-dev |
| 09:07 |
|
H-H-H joined #minetest-dev |
| 09:23 |
|
Megaf joined #minetest-dev |
| 10:23 |
|
deltib joined #minetest-dev |
| 10:30 |
jin_xi |
and here is said 'explanation'... http://irc.minetest.ru/minetest-dev/2012-10-27#i_2592006 |
| 10:55 |
|
Calinou joined #minetest-dev |
| 11:24 |
|
Brains joined #minetest-dev |
| 11:27 |
nrzkt |
jin_xi, good memory :D |
| 11:32 |
jin_xi |
i know and its a pain. i'd love a way to learn to forget :) |
| 11:32 |
|
proller joined #minetest-dev |
| 11:36 |
crazyR_ |
I cant beleive how people can get so easily annoyed or disturbed by what is such a trivial matter. it a blank line really going to cause anyone any harm? |
| 11:43 |
|
thatgraemeguy joined #minetest-dev |
| 11:43 |
|
thatgraemeguy joined #minetest-dev |
| 11:55 |
OldCoder |
What I said in that link stands. jin_xi has left. If somebody sees him or her later, tell him/her to shove off. |
| 11:55 |
OldCoder |
In a channel like this, civility is recommended |
| 11:55 |
|
technics joined #minetest-dev |
| 11:55 |
OldCoder |
No irony there; I give what I get |
| 11:55 |
OldCoder |
|
| 11:56 |
OldCoder |
Thanks loads for dumping on a contributor. Makes lots of sense to p*ss upon people who invest days or weeks trying to help. |
| 11:56 |
OldCoder |
|
| 11:58 |
VanessaE |
this isn't the place to be discussing this. |
| 12:06 |
nrzkt |
OldCoder, mister OldCoder :) |
| 12:06 |
nrzkt |
But OldCoder i agree that empty lines should be avoided |
| 12:07 |
OldCoder |
VanessaE is correct |
| 12:07 |
OldCoder |
nrzkt, you got something to say, PM me |
| 12:07 |
OldCoder |
jin_xi's use of single quotes around explanation was insulting |
| 12:07 |
OldCoder |
I damn well deserve better and you know it |
| 12:07 |
OldCoder |
F*ck |
| 12:07 |
VanessaE |
guys, just DROP IT |
| 12:07 |
OldCoder |
Chase away *everybody* will you? |
| 12:08 |
OldCoder |
I said he/she could PM me |
| 12:13 |
celeron55 |
lol |
| 12:13 |
celeron55 |
this is clearly an important development subject |
| 12:14 |
OldCoder |
Communication about communication happens, celeron55; people here seem to like to bash others about it quite a bit. I've done nothing but explain and respond. |
| 12:14 |
OldCoder |
In a text world, subtleties matter a lot. Civility rules are recommended. |
| 12:14 |
OldCoder |
|
| 12:16 |
OldCoder |
celeron55, add up the people who have been chased away by incivility, it's not a large number. It does however have an impact. I respectfully submit that the project is moving towards potential Mozilla.com level. Civility rules will be needed for the next stage. They are not optional. |
| 12:16 |
OldCoder |
|
| 12:17 |
celeron55 |
ehm |
| 12:17 |
OldCoder |
Am I incorrect? Take it under advisement. |
| 12:17 |
OldCoder |
The project will rise or fall on whether or not the old ways continue. |
| 12:18 |
celeron55 |
yeah but it's now you who i am criticizing; more jin_xi |
| 12:18 |
celeron55 |
not* |
| 12:18 |
OldCoder |
We should seek to avoid issues to begin with. Simple civility rules and expectations will help. |
| 12:18 |
celeron55 |
but your IRC novels are kind of riciulous though, but you already know it so whatever |
| 12:18 |
celeron55 |
ridiculous (what's wrong with my hands) |
| 12:18 |
* OldCoder |
refrains from jokes |
| 12:19 |
OldCoder |
There are *3* reasons for blank lines, celeron55. *3*. However, that is not the point. Criticism should be civil. |
| 12:20 |
OldCoder |
You are unlikely to dispute this. You know that your team has a reputation for being (obscenity redacted)s. Only a few but this is enough. |
| 12:20 |
OldCoder |
Professional behavior is advised. |
| 12:21 |
celeron55 |
yes, i can agree that people should act professionally |
| 12:21 |
OldCoder |
Add to this one point: In a world of text there is no body language. Subtleties matter. |
| 12:22 |
OldCoder |
It is not best to mock somebody by wording explanation as 'explanation' |
| 12:22 |
OldCoder |
Little things matter in IRC |
| 12:22 |
OldCoder |
Hm. I've had my say. Thank you. |
| 12:24 |
celeron55 |
then again, why should you care about what jin_xi said; he's not an important person here and nobody else really cares what he said, and he didn't prevent some other more important discussion |
| 12:25 |
OldCoder |
celeron55, I think I'd respond in PM if you wished to hear more. The parts about civility are appropriate for the channel. My own feelings are not. |
| 12:25 |
OldCoder |
I'll say that nrzkt and jin_xi together... having two people come after me... was not pleasant |
| 12:25 |
OldCoder |
|
| 12:25 |
celeron55 |
yes but you are telling the things about civility to people who don't need to hear about them |
| 12:25 |
OldCoder |
Hm? You will decide the rules, right? |
| 12:26 |
OldCoder |
It is ultimately your decision. I did not suggest that you yourself were incivil. |
| 12:26 |
celeron55 |
anyway, i'll just drop this, getting into any details is useless |
| 12:26 |
OldCoder |
If you wish responses on such subjects, PM me. But civility rules are not useless. |
| 12:27 |
celeron55 |
(we have civility rules; the fact that somebody is not civil does not mean that we don't have them) |
| 12:27 |
OldCoder |
Ah |
| 12:27 |
OldCoder |
Let's call them guidelines. Are they posted somewhere? |
| 12:28 |
OldCoder |
Enough for now. I stand by the point; the core devs are viewed as unpleasant by more than a few people... |
| 12:28 |
celeron55 |
http://dev.minetest.net/How_to_communicate |
| 12:28 |
OldCoder |
Rules or not, this could be improved. Thank you. |
| 12:38 |
|
proller joined #minetest-dev |
| 12:38 |
|
zat joined #minetest-dev |
| 12:46 |
|
julienrat joined #minetest-dev |
| 12:46 |
|
julienrat left #minetest-dev |
| 13:38 |
|
RealBadAngel joined #minetest-dev |
| 13:49 |
|
luizrpgluiz joined #minetest-dev |
| 13:56 |
|
luizrpgluiz left #minetest-dev |
| 14:19 |
|
Hunterz joined #minetest-dev |
| 14:33 |
|
CraigyDavi joined #minetest-dev |
| 15:07 |
VanessaE |
ok, question... |
| 15:07 |
VanessaE |
why is it that when I redefine some old default node (tree trunks in this case) to use something other than the "normal" drawtype, that they turn solid black in the world? |
| 15:07 |
VanessaE |
(and yes, paramtype="light" is already in the new def) |
| 15:08 |
VanessaE |
morning, RealBadAngel. |
| 15:08 |
kahrl |
VanessaE: because the light level is still 0 in those already placed nodes |
| 15:08 |
VanessaE |
so why aren't they black *before* the redef? |
| 15:09 |
kahrl |
because the normal drawtype cares about the light level in the adjacent nodes, not in the node itself |
| 15:09 |
VanessaE |
I see |
| 15:09 |
VanessaE |
in this case I'm writing yet-another-round-treetrunks mod. was hoping by now this had already been fixed :-/ |
| 15:10 |
kahrl |
I'm not sure there is anything to fix |
| 15:12 |
crazyR_ |
hey VanessaE, just to let you know on starting a minetest server up with homedecor enabled. this error is being produced for a handfull of nodes: |
| 15:12 |
crazyR_ |
WARNING[Main]: Not registering alias, item with same name is already defined: homedecor:table_lamp_max -> homedecor:table_lamp_white_max |
| 15:12 |
VanessaE |
the engine can't default to some "sane" value if the drawtype is inconsistent with the way light is handled? |
| 15:12 |
kahrl |
crazyR_: --> #minetest |
| 15:13 |
crazyR_ |
Ive not had chance to report it yet but i will do later, and sorry kahrl i forgot what channel i was in |
| 15:13 |
kahrl |
VanessaE: the engine can't really detect that case |
| 15:14 |
kahrl |
VanessaE: 0 is a valid light level in mesh/nodebox nodes |
| 15:14 |
VanessaE |
hrm |
| 15:14 |
VanessaE |
I guess I could add an ABM to recalc the light or something |
| 15:15 |
VanessaE |
it's too bad I can't just "preset" a param1 value :) |
| 15:15 |
VanessaE |
(yeah I know that wouldn't work) |
| 15:20 |
kahrl |
looks like the ABM is what hungry_games_plus does (in a separate mod so you can activate it once and then disable) |
| 15:20 |
kahrl |
err no hungry_games_plus |
| 15:20 |
kahrl |
3dfurniture |
| 15:21 |
VanessaE |
yeah |
| 15:21 |
VanessaE |
3dforniture had something like that |
| 15:25 |
VanessaE |
it just feels dirty to have to use such a thing |
| 15:26 |
VanessaE |
given that an ABM has a limited action range and doesn't have any kind of "auto-deactivate" |
| 15:28 |
crazyR_ |
could an ABM not be put in a while statement and once it has acheived its objective setting the while statement to false. thus disabling it... not tested it just an idea |
| 15:28 |
VanessaE |
nope. |
| 15:29 |
|
PilzAdam joined #minetest-dev |
| 15:29 |
kahrl |
est31's idea of having ABMs that only run on block load (or activation) could come into play here |
| 15:29 |
crazyR_ |
maybe we need a "de_register_abm" api function?? |
| 15:30 |
PilzAdam |
o/ |
| 15:30 |
kahrl |
moin PilzAdam |
| 15:31 |
VanessaE |
hey PilzAdam. |
| 15:31 |
VanessaE |
kahrl: yeah, that might do the trick. |
| 15:31 |
PilzAdam |
#3258 should be merged soon, since it will break with each commit that adds a new setting |
| 15:31 |
ShadowBot |
https://github.com/minetest/minetest/issues/3258 -- New Lua main menu settings by PilzAdam |
| 15:32 |
PilzAdam |
the stuff in the todo list can be added later; it's already functional enough |
| 15:46 |
VanessaE |
kahrl: this seems to work: http://pastebin.com/MVxjKYQJ |
| 16:33 |
|
Krock joined #minetest-dev |
| 17:04 |
celeron55 |
maybe there should be a callback for when a bunch of map is loaded from disk (in practice a mapblock, but mods don't have to know about those) |
| 17:04 |
celeron55 |
it's still messy because it would be re-done every time the block is loaded |
| 17:04 |
celeron55 |
but really there is no way around it; the node data and definitions have been optimized in such a way that relies on the fact that definitions will not suddenly change in an incompatible way |
| 17:04 |
celeron55 |
to do it in a way that is actually supported, you should define them as a new node type and explicitly convert the old ones to the new ones that use a different way of handling light |
| 17:04 |
|
hmmmm joined #minetest-dev |
| 17:05 |
celeron55 |
but you still end up with many of the same issues because there is no existing systems for handling a case like this done this way either 8) |
| 17:06 |
VanessaE |
celeron55: I was hoping to avoid doing that.. |
| 17:07 |
celeron55 |
the way to make this automatically handled would be to include each definition field that affects how the node data is interpreted of each node type used in a mapblock to the mapblock data, and then convert appropriately at load-time when comparing that data to the data that is actually defined by the current game content |
| 17:08 |
celeron55 |
but that's very complex and wasteful in 99.99% of cases where those data interpretations don't ever change |
| 17:08 |
VanessaE |
plus, ironically, this is not a problem for newly-generated mapblocks so that would be moot anyway |
| 17:08 |
celeron55 |
so, tough luck; there is no proper solution :P |
| 17:08 |
celeron55 |
yes it would not work for your world specifically |
| 17:10 |
VanessaE |
seems to me, the most proper solution is to treat "light=0, drawtype != normal" as a special case and re-calc the light or something. |
| 17:10 |
celeron55 |
one other way would be to allow mods to version their data manually and allow them to run migration steps a bit like automatically migrating a database format |
| 17:10 |
celeron55 |
but there would be like one mod that would be using it so... eh |
| 17:10 |
celeron55 |
VanessaE: but that happens all the time |
| 17:10 |
celeron55 |
it's a completely valid case for all furniture in an unlighted cave for example |
| 17:11 |
celeron55 |
no way around it |
| 17:11 |
VanessaE |
hm |
| 17:12 |
VanessaE |
well the ABM I put in my code at least sort it out gradually. |
| 17:13 |
VanessaE |
sorts* |
| 17:15 |
VanessaE |
now as for register_on_mapload or whatever you wanna call it, seems to me the engine could retain a table of mapblocks that have recently been loaded, something it could pass to the mod |
| 17:16 |
VanessaE |
(well, table of mapblock coords) |
| 17:17 |
VanessaE |
something that would persist until restart, and which would contain a list of ALL blocks that have ever been loaded since startup. |
| 17:17 |
VanessaE |
I dunno.. |
| 17:22 |
|
nrzkt joined #minetest-dev |
| 17:25 |
|
Gael-de-Sailly joined #minetest-dev |
| 17:31 |
hmmmm |
4 celeron55 maybe there should be a callback for when a bunch of map is loaded from disk (in practice a mapblock, but mods don't have to know about those) |
| 17:31 |
hmmmm |
that exists ^ hah |
| 17:31 |
hmmmm |
just no lua interface to it at the moment |
| 17:33 |
celeron55 |
it's kind of funny how minetest is actually quite purely just a complicated visualization software for 4-byte voxel data |
| 17:33 |
celeron55 |
you see it when this kind of situations occur |
| 17:34 |
hmmmm |
yeah this is ridiculous |
| 17:34 |
hmmmm |
minetest is the best OS |
| 17:36 |
hmmmm |
erm anyway, instead of adding a lua callback for loaded blocks, maybe it'd be a better idea to have a single callback that copies m_added_blocks in the environment step to a lua table and calls a single callback |
| 17:36 |
celeron55 |
if there's buffering like that already, then probably yes |
| 17:36 |
hmmmm |
?? yes |
| 17:37 |
hmmmm |
you don't remember the chunk of code in ServerEnvironment::step() that goes through the list of recently loaded blocks to activate them? |
| 17:37 |
celeron55 |
i'm not questioning whether that exists, i'm just not even trying to remember anything |
| 17:38 |
hmmmm |
hmmmm |
| 17:38 |
hmmmm |
hrmmm... |
| 17:39 |
hmmmm |
alright, so Emerge Completion Callbacks have a use; for notification when an asynchronous load/generate block command has finished |
| 17:39 |
hmmmm |
it's not exactly the best thing to write a Lua interface for |
| 17:39 |
|
proller joined #minetest-dev |
| 17:39 |
hmmmm |
because it wouldn't capture any of the instances where blocks were synchronously loaded from the db |
| 17:40 |
hmmmm |
mods who want to know about loaded blocks probably want to know about *all* loaded blocks |
| 17:43 |
|
PilzAdam joined #minetest-dev |
| 17:44 |
hmmmm |
mm okay i just looked, it turns out that added_blocks list is for blocks that became active within that step |
| 17:45 |
hmmmm |
in other words, not all of the recently loaded blocks. i can't help but think that it would be sufficient enough to have the recently activated block list, however. |
| 18:03 |
|
proller joined #minetest-dev |
| 18:17 |
|
proller joined #minetest-dev |
| 18:20 |
|
Soni joined #minetest-dev |
| 18:24 |
|
Gael-de-Sailly joined #minetest-dev |
| 18:34 |
|
jin_xi joined #minetest-dev |
| 19:17 |
|
proller joined #minetest-dev |
| 19:23 |
|
rickmcfarley joined #minetest-dev |
| 19:28 |
|
est31 joined #minetest-dev |
| 19:32 |
|
blaze joined #minetest-dev |
| 19:33 |
est31 |
we do have a mechanism to tell old blocks apart from new ones |
| 19:33 |
est31 |
the timestamp |
| 19:39 |
est31 |
so you could do minetest.register_on_old_block_load("default:stairs_update", function() ... end) |
| 19:40 |
est31 |
and in the world dir, there would be a file "block_load_times.txt" which contains a list of game times together with the names, e.g. default:stairs_update |
| 19:40 |
est31 |
so one line could be default:stairs_update 466832 501340 |
| 19:41 |
est31 |
denoting that the "block replacer" default:stairs_update ran between game times 466832 to 501340. |
| 19:41 |
est31 |
so blocks loaded with that timestams don't get affected by the function |
| 19:41 |
est31 |
but all blocks before or after do. |
| 19:42 |
est31 |
(you see I dont really have a name for it, perhaps we can just realize it with special params for the ABMs) |
| 19:45 |
est31 |
I don't think we should pass the list over registered_on_globalstep functions |
| 19:46 |
est31 |
we can pass the block coords in "bulk" if we want, so that it's faster |
| 19:49 |
est31 |
but globalstep is the wrong place to do it |
| 19:49 |
est31 |
a trivial optimisation would be to not call the step function if no blocks have been loaded |
| 19:49 |
est31 |
and then we enter the ABM domain |
| 19:51 |
est31 |
idc perhaps the stuff can even be stored in the envargs file |
| 19:56 |
est31 |
issue #3198 has some discussion about bulk passing of data |
| 19:56 |
ShadowBot |
https://github.com/minetest/minetest/issues/3198 -- Batching APIs |
| 19:57 |
est31 |
tldr: it is indeed faster, but only a tiny bit |
| 20:12 |
|
Darcidride joined #minetest-dev |
| 20:44 |
|
rickmcfarley joined #minetest-dev |
| 20:58 |
|
DFeniks joined #minetest-dev |
| 22:33 |
|
kaeza joined #minetest-dev |
| 22:51 |
|
proller joined #minetest-dev |
| 22:56 |
|
proller joined #minetest-dev |
| 23:08 |
|
Miner_48er joined #minetest-dev |
| 23:15 |
est31 |
oh, super nice |
| 23:15 |
est31 |
thanks to a "refactor" we crash now when we get a formspec with invsize |
| 23:16 |
est31 |
I'll push a commit that reverts parts of that refactor |
| 23:16 |
hmmmm |
oopsies |
| 23:16 |
hmmmm |
which one |
| 23:16 |
est31 |
#3260 |
| 23:16 |
ShadowBot |
https://github.com/minetest/minetest/issues/3260 -- Crash regression when displaying deprecated formspecs |
| 23:17 |
hmmmm |
oh no dammit |
| 23:17 |
hmmmm |
I'm guessing this is because L is in fact == NULL |
| 23:17 |
est31 |
yes |
| 23:17 |
hmmmm |
how the hell does that happen |
| 23:17 |
est31 |
scripting_game.cpp |
| 23:17 |
est31 |
look at the commit that added the methods b5acec0a3c5701c53854ff7afdf4008863e6e8df |
| 23:18 |
hmmmm |
hrmm |
| 23:19 |
hmmmm |
ahhhhh |
| 23:19 |
hmmmm |
sorry est that one's my fault, I was the one who removed the NULL check there because I didn't think there was any circumstances where it'd be NULL |
| 23:20 |
hmmmm |
I mean L parameters literally everywhere else are assumed to be non-null, so why the difference here? |
| 23:20 |
est31 |
yup |
| 23:20 |
est31 |
will add a comment |
| 23:20 |
hmmmm |
and the answer to that is because of guiFormSpecMenu.cpp |
| 23:20 |
est31 |
it is weird indeed |
| 23:20 |
hmmmm |
the crummy design that parses the formspec string inside of the formspec engine |
| 23:21 |
hmmmm |
and not as part of the interface to lua |
| 23:21 |
est31 |
well it makes total sense |
| 23:21 |
hmmmm |
god I can't wait to blow up formspec |
| 23:21 |
est31 |
lua runs on the server |
| 23:21 |
est31 |
formspec gets parsed by the client |
| 23:22 |
est31 |
if you have lua on the client its wrong, yes |
| 23:22 |
hmmmm |
well I mean there still should be a difference between serialized form and the internal form |
| 23:22 |
hmmmm |
bbl |
| 23:22 |
est31 |
the weird thing is that we call a method from src/script from the client |
| 23:22 |
est31 |
the only place where we have lua on the client is mainmenu |
| 23:22 |
hmmmm |
I know this is all poorly thought out and it does not need to be like that |
| 23:22 |
hmmmm |
:) |
| 23:22 |
hmmmm |
we can fix it |
| 23:22 |
hmmmm |
I'm taking a week off from work so I can really do some damage perhaps |
| 23:23 |
est31 |
wow thats great |
| 23:23 |
hmmmm |
okay be back later |
| 23:30 |
est31 |
hmmmm, PTAL https://github.com/est31/minetest/commit/836486a98e7b09e25b97c9d989301ed9eb365b3b |
| 23:30 |
est31 |
(if you are there) |
| 23:48 |
|
luizrpgluiz joined #minetest-dev |
