|
Re: Left over healthbar visible
[Re: Realspawn]
#469448
11/16/17 17:18
11/16/17 17:18
|
Joined: Jul 2014
Posts: 72
DriftWood
Junior Member
|
Junior Member
Joined: Jul 2014
Posts: 72
|
Remove bar too..
while(1)
{
if (ent_owner)
{
vec_set (my.x, ent_owner.x);
my.z += 15;
my.scale_x = ent_owner.health * 0.2; // skill20 aka "health" stores the health for each entity
}
else
{ ent_remove(me); // remove bar
}
wait (1); // move "while - wait " here
}
}
Post from mobile check for errors ok.
|
|
|
Re: Left over healthbar visible
[Re: DriftWood]
#469449
11/16/17 18:00
11/16/17 18:00
|
Joined: Jun 2007
Posts: 1,337 Hiporope and its pain
txesmi
Serious User
|
Serious User
Joined: Jun 2007
Posts: 1,337
Hiporope and its pain
|
@DriftWood So, certainly, you have to remove entities from the scene in order to remove entities from the scene. I never would have imagined! Unfortunately, your example crashes the same because ent_owner will point to a removed object the same. Engine handles are the way to go with beginners, or the best, no bar action at all.
|
|
|
Re: Left over healthbar visible
[Re: txesmi]
#469454
11/16/17 20:21
11/16/17 20:21
|
Joined: Jul 2014
Posts: 72
DriftWood
Junior Member
|
Junior Member
Joined: Jul 2014
Posts: 72
|
Well, if ent_owner has been removed than it's pointer should be set to NULL.
So simply changing the first if(ent_owner) to if(ent_owner != NULL) , Should fix a crash. If the local pointer is still set to a value, than ent_remove/ptr_remove has failed as the engine should set it to NULL.
A pointer should not be used as a Boolean anyway.
Unless I'm wrong in something.
Edit - Using the safe_remove macro to remove the owner should fix an error if one still exist because a pointer is still valid.
But can agree that if a beginner doesn't understand pointers they should use handles. Also yes, I would wrap the health bar code right into the owner's action. But Spawn is following the AUM.
I'm am not a beginner lol, I actually forget most the stuff I've learned.
Last edited by DriftWood; 11/16/17 20:34.
|
|
|
Re: Left over healthbar visible
[Re: DriftWood]
#469456
11/17/17 00:41
11/17/17 00:41
|
Joined: Jun 2007
Posts: 1,337 Hiporope and its pain
txesmi
Serious User
|
Serious User
Joined: Jun 2007
Posts: 1,337
Hiporope and its pain
|
So simply changing the first if(ent_owner) to if(ent_owner != NULL) , Should fix a crash. If the local pointer is still set to a value, than ent_remove/ptr_remove has failed as the engine should set it to NULL. I am afraid you are wrong. The engine has no responsability about the variables of your own. It will never change them, as spected. When you declare a pointer in your code it is yours. The object where the pointer points to is another story. ent_owner is a ENTITY* type variable of his own allocated in the stack that contains the address of an entity, no more relation between the pointer and the entity. In fact you can make the pointer point to other entity at any time if desired. When you save the address of an object in a pointer of your own and the object is removed somewhere else, the pointer of your own remains unchanged. In other words, it will never be NULL unless you fill it yourself. It can not be other way. So since the pointer continues pointing to the same address but the object has been removed, it crashes when trying to access to it. When refered to beginners I was speaking about the target of his template xP
|
|
|
Re: Left over healthbar visible
[Re: txesmi]
#469457
11/17/17 02:13
11/17/17 02:13
|
Joined: Jul 2014
Posts: 72
DriftWood
Junior Member
|
Junior Member
Joined: Jul 2014
Posts: 72
|
@txesmi - Yes indeed. I'm super rusty. You are totally correct. It's the me/you pointers that are set to NULL. I Apologise. @Spawn wrap it into the owner action like.
Action owner()
{
// Owner Stuff
stuff ;
// Hbar stuff
Entity* ent_hbar = Ent_create(//healhbar modle);
set (ent_hbar, BRIGHT | PASSABLE);
ent_hbar.lightrange =60;
ent_hbar.ambient = 60;
while(my.health > 0)
{
// Owner Stuff
stuff;
// Hbar stuff
if (my.health > 0)
{
vec_set (ent_hbar.x, my.x);
ent_hbar.z += 15;
ent_hbar.scale_x = my.health *0.2; // skill20 aka "health" stores the health for each entity
}
Wait(1);
}
ent_remove(ent_hbar);
ent_remove(me);
}
From mobile, check for errors.
|
|
|
Re: Left over healthbar visible
[Re: txesmi]
#469494
11/18/17 13:23
11/18/17 13:23
|
Joined: Jul 2001
Posts: 4,801 netherlands
Realspawn
OP
Expert
|
OP
Expert
Joined: Jul 2001
Posts: 4,801
netherlands
|
As I always state i am no pro coder and do this purely for the fun of it. When something works problem free it works isn't that the purpose ? The solution i have works and has less rescripting then the stuff mentioned What i ment is that i find it often that people telling a script from aum is wrong or should be scripted in an otherway so i don't complain about aum but at the remarks in this forum about scripts used from it. The word template does not say it is scripted perfect it says its a working game without errors that can easy be adapted and changed. And that is what i aim for.
Last edited by Realspawn; 11/18/17 13:24.
|
|
|
Re: Left over healthbar visible
[Re: Realspawn]
#469495
11/18/17 13:56
11/18/17 13:56
|
Joined: Jun 2007
Posts: 1,337 Hiporope and its pain
txesmi
Serious User
|
Serious User
Joined: Jun 2007
Posts: 1,337
Hiporope and its pain
|
When something works PROBLEM FREE it works isn't that the purpose ? ... it says its a working game WITHOUT ERRORS that can easy be adapted and changed ...
That is a perfect description of what your code is not. It runs circumstantially because the engine does not overwrite the parents entitys address, not because it is problem free or without errors.
|
|
|
|