.qc (dot qc) - the group for quake c coders of all denominations. If you make quake one mods and write code in quake c, join our group! I'll try to answer any quake c questions - please post your inquiry in the forums...

Forum Thread
SV_PushMove issue (Groups : qc : Forum : vault() : SV_PushMove issue) Locked
Thread Options
numbersix quake-c coder++
Sep 6 2016 Anchor

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
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.


 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


-*- Support free code: Patreon.com

Oct 31 2016 Anchor

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;


rqcoop20161031235128 00

Edited by: Teknoskillz

numbersix quake-c coder++
Dec 4 2016 Anchor

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.


-*- Support free code: Patreon.com

Reply to thread
click to sign in and post

Only registered members can share their thoughts. So come on! Join the community today (totally free - or sign in with your social account on the right) and join in the conversation.