SV_PushMove issue Thread - qc

SV_PushMove: entity #100 has an invalid modelindex 0.000000

server EDICT 100:
scale              0.5000
absmin         ' -985.0000   695.0000  -673.0000'
absmax         ' -983.0000   697.0000  -671.0000'
ltime              0.2000
movetype           7.0000
solid              4.0000
origin         ' -984.0000   696.0000  -672.0000'
velocity       '    0.0000     0.0000   -14.0000'
angles         '    0.0000    44.0000     0.0000'
classname      train
model          
use            train_use()
think          SUB_CalcMoveDone()
blocked        train_blocked()
nextthink         11.6286
spawnflags        16.0000
target         t17
noise          misc/null.wav
noise1         misc/null.wav
speed             14.0000
mdl            maps/alt_flt4b.bsp
dmg                2.0000
cnt                1.0000
think1         train_wait()
finaldest      ' -984.0000   696.0000  -832.0000'
classvn        func_train

This is loaded via an .ent file:

{
"angle" "44"
"speed" "14"
"classname" "func_train"
"mdl" "maps/alt_flt4b.bsp"
"target" "t17"
"spawnflags" "16"
"scale" "0.5"
}

I will update when research is complete.
My current thought is that func_train was modified for this special.

Correct:

 setmodel (self,self.model);

// Cataboligne - 6.3.14 - prelim for floaty rock deal
 if (self.spawnflags & 16)
  setmodel (self,self.mdl);

 setsize (self,self.mins,self.maxs);
 setorigin (self,self.origin);

Plats use a map brush based bsp model.
If you want to supply a .mdl or compiled .bsp model, you need to add the code, set spawnflags 16 and set the map entity "mdl" key to the model spec.

Edited by: numbersix

yea doors, plats and func walls are all inline map models, ie: "*44", "*83" etc. Turns out their edict number is almost the same incrementally except off by 1. Since they have hard coded absmns and absmaxs, cant use them except where they exactly are in quake units position,=.

Well sorta - :o)

I just moved a func_wall on the start map to a new loc, and then replicated it again in its spawn func to form another on top of it as per this pic.
So apparently func_wall can be moved with Quake C. Since it also has a star type model (IE: "*xx") this most likely means it can be done with plats, trains
and doors and buttons. However I tried doing this with a button, moving it on e2m6 and it would not go. I was coding that a little different than this experiment.

So if I read this right, the angles for all of these are hard set to VEC_ORIGIN. No doors, walls or buttons or trains in the IDmaps are at funky angles, always in 90 degree perspectives, its because a square / rectangle has to be that way so its determined when the map author draws the model in the map.

Basicly the code is:

void ()
func_wall =
{
self.angles = VEC_ORIGIN;
self.movetype = MOVETYPE_PUSH; // so it doesn't get pushed by anything
self.solid = SOLID_BSP;
self.use = func_wall_use;

setmodel (self, self.model);

if (self.model == "*69") // Cobalt for e2m6 alt layout
if (random () < 0.5)
self.origin_z = self.origin_z - (ceil(random () * 100) + 45);
else makestatic (self);
if (self.model == "*47" && mapname == "start") // Cobalt for start alt layout
{
//self.origin_z = self.origin_z - 64;
self.origin_z = self.origin_z + 183;
self.origin_y = self.origin_y - 312;
local entity dup;
dup = spawn ();
dup.angles = '0 0 0';
dup.classname = self.classname;
dup.solid = self.solid;
dup.movetype = self.movetype;
dup.use = self.use;
setmodel (dup, self.model);
dup.origin = self.origin;
dup.origin_z = dup.origin_z + 145;
}

};

Edited by: Teknoskillz

I better point this out...

	if (self.model == "*69")

The value "69" will not be entirely reliable.

When loaded with the same engine on the same mod, it should always be the same.

However, there is a possibility that a different engine might load bsp sub models differently.
Or, if you open the map in an editor and the sequence of entities is re-arranged. That happens with radiant.

A more ideal solution if you are compiling the map as well as writing the code is to use another field:

// in the maps func_wall entity -

{
"classname" "func_wall"
{
// brush 0
	[ brush data ]
}
"netname" "swall1"
}

// in the code

	if (self.netname = "swall1")
	{
		// code
	}

You know netname for that func_wall will always be "swall1".

If you are writing this code for a map where you have no source and using darkplaces based engines:

command sv_saveentfile: save map entities to .ent file (to allow external editing)

Then you can modify the entity data.
And yet, that .ent file may have a similar issue with bsp sub models as it also encodes them as "*{n}"

You can NOT change bsp data in the .ent file - that task requires re-compiling into the map proper.