Self-Lit damageable mushrooms: discuss

[OrbWeaver]

"Ready to burst" and "Splat" sounds are ready to go as soon as the entity is done.

[Fidcal]

Thanks Orb. I'll review this in the next few days.

[PranQster]

Make them, or some of them, so that they expel gas when they burst... and can be burst with an arrow. They could then be used, possibly, to knock out a guard standing next to one.

Or, they could make you, the player, black out and become immobile for a short time. Or, they could make everything get a bit 'weird' and disorienting for a bit (changing FoV and lighting effects). That could make it possible for an AI to find you while you are under the influence of the mushroom spores.

Edited July 4, 2010 by PranQster

[aidakeeley]

Holy multiple mushroom manifestations!

 

I really like that idea, PranQster.

 

And, of course they'll ill (yes only "ill") you too until you get smart and stay away from them bad 'uns.

Edited July 4, 2010 by aidakeeley

[PranQster]

In addition to drunk guards there could be guards trippin' on mushroom tea.

[nbohr1more]

In addition to drunk guards there could be guards trippin' on mushroom tea.

 

Hey!

 

Quit taking my ideas

 

http://forums.thedarkmod.com/topic/10969-dark-mod-theme-limits/

 

(yeah not quite the same... I guess I don't have full domain over hallucinations )

[Fidcal]

First quick test the colorme is not working (it worked in a separate test) and all my arrows just break on this mushroom. Also need to be able to set the radius as well as color. Also I see the very base of the mushroom brightly lit but no other light. Might be the light origin is right on the surface where the mushroom origin is.

 

entityDef atdm:breakable_mushroom
{
"inherit" "atdm:light_base"
"editor_usage"			"Breakable self-lit, colorme mushroom. Its light is turned off by damage."
"model"   "models/darkmod/nature/mushroom_02.lwo"
"editor_displayFolder"		"Lights/Mushrooms"
"skin"		"skin mushroom_selflit_green_colorme"
"_color"	"0.24 0.50 0.40"
"broken"  ""
"health"  "10"
}

[OrbWeaver]

Might be the light origin is right on the surface where the mushroom origin is.

 

Almost certainly that is the case. A model that is to be used as a light needs to have the origin in the place where the light should come from (although maybe there are other ways of binding a light which don't have this requirement).

[Fidcal]

Raising the light_center appears to fix that. I'll see if I can find any colorme light models that pass _color rather than just change the skin to switch on and off.

[Fidcal]

Can't seem to get any further with this.

 

Tels, if you want to take a look, I've committed

 

test/mushroom.map

def/test_mushroom.def

mtr/test_mushroom.mtr

skins/test_mushroom.skin

 

There is a working unlit colorme mushroom to prove that works. The new breakable mushroom is lit but the model shows black and won't break.

 

Overhead there is an electric colorme light and a lever somewhere to turn it on and off. It appears to work on part of the model (though I am unsure if that is not just illimunation from the light) but the light part of the model doesn't change.

 

There are lit and unlit colorme oil lamps but they are not convincing.

[Tels]

Can't seem to get any further with this.

 

Tels, if you want to take a look, I've committed

 

test/mushroom.map

def/test_mushroom.def

mtr/test_mushroom.mtr

skins/test_mushroom.skin

 

There is a working unlit colorme mushroom to prove that works. The new breakable mushroom is lit but the model shows black and won't break.

 

Overhead there is an electric colorme light and a lever somewhere to turn it on and off. It appears to work on part of the model (though I am unsure if that is not just illimunation from the light) but the light part of the model doesn't change.

 

There are lit and unlit colorme oil lamps but they are not convincing.

 

I'll have a look.

 

Edit: Hm, I am not sure, but it can be that a "colored" material doesn't work on a light. Here is what a light does:

 

void idLight::SetColor( float red, float green, float blue ) {
       // Tels: If the light is currently fading, stop this:
       fadeEnd = 0;
       BecomeInactive( TH_THINK );
       baseColor.Set( red, green, blue );
       SetLightLevel();
}

 

And here is what an entity does:

 

   renderEntity.shaderParms[ SHADERPARM_RED ]      = red;
   renderEntity.shaderParms[ SHADERPARM_GREEN ]    = green;
   renderEntity.shaderParms[ SHADERPARM_BLUE ]     = blue;
   UpdateVisuals();

 

Hm, I am not sure if this is a bug we should fix - currently lights do not change the color values for their models.

 

The colored lamps are in fact entities with an attached light - that is why they work.

 

About the arrows breaking: This seems to be an issue with "moss"?

About the not changing model when it break: You need to set a "brokenmodel" spawnarg so something. However, this is for entities, for lights you need to set "snd_broken" and "mtr_broken". ARRG! Why oh why did id make idLight not simply a subclass of "idEntity"? *sigh*

 

Anyway, I think the verdict is: Use a real entity of a mushroom, bind a light (with a snd and particle to it) and set "health" on it.

 

I am gonna try this next. Stand by.

[Tels]

Ok, got it to work:

 

 

For some inexplicable reason they turn into a bunch of flowers if you shoot them:

 

 

One thing I find rather perplex is that "idStaticEntity" cannot be destroyed, you need to use either "light" (which we can't), or "idDamagable". Ugh, why have another class just for damagable entities and not just make func_statics damagable?

 

This means I somehow need to add that functionality into idStaticEnitity, because otherwise you couldn't use these mushrooms as LOD entities. (idDamagable inherits from idEntity, as does idStaticEnitity, so the LOD code inside idStaticEntity is inaccessible to idDamagable - man I loathe this "one class for every special feature" design...)

 

For now, they work somehow (need still sound and particles and real models, tho), that is the most important part, but I have one more thing on my TODO..

[Tels]

Code change tracked here:

 

http://bugs.angua.at/view.php?id=2302

 

Already looked into it, seems easy, one maybe two hours of work to make idStaticEntities damagable, then remove the now useless idDamagable class.

[Fidcal]

But what effect will that have on existing statics?

[OrbWeaver]

Is it not possible to add the LOD functionality into the top-level idEntity class, rather than requiring LOD-enabled items to derive from idStaticEntity specifically?

[Tels]

But what effect will that have on existing statics?

 

None, as these do not use the "health" spawnarg and are thus still static :

[Tels]

Is it not possible to add the LOD functionality into the top-level idEntity class, rather than requiring LOD-enabled items to derive from idStaticEntity specifically?

 

I have pondered that, but since some classes f.i. override the Think() function (but don't call idEntity::Think()), they would f.i. not inherit LOD functionality etc. either. Also, a lot of classes override the Save()/Restore(), but don't f.i. save/restore other variables, so the LOD data would f.i. not get saved for idStaticEntities.

 

But in general I think that is the right way, so we don't repeat the same mistake again (functionality only available in a branch of the class tree).

[OrbWeaver]

I have pondered that, but since some classes f.i. override the Think() function (but don't call idEntity::Think()), they would f.i. not inherit LOD functionality etc. either. Also, a lot of classes override the Save()/Restore(), but don't f.i. save/restore other variables, so the LOD data would f.i. not get saved for idStaticEntities.

 

But in general I think that is the right way, so we don't repeat the same mistake again (functionality only available in a branch of the class tree).

 

That situation is an ideal use for the Non-Virtual Interface idiom. I.e.

 

1. idEntity provides a public Think method which is NOT virtual, and is not overridden by subclasses.

2. The non-virtual idEntity::Think does any common setup stuff, and then calls a protected virtual method with a different name (e.g. doThink()).

3. Subclasses override the doThink() method with their own custom code, and never have to worry about the common stuff which is dealt with by the non-virtual top-level Think() method.

 

Of course it would probably require considerable work to refactor existing code into this model (depending on how many classes there are), but it is an option for future additions.

[Tels]

That situation is an ideal use for the Non-Virtual Interface idiom. I.e.

 

1. idEntity provides a public Think method which is NOT virtual, and is not overridden by subclasses.

2. The non-virtual idEntity::Think does any common setup stuff, and then calls a protected virtual method with a different name (e.g. doThink()).

3. Subclasses override the doThink() method with their own custom code, and never have to worry about the common stuff which is dealt with by the non-virtual top-level Think() method.

 

Of course it would probably require considerable work to refactor existing code into this model (depending on how many classes there are), but it is an option for future additions.

 

Hm, I only know "the perl" way which works like this:

 

* base class provides a Think() method

* subclasses override Think() with their own, version, which also calles Baseclass::Think()

 

I *think* have even seen this in action in idStaticEntities, they call Entity::Think(). What would be the advantage from your system above?

[OrbWeaver]

Hm, I only know "the perl" way which works like this:

 

* base class provides a Think() method

* subclasses override Think() with their own, version, which also calles Baseclass::Think()

 

C++ can of course do that as well (as indeed it does in this case), but the unique distinction between virtual and non-virtual functions makes the NVI idiom possible as well. Other OO languages tend to treat all class methods as virtual, in which case the NVI idiom is still possible but in some cases you are simply relying on other classes not to override the public method, rather than being able to enforce it (or it can be enforced in other ways, such as with Java's final keyword).

 

I *think* have even seen this in action in idStaticEntities, they call Entity::Think(). What would be the advantage from your system above?

 

Calling the superclass method is perfectly legal of course, but in some cases is considered a "code smell", because the correct behaviour relies on subclasses doing it at the correct time, which they could fail to do. The NVI method takes away this responsibility from subclasses by providing a template method which they can override to contain only their custom code.

 

More information on the anti-pattern:

http://en.wikipedia.org/wiki/Call_super

[Tels]

C++ can of course do that as well (as indeed it does in this case), but the unique distinction between virtual and non-virtual functions makes the NVI idiom possible as well. Other OO languages tend to treat all class methods as virtual, in which case the NVI idiom is still possible but in some cases you are simply relying on other classes not to override the public method, rather than being able to enforce it (or it can be enforced in other ways, such as with Java's final keyword).

 

 

 

Calling the superclass method is perfectly legal of course, but in some cases is considered a "code smell", because the correct behaviour relies on subclasses doing it at the correct time, which they could fail to do. The NVI method takes away this responsibility from subclasses by providing a template method which they can override to contain only their custom code.

 

More information on the anti-pattern:

http://en.wikipedia.org/wiki/Call_super

 

Ah, interesting, Perl can (and does) both ways, with the only exception that classes are always free to override any method (although it is considered very bad coding style).

 

I keep that in mind when adding new things, but as you said, refactoring our code might be too much.

[Fidcal]

Just reviewing this. The easy quick way is I can go ahead and make new skins for

models/darkmod/nature/boletus_big.lwo

and finish off the def so when damaged they just disappear with a splat.

 

Any objections or alternate plans?

[Tels]

Just reviewing this. The easy quick way is I can go ahead and make new skins for

models/darkmod/nature/boletus_big.lwo

and finish off the def so when damaged they just disappear with a splat.

 

Any objections or alternate plans?

 

The only thing I want to do is make "idStaticEntity" damagable, and remove the "idDamagable" class, but that should't impact your work.

[Fidcal]

OK, I'll go ahead.

[Baddcog]

I'll make a big fat round mushroom this weekend with suitable 'flinders'. A nice gas cloud explosion would be cool.

 

I don't really see a need for LOD if it makes them complicated. They'll be fairly low poly anyway, and this is typically something a mapper wants to place specificallly for benefits of lighting/ambieance/gassing AI...(if we go the gas route).

Not something you want placed randomly like grass and flowers imo.