| Time |
Nick |
Message |
| 00:52 |
|
cib joined #minetest-dev |
| 01:06 |
|
SaphirePhenux_ joined #minetest-dev |
| 01:17 |
|
paramat joined #minetest-dev |
| 01:53 |
|
Player2 joined #minetest-dev |
| 02:26 |
|
cib0 joined #minetest-dev |
| 02:36 |
|
paramat left #minetest-dev |
| 02:45 |
|
JohnnyComeL8ly joined #minetest-dev |
| 03:02 |
|
Supertan1er2 joined #minetest-dev |
| 03:12 |
|
cib0 joined #minetest-dev |
| 04:03 |
|
sloantothebone joined #minetest-dev |
| 04:05 |
|
ShadowNinja joined #minetest-dev |
| 04:06 |
|
Guest56314 joined #minetest-dev |
| 05:14 |
|
paramat joined #minetest-dev |
| 05:46 |
|
ace joined #minetest-dev |
| 06:04 |
paramat |
Default/mapgen: Tune biome points for improved disribution #720 https://github.com/minetest/minetest_game/pull/720 |
| 06:04 |
|
paramat left #minetest-dev |
| 06:07 |
|
CraigyDavi joined #minetest-dev |
| 06:34 |
|
gtown joined #minetest-dev |
| 06:49 |
|
DFeniks joined #minetest-dev |
| 07:01 |
|
Hunterz joined #minetest-dev |
| 08:16 |
|
RealBadAngel joined #minetest-dev |
| 08:19 |
|
nrzkt joined #minetest-dev |
| 08:20 |
|
sloantothebone joined #minetest-dev |
| 08:29 |
hmmmm |
PTAL https://github.com/kwolekr/minetest/commit/e96f7e662f1917979da3eff87077d199c3484223 |
| 08:40 |
hmmmm |
new version: https://github.com/kwolekr/minetest/commit/d52b6d9a15451dd0a0b00f84f7d70a5a6639f3b7 |
| 08:43 |
hmmmm |
paramat: looks nice |
| 08:46 |
|
eeew joined #minetest-dev |
| 08:49 |
ShadowNinja |
hmmmm: Why not just use get_content_id instead of the constants? Also >globally scoped< a file local will do fine. |
| 08:51 |
ShadowNinja |
GTG now though, I'll look at it closer later if it isn't merged by then. |
| 08:55 |
hmmmm |
because constants don't hurt and they're a lot easier to reference than "the result of minetest.get_content_id("ignore")" |
| 09:00 |
|
Krock joined #minetest-dev |
| 09:11 |
|
jin_xi joined #minetest-dev |
| 09:29 |
|
Megaf_ joined #minetest-dev |
| 09:39 |
|
Calinou joined #minetest-dev |
| 10:18 |
|
PilzAdam joined #minetest-dev |
| 10:20 |
|
FR^2 joined #minetest-dev |
| 10:39 |
|
blaze joined #minetest-dev |
| 10:44 |
celeron55 |
i've been working on the FarMesh successor for a few days now |
| 10:45 |
|
proller joined #minetest-dev |
| 10:45 |
celeron55 |
i think this is turning out just fine |
| 10:46 |
celeron55 |
oh... actually, more like a week |
| 10:47 |
celeron55 |
well, this better be good or i'm totally wasting my time |
| 10:53 |
Calinou |
does it work with all C++ mapgens? |
| 10:53 |
Calinou |
ie. v5, v6, V7 |
| 10:58 |
|
deltib joined #minetest-dev |
| 11:07 |
celeron55 |
yeah, but all of those make very boring landscapes at large scale |
| 11:07 |
celeron55 |
and lua mapgens are too slow |
| 11:07 |
celeron55 |
however, the recent built-in watershed is quite good for this |
| 11:07 |
celeron55 |
that's what i'm using for testing |
| 11:13 |
celeron55 |
i mean, what i'm doing is enabling the server to efficiently transfer huge areas at low resolution and the client to efficiently render huge areas at low resolution; there's no special mapgen interface at least yet |
| 11:14 |
PilzAdam |
would it be possible that Lua mapgens supply extra hooks to generate data for clients necessary to use farmesh? |
| 11:15 |
celeron55 |
of course but i'm focusing on the client side and the protocol |
| 11:15 |
celeron55 |
if someone is interested on that side, they can do it later |
| 11:34 |
|
zupoman joined #minetest-dev |
| 11:34 |
|
zupoman joined #minetest-dev |
| 11:34 |
crazyR |
just a quick thought.. the thought of changing the formspecs has been brought up a fair few times. but no one really want to do it due to the amount of work involved.. and due to how many changes would be required by mods etc... I understand this next suggestion doesnt really solve that issue currently but what if we added an object based formspec api in a similar fasion to smart formspcs.... that way future changes to the formspecs would be |
| 11:34 |
crazyR |
easier to acheive.. in terms of not having to wait so long for mods to update there mods.... |
| 11:35 |
crazyR |
especially if each method used a table of variables instead of defining them ie fs_object:button(def) --do what ever end |
| 11:40 |
Hunterz |
thanks for addng server console :-) |
| 11:43 |
|
sloantothebone joined #minetest-dev |
| 12:20 |
celeron55 |
i wonder if map transfers should be prioritized globally or whether each client should get equal transfer budget |
| 12:20 |
|
gregorycu joined #minetest-dev |
| 12:20 |
celeron55 |
currently they are prioritized globally |
| 12:23 |
celeron55 |
what that causes is that when a new client comes in or a client is running or flying around, it gets full transfer capacity due to the nearby blocks being transferred and pushes back other clients as needed |
| 12:23 |
celeron55 |
i guess it makes a better experience |
| 12:24 |
celeron55 |
but there's a problem when trying to implement that when making a protocol that allows any client to request any block |
| 12:25 |
celeron55 |
because the server can't trust them to give any absolute priority to their blocks |
| 12:25 |
celeron55 |
someone could just increase it and get all the bandwidth for however far areas they want |
| 12:27 |
celeron55 |
i think i'll just give equal priority to every client and hope that it's fine for low-bandwidth servers |
| 12:33 |
|
sloantothebone_ joined #minetest-dev |
| 12:35 |
|
BlockMen joined #minetest-dev |
| 12:35 |
|
Darcidride_ joined #minetest-dev |
| 12:39 |
BlockMen |
is "looks good" equal to "+1"? |
| 12:40 |
|
sloantothebone_ joined #minetest-dev |
| 12:41 |
celeron55 |
i think it was decided that it isn't |
| 12:42 |
BlockMen |
ok, can someone check #3288 then? |
| 12:42 |
BlockMen |
https://github.com/minetest/minetest/pull/3288 |
| 12:47 |
celeron55 |
i guess those essentially mean +1 though; we _really_ need to define what all these mean |
| 12:47 |
|
sloantothebone_ joined #minetest-dev |
| 12:48 |
gregorycu |
Why isn't this a first class concept in github? |
| 12:48 |
celeron55 |
i have no idea; it's indeed a bit lacking |
| 12:48 |
BlockMen |
IMO we should use something like "good to merge", that would be clear |
| 12:48 |
celeron55 |
BlockMen: when does this sound play in practice? |
| 12:49 |
BlockMen |
whenever the client does not allow to place a node, e.g. where you are standing |
| 12:49 |
BlockMen |
the serverside is not touched |
| 12:50 |
celeron55 |
i know that; so the question is when does the client know that a node can't be placed |
| 12:52 |
BlockMen |
when nodePlacementPrediction returns false, see https://github.com/minetest/minetest/blob/master/src/game.cpp#L889 |
| 12:53 |
gregorycu |
celeron55: How do you feel about splitting up the algo that decides what blocks to draw, vs what blocks the server should send? |
| 12:53 |
celeron55 |
looks like it's only a few special cases; 1) the mapblock where the node is being placed isn't loaded, 2) the node being pointed is not buildable_to, 3) the node being placed is attached_node and the pointed node is not walkable, 4) the node is being placed where the player is standing |
| 12:53 |
|
kilbith joined #minetest-dev |
| 12:54 |
BlockMen |
celeron55, the other cases can be done by mods |
| 12:55 |
celeron55 |
does it make sense that the sound is defined by the node being placed and not by something else |
| 12:55 |
gregorycu |
You think the pointed-to node? |
| 12:56 |
gregorycu |
(As an example) |
| 12:56 |
celeron55 |
what kind of sound is that even |
| 12:56 |
BlockMen |
its equivalent to the place sound (which is also defined by the node going to be placed) |
| 12:57 |
BlockMen |
i would use some "error" sound, but you dont have to use it. it is just adding the ability to get feedback (as requested) |
| 12:58 |
gregorycu |
Could an alternative idea for the ability to play an arbitrary sound at any stage? And users can hook node placement failure and do whatever they want (which may include a sound) |
| 12:58 |
celeron55 |
ok that makes sense; i can imagine that for example just a lower or higher pitch variant of the normal sound would make sense |
| 13:01 |
|
ElectronLibre joined #minetest-dev |
| 13:01 |
celeron55 |
that isn't going to fit in a 23-line patch |
| 13:03 |
|
cib0 joined #minetest-dev |
| 13:14 |
|
kilbith left #minetest-dev |
| 13:20 |
gregorycu |
Given that the current frustrum culling is a bit buggy, why doesn't minetest just use the built in frustum culling that's part of irrlicht? |
| 13:21 |
celeron55 |
because minetest does other things alongside it that irrlicht doesn't do |
| 13:22 |
celeron55 |
and there might be some specialization in it anyway; irrlicht is not a boxel engine |
| 13:23 |
celeron55 |
for one, minetest doesn't update the list of blocks to be rendered on every frame, and it does software occlusion culling |
| 13:23 |
celeron55 |
i mean, this is not a thing that is just there "because random" like many things are |
| 13:24 |
gregorycu |
I figured that a reason is that the server uses exactly the same logic to determine what to send |
| 13:24 |
gregorycu |
Wasn't sure if that was the end of it |
| 13:24 |
celeron55 |
the server doesn't know the client's FOV |
| 13:24 |
celeron55 |
that's an issue |
| 13:24 |
celeron55 |
i'm probably removing that particular piece of code though; now stop asking so that i can code |
| 13:25 |
Calinou |
fov = 170 |
| 13:25 |
Calinou |
8) |
| 13:25 |
celeron55 |
nothing progresses when we just talk here |
| 13:25 |
gregorycu |
Are you redoing the server side stuff? Or also the client side frustum |
| 13:25 |
celeron55 |
go fix a bug |
| 13:25 |
gregorycu |
I am |
| 13:25 |
celeron55 |
no you aren't; you are talking! |
| 13:26 |
gregorycu |
I'd prefer to talk before starting dev, rather than after and get "why the hell did you do that" |
| 13:27 |
celeron55 |
well don't touch that now, it's pretty close to what i'm wiggling around currently |
| 13:28 |
gregorycu |
Ok, I'll do something else |
| 13:41 |
|
o_O joined #minetest-dev |
| 13:45 |
|
Fixer joined #minetest-dev |
| 13:58 |
|
ElectronLibre joined #minetest-dev |
| 14:17 |
BlockMen |
mergin now #3288 |
| 14:21 |
|
gregorycu_ joined #minetest-dev |
| 14:22 |
|
jin_xi joined #minetest-dev |
| 14:24 |
|
zat joined #minetest-dev |
| 14:25 |
|
gregorycu joined #minetest-dev |
| 14:34 |
|
kaeza joined #minetest-dev |
| 15:18 |
|
rubenwardy joined #minetest-dev |
| 15:20 |
|
Taoki joined #minetest-dev |
| 15:54 |
|
est31 joined #minetest-dev |
| 16:02 |
est31 |
about the client requesting blocks from the server principle vs. the server deciding what to send. In the setup with the client asking, we can't really implement any occlusion culling. If there was, it would be slowed down by the factor (network ping time) * (viewing range). Because, the client doesn't know whether the block ahead of it is transparent or has non-transparent holes. So it has to wait for the server to send the block, and only once |
| 16:02 |
est31 |
its there, it can decide whether to request the block behind it, or whether to decide the block behind it is occluded, and not request anything. |
| 16:03 |
est31 |
I know that ppl like PilzAdam want the client to request them, but I think the use cases can be solved by changing the protocol at other points. |
| 16:04 |
est31 |
just my 2 cents. |
| 16:22 |
|
hmmmm joined #minetest-dev |
| 16:39 |
celeron55 |
http://i.imgur.com/8UfG4Sy.jpg |
| 16:39 |
celeron55 |
this may not be the prettiest forest renderer... |
| 16:39 |
celeron55 |
...but that fog stops at 1000 nodes |
| 16:40 |
nrzkt |
strange leaves :p |
| 16:41 |
celeron55 |
wait, no; 800 nodes |
| 16:50 |
hmmmm |
thought you were working on client side modding |
| 16:51 |
Calinou |
would it be possible to have transparent water? |
| 16:52 |
|
celeron55 joined #minetest-dev |
| 16:56 |
hmmmm |
I advocate not having client request blocks |
| 16:56 |
hmmmm |
I used to from a design standpoint, but practicality ultimately wins here |
| 16:56 |
hmmmm |
the server has nearly all of the information it needs |
| 17:00 |
hmmmm |
merged https://github.com/minetest/minetest/commit/f9e394a4669e667fcef8992946458c769b4e2770 |
| 17:00 |
hmmmm |
hopefully people can get off my back now |
| 17:03 |
celeron55 |
i'm effectively making a client-requests-blocks system now though; it's fine |
| 17:03 |
hmmmm |
well |
| 17:03 |
celeron55 |
the server doesn't have much time to do any fancy occlusion culling or stuff like that anyway |
| 17:04 |
hmmmm |
i wanted to modify the current system so that it lowers the priority of blocks that are completely transparent |
| 17:04 |
hmmmm |
i hope this could become accomodated somehow |
| 17:06 |
celeron55 |
it doesn't really matter who invokes the server to check if a block is transparent, the server itself or the client |
| 17:06 |
celeron55 |
this is a non-concern |
| 17:09 |
celeron55 |
of course i'll change it if it doesn't work, but it seems to work |
| 17:12 |
|
DFeniks joined #minetest-dev |
| 17:16 |
celeron55 |
there are good and bad sides in both solutions actually |
| 17:17 |
celeron55 |
practically thinking, that is |
| 17:17 |
celeron55 |
it comes from the fact that the algorithm needs information from both the server and the client, no matter which one it is running on |
| 17:18 |
celeron55 |
and that information includes more from the client side than just a position |
| 17:18 |
celeron55 |
or just the things that would be sent anyway |
| 17:23 |
|
PilzAdam joined #minetest-dev |
| 17:36 |
celeron55 |
here's a watershed mountain: http://i.imgur.com/DIsRLbl.jpg |
| 17:39 |
rubenwardy |
that's cool |
| 17:39 |
rubenwardy |
what's the bottleneck now, stopping you looking further? Mapgen? |
| 17:39 |
Krock |
Fancy stuff |
| 17:40 |
celeron55 |
mapgen mostly; it doesn't trigger mapgen yet at all |
| 17:41 |
rubenwardy |
I see |
| 17:41 |
celeron55 |
of course generating that far is very slow especially as transfer is symmetrical to all directions in true minetest fashion |
| 17:41 |
celeron55 |
and transferring and mesh generation that far does take minutes |
| 17:42 |
rubenwardy |
even at a lower LOD? |
| 17:42 |
celeron55 |
or, well i suppose the bottleneck in loading time is the server that doesn't save anything on disk to speed up loading |
| 17:42 |
celeron55 |
that is the best LOD; worse isn't faster in practice |
| 17:42 |
celeron55 |
it's going to be static because nothing else makes any sense |
| 17:43 |
rubenwardy |
does the server send the whole block and the client lowers the res, or is the lower res done on the server? |
| 17:43 |
celeron55 |
the server generates the low-resolution blocks |
| 17:43 |
rubenwardy |
awesome |
| 17:43 |
celeron55 |
they are called FarBlocks and their size is 8x8x8 MapBlocks |
| 17:44 |
celeron55 |
that again is probably the only size that makes sense |
| 17:44 |
|
PilzAdam joined #minetest-dev |
| 17:51 |
Calinou |
doesn't it generate a lot of load on server-side? |
| 17:51 |
celeron55 |
yes |
| 17:51 |
celeron55 |
a lot of load and lagginess with my current implementation that isn't intended for real use |
| 17:52 |
celeron55 |
it probably needs caching |
| 17:52 |
hmmmm |
you're really good at making quick prototypes of advanced features but you never polish those features |
| 17:53 |
hmmmm |
and they remain very slow or have some kind of subtle bug |
| 17:53 |
hmmmm |
please, deliver a whole product |
| 17:55 |
celeron55 |
we'll see |
| 17:55 |
hmmmm |
as I've said before, anybody can code but not everybody can make a solid, well-designed, flexible implementation of a feature |
| 17:56 |
hmmmm |
i don't mean any offense to RBA, but look at him as an example of this |
| 17:56 |
hmmmm |
he codes all these flashy things, pushes them half-assed and as-is, and then expects the rest of us to polish the turd |
| 17:56 |
celeron55 |
lol |
| 17:56 |
celeron55 |
that is an offence to me though |
| 17:56 |
celeron55 |
offense* |
| 17:57 |
hmmmm |
meanwhile he walks away with all the internet praise |
| 17:58 |
celeron55 |
why are you telling this to me when i am showing an alpha version? |
| 17:58 |
celeron55 |
you can trust me for sure |
| 17:59 |
celeron55 |
there are people you shouldn't trust; i find it silly and annoying that you consider me one |
| 17:59 |
celeron55 |
it's like you'll tear this whole project apart if i push something upstream without your precious permission first |
| 18:00 |
hmmmm |
it's not *my* permission, I just happen to be around a lot of the time |
| 18:00 |
celeron55 |
i appreciate the quality control, but you don't have to remind me of it all the time |
| 18:00 |
celeron55 |
i get it |
| 18:00 |
celeron55 |
do you get it that i get it? |
| 18:01 |
hmmmm |
ok mister "I need smart pointers because my code keeps segfaulting on me" |
| 18:01 |
celeron55 |
even if i push something half-assed, i do it with the full knowledge that it will make people miserable |
| 18:01 |
celeron55 |
there are people who will push shit without understanding what it causes |
| 18:02 |
hmmmm |
i try my best to prevent this from happening but it's inevitable sometimes |
| 18:03 |
hmmmm |
we should get back to coding |
| 18:04 |
celeron55 |
well, i've coded for 9 hours straight already so i kind of need a break already 8) |
| 18:04 |
hmmmm |
that is admirable focus |
| 18:06 |
celeron55 |
admirable lack of real work |
| 18:09 |
celeron55 |
this is hard as fuck compared to anything though |
| 18:09 |
celeron55 |
hmmmm: can you tell me how all the server's things are currently supposed to be locked these days? |
| 18:09 |
celeron55 |
because it's one thing that has changed a lot |
| 18:10 |
hmmmm |
conlock is sort of an obsolete thing i believe since those operations are totally encapsulated in connection.cpp |
| 18:10 |
hmmmm |
envlock needs to be practically everywhere and it already is |
| 18:10 |
hmmmm |
scriptlock is only active inside of the on_foobar() callbacks, from SCRIPTAPI_PRECHECKHEADER to the end of the scope it's defined in |
| 18:11 |
hmmmm |
envlock always needs to be locked before scriptlock |
| 18:11 |
|
rubenwardy joined #minetest-dev |
| 18:11 |
hmmmm |
and that's it |
| 18:13 |
|
A_noob joined #minetest-dev |
| 18:13 |
celeron55 |
i suppose the best way to generate something on the server side from map data is to grab a big chunk into a VoxelManipulator and throw it into a worker thread |
| 18:13 |
hmmmm |
huh? |
| 18:14 |
hmmmm |
in any case, I hope you're not going to bring back map generation in the serverthread... |
| 18:14 |
celeron55 |
WTF :D |
| 18:14 |
hmmmm |
remember that? |
| 18:14 |
celeron55 |
this is already absurd |
| 18:14 |
hmmmm |
generateBlock() |
| 18:14 |
celeron55 |
stop it |
| 18:14 |
celeron55 |
stop it! |
| 18:14 |
hmmmm |
anyway |
| 18:15 |
hmmmm |
what are you doing with generating now? |
| 18:15 |
hmmmm |
it might be a good idea to throw it into an EmergeThread and then resume what you're doing upon emerge completion |
| 18:15 |
celeron55 |
i need to generate low-resolution map data (FarBlocks) from the high-resolution normal map data (MapBlocks); and that is done in chunks of 8x8x8 MapBlocks |
| 18:16 |
celeron55 |
and uses a special algorithm that does tricks to figure out how to best represent the map in low resolution |
| 18:16 |
hmmmm |
and these FarBlocks are not being stored on disk, right? |
| 18:16 |
celeron55 |
i don't intend to, but i don'ẗ know what people end up wanting |
| 18:17 |
hmmmm |
well |
| 18:17 |
celeron55 |
that would allow quite glorious resumption of singleplayer games, but it's out of scope for me at the moment |
| 18:17 |
hmmmm |
I am pretty sure this operation will need to be done completely under envlock |
| 18:17 |
hmmmm |
since you're accessing 512 mapblocks in a single operation |
| 18:18 |
hmmmm |
how slow is the actual downscaling algorithm? |
| 18:18 |
hmmmm |
what is the downscaling algorithm, first of all |
| 18:19 |
celeron55 |
well it's not exactly blazing fast as it needs to figure out how to scale down 2097152 nodes |
| 18:19 |
celeron55 |
it doesn't read all of them but some |
| 18:20 |
celeron55 |
i guess essentially it's as slow as a fast map generator |
| 18:21 |
hmmmm |
the result from your algorithm represents an 8x8x8 chunk of mapblocks but that doesn't mean it actually needs to downscale all the nodes |
| 18:22 |
hmmmm |
this is just going to operate on each of the 6 faces of this region, right? |
| 18:22 |
hmmmm |
so really the worst case should be (8 * 16)^3 |
| 18:22 |
hmmmm |
* 6 |
| 18:23 |
hmmmm |
errm i mean (8*16)^2 * 6 |
| 18:23 |
celeron55 |
it operates on volumes but is mostly interested in figuring out how the topside of each 4x4x4 chunk of nodes looks like |
| 18:24 |
hmmmm |
my concern is that this sounds really heavyweight and we're going to be spending a lot more server time than necessary on this operation |
| 18:24 |
celeron55 |
currently it iterates through one Y column, finding a surface and then based on that data it guesses something |
| 18:24 |
celeron55 |
it needs more to lessen the prominence of tree trunks and other thin objects |
| 18:25 |
celeron55 |
anyway, the value you are looking for is a few hundred milliseconds |
| 18:25 |
hmmmm |
and whether it's copying 512 mapblocks to a voxelmanipulator and doing lockless operations or whatever, i suspect a significant amount of time will be spent slowing everything else down |
| 18:27 |
celeron55 |
i'm not going to do it synchronously if i can avoid it |
| 18:27 |
celeron55 |
but the prerequisite to that is being able to copy 8x8x8 MapBlocks with considerably less time than that |
| 18:27 |
celeron55 |
i guess adding this to be done inside emergethread as it loads and generates stuff would work fine |
| 18:27 |
celeron55 |
it can be done incrementally one mapblock at a time as the data is kept around as a cache anyway |
| 18:28 |
hmmmm |
that actually sounds fine to me |
| 18:28 |
hmmmm |
the emergethread is pretty much the perfect place to add this |
| 18:29 |
celeron55 |
one thing that isn't wise is generating this from the 512 mapblocks when the client asks it or the server decides to send it for some other reason, even if the data was cached in the mapblocks itself |
| 18:29 |
celeron55 |
or, at least i suppose si |
| 18:29 |
celeron55 |
so* |
| 18:30 |
|
technics joined #minetest-dev |
| 18:30 |
celeron55 |
a parallel FarMap/FarSector/FarBlock thing is probably wisest as then all the data is in exactly organized in the format that has to be sent to the client; it's then just a matter of doing one lookup and telling the networkings to throw it on the wire |
| 18:31 |
hmmmm |
omit the FarSector perhaps |
| 18:31 |
hmmmm |
MapSector is a relic of the past. it does not make sense to have this data structure in modern minetest. |
| 18:33 |
celeron55 |
well, i suppose so |
| 18:33 |
celeron55 |
it would be a good place to do some Y-wise optimization but as we kind of try to avoid those, it's useless |
| 18:47 |
celeron55 |
funnily enough one of the slowest things FarMap has to do is rendering fill-ins for the transition from MapBlocks to FarBlocks |
| 18:48 |
celeron55 |
essentially MapBlock meshes with FarBlock mesh content; very small meshes but just as many as there are MapBlocks which slows it down |
| 18:48 |
celeron55 |
i need to test whether 4x4x4 would be better than 8x8x8 due to that; but i don't really like the idea |
| 18:53 |
celeron55 |
well, i think it'll be fine; maybe i'll restrict MapBlock rendering to 2x2x2 MapBlock chunks to get rid of the unnecessarily small things |
| 18:53 |
hmmmm |
why does this matter? |
| 18:53 |
hmmmm |
just make it a config option and let other people tune it for you |
| 18:55 |
celeron55 |
it matters because if i can determine that something isn't needed at all, there doesn't need to be an option for it |
| 18:55 |
celeron55 |
of course this whole thing is optional to begin with because i'm sure some people will absolutely hate it |
| 18:55 |
celeron55 |
personally i already absolutely love it |
| 19:05 |
|
Fixer joined #minetest-dev |
| 19:09 |
celeron55 |
it's like a large part of buildat was actually useful after all, as this is one of the features that i originally made for it |
| 19:09 |
celeron55 |
(while this doesn't use much of the same code at all) |
| 19:09 |
celeron55 |
it's the same concept and same tricks |
| 19:30 |
|
Fixer left #minetest-dev |
| 19:30 |
|
Fixer joined #minetest-dev |
| 20:11 |
|
RealBadAngel joined #minetest-dev |
| 20:19 |
celeron55 |
actually; it looks like 4x4x4 is simply not faster at all when rendering the kind of distances that i want to render |
| 20:20 |
celeron55 |
it's because while the mini-mapblock count goes radically down, the bulk FarBlock count goes even more radically up |
| 20:21 |
celeron55 |
and that's not good 8) |
| 20:46 |
celeron55 |
so |
| 20:46 |
celeron55 |
what's up with all these setting locations now |
| 20:47 |
celeron55 |
where's a script that i can use to update minetest.conf.example from builtin/settingtypes.txt or the other way around |
| 20:48 |
celeron55 |
not under util/ at least; i would have hoped to find one |
| 20:52 |
PilzAdam |
celeron55, that is still TODO |
| 20:53 |
PilzAdam |
look at the bottom of settings.lua |
| 20:53 |
PilzAdam |
in builtin/mainmenu |
| 20:55 |
PilzAdam |
I guess maybe we can just run tab_settings.lua from a shell script, and it generates minetest.conf.example if it detects that core is nil |
| 20:55 |
celeron55 |
also the simple settings menu should still be available |
| 20:56 |
PilzAdam |
yeah, I asked on the forums and most people would like to keep the old one |
| 20:56 |
PilzAdam |
although I think that we should reconsider which exact settings it should contain |
| 20:56 |
|
DFeniks joined #minetest-dev |
| 20:56 |
celeron55 |
yeah the content of it was quite random |
| 20:56 |
celeron55 |
but it would be better as-is than to have nothing |
| 20:59 |
|
kaeza joined #minetest-dev |
| 21:12 |
hmmmm |
advanced button |
| 21:12 |
kaeza |
greetings. having this issue since about a while ago: https://gist.github.com/kaeza/8b2d457c36cd52020501 |
| 21:12 |
kaeza |
can somebody with MinGW32 (sfan5) test? |
| 21:14 |
kaeza |
also, some warnings in case somebody cares: https://gist.github.com/kaeza/dec0af3158da63aa2c5d |
| 21:38 |
|
JohannesG joined #minetest-dev |
| 21:45 |
|
ElectronLibre left #minetest-dev |
| 21:51 |
|
rubenwardy joined #minetest-dev |
| 21:53 |
kaeza |
can somebody recommend a good (preferably open source) RTS? |
| 21:54 |
kaeza |
I'd settle for some crappy turn-based RPG |
| 21:55 |
kaeza |
but pls no Nethack or Battle for Wesnoth |
| 21:55 |
kaeza |
oops wrong chan |
| 21:55 |
kaeza |
sorry |
| 22:00 |
|
Fixer joined #minetest-dev |
| 23:20 |
|
paramat joined #minetest-dev |
| 23:20 |
paramat |
so good to see new farmesh |
| 23:21 |
paramat |
i tend to create huge structures so it will be very usable |
| 23:22 |
paramat |
reading logs.. |
| 23:24 |
paramat |
hmmmmm good vm docs, i learn a lot from this |
