Wishes for Minetest 0.4.11 (or 0.5)
- rubenwardy
- Moderator
- Posts: 6978
- Joined: Tue Jun 12, 2012 18:11
- GitHub: rubenwardy
- IRC: rubenwardy
- In-game: rubenwardy
- Location: Bristol, United Kingdom
- Contact:
Re: Wishes for Minetest 0.4.11 (or 0.5)
map_generation_limit in Minetest.conf. make sure you read the docs in Minetest.conf.example
- kaadmy
- Member
- Posts: 706
- Joined: Thu Aug 27, 2015 23:07
- GitHub: kaadmy
- IRC: KaadmY
- In-game: KaadmY kaadmy NeD
Re: Wishes for Minetest 0.4.11 (or 0.5)
Make what sizescalable? the 31000 node limit? Somebody correct me if i'm wrong, but you probably shouldn't change that.
Re: Wishes for Minetest 0.4.11 (or 0.5)
Should make sizeable cubes the next upgrade
o__l_ dpbqR o-l&&&&&
- iisu
- Member
- Posts: 220
- Joined: Tue Mar 28, 2017 20:13
- GitHub: iisu
- IRC: iisu
- In-game: iisu
- Location: Internet
Re: Wishes for Minetest 0.4.11 (or 0.5)
- Fix the rendering. viewtopic.php?f=3&t=16836
- Reduce the size of the map. Identify nodes with keys to a global dictionary hosting the node names rather than the names. An integer takes less space than a string like "default:stone". This is not only because of the storage, because storage is rather cheap, but also because you send this data to players and back and the fewer data you have to send on the network, the less lag there is. The current state of both size of the map on the dist and lags is pretty ok to me, surely not as serious as the problem above but if it could be improved why not improve it.
This is something that breaks compatibility with older clients so 0.5 is one of a limited number of occasions to do it.
- Hide ores from the client. Generate the terrain first and then generate the ores randomly, independent from the map's seed. This way players won't be able to use the same seed to generate them on singleplayer and then just mine straight to them on the server. (At least those rare ones like Nyans and mese blocks.) Send the player only the terrain when he requests a chunk, send the ores later when he can actually see them. This way if he tries to follow the same strategy as above on saved map data or use CSM do find the ores, he will only see stone/dirt etc. unless the ore has been within his sight before. This requires a better rendering first and may bring some more lag that hopefully will be balanced by reducing the size of the chunks sent to client.
Communication with the server would look like this:
1. Player requests to load the chunk
2. Server sends the chunk but without ores or anything else that requires hiding
2.a) Hidden nodes are now mocked with whatever is generated by the seed on their place
3. Player sends information about the camera position and rotation
4. Server finds all hidden nodes within player sight, given the camera position and rotation and sends them to the player
5. Player replaces the mocked nodes with those received from the server.
- Add option to treat some chunks as temporary and only store a limited number of such chunks, removing the oldest/least recently used of them when the limit is exceeded. Beyond the current map limits all chunks would be temporary, allowing for almost infinite wild worlds. This requires ores to be generated independently from the map seed as in previous suggestion, to avoid farming ores. Mods could be made to integrate with a protection mod and make all chunks except those intersecting with protected areas temporary chunks.
- Reduce the size of the map. Identify nodes with keys to a global dictionary hosting the node names rather than the names. An integer takes less space than a string like "default:stone". This is not only because of the storage, because storage is rather cheap, but also because you send this data to players and back and the fewer data you have to send on the network, the less lag there is. The current state of both size of the map on the dist and lags is pretty ok to me, surely not as serious as the problem above but if it could be improved why not improve it.
This is something that breaks compatibility with older clients so 0.5 is one of a limited number of occasions to do it.
- Hide ores from the client. Generate the terrain first and then generate the ores randomly, independent from the map's seed. This way players won't be able to use the same seed to generate them on singleplayer and then just mine straight to them on the server. (At least those rare ones like Nyans and mese blocks.) Send the player only the terrain when he requests a chunk, send the ores later when he can actually see them. This way if he tries to follow the same strategy as above on saved map data or use CSM do find the ores, he will only see stone/dirt etc. unless the ore has been within his sight before. This requires a better rendering first and may bring some more lag that hopefully will be balanced by reducing the size of the chunks sent to client.
Communication with the server would look like this:
1. Player requests to load the chunk
2. Server sends the chunk but without ores or anything else that requires hiding
2.a) Hidden nodes are now mocked with whatever is generated by the seed on their place
3. Player sends information about the camera position and rotation
4. Server finds all hidden nodes within player sight, given the camera position and rotation and sends them to the player
5. Player replaces the mocked nodes with those received from the server.
- Add option to treat some chunks as temporary and only store a limited number of such chunks, removing the oldest/least recently used of them when the limit is exceeded. Beyond the current map limits all chunks would be temporary, allowing for almost infinite wild worlds. This requires ores to be generated independently from the map seed as in previous suggestion, to avoid farming ores. Mods could be made to integrate with a protection mod and make all chunks except those intersecting with protected areas temporary chunks.
Roses are red, violets are blue. Omae wa mou shindeiru.
- sorcerykid
- Member
- Posts: 1847
- Joined: Fri Aug 26, 2016 15:36
- GitHub: sorcerykid
- In-game: Nemo
- Location: Illinois, USA
Re: Wishes for Minetest 0.4.11 (or 0.5)
I could be mistaken, but isn't that how it's already done internally? I thought the engine stores and indexes nodes using ContentIDs and the translation back to node names only occurs at the scripting interface.iisu wrote:Identify nodes with keys to a global dictionary hosting the node names rather than the names. An integer takes less space than a string like "default:stone".
Ores are already generated using seeds that are independent from the map seed. These seeds can be changed in default/mapgen.lua. As for the Nyan Cat, that's just a matter of supplying a different seed to the PsuedoRandom function in nyancat/init.lua.Generate the terrain first and then generate the ores randomly, independent from the map's seed. This way players won't be able to use the same seed to generate them on singleplayer and then just mine straight to them on the server. (At least those rare ones like Nyans and mese blocks.)
That sounds quite complicated, not to mention redundant since there would have to be two passes of data sent to the client. Currently, I believe the client receives all chunks within a given range, and there is no way for the server to "know" (or even predict) what nodes are visible to the client at any time during the rendering phase without some type of some very sophisticated heuristics. Handing player movements and interactions with the environment as well as mapblock sends and Lua callbacks is already taxing enough for the CPU without adding line of sight calculations.Send the player only the terrain when he requests a chunk, send the ores later when he can actually see them. This way if he tries to follow the same strategy as above on saved map data or use CSM do find the ores, he will only see stone/dirt etc. unless the ore has been within his sight before.
Anyway, don't take my criticisms the wrong way. You've pointed out some important issues. And I do wish we could devise an almost foolproof anticheat solution. But this might not be the most practical way to accomplish it.
- iisu
- Member
- Posts: 220
- Joined: Tue Mar 28, 2017 20:13
- GitHub: iisu
- IRC: iisu
- In-game: iisu
- Location: Internet
Re: Wishes for Minetest 0.4.11 (or 0.5)
Yes but if I understand it correctly, ContentIDs are local for every chunk so every chunk stores the names of each different kind of node it stores. I don't see a reason to do it but maybe there is some, anyways the long name strings are stored in the chunks where there could be a global dictionary to store them all once for an entire map.sorcerykid wrote:I could be mistaken, but isn't that how it's already done internally? I thought the engine stores and indexes nodes using ContentIDs and the translation back to node names only occurs at the scripting interface.iisu wrote:Identify nodes with keys to a global dictionary hosting the node names rather than the names. An integer takes less space than a string like "default:stone".
That's what I thought but I wasn't sure of. Good to hear this is already implemented.sorcerykid wrote:Ores are already generated using seeds that are independent from the map seed. These seeds can be changed in default/mapgen.lua. As for the Nyan Cat, that's just a matter of supplying a different seed to the PsuedoRandom function in nyancat/init.lua.
Again, I'm not sure how it currently works but I think if a node is generated from the seed and untouched there's no need to save it at all as it can be calculated from the same seed on the fly. At least it sounds reasonable. If that's the case, there shouldn't be any redundant data.sorcerykid wrote:That sounds quite complicated, not to mention redundant since there would have to be two passes of data sent to the client.Send the player only the terrain when he requests a chunk, send the ores later when he can actually see them. This way if he tries to follow the same strategy as above on saved map data or use CSM do find the ores, he will only see stone/dirt etc. unless the ore has been within his sight before.
If the node is natural and not hidden, nothing is sent because nothing is saved.
If the node is different from the seed but is not hidden, the data is sent once every time the client requests to load the chunk.
If the node is hidden, whether generated or placed by another player, the data is sent once every time the client informs the server about its camera movement but only if the node is within player's view. Client receives no data when loading a chunk so it calculates the node from the seed. This way if you try to mine the data that you receive from the server using external programs, hacks or CSM, you will not see any more than you should.
Actually that means less data will be sent in the chunks but the difference will be sent later in smaller packets like it is sent when mining. You don't send and receive a whole chunk every time you mine a node, don't you?
Also, it only makes sense to hide rare nodes like Nyans, mese blocks and maybe diamonds and mese crystals. Modders might want to hide some of their rare resources like mithril as well.
I agree that recalculating the scene on server side for every client may be quite heavy. Maybe it should be disabled on default if it turns out to be too heavy, letting server owners decide whether to enable it on their machines. If the server runs on a better computer that can handle this and defense against cheating is important to the server owner why not give him this possibility.
Roses are red, violets are blue. Omae wa mou shindeiru.
Re: Wishes for Minetest 0.4.11 (or 0.5)
my wish for 0.5 is for sofar's entity_ai mod completed and merged into MTG
Hey, what can i say? I'm the bad guy.
-
- Member
- Posts: 818
- Joined: Tue Apr 14, 2015 01:59
- GitHub: raymoo
- IRC: Hijiri
- In-game: Raymoo + Clownpiece
Re: Wishes for Minetest 0.4.11 (or 0.5)
There are global ContentIDs too. These are the IDs you get in VoxelManips etc, and these are the IDs that are used to represent the node in memory.iisu wrote:Yes but if I understand it correctly, ContentIDs are local for every chunk so every chunk stores the names of each different kind of node it stores. I don't see a reason to do it but maybe there is some, anyways the long name strings are stored in the chunks where there could be a global dictionary to store them all once for an entire map.sorcerykid wrote:I could be mistaken, but isn't that how it's already done internally? I thought the engine stores and indexes nodes using ContentIDs and the translation back to node names only occurs at the scripting interface.iisu wrote:Identify nodes with keys to a global dictionary hosting the node names rather than the names. An integer takes less space than a string like "default:stone".
Every time a mod API is left undocumented, a koala dies.
Re: Wishes for Minetest 0.4.11 (or 0.5)
I really want options to up the graphics. Shaders have been something many in the MT community have wanted for a while now.
I also love the polish in the latest version of Minetest, keep up the good work, Random Bunch Of Lunatics!
I also love the polish in the latest version of Minetest, keep up the good work, Random Bunch Of Lunatics!
I test mines.
-
- Member
- Posts: 190
- Joined: Mon Jan 02, 2017 21:00
- GitHub: Sires0
- IRC: Sires
- In-game: Sires Sores Siri Seris or anything ppl call me
- Location: :noitacoL
Re: Wishes for Minetest 0.4.11 (or 0.5)
"How to start an endless discussion about is something worth or not making with Sires :D"
*cough cough*
Colored lights
*cough cough*
*cough cough*
Colored lights
*cough cough*
I don't have anything important to say.
Re: Wishes for Minetest 0.4.11 (or 0.5)
Sires wrote:"How to start an endless discussion about is something worth or not making with Sires :D"
*cough cough*
Colored lights
*cough cough*
I test mines.
- azekill_DIABLO
- Member
- Posts: 7507
- Joined: Wed Oct 29, 2014 20:05
- GitHub: azekillDIABLO
- In-game: azekill_DIABLO
- Location: OMICRON
- Contact:
Re: Wishes for Minetest 0.4.11 (or 0.5)
I ish a on_death callback for entities!
Gone, but not dead. Contact me on discord: azekill_DIABLO#6565
DMs are always open if you want to get in touch!
DMs are always open if you want to get in touch!
- ThomasMonroe
- Member
- Posts: 286
- Joined: Tue Apr 04, 2017 16:21
- GitHub: ThomasMonroe314
- IRC: ThomasMonroe TMcSquared
- In-game: ThomasMonroe TMcSquared
- Location: Wherever I am at
Re: Wishes for Minetest 0.4.11 (or 0.5)
or an on_delete, because not all entities are mobs :P
I don't make messes, I just, er...disturb the local entropy!
- azekill_DIABLO
- Member
- Posts: 7507
- Joined: Wed Oct 29, 2014 20:05
- GitHub: azekillDIABLO
- In-game: azekill_DIABLO
- Location: OMICRON
- Contact:
Re: Wishes for Minetest 0.4.11 (or 0.5)
if you prefer! :D
Gone, but not dead. Contact me on discord: azekill_DIABLO#6565
DMs are always open if you want to get in touch!
DMs are always open if you want to get in touch!
-
- New member
- Posts: 2
- Joined: Mon Jan 14, 2019 00:12
Re: Wishes for Minetest 0.4.11 (or 0.5)
better renderer
shadows, bloom/fake hdr
colored lights, better occlusion culling
smoother more optimized gameplay
better in game menus
more magic mods
shadows, bloom/fake hdr
colored lights, better occlusion culling
smoother more optimized gameplay
better in game menus
more magic mods
-
- Member
- Posts: 190
- Joined: Mon Jan 02, 2017 21:00
- GitHub: Sires0
- IRC: Sires
- In-game: Sires Sores Siri Seris or anything ppl call me
- Location: :noitacoL
Re: Wishes for Minetest 0.4.11 (or 0.5)
Your gong 2 fazt.mentalmage wrote:better renderer
shadows, bloom/fake hdr
colored lights, better occlusion culling
smoother more optimized gameplay
better in game menus
more magic mods
S T O P P
I don't have anything important to say.
- iisu
- Member
- Posts: 220
- Joined: Tue Mar 28, 2017 20:13
- GitHub: iisu
- IRC: iisu
- In-game: iisu
- Location: Internet
Re: Wishes for Minetest 0.4.11 (or 0.5)
Support for ctrl+C, ctrl+V, X11 clipboard, dead keys, compose key, ctrl+shift+U and IMEs in chat.
Roses are red, violets are blue. Omae wa mou shindeiru.
Re: Wishes for Minetest 0.4.11 (or 0.5)
railings and bannisters
Who is online
Users browsing this forum: No registered users and 7 guests