| Time |
Nick |
Message |
| 00:24 |
|
VanessaE joined #minetest-dev |
| 00:33 |
|
Icedream joined #minetest-dev |
| 01:15 |
|
paramat joined #minetest-dev |
| 01:20 |
paramat |
hmmmm concering #3222 is there a reason to disallow setting chunksize using set_mapgen_params()? |
| 01:20 |
ShadowBot |
https://github.com/minetest/minetest/issues/3222 -- Allow changing chunksize from lua API, with set_mapgen_params() |
| 01:29 |
|
Icedream joined #minetest-dev |
| 01:34 |
|
Icedream joined #minetest-dev |
| 01:36 |
hmmmm |
there's really not any good reason for setting chunksize |
| 01:37 |
hmmmm |
in fact i kinda wish i didn't make it modifiable at all |
| 01:37 |
paramat |
i sortof agree |
| 01:39 |
hmmmm |
if you change the chunksize of a map that started out as one chunksize, you'll get shapes of blocks that will stay ungenerated |
| 01:40 |
hmmmm |
and it'll probably fill the emerge queue with requests for those chunks not knowing that they're not going to get generated |
| 01:40 |
hmmmm |
which prevents other blocks from getting queued due to the limit |
| 01:41 |
|
Icedream joined #minetest-dev |
| 01:42 |
paramat |
ah, making it a param and getting it was added for good reason, that should remain |
| 01:43 |
paramat |
very useful, it was on my request |
| 01:43 |
hmmmm |
i think it's an artifact of the emerge queue not being very robust |
| 01:44 |
paramat |
setting it for a singlenode mapgen would be ok though perhaps |
| 01:44 |
|
est31 joined #minetest-dev |
| 01:44 |
paramat |
well i'll ask these modders why they feel they need it |
| 01:44 |
est31 |
how is there an additional problem with the emerge queue |
| 01:45 |
est31 |
are blocks which dont get generated never removed from the queue? |
| 01:45 |
hmmmm |
they just keep getting readded each server step if they aren't generated |
| 01:45 |
hmmmm |
hmm actually no |
| 01:46 |
hmmmm |
changing the chunksize in an already existing map will just regenerate mostly everything |
| 01:46 |
hmmmm |
come to think of it, the current design shouldn't cause any ungenerated gaps |
| 01:46 |
est31 |
I guess increas is different from decrease? |
| 01:46 |
est31 |
decrease should work?? |
| 01:46 |
hmmmm |
both should work |
| 01:47 |
hmmmm |
for mapgens that still modify blocks which already have been generated (like v6) this would cover everything with poopy mud |
| 01:47 |
hmmmm |
but it should be okay for v5 and v7 |
| 01:48 |
paramat |
hehe |
| 01:48 |
hmmmm |
maybe.. i'm not entirely sure ever since that overgeneration feature got added |
| 01:48 |
hmmmm |
rather nevermind that doesn't apply to the map emerged |
| 01:48 |
hmmmm |
just the noise generated |
| 01:49 |
est31 |
Either way, I'm completely open on whether to expose it via the API, making it an option, or removing it entirely |
| 01:49 |
* est31 |
no mapgen pro |
| 01:49 |
paramat |
setting it in conf is perhaps good enough |
| 01:49 |
est31 |
but what paramat asked on github is a general good tactic |
| 01:50 |
est31 |
asking for the usecase |
| 01:50 |
est31 |
https://github.com/minetest/minetest/issues/3222#issuecomment-145306267 |
| 01:50 |
est31 |
then you know what people want, and can try to find a solution for their needs, and not what they think they need. |
| 01:52 |
est31 |
about #3221 we really do need a new settings menu setup |
| 01:52 |
ShadowBot |
https://github.com/minetest/minetest/issues/3221 -- Add viewing range GUI setting by kilbith |
| 01:52 |
est31 |
e.g. multiple settings menus |
| 02:15 |
est31 |
opinions on #3219? |
| 02:15 |
ShadowBot |
https://github.com/minetest/minetest/issues/3219 -- Add new ContentParamType2 "CPT2_DEGROTATE" by est31 |
| 02:18 |
paramat |
i don't like the slight slowdown in meshgen, or the plant rotation feature itself, but as long as we have the feature it should be coded correctly and be a separate param2type |
| 02:20 |
paramat |
i wonder if we should bother correctly rotating these by adding to rotateNodeAlongYAxis .. |
| 02:21 |
paramat |
most uses will be random rotation so no need to rotate |
| 02:29 |
paramat |
think i'll wait until someone complains :) |
| 02:37 |
est31 |
the slowdown is so minimal, its barely there |
| 02:42 |
paramat |
yeah. my objection is more on principle :) feeling we just don't need the feature. anyway i expect it will stay |
| 02:48 |
|
paramat left #minetest-dev |
| 02:56 |
|
est31 joined #minetest-dev |
| 03:18 |
|
Kray_ joined #minetest-dev |
| 03:19 |
|
EUGD joined #minetest-dev |
| 03:26 |
|
EUGD joined #minetest-dev |
| 03:34 |
|
EUGD joined #minetest-dev |
| 04:15 |
|
paramat joined #minetest-dev |
| 04:19 |
|
EUGD joined #minetest-dev |
| 04:23 |
|
EUGD joined #minetest-dev |
| 05:16 |
paramat |
hmmmm #3223 improvements to mgv5 getGroundLevelAtPoint |
| 05:16 |
ShadowBot |
https://github.com/minetest/minetest/issues/3223 -- Mgv5: getGroundLevelAtPoint searches a larger range by paramat |
| 05:21 |
|
Hunterz joined #minetest-dev |
| 05:47 |
hmmmm |
sure, looks good |
| 05:49 |
paramat |
ok thanks |
| 06:13 |
|
paramat left #minetest-dev |
| 06:56 |
hmmmm |
PTAL |
| 06:56 |
hmmmm |
https://github.com/kwolekr/minetest/commit/366cf9e4e1754990af8c093abed585be35c35d22 |
| 06:56 |
hmmmm |
https://github.com/kwolekr/minetest/commit/a8f522cdb4783dab84f1c02d4202e70a21d1fb50 |
| 06:56 |
hmmmm |
https://github.com/kwolekr/minetest/commit/6d3aea2d750cb543af34c680b050212563484bd8 |
| 07:12 |
|
Krock joined #minetest-dev |
| 07:26 |
|
paramat joined #minetest-dev |
| 07:27 |
paramat |
hmmmm limit constants looks good, there is also a (u32)-1 in writeParams in mgv5/6/7 |
| 07:34 |
paramat |
proposed new header image for mtgame https://github.com/minetest/minetest_game/issues/480#issuecomment-145301062 |
| 07:34 |
|
paramat left #minetest-dev |
| 07:36 |
|
FR^2 joined #minetest-dev |
| 07:44 |
OldCoder |
The long serialization error messages and lockups are still occurring with git-current. Is this to be expected? |
| 08:00 |
|
Krock joined #minetest-dev |
| 08:02 |
hmmmm |
yup got it |
| 08:03 |
hmmmm |
not good |
| 08:03 |
hmmmm |
i pushed the wrong branch |
| 08:03 |
Krock |
ouch. |
| 08:04 |
hmmmm |
fixed |
| 08:39 |
|
nrzkt joined #minetest-dev |
| 08:40 |
|
jin_xi joined #minetest-dev |
| 09:18 |
|
Megaf joined #minetest-dev |
| 09:33 |
|
Calinou joined #minetest-dev |
| 09:57 |
|
AnotherBrick joined #minetest-dev |
| 10:10 |
|
Lithia joined #minetest-dev |
| 10:24 |
|
rubenwardy joined #minetest-dev |
| 10:54 |
|
H-H-H joined #minetest-dev |
| 11:07 |
|
ElectronLibre joined #minetest-dev |
| 12:25 |
|
Gael-de-Sailly joined #minetest-dev |
| 12:40 |
|
EMK_ joined #minetest-dev |
| 13:06 |
|
hmmmm joined #minetest-dev |
| 13:33 |
|
turtleman_ joined #minetest-dev |
| 13:38 |
|
ElectronLibre joined #minetest-dev |
| 14:05 |
|
CapiZ joined #minetest-dev |
| 14:28 |
hmmmm |
guys |
| 14:28 |
hmmmm |
https://github.com/kwolekr/minetest/commit/53ba9a16c086bb5d2da49fdd37ce791f335501e0 PTAL |
| 14:36 |
OldCoder |
celeron55, recall our discussion about clumping ABMs. I believe I found the answer in the core code. |
| 14:37 |
OldCoder |
- if(aabm.chance == 0) a- if(aabm.chance == 0) aabm.chance = 1; |
| 14:37 |
OldCoder |
+ if(aabm.chance == 0) aabm.chance = 1000000;abm.chance = 1; |
| 14:37 |
OldCoder |
+ if(aabm.chance == 0) aabm.chance = 1000000; |
| 14:37 |
OldCoder |
Oops |
| 14:37 |
OldCoder |
|
| 14:37 |
OldCoder |
- if(aabm.chance == 0) aabm.chance = 1; |
| 14:37 |
OldCoder |
+ if(aabm.chance == 0) aabm.chance = 1000000; |
| 14:37 |
OldCoder |
There |
| 14:37 |
OldCoder |
If there are blocks in the game not visited for a while |
| 14:38 |
OldCoder |
They tend to trigger all ABMs at once |
| 14:38 |
rubenwardy |
er what |
| 14:38 |
OldCoder |
Yes |
| 14:38 |
OldCoder |
I discussed this with celeron55 recently... |
| 14:38 |
OldCoder |
I noticed that ABMs have a tendency under some conditions |
| 14:38 |
OldCoder |
to trigger all at once on the same node |
| 14:38 |
OldCoder |
He wondered if the issue might by in myrand |
| 14:38 |
OldCoder |
What actually seems to be happening |
| 14:39 |
OldCoder |
Is that if there is large time discrepancy between node time and current time |
| 14:39 |
OldCoder |
The large interval triggers |
| 14:39 |
OldCoder |
if(aabm.chance == 0) aabm.chance = 1; |
| 14:39 |
rubenwardy |
ah |
| 14:39 |
OldCoder |
as effective chance is perceived to have reduced to zero |
| 14:39 |
OldCoder |
And all the nodes go off at once |
| 14:39 |
rubenwardy |
so it's an overflow? |
| 14:39 |
OldCoder |
Not quite but sort of |
| 14:40 |
OldCoder |
I believe the (two) lines should read |
| 14:40 |
OldCoder |
if(aabm.chance == 0) aabm.chance = 1000000; |
| 14:40 |
OldCoder |
A better solution |
| 14:40 |
OldCoder |
would be to rework the code at a higher level |
| 14:40 |
rubenwardy |
does that break leaving out chance in an abm definition? |
| 14:40 |
OldCoder |
That computes the large time interval |
| 14:40 |
OldCoder |
and cap it |
| 14:40 |
OldCoder |
Explain question? |
| 14:41 |
OldCoder |
I don't know; if you leave out chance, does it default to 1? |
| 14:41 |
OldCoder |
If so, this should not affect it directly |
| 14:41 |
rubenwardy |
if you leave out chance in register_abm, it should default to 1 |
| 14:41 |
OldCoder |
Ninja |
| 14:41 |
OldCoder |
Chance in register abm |
| 14:41 |
OldCoder |
Seems to get divided |
| 14:41 |
OldCoder |
under some conditions |
| 14:41 |
OldCoder |
by a time interval computed based on the age of a block |
| 14:42 |
OldCoder |
I don't know if chance being 1 to begin with makes a difference |
| 14:42 |
OldCoder |
and am falling asleep now so can't check |
| 14:42 |
OldCoder |
I will say that that line or the time interval code at a higher level |
| 14:42 |
OldCoder |
One or the other needs to be tweaked |
| 14:42 |
OldCoder |
As presently you get all sorts of clumps of ABMs |
| 14:42 |
OldCoder |
going off at once; done. Is this sufficient to warrant interest? |
| 14:42 |
OldCoder |
|
| 14:43 |
OldCoder |
The two locations in the code are: |
| 14:43 |
OldCoder |
src/environment.cpp circa line 589 where the code diddles with chance |
| 14:43 |
OldCoder |
and |
| 14:43 |
OldCoder |
void ServerEnvironment::activateBlock |
| 14:43 |
OldCoder |
dtime_s = m_game_time - block->getTimestamp(); |
| 14:43 |
OldCoder |
That code |
| 14:44 |
OldCoder |
dtime_s being large (or is it negative?) causes odd effects |
| 14:44 |
OldCoder |
|
| 14:44 |
OldCoder |
My temporary patch does seem to eliminate the clumps |
| 14:44 |
OldCoder |
|
| 14:46 |
OldCoder |
float actual_interval = dtime_s; |
| 14:46 |
OldCoder |
float intervals = actual_interval / trigger_interval; |
| 14:46 |
OldCoder |
float chance = abm->getTriggerChance(); |
| 14:46 |
OldCoder |
aabm.chance = chance / intervals; |
| 14:46 |
OldCoder |
trace through that and observe what happens if dtime_s is large |
| 14:46 |
OldCoder |
if(aabm.chance == 0) aabm.chance = 1; |
| 14:46 |
OldCoder |
|
| 14:47 |
OldCoder |
zzz |
| 14:47 |
celeron55 |
that code is probably working as intended |
| 14:47 |
OldCoder |
OK |
| 14:47 |
celeron55 |
but the intention might be wrong |
| 14:47 |
OldCoder |
Then what about the clumps? |
| 14:47 |
OldCoder |
Ah |
| 14:47 |
OldCoder |
Perhaps dtime_s should be capped instead? |
| 14:47 |
celeron55 |
what it's doing is making it so that if you leave a block and come back after a long time, for example grass growth will catch up |
| 14:47 |
OldCoder |
Yes |
| 14:47 |
celeron55 |
but with more complex ABMs it messes things up |
| 14:48 |
OldCoder |
indeed |
| 14:48 |
* OldCoder |
has piles of deadly Pumpkings and Enderducks |
| 14:48 |
celeron55 |
maybe the ABM definition needs a flag for whether that behavior is enabled or not |
| 14:48 |
OldCoder |
Hm |
| 14:48 |
OldCoder |
Wait |
| 14:48 |
celeron55 |
so that grass and others can have it as they benefit from it, but some other things can disable it |
| 14:48 |
OldCoder |
If you do go away and come back... |
| 14:48 |
OldCoder |
behavior will revert to normal |
| 14:49 |
OldCoder |
grass will not immediately catch up |
| 14:49 |
OldCoder |
but it will resume growing while you are in the area |
| 14:49 |
OldCoder |
Isn't this sufficient? |
| 14:50 |
celeron55 |
in my personal opinion? no, it isn't sufficient |
| 14:50 |
celeron55 |
i don't know if any actual player wants it though |
| 14:50 |
OldCoder |
This means that everything happens at once, though |
| 14:50 |
OldCoder |
Which is interesting |
| 14:50 |
OldCoder |
"Time is Nature's way of making sure everything doesn't happen at once" |
| 14:51 |
OldCoder |
ABM flag is one option. What happens if you cap dtime_s instead? Or simply increase odds? |
| 14:51 |
celeron55 |
you can't actually run all ABMs so simulating everything at once is the only solution if that has to happen |
| 14:51 |
* OldCoder |
thinks |
| 14:51 |
OldCoder |
catchup = false | true -- Hm |
| 14:52 |
OldCoder |
Cap dtime_s won't solve the problem you mentioned... |
| 14:52 |
celeron55 |
i think adding that flag is the only sensible solution |
| 14:52 |
OldCoder |
I tend to agree |
| 14:52 |
celeron55 |
maybe it has to default to false |
| 14:52 |
OldCoder |
Unless something else comes up |
| 14:53 |
OldCoder |
It is backwards compatible; sensible that way |
| 14:53 |
celeron55 |
i don't think most modders want, care about nor understand this functionality |
| 14:53 |
celeron55 |
true would be backwards compatible |
| 14:53 |
OldCoder |
celeron55, I need to sleep; wanted to get back to you. Regardless of modders, default of catchup to false is safer. Yes to your point... |
| 14:53 |
OldCoder |
I meant API compatible |
| 14:53 |
rubenwardy |
catchup is misleading |
| 14:53 |
celeron55 |
false isn't; false is compatible with what modders seem to expect |
| 14:54 |
OldCoder |
modders would not expect catchup, I think |
| 14:54 |
OldCoder |
rubenwardy, what would best name be? |
| 14:54 |
rubenwardy |
because it doesn't run multiple times, it just increases the chance of running |
| 14:54 |
OldCoder |
to 100% |
| 14:54 |
OldCoder |
Hence catch-up? |
| 14:54 |
celeron55 |
if it could run multiple times, the server would practically just hang in many cases :P |
| 14:54 |
OldCoder |
If catchup (or other name) is enabled, one gets 100% run of an ABM if there is a long run |
| 14:55 |
OldCoder |
Yes I accidentally simulated that |
| 14:55 |
OldCoder |
celeron55, I think a flag is a sensible workaround and suggest default false |
| 14:55 |
OldCoder |
consensus could determine this |
| 14:55 |
OldCoder |
Doesn't break API, makes ABMs trigger as expected (by modders) |
| 14:55 |
rubenwardy |
catchup_by_chance_reduction? |
| 14:56 |
rubenwardy |
meh |
| 14:56 |
celeron55 |
rubenwardy: maybe "simple_catch_up" or something; the purpose is catch-up regardless of how well that works for a general ABM usage |
| 14:56 |
OldCoder |
Yep |
| 14:56 |
OldCoder |
simple_catch_up is good |
| 14:56 |
rubenwardy |
yeah, it's good |
| 14:56 |
* OldCoder |
looks forward to worlds not filled with deadly ducks |
| 14:57 |
OldCoder |
It was weird for a while; ever see Santa merged with a snowman and a deadly duck plus a bear? |
| 14:57 |
OldCoder |
They get stuck together and can't pull apart |
| 14:57 |
OldCoder |
celeron55, I lack a better proposal. Most obvious solutions have no advantages. |
| 14:58 |
* OldCoder |
really should nap now and sides with the flag and hopes it can be default false |
| 14:58 |
OldCoder |
Zzz |
| 15:13 |
|
Player_2 joined #minetest-dev |
| 15:16 |
|
ElectronLibre joined #minetest-dev |
| 16:14 |
|
kilbith joined #minetest-dev |
| 16:14 |
|
EUGD joined #minetest-dev |
| 16:15 |
|
TenPlus1 joined #minetest-dev |
| 16:15 |
TenPlus1 |
hi folks |
| 16:16 |
kilbith |
MT crashes randomly on launching on that error : http://paste.ubuntu.com/12681172/ |
| 16:16 |
TenPlus1 |
could someone answer a code question for me plz |
| 16:16 |
TenPlus1 |
what causes this error: "minetest: /build/minetest-PDtZw2/minetest-201509300128/src/util/serialize.h:265: void writeF1000(irr::u8*, irr::f32): Assertion `i >= ((float)(s32)((-0x7FFFFFFF - 1) / 1000.0f)) && i <= ((float)(s32)((0x7FFFFFFF) / 1000.0f))' failed." |
| 16:16 |
TenPlus1 |
or should I ask, what WOULD cause this error ? |
| 16:17 |
nrzkt |
kilbith: a gdb trace is appreciated |
| 16:18 |
TenPlus1 |
I've done one already and pasted it on forum and github for you... |
| 16:18 |
TenPlus1 |
but my question is, what would cause such an error to happen in the 1st place ? from the code's perspective |
| 16:18 |
TenPlus1 |
am hoping to backtrack it |
| 16:33 |
|
DFeniks joined #minetest-dev |
| 16:37 |
|
EUGD1 joined #minetest-dev |
| 16:42 |
hmmmm |
TenPlus1: I have not seen a single backtrace. At all. Can you point me to this backtrace on the forums or on github you speak of? |
| 16:42 |
hmmmm |
This is hilarious and pathetic at the same time... why are so many regular players running debug builds? and none of them seem to know how to run minetest in gdb |
| 16:43 |
hmmmm |
definitely not our fault. debug builds are for developers, not regular players. if you don't like the crashing, why use a version that's built for testing/debugging purposes only? |
| 16:44 |
rubenwardy |
because when Minetest segfaults so much, you want to be able to make tracebacks so developers can fix it |
| 16:44 |
rubenwardy |
It doesn't do that so much anymore |
| 16:44 |
hmmmm |
on production servers?? |
| 16:44 |
rubenwardy |
but it did just before 0.4.13 |
| 16:45 |
hmmmm |
that's because I stopped people from shit committing code and focus on bug squashing |
| 16:46 |
hmmmm |
but anyway I still don't get it. people want to run debug versions to provide backtraces, yet nobody knows how to get a backtrace |
| 16:46 |
|
misprint joined #minetest-dev |
| 16:58 |
|
est31 joined #minetest-dev |
| 17:00 |
est31 |
hmmmm, about https://github.com/kwolekr/minetest/commit/53ba9a16c086bb5d2da49fdd37ce791f335501e0 |
| 17:00 |
est31 |
cant review it right now, but the general idea is very good like it |
| 17:01 |
nrzkt |
hmmmm: can you explain a little bit more what your commit does in the commit desc please ? It's a huge commit to review, many things are trivial to review but we need to have more ideas :) |
| 17:02 |
hmmmm |
it's just a huge refactoring |
| 17:02 |
hmmmm |
too many things to list honestly |
| 17:02 |
hmmmm |
the EmergeManager and EmergeThread now have clean and consistent interfaces |
| 17:03 |
hmmmm |
and it also adds the concept of emerge callbacks |
| 17:03 |
nrzkt |
this should be added to commit desc :) |
| 17:03 |
est31 |
I always do a list of "->"s |
| 17:03 |
est31 |
or 1. 2. 3. |
| 17:03 |
hmmmm |
those things are already |
| 17:03 |
est31 |
either way gtg |
| 17:04 |
|
Zeitgeist_ joined #minetest-dev |
| 17:04 |
rubenwardy |
how much testing have you done? |
| 17:05 |
hmmmm |
enough |
| 17:05 |
hmmmm |
it works |
| 17:07 |
hmmmm |
it'd probably be much easier to review using a side-by-side diff instead of a unified version. |
| 17:07 |
hmmmm |
much of it is also simply renaming and moving things around too |
| 17:11 |
|
T4im joined #minetest-dev |
| 18:15 |
rubenwardy |
I view in side-by-side by default now XD |
| 18:33 |
|
Soni joined #minetest-dev |
| 18:48 |
|
Amaz joined #minetest-dev |
| 19:00 |
|
est31 joined #minetest-dev |
| 19:18 |
|
zupoman joined #minetest-dev |
| 19:21 |
est31 |
about #3221 i'm not sure what to add/not add to the settings menu |
| 19:21 |
ShadowBot |
https://github.com/minetest/minetest/issues/3221 -- Add viewing range GUI setting by kilbith |
| 19:21 |
est31 |
so I can't really +-1 here. |
| 19:26 |
|
ottodachshund joined #minetest-dev |
| 19:28 |
|
Anchakor_ joined #minetest-dev |
| 19:29 |
hmmmm |
is there an enumeration of all APIs that place nodes? |
| 19:31 |
|
Player-2 joined #minetest-dev |
| 19:32 |
|
Fritigern joined #minetest-dev |
| 19:32 |
|
cheapie joined #minetest-dev |
| 19:32 |
est31 |
minetest has only one API hmmmm |
| 19:32 |
est31 |
its the "minetest" lua table |
| 19:32 |
est31 |
or "core" |
| 19:32 |
|
VargaD joined #minetest-dev |
| 19:32 |
hmmmm |
wow you pedantic fuck |
| 19:32 |
hmmmm |
API function :) |
| 19:33 |
est31 |
API is just a so general term |
| 19:33 |
est31 |
I mean I know what you mean, but perhaps others dont |
| 19:33 |
est31 |
and it took a while until I realized what you mean with "API" |
| 19:34 |
est31 |
either way, dunno rly |
| 19:34 |
est31 |
I just know set_node, the voxelmanip stuff then the schematics, perhaps more. |
| 19:35 |
est31 |
and ofc high level stuff like place_node or dig_node |
| 19:35 |
hmmmm |
yeah nevermind, i found a better way to phrase it anyway :) |
| 19:37 |
hmmmm |
https://github.com/kwolekr/minetest/commit/1f9c5a4a7b15ab49e717d81162fe58e4202c0814 |
| 19:37 |
hmmmm |
pushing if no objection |
| 19:37 |
est31 |
objection! |
| 19:37 |
* est31 |
lookin first |
| 19:37 |
hmmmm |
what, are you phoenix wright or something |
| 19:38 |
est31 |
okay for me |
| 19:38 |
* T4im |
nods too |
| 19:39 |
est31 |
okay now to the emerge commit |
| 19:39 |
est31 |
https://github.com/kwolekr/minetest/commit/53ba9a16c086bb5d2da49fdd37ce791f335501e0 |
| 19:39 |
est31 |
what was the criterion to reorder the #include s? |
| 19:40 |
hmmmm |
alphabetical order? |
| 19:40 |
est31 |
okay makes sense |
| 19:40 |
hmmmm |
the way I do it anymore is |
| 19:40 |
hmmmm |
C headers |
| 19:40 |
hmmmm |
C++ headers |
| 19:40 |
hmmmm |
headers in subdirectories |
| 19:40 |
hmmmm |
regular headers |
| 19:40 |
hmmmm |
err the very first header is the .h for the current file |
| 19:41 |
est31 |
perhaps it should be documented somewhere |
| 19:41 |
hmmmm |
something that nitpicky is not a code rule.. |
| 19:41 |
est31 |
well, shrug |
| 19:41 |
est31 |
next thing: isn't the m_ prefix only used for private members? |
| 19:41 |
hmmmm |
yeah |
| 19:42 |
est31 |
these are all public: https://github.com/kwolekr/minetest/commit/53ba9a16c086bb5d2da49fdd37ce791f335501e0#diff-1dc3934293fad6b8769890134ac51c21L66 |
| 19:42 |
est31 |
better do m_server → server |
| 19:45 |
est31 |
yeah seeing that the container for the emerge threads was called "emergethread" really freaked me out great you renamed it |
| 19:51 |
hmmmm |
here's the newest version https://github.com/kwolekr/minetest/commit/9d55e86a8d543af202a189574f0548c52ea43586 |
| 20:08 |
est31 |
why does EmergeManager need pushBlockEmergeData and popBlockEmergeData? |
| 20:08 |
est31 |
I mean why can't the BlockEmergeData directly be pushed to the threads |
| 20:09 |
est31 |
This would spare the map lookups |
| 20:09 |
est31 |
(and additions + deletions) |
| 20:09 |
hmmmm |
because it's used for checking uniqueness |
| 20:12 |
est31 |
why does pushBlockEmergeData return true even if update_existing == true? |
| 20:13 |
hmmmm |
because neither case is a failure |
| 20:19 |
|
paramat joined #minetest-dev |
| 20:20 |
est31 |
btw hmmmm why do you replace /**/ with #if 0 ? |
| 20:21 |
Calinou |
shouldn't #if 0 be avoided entirely? |
| 20:21 |
est31 |
well its neccessary |
| 20:21 |
hmmmm |
because #if 0 won't mess up nested block comments |
| 20:21 |
est31 |
because /**/ can't be done with multiple levels |
| 20:22 |
est31 |
but still, the "lowest" level works for /**/ |
| 20:22 |
est31 |
and you can still surround /**/ with #if 0 |
| 20:22 |
hmmmm |
#if 0 also seems like a more formal way of saying "this piece of code is still relevant and it might be reenabled one day, don't remove very soon" |
| 20:23 |
paramat |
c 55 > maybe the ABM definition needs a flag for whether that behavior is enabled or not < optional abm catchup is needed, in all my uses of abms the catchup just caused problems |
| 20:23 |
|
younishd joined #minetest-dev |
| 20:25 |
est31 |
hmmmm, there is an indentation problem : https://github.com/kwolekr/minetest/commit/9d55e86a8d543af202a189574f0548c52ea43586#diff-ab005ad9757130721ffb66a09833090aR2387 |
| 20:26 |
hmmmm |
fixed |
| 20:26 |
hmmmm |
also a comment is misplaced in that same function |
| 20:27 |
hmmmm |
ironically enough it was like that to begin with.. i was going to move it to the correct location but i had forgotten |
| 20:28 |
est31 |
okay, the commit looks good. |
| 20:30 |
est31 |
good to merge |
| 20:32 |
hmmmm |
yea |
| 20:32 |
hmmmm |
ok done |
| 20:37 |
hmmmm |
PTAL |
| 20:37 |
hmmmm |
https://github.com/kwolekr/minetest/commit/ac527eda21ba7468578841fa24cf54d707b13ee3 |
| 20:44 |
paramat |
seems a good idea |
| 20:48 |
paramat |
from forum: "v6 ok, v7 just why, math wtf, indev what is even diffrent, singlenode ahhh I am falling and I can't get up, or move, or fly or place blocks." |
| 21:00 |
|
Icedream joined #minetest-dev |
| 21:01 |
hmmmm |
maybe they should've gotten lifealert |
| 21:02 |
paramat |
i guess 'include hidden' is for future use |
| 21:03 |
hmmmm |
do you think it should be part of the mainmenu api too |
| 21:04 |
paramat |
not sure, for use in other subgames? not sure how the bool will be used |
| 21:05 |
hmmmm |
dunno just trying to make things as flexible and universal as possible |
| 21:05 |
hmmmm |
do you think i should add a "include hidden" boolean to get_mapgen_names()? |
| 21:08 |
paramat |
not sure include hidden is needed yet, but i have no objection to it. we will still be able to select singlenode using .conf? |
| 21:08 |
hmmmm |
yes, and mods |
| 21:11 |
paramat |
well personally i wouldn't bother having include hidden at all, yet |
| 21:12 |
hmmmm |
updated version https://github.com/kwolekr/minetest/commit/9f25aba6c2c3a922ebe74c327e275e83fef1f6f6 |
| 21:17 |
paramat |
looks good |
| 21:23 |
|
Darcidride joined #minetest-dev |
| 21:26 |
hmmmm |
PTAL https://github.com/kwolekr/minetest/commit/5130dbce7b294c392733e93c05e2099786523342 |
| 21:27 |
nrzkt |
+1 |
| 21:28 |
paramat |
seems good |
| 21:30 |
|
proller joined #minetest-dev |
| 21:34 |
|
proller joined #minetest-dev |
| 21:43 |
paramat |
i might attempt to add a catchup bool to abms soon |
| 21:43 |
|
paramat left #minetest-dev |
| 21:50 |
|
est31 joined #minetest-dev |
| 21:53 |
est31 |
hmmmm, since you have time, does #3219 look good to you |
| 21:53 |
ShadowBot |
https://github.com/minetest/minetest/issues/3219 -- Add new ContentParamType2 "CPT2_DEGROTATE" by est31 |
| 21:56 |
hmmmm |
looks good |
| 21:57 |
hmmmm |
that's the plant rotation vanessae was talking about? |
| 21:57 |
hmmmm |
yeah that is definitely not facedir. |
| 21:57 |
est31 |
its only plant rotation |
| 21:57 |
hmmmm |
of course rotateAlongYAxis won't support that |
| 21:58 |
est31 |
paramat said about this I think that he will implement it but only if people ask for it |
| 21:58 |
hmmmm |
sounds fair enough |
| 22:07 |
est31 |
seems weblate has a merge conflict due to force pushes |
| 22:07 |
est31 |
or so |
| 22:08 |
est31 |
it claims to have commit fa53008cae557bad35849144fcfdc723f313e6cf, which doesnt exist anymore |
| 22:08 |
est31 |
well... |
| 22:15 |
est31 |
seems I'll have to resolve the conflict, and merge the translation updates now |
| 22:15 |
est31 |
a week early for this month |
| 22:24 |
|
celeron55 joined #minetest-dev |
| 22:26 |
|
Player_2 joined #minetest-dev |
| 22:26 |
|
Player-2 joined #minetest-dev |
| 22:28 |
|
Dumbeldor joined #minetest-dev |
| 22:29 |
|
Dumbeldor left #minetest-dev |
| 23:03 |
* est31 |
breaks bot |
| 23:03 |
* est31 |
runs away |
| 23:04 |
OldCoder |
Is a forums admin present? I'd like to avoid things getting out of hand there |
| 23:05 |
OldCoder |
sfan5 is probably asleep and Vanessa is unable to be present as much as before |
| 23:11 |
|
DFeniks joined #minetest-dev |
| 23:27 |
|
paramat joined #minetest-dev |
| 23:30 |
paramat |
will merge fairly trivial fixes game#695 soon |
| 23:30 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/695 -- Flowers: Allow placing waterlily on river water by paramat |
| 23:30 |
|
est31 joined #minetest-dev |
| 23:30 |
est31 |
celeron55, you around? |
| 23:31 |
est31 |
if yes, can you kick MinetestBot from #minetest? |
| 23:31 |
|
proller joined #minetest-dev |
| 23:31 |
est31 |
thanks |
| 23:33 |
paramat |
lol |
| 23:34 |
waressearcher2 |
why MinetestBot is not here ? |
| 23:55 |
|
est31 joined #minetest-dev |
| 23:55 |
est31 |
can anybody review https://github.com/est31/minetest/commit/39f32a3037d7050e9f6a3b1b358f345892584de0 |
| 23:56 |
est31 |
its a better fix than #3115 |
| 23:56 |
ShadowBot |
https://github.com/minetest/minetest/issues/3115 -- Split large fgettext call by JakubVanek |
| 23:58 |
|
Ardonel joined #minetest-dev |
