More randomness for slime chunks #4466
No reviewers
Labels
No Label
#P1 CRITICAL
#P2: HIGH
#P3: elevated
#P4 priority: medium
#P6: low
#Review
annoying
API
bug
code quality
combat
commands
compatibility
configurability
contribution inside
controls
core feature
creative mode
delayed for engine release
documentation
duplicate
enhancement
environment
gameplay
graphics
ground content conflict
GUI/HUD
help wanted
incomplete feature
invalid / won't fix
items
looking for contributor
mapgen
meta
mineclone2+
Minecraft >= 1.13
Minecraft >= 1.17
missing feature
mobile
mobs
mod support
model needed
multiplayer
Needs adoption
needs discussion
needs engine change
needs more information
needs research
nodes
non-Minecraft feature
non-mob entities
performance
player
possible close
redstone
release notes
schematics
Skyblock
sounds
Testing / Retest
tools
translation
unconfirmed
mcl5
mcla
Media missing
No Milestone
No project
No Assignees
4 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: VoxeLibre/VoxeLibre#4466
Loading…
Reference in New Issue
No description provided.
Delete Branch "kno10/VoxeLibre:slime-spawning"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
The old code caused a diagonal pattern. If some x,z was a slime chunk, then so was x+1,z-1.
Use a classic pseudo-random hashing approach instead, by multiplication of chunk numbers
with large primes that should be more random.
This pull does not modify spawn frequency, only the chunk logic.
Because this replaces the computation of slime chunks, do not expect slimes to spawn in the same places as before. For testing, you can increase the slime chunk density, e.g., to 2 (every other chunk). There is a commented log that will print, e.g.,
Chunk 1182545475 is a slime chunk: false
andChunk 2924583950 is a slime chunk: true
Aside of the typo in a comment, lgtm... as long as slimes don't spawn on the surface more than they do without this patch.
Haven't tested yet.
@ -9,0 +13,4 @@
local slime_max_light = (tonumber(minetest.settings:get_bool("mcl_mobs_slime_max_light", true)) or minetest.LIGHT_MAX) + 1
-- maximum light level for swamp spawning
local swamp_light_max = 7
-- maximum highzt to spawn in slime chunks
Typo:
height
nothighzt
?ee0db05876
to0edcfce8d4
Fixed the typo, thanks.
Next time you fix something, please mark the conversation as 'Resolved'.
Here's your review.
I haven't been able to get any slimes to spawn. Perhaps it's because of all the settings being so broken?
@ -9,0 +8,4 @@
-- slime density, where default N=10 is every 10th chunk
local slime_density = math.floor(tonumber(minetest.settings:get("mcl_mobs_slime_density")) or 10)
-- use 3D chunking instead of 2d chunks
local slime_3d_chunks = minetest.settings:get("mcl_mobs_slime_3d_chunks") or false
get
method is... bizarre.get_bool
can handle default values as its second argument, see http://api.minetest.net/class-reference/#methods_16.@ -9,0 +10,4 @@
-- use 3D chunking instead of 2d chunks
local slime_3d_chunks = minetest.settings:get("mcl_mobs_slime_3d_chunks") or false
-- maximum light level, for slimes in caves only, not magma/swamps
local slime_max_light = (tonumber(minetest.settings:get_bool("mcl_mobs_slime_max_light", true)) or minetest.LIGHT_MAX) + 1
So now you're getting an integer value through
get_bool
, withtrue
as the default value. O_oLOL, put that into the wrong line...
@ -88,2 +27,2 @@
assert(calculate_chunk_value(vector.new(16,0,64)) == (3), "calculate_chunk_value failed")
assert(calculate_chunk_value(vector.new(-160,0,-160)) == 0, "calculate_chunk_value failed")
local math_floor = math.floor
local math_max = math.max
Why localize these functions if you're already using them unlocalized a few lines above (when handling settings)?
Following this pattern from other modules, although the minetest "vector" class does not seem to bother.
My guess was that this can help with performance in functions that are frequently called (as it is not necessary to check if someone modified math.floor in the meantime).
For the settings, which supposedly is only executed once and hence not performance critical, I would prefer the standard version.
But I have to rely on your experience whether localizing is beneficial or not.
I did a profile of this recently (local access compared to accessing a global) and accessing a local was about 3 times faster on my hardware than a simple global access (see #4338 (comment)). I haven't profiled it this specific thing, but I would expect accessing a field thru a global would be a bit less than an additional 2x. But even then, we are talking about 3.1 ns for a local access and an estimated 16.3 ns (2 * (9.7 - 3.1) + 3.1) for the non-local access so unless this is in an inner loop it probably doesn't matter that much. Defaulting to the faster method when they behave (or should behave) the same is a good habit to get into though.
Probably easy enough just to move the local variable assignment to near the top of the file and use it everywhere.
@ -224,0 +224,4 @@
# Slime chunk density
mcl_mobs_slime_density (Slime chunk density, default is one in ten, 0 to disable cave slime) int 10 0
# Use 3d chunking instead of 2d chunking
mcl_mobs_slime_3d_chunks (Use 3d chunking instead of 2d chunking) bool false
Reduce all of these settings to from
mcl_mobs_slime_...
toslime_...
(and don't forget to update the .lua file for that). Explanation:mcl_mobs
. They are defined inmobs_mc
.Also, consider making the visible names of these settings a lot shorter and prepending all of them with "Slime". If the 3D/2D chunking is only relevant for slimes, it should be apparent for the player that it's only relevant for slimes.
The names get cut off, and it's even worse when you're using a custom font.
UPD: I think I know what the issue was. You've mixed up text in comment (which is the description for a setting) and in brackets (which is the visible name of a setting). Still, you don't have to repeat the same thing for
slime_3d_chunks
name and description if there's no more info to add.0edcfce8d4
to9c759d4f6b
9c759d4f6b
to2adf3a9904
@rudzik8, updated. Please let me know whether I should de-localize these functions.
First:
Second, after reading through teknomunk's comment, I don't think you should.
@rudzik8 you can use worldedit to rip out large areas underground and see if slimes are spawning there.