Need QuakeC help: can't get decals/bulletholes to work with spawned in BSP entities.

[Haeylleh]

Static entities seem to get decals allowed:

/*
=====================
CL_ParseStatic
=====================
*/
static void CL_ParseStatic (int large)
{
entity_t *ent;

if (cl.num_static_entities >= cl.max_static_entities)
Host_Error ("Too many static entities");
ent = &cl.static_entities[cl.num_static_entities++];
CL_ParseBaseline (ent, large);

if (ent->state_baseline.modelindex == 0)
{
Con_DPrintf("svc_parsestatic: static entity without model at %f %f %f\n", ent->state_baseline.origin[0], ent->state_baseline.origin[1], ent->state_baseline.origin[2]);
cl.num_static_entities--;
// This is definitely a cheesy way to conserve resources...
return;
}

// copy it to the current state
ent->render.model = CL_GetModelByIndex(ent->state_baseline.modelindex);
ent->render.framegroupblend[0].frame = ent->state_baseline.frame;
ent->render.framegroupblend[0].lerp = 1;
// make torchs play out of sync
ent->render.framegroupblend[0].start = lhrandom(-10, -1);
ent->render.skinnum = ent->state_baseline.skin;
ent->render.effects = ent->state_baseline.effects;
ent->render.alpha = 1;

//VectorCopy (ent->state_baseline.origin, ent->render.origin);
//VectorCopy (ent->state_baseline.angles, ent->render.angles);

Matrix4x4_CreateFromQuakeEntity(&ent->render.matrix, ent->state_baseline.origin[0], ent->state_baseline.origin[1], ent->state_baseline.origin[2], ent->state_baseline.angles[0], ent->state_baseline.angles[1], ent->state_baseline.angles[2], 1);
ent->render.allowdecals = true;
CL_UpdateRenderEntity(&ent->render);
}

" Mr. Bougo Offline
Author of commit e128932
*******
Posts: 4,316
Joined: Mar 2010
Reputation: 108
RE: QuakeWiki revival
I believe the static entities are the brush-based ones. Like lifts, doors, perhaps some trigger brushes, etc.

EDIT: And, since 2010, DP supports 256 static entities when compiled with SMALLMEMORY #define'd, but 1024 otherwise. "

[Haeylleh]

Maybe there is a prvm edict to set allowdecals?

[Haeylleh]

I can't find where it would start up a regular model entity

[Haeylleh]

Tryd putting in various places in cl_main.c...
ent->render.allowdecals = TRUE; //See if this does it

(didn't work)

[Zop]

At first I thought you made up .allowdecals, and were hoping it would just work. I see it's an actual field, in the c code, but quakec has access to many less fields.

Quakec calls the spawn() function, and you should be able to find that in the code. You also hit a bit of a jackpot with static entities. There is a quakec function called makestatic() that turns entities static. Such entities they can no longer move, think, or be removed(), so hopefully that's ok.

[Haeylleh]

There is a quakec function called makestatic() that turns entities static. Such entities they can no longer move, think, or be removed(), so hopefully that's ok.

These entities need to beable be removed. A nuclear bomb can wreck them. Also DP only allows 1024 static entities.

Im going to try that out tho, to see if the makestatic(); lets it have decals, will report back.

[Haeylleh]

makestatic(self); didn't work too well.

The models don't show up at all after that.

I need away to allowdecals on the models regular.
They're tricked where they intersect the world, the engine thinks it's aight to add decals to those surfaces.

Could it be done prvm edict?

[Cobalt]

If they are gonna move the decal more or less has to track the other ent with respect to its origin and angles. Thats why MOVETYPE_FOLLOW would be my first choice. Calculating the relative angles of the follow_ent can be challenging though depending on maybe if the other ent is changing frames, and thereby showing a different shape for ex.

[frag.machine]

This example comes with dpextension.qc:

//DP_MOVETYPEFOLLOW
//idea: id Software, LordHavoc (redesigned)
//darkplaces implementation: LordHavoc
//movetype definitions:
float MOVETYPE_FOLLOW = 12;
//description:
//MOVETYPE_FOLLOW implemented, this uses existing entity fields in unusual ways:
//aiment - the entity this is attached to.
//punchangle - the original angles when the follow began.
//view_ofs - the relative origin (note that this is un-rotated by punchangle, and that is actually the only purpose of punchangle).
//v_angle - the relative angles.
//here's an example of how you would set a bullet hole sprite to follow a bmodel it was created on, even if the bmodel rotates:
//hole.movetype = MOVETYPE_FOLLOW; // make the hole follow
//hole.solid = SOLID_NOT; // MOVETYPE_FOLLOW is always non-solid
//hole.aiment = bmodel; // make the hole follow bmodel
//hole.punchangle = bmodel.angles; // the original angles of bmodel
//hole.view_ofs = hole.origin - bmodel.origin; // relative origin
//hole.v_angle = hole.angles - bmodel.angles; // relative angles

Everything is handled by the engine, no need of extra code to track anything.

[Haeylleh]

DP has built in decals.
You can see it's working on the worldspawn bsp and also where the other bsp entities are near a surface of the worldspawn bsp. Also static ents spawned by the worldspawn have decals. There is an internal variable (allowdecals) that seems to allow it. It is not conventionally accessable via QC and I don't know how to get it to allow a func_clientwall to get allowdecals'ed.

[Cobalt]

True, I was meaning that it can be challenging, depending on what you are wanting to to , to determine the relative angles and position of the follow ent with respect to the ent its intending to follow. More of a statement that shows my shortcomings in advanced math I guess.

This example comes with dpextension.qc:

//DP_MOVETYPEFOLLOW
//idea: id Software, LordHavoc (redesigned)
//darkplaces implementation: LordHavoc
//movetype definitions:
float MOVETYPE_FOLLOW = 12;
//description:
//MOVETYPE_FOLLOW implemented, this uses existing entity fields in unusual ways:
//aiment - the entity this is attached to.
//punchangle - the original angles when the follow began.
//view_ofs - the relative origin (note that this is un-rotated by punchangle, and that is actually the only purpose of punchangle).
//v_angle - the relative angles.
//here's an example of how you would set a bullet hole sprite to follow a bmodel it was created on, even if the bmodel rotates:
//hole.movetype = MOVETYPE_FOLLOW; // make the hole follow
//hole.solid = SOLID_NOT; // MOVETYPE_FOLLOW is always non-solid
//hole.aiment = bmodel; // make the hole follow bmodel
//hole.punchangle = bmodel.angles; // the original angles of bmodel
//hole.view_ofs = hole.origin - bmodel.origin; // relative origin
//hole.v_angle = hole.angles - bmodel.angles; // relative angles

Everything is handled by the engine, no need of extra code to track anything.

[Haeylleh]

These buildings

These buildings want decals: