[Mod] Mobs Redo [1.47] [mobs]

User avatar
Chibi ghost
Member
 
Posts: 777
Joined: Fri Jan 08, 2016 21:17
In-game: Ghost

Re: [Mod] Mobs Redo [1.47] [mobs]

by Chibi ghost » Sat Oct 06, 2018 14:46

ta very much thank you
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


should I delete it?
 

User avatar
TenPlus1
Member
 
Posts: 2404
Joined: Mon Jul 29, 2013 13:38
GitHub: tenplus1

Re: [Mod] Mobs Redo [1.47] [mobs]

by TenPlus1 » Sat Oct 06, 2018 19:12

you can add the new mobs:spawn() either in a new mod or at the end of the file... doesnt have to be between the ethereal line.
 

sirrobzeroone
Member
 
Posts: 22
Joined: Mon Jul 16, 2018 07:56

Re: [Mod] Mobs Redo [1.47] [mobs]

by sirrobzeroone » Mon Oct 15, 2018 06:29

thanks for the fix TenPlus1.

While I was playing around I noticed that the uniqueID (self.id) that is used with the trader looks like a cool idea. I played around a little but placed the code into the init.lua for npcs and found a UUID generator written in lua on the www. Less chance of duplicate id's getting generated. Anyways not sure if you can or even would like to use it. But i did confirm it worked as a replacement for the self.id generation

i replaced this bit:
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


With this - not my code I just adapted it for the above job:
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


Inside the trader code i added the below - more for others than yourself Tenplus1 :), although I haven't quiet worked out what it does yet... (self.id I mean)
Code: Select all
self.id = uuid()


thought it better to post the code fragment here than have it sitting on my HDD :)
 

auouymous
Member
 
Posts: 158
Joined: Sun Dec 07, 2014 09:39
GitHub: auouymous
IRC: air
In-game: auouymous

Re: [Mod] Mobs Redo [1.47] [mobs]

by auouymous » Mon Oct 15, 2018 10:21

sirrobzeroone wrote:Less chance of duplicate id's getting generated.


Not really. Random numbers shouldn't be used at all in a UUID.


sirrobzeroone wrote:
Code: Select all
self.id = (math.random(1, 1000) * math.random(1, 10000))
         .. self.name .. (math.random(1, 1000) ^ 2)


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
   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)


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.


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


This uses the name, position, current time in seconds since epoch and a per-session counter. The counter resets to zero each time server is started, and incrementing it guarantees no two mobs per session will have the same ID. The current time guarantees no two mobs between sessions will have the same ID. Using the spawn position is overkill, but adds another data point to prevent collisions in case the server has clock skew that causes time to be rolled back to an earlier session's time.

current code: 1.75 microseconds
curent code without ^2: 1.59 microseconds (~10% faster)
original uuid function: 13.50 microseconds
name+pos+time+counter: 3.06 microseconds
name+time+counter: 1.62 microseconds
 

lilo
Member
 
Posts: 31
Joined: Sat May 27, 2017 14:45

Re: [Mod] Mobs Redo [1.47] [mobs]

by lilo » Mon Oct 15, 2018 16:12

Hi,

it is possible that mobs_monster will be spawn in standard dungeon?

greets
 

User avatar
davidthecreator
Member
 
Posts: 258
Joined: Mon Aug 18, 2014 19:48
Location: Lithuania
GitHub: daviddoesminetest
In-game: DavidDoesMinetest

Re: [Mod] Mobs Redo [1.47] [mobs]

by davidthecreator » Mon Oct 15, 2018 18:16

lilo wrote:Hi,

it is possible that mobs_monster will be spawn in standard dungeon?

greets


Only if you make em' spawn on mossy and/or regular cobble
 

sirrobzeroone
Member
 
Posts: 22
Joined: Mon Jul 16, 2018 07:56

Re: [Mod] Mobs Redo [1.47] [mobs]

by sirrobzeroone » Mon Oct 15, 2018 21:15

auouymous wrote:
sirrobzeroone wrote:Less chance of duplicate id's getting generated.


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.

I do like your fixed code it's far more elegant and faster, is there any advantage to using a known standard such as UUID for longer term consistency and maintenance? I haven't yet stumbled across the code inside the mobs_redo code that makes use of the id string it seems to just be used locally for a check to confirm a nametag hasn't been set but I'm unsure why check for id as a straight check for a nametag first would seem more efficient overall.

I don't have a development background just some javascript and php dabbling every now and then so trying to get my head around OOP and Lua has been interesting. I find speed and optimization discussions very interesting myself as I think it helps improve the user experience.
 

auouymous
Member
 
Posts: 158
Joined: Sun Dec 07, 2014 09:39
GitHub: auouymous
IRC: air
In-game: auouymous

Re: [Mod] Mobs Redo [1.47] [mobs]

by auouymous » Mon Oct 15, 2018 23:41

sirrobzeroone wrote:is there any advantage to using a known standard such as UUID for longer term consistency and maintenance?


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".

I think I saw that you could provide your own self.id value, if that is the case, anyone providing their own value needs to be aware of the format used by the internal implementation. But I imagine self.name is something like "<mod_name>:<entity_name>", so everything will work out fine as long as a mod uses self.name somewhere in the self.id value it generates. A mod could still generate IDs that collide with its own entities, but they wouldn't collide with entities in other mods. Forcing all mods to use the internal implementation would be better, but there is probably is valid reason for allowing them to generate their own.
 

sirrobzeroone
Member
 
Posts: 22
Joined: Mon Jul 16, 2018 07:56

Re: [Mod] Mobs Redo [1.47] [mobs]

by sirrobzeroone » Thu Oct 18, 2018 09:52

found this sort of possible Sheep death sound effect for mobs_animal
its under CC0 and originally from over at the free sound org, converted it to an ogg

https://freesound.org/people/sqeeeek/sounds/237103/

Not sure if this is useful or not, if it is I'm happy to add any others here I stumble on.
Attachments
mobs_sheep_death.zip
(18.96 KiB) Downloaded 6 times
 

User avatar
TenPlus1
Member
 
Posts: 2404
Joined: Mon Jul 29, 2013 13:38
GitHub: tenplus1

Re: [Mod] Mobs Redo [1.47] [mobs]

by TenPlus1 » Thu Oct 18, 2018 12:32

Lol, sounds like someone with a bad morning cough :) thanks for the sound, will keep hold if it just incase :P
 

sirrobzeroone
Member
 
Posts: 22
Joined: Mon Jul 16, 2018 07:56

Re: [Mod] Mobs Redo [1.47] [mobs]

by sirrobzeroone » Sat Oct 20, 2018 04:10

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
 

User avatar
Lone_Wolf
Member
 
Posts: 1939
Joined: Sun Apr 09, 2017 05:50
Location: Hopefully very far from yours, snoop :P
GitHub: LoneWolfHT
IRC: Lone_Wolf
In-game: Lone_Wolf

Re: [Mod] Mobs Redo [1.47] [mobs]

by Lone_Wolf » Sat Oct 20, 2018 04:56

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

I'm not sure what's going on but your code should look similar to this:
self.object:set_velocity(var)
Or
obj:set_velocity(var)
Might be that 'var' has a nil value. And vector tables look like this:
{x=0, y=0, z=0}
 

sirrobzeroone
Member
 
Posts: 22
Joined: Mon Jul 16, 2018 07:56

Re: [Mod] Mobs Redo [1.47] [mobs]

by sirrobzeroone » Sat Oct 20, 2018 05:18

That'll be it, I had:

self.set_velocity(self, self.run_velocity)

edit: think I was after set_acceleration not velocity....although amusing to watch not the effect I was after :).
 

User avatar
runs
Member
 
Posts: 56
Joined: Sat Oct 27, 2018 08:32
GitHub: runsy

Re: [Mod] Mobs Redo [1.47] [mobs]

by runs » Wed Oct 31, 2018 19:53

Could you make mobs smarter?

When they find themselves in front of an obstacle, they start jumping again and again, and only after a while they turn around. (even with pathfinding=1)
 

User avatar
TenPlus1
Member
 
Posts: 2404
Joined: Mon Jul 29, 2013 13:38
GitHub: tenplus1

Re: [Mod] Mobs Redo [1.47] [mobs]

by TenPlus1 » Thu Nov 01, 2018 09:51

runs - I've added a jump counter so that when a mob jumps against a wall 4 times it will turn around, this might help the dumber mobs get around :)
 

Astrobe
Member
 
Posts: 151
Joined: Sun Apr 01, 2018 10:46

Re: [Mod] Mobs Redo [1.47] [mobs]

by Astrobe » Thu Nov 01, 2018 10:54

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".

For the jump issue, you can have the mobs check if it would allow them to climb the obstacle (by checking the node above the primary obstacle. The annoying issue is that in the mob definition one doesn't specify a jump height but a jump velocity. What I did is enable this check only for mobs that have a jump height above the default, because the default value allow mobs to climb one block for sure. For mobs that have better jump specs, this still works well (I have spiders with a jump height of 8).
If the check returns a negative result, just make them turn randomly, but always to the left or the right. This allows them to get out of "mazes" eventually.

A thing that works well too in order to "un-stuck" mobs is to randomize a bit the direction of the probing; sometimes mobs are stuck at the corner of the node: the collision box stop them but the probe sees nothing. Some jitter in the probing direction gives the chance for the probe to detect the obstacle.

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 (btw there is a blinktimer property that doesn't seem to be used anymore - don't reuse it to delay the return to walk state; it adds complexity for very little enhancements compared to the "players scanning" described below).

One issue with the current implementation is that mobs that saw players once will be in attack state for as long as the player is in visual range. This is true also for NPCs. So you can have a monster and and an NPC "locked" on each other forever - even though the NPC is on the surface and the monster in a cave below.

Shooting mobs should check their line of sight before shooting too. I realized that when one of my players complained he was killed by a dragon shooting explosive fireballs even though he was perfectly hidden from the dragon because he was digging a tunnel in a mountain (the drake was outside). Another reason to do that is that it gives the chance for the shooting mob to move a little when the player dodges or hides; that makes the fights more dynamic and mitigates abuse of "stuck" mobs.

Finally, you can have the mobs scan the world for the nearest player and have them to turn towards them rather than randomly in "stand" state. This doesn't result in mobs crowding the players because both players and mobs constantly move ("walk" state). This fits very well survival/action oriented games; foes tend to find players eventually even if they hide behind trees or walls (works best with the LoS checks). This hack is cheap if one uses get_connected_players()).

One (really) last thing: the runaway behavior which is probably underused. One neat addition is to add a "suicidal" property, which tells the mob if it should fight to death or runaway when it's low HP (I use a 10% of the max HP criteria). This adds a "chasing" phase to combats and is a believable behavior for human(-oid) NPCs or wild animals.

(PS: the LoS check can be factored so it applies to shooting and CQC after the view range check, so it's only mildly expensive.)

(PPS: you can checkout those changes on the Minefall server (when it is up, usually on the UTC evenings)
 

User avatar
TenPlus1
Member
 
Posts: 2404
Joined: Mon Jul 29, 2013 13:38
GitHub: tenplus1

Re: [Mod] Mobs Redo [1.47] [mobs]

by TenPlus1 » Thu Nov 01, 2018 14:55

Astrobe - Post a link to your fork and I'll check it out.
 

auouymous
Member
 
Posts: 158
Joined: Sun Dec 07, 2014 09:39
GitHub: auouymous
IRC: air
In-game: auouymous

Re: [Mod] Mobs Redo [1.47] [mobs]

by auouymous » Thu Nov 01, 2018 22:10

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...


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:Shooting mobs should check their line of sight before shooting too.


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:One (really) last thing: the runaway behavior which is probably underused.


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.
 

User avatar
runs
Member
 
Posts: 56
Joined: Sat Oct 27, 2018 08:32
GitHub: runsy

Re: [Mod] Mobs Redo [1.47] [mobs]

by runs » Thu Nov 01, 2018 22:37

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".


Please, publish your fork to the community. We need to check it.

Why do you keep it hidden? It's a pity, maybe tomorrow you'll leave minetest and your ideas will be lost forever... :-(
 

User avatar
TenPlus1
Member
 
Posts: 2404
Joined: Mon Jul 29, 2013 13:38
GitHub: tenplus1

Re: [Mod] Mobs Redo [1.47] [mobs]

by TenPlus1 » Fri Nov 02, 2018 07:30

auouymous - that's how it currently works with mobs not giving up until player is out of range or pathfinding kicks in and they find a way to get to the player, fireballs dont need line of sight but I will add a runaway when health gets too low, that would be fun :)
 

Astrobe
Member
 
Posts: 151
Joined: Sun Apr 01, 2018 10:46

Re: [Mod] Mobs Redo [1.47] [mobs]

by Astrobe » Tue Nov 06, 2018 20:23

Sorry for the delay, I was tuning and testing various things.

First, this is not a "fork" properly speaking, it's a "private edition". I removed the pathfinding code, I removed the explosing creeper code, etc. because I don't use them in my game and they were in the way when I was making my edits.

It's also not under git cause I'm a pig. Sorry.

Actually I, intended to PM it directly to TenPlus1, but unless I'm mistaken one cannot attach files to PM, so I post it here.

Aside from what I've mentioned, there is a slight improvement for the arrow collision detection code. The current code is problematic with mobs whose collision box starts at y=0 (like many if Doom's mobs). There are remains of my previous attempt, which tried to use accurately collision boxes, but for some reason sometimes arrows would go through the mob. The current method works better. It needs a bit more work though because now two arrows may collide (which is not what I want, don't know about other users).

THE ATTACHED FILE IS FOR REFERENCE ONLY. Do not use as-is.
Attachments
mobs-redo-api-only.zip
For modders only
(19.9 KiB) Downloaded 9 times
 

User avatar
TenPlus1
Member
 
Posts: 2404
Joined: Mon Jul 29, 2013 13:38
GitHub: tenplus1

Re: [Mod] Mobs Redo [1.47] [mobs]

by TenPlus1 » Thu Nov 08, 2018 20:23

Atorian37: Bee's spawn in the world around flowers in any biome, they can be rare and never found higher up.
 

Astrobe
Member
 
Posts: 151
Joined: Sun Apr 01, 2018 10:46

Re: [Mod] Mobs Redo [1.47] [mobs]

by Astrobe » Fri Nov 09, 2018 17:32

Sorry, I missed that post.

auouymous wrote:
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...


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.


30-60 seconds is way too long, especially when, because of other limitations, the mob spends that time rubbing its face against a wall.

You are correct that you can see lock/lose targets simply by fighting in a forest. I don't mind this behavior because the foes in my game are not humanoids, so a little bit of dumbness is acceptable to me.

However, because the mob is oriented towards the player's last known position, it eventually finds you. The other change I suggested - turn towards the nearest player independently of LoS - might contribute to this but I believe it is really minor.

One improvement that can be made, though, is to switch to kind of a "rush/run state", basically a walk state but with running animation and speed, in order to hide the switch a little more.

Astrobe wrote:Shooting mobs should check their line of sight before shooting too.


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.


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.

It's a minor issue though, as I believe games don't often let mobs shoot TNT-like explosive stuff outside of controlled environments like mines.

Astrobe wrote:One (really) last thing: the runaway behavior which is probably underused.


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.


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.

I believe these tactics won't work or would be detrimental because of the generous hit boxes and the usual range and speed superiority over mobs of the players. The runaway behavior I have implemented and suggested really work for flying mobs, who actually have a chance to survive; for walking mobs it's mostly for the show: there is some satisfaction for players sometimes to hunt down and kill a fleeing mob that ambushed them, for instance.

Improvement can be found in combinations of simple features. For instance my spiders come from cobwebs and regenerate health when in them (*). So when they are about to die they often look like they runaway to the safety of cobwebs (but sometimes they just go rub their faces against some wall too).

A feature that could be useful, and maybe more general than the "runaway when low HP" behavior would be to provide a "drops to low HP" callback, so that modders can do what they want - runaway, perform a super-jump, teleport, throw a net to the player, etc.

(*) I think there are traces of this in the file I gave, next to some crap about "melding". The right thing to do is to implement a table for node-specific damage-over-time, which would allow damage by air for sea critters.
 

User avatar
Lone_Wolf
Member
 
Posts: 1939
Joined: Sun Apr 09, 2017 05:50
Location: Hopefully very far from yours, snoop :P
GitHub: LoneWolfHT
IRC: Lone_Wolf
In-game: Lone_Wolf

Re: [Mod] Mobs Redo [1.47] [mobs]

by Lone_Wolf » Fri Nov 09, 2018 20:42

Why not set it up so that when a mob loses sight of a player it walks to the last position it saw the player?
 

User avatar
runs
Member
 
Posts: 56
Joined: Sat Oct 27, 2018 08:32
GitHub: runsy

Re: [Mod] Mobs Redo [1.47] [mobs]

by runs » Fri Nov 09, 2018 20:46

Hey TenPlus1 so take ideas to improve your mod, please.

:-)
 

PreviousNext

Return to Mod Releases



Who is online

Users browsing this forum: No registered users and 13 guests