monster_spawn function?

[hondobondo]

DMSP is a mod that spawns monsters in deathmatch maps, which is why it is called DMSP. (Deathmatch single player). http://strlen.com/maps/dmsp/index.html

Back story done, continuing ... this mod spawns monsters out of thin air.

1) dmsp.qc thread: viewtopic.php?t=2587 where hondobondo shares dmsp.qc which I guess he got from Aardappel.
2) This .qc file is in the download here: http://www.moddb.com/members/hondobondo ... collection

i talked to aardappel and he said it was ok if i used decompiled code. i have changed it a bit though.

(1) the monster stuff has to be precached
(2) when you spawn the monster you have to call the telefrag function
(3) this code dmsp.qc cycles through info_player_deathmatch locations to find empty spots
(4) then entity = spawn(); pretty easy

i hate reinventing the wheel. i dont know why anyone would want to do that. it works pretty flawlessly. you can set it up to spawn monsters from any entity origin, hardcoded to the map or whatever.

[hondobondo]

i was also able at one point to spawn an entire set of monsters in one spot, for some reason i never used it

you have to create a loop, then set origin to origin_x + n

while (n < 256)
{
monster spawn code
setorigin(monster,origin_x + n);
n = n + 32;
}

just adapt the dmsp.qc stuff

[ajay]

Ok, I'm trying to use the excellent examples here for my mod. Breakdown on what I want to happen:
- Monsters need to appear at a pre-arranged point in the map ("The Gate")
- What/how many monsters will be dependent on what "goal" the player has reached, so they'll need to be a "if (goal_mission == 1)" type of thing going on, into which I'll set the type/number etc
- They'll be separate points for each monster that arrives (info_monster_arrival_1, info_monster_arrival_2 etc) but which will be re-used for each goal_mission ("wave")
- They'll be a total number of "info_monster_arrival_" 's, though not all will be used for each goal_mission - I'll not need to check they're clear though

My questions are these:
- obviously is this all do-able?
- can you create "info_monster_arrival" points (instead of info_player_start"); is there anything I need to do other than create them in quake.fgd and then use them in the spawn code instead of info_player_start?
- could someone explain the precaching a bit more - do I just need to precache the mdl or is there anything else, and where? In the new .qc or world.qc, defs etc?

Thanks as always
ajay

[goldenboy]

- obviously is this all do-able?

Yes.

- can you create "info_monster_arrival" points (instead of info_player_start"); is there anything I need to do other than create them in quake.fgd and then use them in the spawn code instead of info_player_start?

Yes. It doesn't matter what to call the entity, the new spawn just needs to know where to appear. There are several ways to accomplish this, either have the spawn code check for a free spot in the vicinity or assign a free spawn point after some sort of pattern.

Entities are not created in .fgd files anyway, they have spawn functions (monster_army in the qc is a spawn function) that are called during map load. .def and .fgd files are just for the map editor. Apples and oranges.

- could someone explain the precaching a bit more - do I just need to precache the mdl or is there anything else, and where? In the new .qc or world.qc, defs etc?

You must precache all sounds and models the new spawn could theoretically require during its lifetime, and what's more, you must call these precaches during map load (in some entity's spawn function or even in worldspawn / world.qc) - otherwise you'll get the "precaches can only be done in spawn functions" error. This is the reason why RMQ (and Drake IIRC) monsters have dedicated precache functions separate from their spawn functions; if they are to be spawned at runtime, someting else calls their precaches during map load, long before their spawn function is run.

The alternative is to place one of every monster in an inaccessible area of your map, because then they can normally call all their precaches.

Try it and see what error messages you get. Then fix one problem after the other.

[ajay]

Thanks gb, great answer, very helpful
ajay

[Seven]

Hello ajay,

Regarding precaching:
The worldspawn () function (in world.qc) has been commented nicely (even in original 1.06 source code). So you can quickly see how and what to precache there.

Regarding monster "waves":
Will you use your own maps, or will/shall your mod be playable with existing maps ?
The positioning of "The Gate" is the most sensible thing in case 2.
Which should not be a problem in case 1, because you know the exact x/y/z coordinate.

Once you set your "Gate" origin/position, you maybe want to take a look into the source of the "IQ reprised" mod:
http://quakeone.com/forums/quake-mod-re ... rised.html
ezzetabi coded a "monster-wave" into Entar´s IQ mod.
ezzetabi described that "monster-wave" function in the thread itself and I think this code could be very useful for you.
He uses the position of the killed enemies as "The Gate" for new enemies.
That is the only difference to your idea I guess, which should make it even 'easier' to implement it (with a fixed/static "Gate").

Good luck,
Seven.

[Seven]

Dear all,

I didnt want to start a new thread for that small question I have:
It always wondered me what exactly happens (engine and file sided) when a file is precached.
Is that model/sound written into a big temporary file (like the windows pagefile.sys) or into ram ?

Next question is, will one file be precached everytime a precache codeline is read by the engine ?
Example the monsters spawn functions:
They precache the monsters individual models + sounds.
But when a map has 20 soldiers, will these files be precached 20 times ?
Or does the engine notice that it already precached that model/sound and skips it next time.

Due to the fact that I use the "dp-precache-anywhere-anytime" extension, I wonder if loading time will be affected
when a single file is precached 10 times, or does the engine skip it after it was precached 1st time.

Thank you for your answer.

[mankrip]

They use the RAM, not a temporary file.

The precache functions creates a list of files to be cached, and repetitions are skipped. So, when you have 20 soldiers, only one instance of the soldier.mdl will be cached.

Also, the actual data that is currently not in use can be unloaded from memory (for example, shamblers that are hidden very far away, if no other shambler is currently visible), and the engine will reload their files from disk (and back into the same positions in the lists) when needed.

If I understand it correctly, all that the DP extension does is to allow more items to be added to those lists in the middle of the game. This may have some impact on savegames that uses the .modelindex of models that were loaded after worldspawn, but nothing else.

[Spike]

precaching does two things:
1: establishes a link from model -> modelindex -> model. this means 1-byte modelindexes can be used over the network instead of entire strings, and the client can use direct lookups to get a pointer to the memory representation of the file.
2: moves loading/disk-based stalls to a loading screen, instead of the game randomly freezing when loading data/textures from the disk.

If you precache any time, there will be a window where the modelindex does not map to anything (if datagrams get through before reliables). this can cause issues if the resulting model pointer/size/etc is cached/dereferenced.
If the entity is animating this is generally fixed on the next update, but I gather dp can fail to update unmodified/unmoving entities.

late caching a bsp model is not recommended. this can result in lightmaps or other loadtime processing not being done (and will give awesome lighting glitches in fte, I assume dp is similar).

for monsters or missiles or whatever it should not be a real issue, so long as you don't mind the stalls.

[Seven]

Thank you mankrip and Spike.

That answeres all my questions.

And yes, even though I use dp´s extension, I precache files whenever possible in worldspawn or main monster spawn functions.
Only in rare conditions, where these files will be used only in certain circumstances I precache them several functions before they are used/called/spawned (to prevent unnesseccary precaching for all monsters, etc.)

Thank you again.

[Baker]

What a pain!

I ended up working through this without the benefit of finding this thread first

And then had the mystery of total_monsters not updating in the scoreboard.

Which after an intensive investigation, you do this after updating the count:

float SVC_UPDATESTAT = 3;
float STAT_TOTALMONSTERS = 12;

total_monsters = total_monsters +1;
WriteByte (MSG_ALL, SVC_UPDATESTAT);
WriteByte (MSG_ALL, STAT_TOTALMONSTERS);
WriteLong (MSG_ALL, total_monsters);