some of the things this mod provides are invaluable on survival multiplayer servers, where the admins want to restrict what players can do in certain areas. the special nodes - particularly fullclip and nointeract - are incredibly useful, and the admin pickaxes are indispensible.
oh! i didn't realize that. perhaps you should limit the number of balls one can put into the cannon at once? i just put in a stack and pressed the fire button, expecting it to just launch one shot.
the default explosion radius of the cannon shell seems to be something close to 100? i'm lucky i tested it relatively far from other things on my test world.
EDIT: apparently it was user error - be very careful to not put too many cannonballs inside at once!
oh, this is a way for creating discrete onset, active, and falling off scales for effects? that sounds quite useful, i bet i can implement something similiar. i actually want to do something like this for e.g. a lycanthropy effect, where you shouldn't instantly change abilities, and your speed/jump/etc should scale gradually when it's starting or ending.
today i've added some API to allow an easier incorporation of "monoid limiters", though the whole thing is still fairly esoteric and math-heavy. i'd like to give the different limiters more natural explanations, but i'm not quite sure how to do that. i'll meditate on that for a while. suggestions are welcome.
can effects by this mod be applied with different curves?
currently, the individual effect definitions have control over how the effects are applied. the base mod (status effects) provides a handful of ways of composing values, but those ways are rather basic. if there is interest, i can supply some "fold" methods which make use of the same mechanisms as my limit_phyiscs_monoids mod, which provides different "curves".
actually, after thinking about this for a while, i think i should break out the scaling mechanisms in the limit_physics_monoids mod into futil and provide that as an option for people creating status effects.
this status effects mod is one step in a chain of a very complicated system of interacting effects that i'm trying to gradually bring into a mature state. i've been sitting on this for a while while i contemplate whether i'm approaching the goals in the right way. the mods that i'm aiming to release that depend on this are std_effects, then staminoid, then balanced_nutrients, then balanced_nutrient_overrides.
i'm aware of player effects, but it doesn't meet all my use cases. one of the biggest differences is that a single effect created w/ status effects can be used simultaneously by multiple separate mods without explicit integration code. this allows you to e.g. have a player be poisoned from two separate sources, and have the amount of the poisoning stack. you can also have, say, an "antiserum" that cures the poisoning from all sources, though it looks like player effects does allow cancelling an ongoing effect
another difference is that it's possibble to define an effect which increments or decrements a value every-so-often (e.g. poison or regen), and have the effect "catch up" if there's a lag spike.
for uses of status effects, see std_effects, which i'll add to the CDB when it's in a more finalized state. in particular, the exhaustion, lycanthropy, and builders_flight effects should show some of the power of the approach i've gone with. you can test out this mod (and others) on my public server "fluxtest" to get a feel for how effects can combine.
the monoid mechanic allows various mods to modify the same player attributes without stepping on the toes of other mods trying to do the same thing. it's very effective. i wish more mods made use of it. i've made a whole lot of mods based on this one.
we're interested in using this mod on the your-land server, but we've got a few issues:
could you put the code in some public-facing git server which allows for submitting issues and pull requests? i suppose this isn't strictly necessary, but it'd help w/ our workflows.
we need a way to prevent players from attaching leads to mobs owned by other players
we need a way to prevent attaching leads to certain kinds of mobs entirely (e.g. monsters, NPCs)
we need a way to prevent players attaching leads to nodes in protected areas that they don't control.
i apologise. i am terrible at GUI stuff and i don't have access to any sort of mobile platform. however, i think making minetest mobile friendly is very important. please create an issue at https://github.com/fluxionary/minetest-digicolor/issues/new and let's figure out how to make the mod usable for mobile users there.
that command only logs when entity steps take "too long", which is .45 seconds by default. you can change this by modifying the debuggery.entity_lag_log_threshold setting. note that the setting is in microseconds, so the default value is 450000.
Trees other than the one I cut start disappearing too.
this is a difficult problem to solve, but one that i do want to do better in the future. there is already a limit on how far away it will continue to cut, which is dependent on the expected size of the tree, but that limit is generally about double what it might be. also, adjacent trees will only be cut if they're touching the original tree. to reduce the amount that adjacent trees are cut, set choppy.halo_size = 0 and choppy.step_radius = 1
suddenly the entire tree starts disappearing and leaves fall.
the speed at which the tree is dug is dependent on the speed of the axe you are using, and the hardness of the tree. trunk nodes shouldn't be dug any faster than what you can do w/ the axe, if you were able to actually point your axe at them. leaves are cut much faster by default. to slow down the process by a constant amount, you can set choppy.dig_speed_multiplier to a value less than 1. to slow down the rate at which leaves are cut, you can set choppy.snappy_multiplier to a value less than the default (5). if you want to put more of a limit on how quickly things can be cut, you can set choppy.max_trunks_per_second to a lower value (default 20).
instead of flawlessly appearing in inventory, their log nodes get dropped for retrieval by the player.
this mod should integrate well w/ https://content.minetest.net/packages/texmex/item_drop/ if that's behavior you desire, though that will cause all dug nodes to drop in the world. i'll look into adding an option to have the dug nodes drop as items.
like CalebJ, i also encountered this during a period of extended downtime on the tunnelers' abyss server, and found it almost as fun =D. the infinite nature of the game ensures that you'll always have plenty of areas you can solve if you ever get stuck in one place.
@CalebJ the aesthetic interests of players is actually something i think is very important. while i think the current menagerie of shop entities is optimal for FPS for low-power clients (almost, i have a couple more ideas for minor improvements), i think i should add a setting to allow people to either
optimize for FPS (current default)
show 4 wielditems (old behavior)
only show wielditems or upright sprites (a compromise which is less visually jarring)
some of the things this mod provides are invaluable on survival multiplayer servers, where the admins want to restrict what players can do in certain areas. the special nodes - particularly fullclip and nointeract - are incredibly useful, and the admin pickaxes are indispensible.
oh! i didn't realize that. perhaps you should limit the number of balls one can put into the cannon at once? i just put in a stack and pressed the fire button, expecting it to just launch one shot.
the default explosion radius of the cannon shell seems to be something close to 100? i'm lucky i tested it relatively far from other things on my test world.EDIT: apparently it was user error - be very careful to not put too many cannonballs inside at once!
it's working fine for me, but open an issue on github and give any more details and i'll look into it.
oh, this is a way for creating discrete onset, active, and falling off scales for effects? that sounds quite useful, i bet i can implement something similiar. i actually want to do something like this for e.g. a lycanthropy effect, where you shouldn't instantly change abilities, and your speed/jump/etc should scale gradually when it's starting or ending.
either i totally missed this originally, or you edited your comment? i'll certainly dig into what that mod is doing and see if i can repurpose it.
today i've added some API to allow an easier incorporation of "monoid limiters", though the whole thing is still fairly esoteric and math-heavy. i'd like to give the different limiters more natural explanations, but i'm not quite sure how to do that. i'll meditate on that for a while. suggestions are welcome.
currently, the individual effect definitions have control over how the effects are applied. the base mod (status effects) provides a handful of ways of composing values, but those ways are rather basic. if there is interest, i can supply some "fold" methods which make use of the same mechanisms as my limit_phyiscs_monoids mod, which provides different "curves".
actually, after thinking about this for a while, i think i should break out the scaling mechanisms in the limit_physics_monoids mod into futil and provide that as an option for people creating status effects.
this status effects mod is one step in a chain of a very complicated system of interacting effects that i'm trying to gradually bring into a mature state. i've been sitting on this for a while while i contemplate whether i'm approaching the goals in the right way. the mods that i'm aiming to release that depend on this are std_effects, then staminoid, then balanced_nutrients, then balanced_nutrient_overrides.
i'm aware of player effects, but it doesn't meet all my use cases. one of the biggest differences is that a single effect created w/ status effects can be used simultaneously by multiple separate mods without explicit integration code. this allows you to e.g. have a player be poisoned from two separate sources, and have the amount of the poisoning stack. you can also have, say, an "antiserum" that cures the poisoning from all sources, though it looks like player effects does allow cancelling an ongoing effect
another difference is that it's possibble to define an effect which increments or decrements a value every-so-often (e.g. poison or regen), and have the effect "catch up" if there's a lag spike.
for uses of status effects, see std_effects, which i'll add to the CDB when it's in a more finalized state. in particular, the exhaustion, lycanthropy, and builders_flight effects should show some of the power of the approach i've gone with. you can test out this mod (and others) on my public server "fluxtest" to get a feel for how effects can combine.
the monoid mechanic allows various mods to modify the same player attributes without stepping on the toes of other mods trying to do the same thing. it's very effective. i wish more mods made use of it. i've made a whole lot of mods based on this one.
i still don't have access to any sort of mobile platform. is there a chance you could post a screenshot of the problem somewhere?
it should update automatically eventually, not sure how long that takes.
we're interested in using this mod on the your-land server, but we've got a few issues:
could you put the code in some public-facing git server which allows for submitting issues and pull requests? i suppose this isn't strictly necessary, but it'd help w/ our workflows.
we need a way to prevent players from attaching leads to mobs owned by other players
we need a way to prevent attaching leads to certain kinds of mobs entirely (e.g. monsters, NPCs)
we need a way to prevent players attaching leads to nodes in protected areas that they don't control.
i've added a "save" button to the formspec and an LBM to update any nodes already placed in the world. hope that helps!
i apologise. i am terrible at GUI stuff and i don't have access to any sort of mobile platform. however, i think making minetest mobile friendly is very important. please create an issue at https://github.com/fluxionary/minetest-digicolor/issues/new and let's figure out how to make the mod usable for mobile users there.
that command only logs when entity steps take "too long", which is .45 seconds by default. you can change this by modifying the
debuggery.entity_lag_log_thresholdsetting. note that the setting is in microseconds, so the default value is450000.i've added a new setting. set
choppy.handle_drop_behavior = add_itemto make chopped nodes drop on the ground.before messing around w/ the API, i'd recommend checking out the settings: https://github.com/fluxionary/minetest-choppy/blob/main/settingtypes.txt
this is a difficult problem to solve, but one that i do want to do better in the future. there is already a limit on how far away it will continue to cut, which is dependent on the expected size of the tree, but that limit is generally about double what it might be. also, adjacent trees will only be cut if they're touching the original tree. to reduce the amount that adjacent trees are cut, set
choppy.halo_size = 0andchoppy.step_radius = 1the speed at which the tree is dug is dependent on the speed of the axe you are using, and the hardness of the tree. trunk nodes shouldn't be dug any faster than what you can do w/ the axe, if you were able to actually point your axe at them. leaves are cut much faster by default. to slow down the process by a constant amount, you can set
choppy.dig_speed_multiplierto a value less than 1. to slow down the rate at which leaves are cut, you can setchoppy.snappy_multiplierto a value less than the default (5). if you want to put more of a limit on how quickly things can be cut, you can setchoppy.max_trunks_per_secondto a lower value (default 20).this mod should integrate well w/ https://content.minetest.net/packages/texmex/item_drop/ if that's behavior you desire, though that will cause all dug nodes to drop in the world. i'll look into adding an option to have the dug nodes drop as items.
like CalebJ, i also encountered this during a period of extended downtime on the tunnelers' abyss server, and found it almost as fun =D. the infinite nature of the game ensures that you'll always have plenty of areas you can solve if you ever get stuck in one place.
@CalebJ the aesthetic interests of players is actually something i think is very important. while i think the current menagerie of shop entities is optimal for FPS for low-power clients (almost, i have a couple more ideas for minor improvements), i think i should add a setting to allow people to either
optimize for FPS (current default)
show 4 wielditems (old behavior)
only show wielditems or upright sprites (a compromise which is less visually jarring)
overall, this mod gets an upvote from me, though there are some downsides. however, some old downvotes critique things which have been solved.
things which have been fixed:
you can disable the syringe (
disable_syringe = truein user.conf)you can disable specific mobs you might think are inappropriate in user.conf, e.g. killer santas, by editing the
petz_listsetting in user.confthe mod can be used reliably. it doesn't have any serious conflicts w/ other mods, though there are a few aesthetic conflicts
pluses:
mod is actively maintained
the tamed mobs are much more reliable than mods_redo
there's quite a lot of variety, and new content gets added all the time
there's a number of different mechanics that players enjoy engaging with
people like taming and keeping petz
people like keeping beehives
werewolves are fun
playing fetch is fun
some things are easy, and some are difficult but rewarding
ambivalent, but notable:
minuses
has its own custom system for settings
some questionable choices of which things not related to "pets" should be included
max/min height and damage are already settings, see https://github.com/fluxionary/minetest-mobs_balrog/blob/main/settingtypes.txt for a full list.
EDIT: wait, that currently isn't updated, the names of the settings have changed slightly.
EDIT2: Updated settingtypes, should be correct now.