line 71 might be a bother that part of the code seems a bit like it could be a problem for what I'm trying to do
Code: Select all
if minetest.get_modpath("ethereal") then
Code: Select all
if minetest.get_modpath("ethereal") then
Code: Select all
if not self.id then
self.id = (math.random(1, 1000) * math.random(1, 10000))
.. self.name .. (math.random(1, 1000) ^ 2)
end
Code: Select all
-------------------------------------------------------------------
---- UUID Lua generator from the Worldwide Web ----
---- cc0, Public domain ----
-------------------------------------------------------------------
math.randomseed(os.clock()+os.time())
function uuid()
local random = math.random
local template ='xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx'
return string.gsub(template, '[xy]', function (c)
local v = (c == 'x') and random(0, 0xf) or random(8, 0xb)
return string.format('%x', v)
end)
end
Code: Select all
self.id = uuid()
Not really. Random numbers shouldn't be used at all in a UUID.sirrobzeroone wrote:Less chance of duplicate id's getting generated.
That ^2 is wasted cycles and does nothing to reduce collisions. If random() produces the same number, do you think squaring it will somehow make them different numbers?sirrobzeroone wrote:Code: Select all
self.id = (math.random(1, 1000) * math.random(1, 10000)) .. self.name .. (math.random(1, 1000) ^ 2)
Calling string.format('%x', random(0, 0xf)) ~31 times and overwriting each index in a length ~31 string would produce the same result with less code and fewer cycles.sirrobzeroone wrote:Code: Select all
local template ='xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx' return string.gsub(template, '[xy]', function (c) local v = (c == 'x') and random(0, 0xf) or random(8, 0xb)
Code: Select all
local mob_counter = 0 -- global variable
--self.id = self.name .."-".. os.time() .."-".. mob_counter
self.id = self.name .."-".. pos.x .."-".. pos.y .."-".. pos.z .."-".. os.time() .."-".. mob_counter
mob_counter = mob_counter + 1
Only if you make em' spawn on mossy and/or regular cobblelilo wrote:Hi,
it is possible that mobs_monster will be spawn in standard dungeon?
greets
Thanks for the feedback always interesting to read for me. The first block of quoted code up there is the existing code being used. I have some awareness that using random to generate unique id's is not real hot as there is a chance even though significantly small that the same number could be generated as to the why the current code block does what it does (no clue myself why it does the squaring either) you'd need to ask the original person who wrote it...I have no clue who that is.auouymous wrote:sirrobzeroone wrote:Less chance of duplicate id's getting generated.
A standard UUID format is needed if there will be multiple implementations of the UUID generating code (every language might need its own and people like reinventing wheels). Standard UUIDs include a sub-second timestamp, counter and a machine identifier. But it all depends on the data you have available and how the UUID will be used. Standard UUIDs are also designed to be read and manually typed, that is why they break up the digits into smaller groups with hyphens and why they only use hex digits, as it avoids font issues with "1l0O".sirrobzeroone wrote:is there any advantage to using a known standard such as UUID for longer term consistency and maintenance?
I'm not sure what's going on but your code should look similar to this:sirrobzeroone wrote:Quick question, I'm trying to use set_velocity inside do_custom, however I kept getting a nil error. When I checked the set_velocity function it seemed to be set as a local object/function.
I removed the local from inside the api which i think I know has now made set_velocity a global function. My question is, is there an easier way to access this function that I'm missing? ie is there long hand way to call the set_velocity from inside my do_custom? without modding the main api file the way I have?
It's that or copy the whole function over verbatim which might also be easier...
thanks
The mob shouldn't immediately lose interest in the target when it is no longer in line of sight, otherwise you can place two vertical nodes to hide from mobs. It should need about 30-60 seconds of failed LoS checks before it gives up, and a successful check should reset the counter.Astrobe wrote:Another thing to do in order to make mobs behave smarter is to tie the attack state (and shooting) to the line of sight. If they lose visual contact, just return them to the "walk" state...
A mob shooting arrows should check, but a mob shooting explosives should not. Your issue would be solved if the mob requires LoS before entering the attack state.Astrobe wrote:Shooting mobs should check their line of sight before shooting too.
It would be cool if mobs could randomly switch to multiple alternate attack states (evading, dodging, ...) after taking any damage. If it doesn't take damage in the alternate attack state it could return to attack state, otherwise it could randomly switch to another alternate attack state, or even return to attack state. Would create more interesting fights, instead of the current situation.Astrobe wrote:One (really) last thing: the runaway behavior which is probably underused.
Please, publish your fork to the community. We need to check it.Astrobe wrote:I've hacked MobsRedo so much that it would be unfortunately pointless for me to submit patches now, but I can share some ideas I have implemented in my "fork".
30-60 seconds is way too long, especially when, because of other limitations, the mob spends that time rubbing its face against a wall.auouymous wrote:The mob shouldn't immediately lose interest in the target when it is no longer in line of sight, otherwise you can place two vertical nodes to hide from mobs. It should need about 30-60 seconds of failed LoS checks before it gives up, and a successful check should reset the counter.Astrobe wrote:Another thing to do in order to make mobs behave smarter is to tie the attack state (and shooting) to the line of sight. If they lose visual contact, just return them to the "walk" state...
My point of view is that the "wall hack" (as it is called when cheaters do that in FPS games) is too obvious, explosive shells or not, when it happens in the open; contrary to when a dungeon master shoots from a dark corner in a mine before you notice it.A mob shooting arrows should check, but a mob shooting explosives should not. Your issue would be solved if the mob requires LoS before entering the attack state.Astrobe wrote:Shooting mobs should check their line of sight before shooting too.
I agree it would be nice to have more alternate behaviors. However the options are quite limited. "dodging" really applies only to missile-type attacks and is hard to implement (if you take into consideration the moving speed, the mob has to anticipate a lot to have a chance to succeed); "evading" is kind of like "runaway" to me, only more temporary.It would be cool if mobs could randomly switch to multiple alternate attack states (evading, dodging, ...) after taking any damage. If it doesn't take damage in the alternate attack state it could return to attack state, otherwise it could randomly switch to another alternate attack state, or even return to attack state. Would create more interesting fights, instead of the current situation.Astrobe wrote:One (really) last thing: the runaway behavior which is probably underused.
Users browsing this forum: Skamiz Kazzarch and 1 guest