Mobkit - Entity API [mobkit][alpha]

Andrey01 · by **Andrey01** » Sat Dec 07, 2019 09:36 Post

As I`ve understood now, this error about what I talked above is caused by this line: head_obj:set_attach(self.object, "", rel_pos, {x=deg(rot.x), y=deg(rot.y), z=deg(rot.z)})

head_obj is head object, it was set successful in the world. rel_pos is a position relatively to the torso`s origin that takes the coords table from 'pos' field in the entity def. It`s just strange, may your API not allow to attach any objects to the main ones?

Termos · by **Termos** » Sat Dec 07, 2019 16:24 Post

Andrey01 wrote:It`s just strange, may your API not allow to attach any objects to the main ones?

It definitely does, check sailing_kit code, it does just that.
If you mean that lastvelocity problem, I'm pretty sure it's unrelated to set_attach, probably there's an entity connected to stepfunc and not connected to actfunc. I'd have to check out your code to be able tell more.

Gundul wrote:The eagle already flies very nicely. Best results I had so far in singleplayer.

I failed to reproduce the Zombietest problem locally, i tried increasing server step to 3s, releasing hundreds of birds at once, they can maintain height no matter what I do.

Can you try increasing their params in ZT? Around line 194:
if mobkit.is_queue_empty_low(self) then aerotest.lq_fly_pitch(self,0.6,12,(random(2)-1.5)*30,2,'fly') end

Andrey01 · by **Andrey01** » Sat Dec 07, 2019 21:15 Post

I`ve already decided that problem by adding checking name of the entity in each function ('actfunc', 'stepfunc' and 'stepfunc'). It must not be equal to the name of the zombie head object and then it will omit the further code.

But: the next problem is caused! After the restart the singleplayer or server it leaves last head object and then add and attach other one:

Talking in-short how I implemented the saving of the head attachment after the restart: default, as I understood, all attached entities are detached and all other together with them are deleted from the memory before the restart. That`s why it`s important to save real positions of all head objects, in given case they are saved to mobkit.saved_heads_data, but at first that table saves head objects instead each time when the torso ones are instantiated (mobkit.actfunc). The look of all current fields is [<string torso pos>] = <head obj>. When a singleplayer or a server is intended to shut down, mobkit.before_shutdown is triggered that replaces each the table value to <head object pos>.

My code:

Code: Select all

function mobkit.before_shutdown()
    for tpos, head in pairs(mobkit.saved_heads_data) do
            mobkit.saved_heads_data[tpos] = head:get_pos()
    end
    
    minetest.debug("2")
    minetest.debug(dump(mobkit.saved_heads_data))
end

function mobkit.actfunc(self, staticdata, dtime_s)
    local name = self.name
    if name ~= "zombiestrd:zombie_head" then
    -- head attaching
	local headname = minetest.registered_entities[name].head
	if headname then
	     local selfpos = self.object:get_pos()
	     local strpos = minetest.pos_to_string(selfpos)
	     local head_obj
	     local rel_pos = minetest.registered_entities[headname].pos
	     minetest.debug("1")
	     minetest.debug(dump(mobkit.saved_heads_data))
	     if not mobkit.saved_heads_data[strpos] then
	            local real_pos = {x = selfpos.x+rel_pos.x, y=selfpos.y+rel_pos.y, z=selfpos.z+rel_pos.z}
	            head_obj = minetest.add_entity(real_pos, headname)
	     else
	            minetest.debug("minetest")
	            head_obj = minetest.get_objects_inside_radius(mobkit.saved_heads_data[strpos], 0)
	            mobkit.saved_heads_data[strpos] = nil
	     end
	     
         mobkit.saved_heads_data[strpos] = head_obj
	     local rot = self.object:get_rotation() 
	     head_obj:set_attach(self.object, "", rel_pos, {x=deg(rot.x), y=deg(rot.y), z=deg(rot.z)})
	end
	self.logic = self.logic or self.brainfunc
	self.physics = self.physics or mobkit.physics
	
	self.lqueue = {}
	self.hqueue = {}
	self.nearby_objects = {}
	self.nearby_players = {}
	self.pos_history = {}
	self.path_dir = 1
	self.time_total = 0
	self.water_drag = self.water_drag or 1
	local sdata = minetest.deserialize(staticdata)
	if sdata then 
		for k,v in pairs(sdata) do
			self[k] = v
		end
	end
	
	if self.timeout and self.timeout>0 and dtime_s > self.timeout and next(self.memory)==nil then
		self.object:remove()
	end
	
	if not self.memory then 		-- this is the initial activation
		self.memory = {} 
		
		-- texture variation
		if #self.textures > 1 then self.texture_no = random(#self.textures) end
	end
	
	-- apply texture
	if self.texture_no then
		local props = {}
		props.textures = {self.textures[self.texture_no]}
		self.object:set_properties(props)
	end

--hp
	self.max_hp = self.max_hp or 10
	self.hp = self.hp or self.max_hp
--armor
	if type(self.armor_groups) ~= 'table' then
		self.armor_groups={}
	end
	self.armor_groups.immortal = 1
	self.object:set_armor_groups(self.armor_groups)
	
	self.buoyancy = self.buoyancy or 0
	self.oxygen = self.oxygen or self.lung_capacity
	self.lastvelocity = {x=0,y=0,z=0}
	self.sensefunc=sensors()
	
	end
end

Termos · by **Termos** » Sun Dec 08, 2019 09:28 Post

Andrey01 wrote:Talking in-short how I implemented the saving of the head attachment after the restart:

Wait, don't.
Just make heads' static_save=false a requirement and have the torso spawn a new one on every activation.

Andrey01 wrote:adding checking name of the entity in each function ('actfunc', 'stepfunc' and 'stepfunc'). It must not be equal to the name of the zombie head object and then it will omit the further code.

That sounds very redundant. Do you still insist on connecting heads to the api for some reason?

Andrey01 · by **Andrey01** » Sun Dec 08, 2019 16:37 Post

Termos wrote:have the torso spawn a new one on every activation.

Umm, why do you say I need to have torso spawn a new one? It should stay the same after the restart, I mean the same coords, right?

Termos wrote:Do you still insist on connecting heads to the api for some reason?

Yes, I`m making it.

Termos · by **Termos** » Sun Dec 08, 2019 18:23 Post

Andrey01 wrote:Umm, why do you say I need to have torso spawn a new one? It should stay the same after the restart, I mean the same coords, right?

Better question, why save? Coords are always the same, and persisting rotation makes no sense whatsoever. Just reattach a new head instead of wasting resources.

You mention referencing specific entity names in on_activate, that kind of thing has no place in an api, maybe start with a mod instead?

Termos · by **Termos** » Mon Dec 09, 2019 19:38 Post

Update 191209

fixes:

fixed possible crash on slow machines, where entities can spawn in water next to unloaded blocks.

fixed possible problem on slow machines when entity timeout is set shorter than dtime duration.

Andrey01 · by **Andrey01** » Wed Dec 11, 2019 22:56 Post

Termos, I don`t understand why after the instantiation of the zombie torso for a while a bunch of heads are starting to be spawned around that instead of to just spawn a sole head and attach it to the torso. Maybe is on_activate called not one time for each entity?

My mobkit fork: https://github.com/Andrey2470T/mobkit/tree/head_turning

Zombiestrd fork: https://github.com/Andrey2470T/zombiest ... head_turns

Termos · by **Termos** » Thu Dec 12, 2019 13:09 Post

Andrey01 wrote:Termos, I don`t understand why after the instantiation of the zombie torso for a while a bunch of heads are starting to be spawned around that instead of to just spawn a sole head and attach it to the torso. Maybe is on_activate called not one time for each entity?

That's why I suggested using static_save=false, multiple times.
Yes, on_activate is called every reactivation, if heads get saved, then every subsequent activation leaves behind an old orphan head from before.

Andrey01 · by **Andrey01** » Thu Dec 12, 2019 19:11 Post

Termos wrote:
Andrey01 wrote:Termos, I don`t understand why after the instantiation of the zombie torso for a while a bunch of heads are starting to be spawned around that instead of to just spawn a sole head and attach it to the torso. Maybe is on_activate called not one time for each entity?
That's why I suggested using static_save=false, multiple times.
Yes, on_activate is called every reactivation, if heads get saved, then every subsequent activation leaves behind an old orphan head from before.

If I set 'static_save=false', all objects won`t be saved what is bad. I think in such case a table with positions of all those objects is needed to revive them after a restart.

Termos · by **Termos** » Fri Dec 13, 2019 12:06 Post

Andrey01 wrote:If I set 'static_save=false', all objects won`t be saved what is bad. I think in such case a table with positions of all those objects is needed to revive them after a restart.

That's all incorrect.

I don't understand why you keep asking these questions only to refuse taking the answers.
Anyway, your problems are related to basic minetest api rather than mobkit, maybe try asking in modding discussion.

3D-BDET · by **3D-BDET** » Fri Dec 13, 2019 19:51 Post

Zombies are impossible to kill for me. Minetest 5.10 pcoslinux.

Termos · by **Termos** » Fri Dec 13, 2019 21:15 Post

3D-BDET wrote:Zombies are impossible to kill for me. Minetest 5.10 pcoslinux.

Aim for the head with a stone tool or better.
Here's the description.

Extex · by **Extex** » Fri Dec 13, 2019 21:58 Post

I just realised my flapping animation is glitchy

I fixed it

P.S. What happened to the texture? It's all discoloured

Gundul · by **Gundul** » Sat Dec 14, 2019 10:08 Post

Termos wrote: I failed to reproduce the Zombietest problem locally, i tried increasing server step to 3s, releasing hundreds of birds at once, they can maintain height no matter what I do.

Can you try increasing their params in ZT? Around line 194:
if mobkit.is_queue_empty_low(self) then aerotest.lq_fly_pitch(self,0.6,12,(random(2)-1.5)*30,2,'fly') end

I updated to latest mobkit version (master) and changed line 194 like you suggested above. It is still behaving weird.
Sometimes it suddenly drops down like a stone, or sometimes it flies straight upwards. But this only happens on ZombieTest, not in Singleplayer (or if I start a server on my home machine)

Termos · by **Termos** » Tue Dec 17, 2019 10:12 Post

Extex wrote:What happened to the texture? It's all discoloured

You mean that one in the demo? I had to reduce lightness because it was glowing.

Gundul wrote:Sometimes it suddenly drops down like a stone, or sometimes it flies straight upwards. But this only happens on ZombieTest, not in Singleplayer (or if I start a server on my home machine)

I got it!
...I think.

I was able to reproduce the problem by skipping engine steps and running calculations only every n-th step.

Physics systems based on acceleration are tricky, because stuff doesn't happen continuously like in rl, but in discrete steps of variable durations. If these steps take too long, as often happens on slow machines, velocities tend to grow too fast due to acceleration operating too long in the same direction, so these systems tend to stop self adjusting and become turbulent.

However, I found some room for improvement, this new version they were able to maintain altitude even when running only every 10th step, that's an order of magnitude so that must mean something.

Gundul · by **Gundul** » Tue Dec 17, 2019 15:19 Post

Termos wrote: I got it!
...I think.

I was able to reproduce the problem by skipping engine steps and running calculations only every n-th step.

Physics systems based on acceleration are tricky, because stuff doesn't happen continuously like in rl, but in discrete steps of variable durations. If these steps take too long, as often happens on slow machines, velocities tend to grow too fast due to acceleration operating too long in the same direction, so these systems tend to stop self adjusting and become turbulent.

However, I found some room for improvement, this new version they were able to maintain altitude even when running only every 10th step, that's an order of magnitude so that must mean something.

ZombieTest updated.

On a first test it looks like it works almost perfect now. Even on a very small machine machine like ZT.
Definitely the best flying mob I saw so far, imho :)

Termos · by **Termos** » Wed Dec 18, 2019 14:14 Post

Gundul wrote:On a first test it looks like it works almost perfect now. Even on a very small machine machine like ZT.
Definitely the best flying mob I saw so far, imho :)

Well, they still stand no chance against valleys' sugarloaf mountains and spikes, and sometimes client has trouble guessing where they are due to lag, but that's probably as good as it can get given the circumstances.

Do you have any statistics concerning engine step durations (dtime) on ZT? Average, max, that kind of thing?

Gundul · by **Gundul** » Wed Dec 18, 2019 14:55 Post

Termos wrote: Well, they still stand no chance against valleys' sugarloaf mountains and spikes, and sometimes client has trouble guessing where they are due to lag, but that's probably as good as it can get given the circumstances.

only a question of time. collision box of the eagle is not very big and a radar function of what is ahead of it should
be solveable. landing, starting from ground and hunting prey is maybe more difficult.

Termos wrote: Do you have any statistics concerning engine step durations (dtime) on ZT? Average, max, that kind of thing?

No I do not have any statistics. Anything minetest engine could provide ?

Termos · by **Termos** » Wed Dec 18, 2019 17:22 Post

Termos wrote:No I do not have any statistics. Anything minetest engine could provide ?

Don't know, haven't found anything.
Maybe I'm reinventing the wheel but I'm using stuff like the following for the purpose:

Code: Select all

local dttot=0
local dtavg=0
local dtnum=0
local dtmax=0
local dttimer = 10
minetest.register_globalstep(function(dtime)
	dttot=dttot+dtime
	dtnum=dtnum+1
	dtmax = dtime>dtmax and dtime or dtmax
	
	if dttot>dttimer then
		dttimer=dttimer+10
		minetest.chat_send_all('avg:'.. dttot/dtnum ..' max:'..dtmax ..' now:'.. dtime)
		dtmax=0
	end
end)

Gundul · by **Gundul** » Fri Dec 20, 2019 12:55 Post

Termos wrote: Don't know, haven't found anything.
Maybe I'm reinventing the wheel but I'm using stuff like the following for the purpose:

using your statistic code it says dtime average is 0.09.
dtime can have peaks of 0.3 to 0.8 when you move around a lot. Every now and then it can even
rise to short max peak of 2.x to 5.x. I guess that happens when server has to load and serve mapblocks to
the client. Maybe I should reduce max mapblocks sended to client at one time.

Termos · by **Termos** » Mon Dec 23, 2019 14:23 Post

Gundul wrote: using your statistic code it says dtime average is 0.09.
dtime can have peaks of 0.3 to 0.8 when you move around a lot. Every now and then it can even rise to short max peak of 2.x to 5.x.

That's roughly 3 times slower than my old laptop

Gundul wrote:I guess that happens when server has to load and serve mapblocks to
the client. Maybe I should reduce max mapblocks sended to client at one time.

I'm also getting an impression the problem may be mapgen related.
Sometimes blocks take quite a long time to load, and the no1 cause of bird deaths seems to be collisions with unloaded air blocks.
Also seems MT version dependent, 501 was okay-ish, 510dev is not so good, 510 stable was unplayable.

Lone_Wolf · by **Lone_Wolf** » Mon Dec 23, 2019 18:34 Post

mobkit.hq_goto() is returning before the mob reaches its destination (An un-walkable cobweb in this case)

Is this intended behavior? I can see why it might be. Checking just in case though

Termos · by **Termos** » Mon Dec 23, 2019 20:50 Post

Lone_Wolf wrote:mobkit.hq_goto() is returning before the mob reaches its destination

It's difficult to make them stop on exact position, so it has to be a position within certain radius from target. I just don't remember why I made the radius so damn wide ;)
Anyway, builtin behaviors are examples really, hq_goto is very simple, for now you can copy it over to your mod (and change the namespace name) adjust the radius and use that instead.

I'm definitely going to make the radius a parameter and reduce the default a lot.

Lone_Wolf · by **Lone_Wolf** » Tue Dec 24, 2019 00:29 Post

Termos wrote:It's difficult to make them stop on exact position, so it has to be a position within certain radius from target. I just don't remember why I made the radius so damn wide ;)
Anyway, builtin behaviors are examples really, hq_goto is very simple, for now you can copy it over to your mod (and change the namespace name) adjust the radius and use that instead.

I'm definitely going to make the radius a parameter and reduce the default a lot.

Alrighty, thanks

Minetest Forums

Mobkit - Entity API [mobkit][alpha]

Re: Mobkit - Entity API [mobkit][alpha]

Re: Mobkit - Entity API [mobkit][alpha]

Re: Mobkit - Entity API [mobkit][alpha]

Re: Mobkit - Entity API [mobkit][alpha]

Re: Mobkit - Entity API [mobkit][alpha]

Re: Mobkit - Entity API [mobkit][alpha]

Re: Mobkit - Entity API [mobkit][alpha]

Re: Mobkit - Entity API [mobkit][alpha]

Re: Mobkit - Entity API [mobkit][alpha]

Re: Mobkit - Entity API [mobkit][alpha]

Re: Mobkit - Entity API [mobkit][alpha]

Re: Mobkit - Entity API [mobkit][alpha]

Re: Mobkit - Entity API [mobkit][alpha]

Re: Mobkit - Entity API [mobkit][alpha]

Re: Mobkit - Entity API [mobkit][alpha]

Re: Mobkit - Entity API [mobkit][alpha]

Re: Mobkit - Entity API [mobkit][alpha]

Re: Mobkit - Entity API [mobkit][alpha]

Re: Mobkit - Entity API [mobkit][alpha]

Re: Mobkit - Entity API [mobkit][alpha]

Re: Mobkit - Entity API [mobkit][alpha]

Re: Mobkit - Entity API [mobkit][alpha]

Re: Mobkit - Entity API [mobkit][alpha]

Re: Mobkit - Entity API [mobkit][alpha]

Re: Mobkit - Entity API [mobkit][alpha]

Who is online