can you give example code?

I keep getting the "host error pf precache can only be done in spawn functions?"

regardless of where I put the monster's precache ? 

spawny.origin_x = (0.5 - random())* 2 * 5000; //It's origin is randomized
spawny.origin_y = (0.5 - random())* 2 * 5000;
spawny.origin_z = (0.5 - random())* 2 * 5000;

while((pointcontents(spawny.origin) != CONTENT_EMPTY) && (spawny.aflag < 75))
{
//If the pointcontents of the monster origin is not empty, reset it To a more suitable space. If no space can be found within 75 loops,
//Leave it where it last was placed.
spawny.origin_x = (0.5 - random())* 2 * 5000;
spawny.origin_y = (0.5 - random())* 2 * 5000;
spawny.origin_z = (0.5 - random())* 2 * 5000;

spawny.aflag = spawny.aflag + 1;
} 

The important part is not where you put the precaches, but REMOVING them from everywhere except worldspawn. If you are really struggling, remove all the precaches of the model until you start getting a different error about a resource NOT being precached. Then add one precache to worldspawn and you should be set. 

I didn't realize it was so simple! weird... i swore i did that before and it didn't work...

Ok so I can spawn the monster now and i can see the monster in front of me for a few sec, but then game crashes with "host error pr execute program null function" 

what controls how high or low a monster can step up/down?

seems they have trouble with stairs & small ledges? 

Best measure is 16 units,might be 15.
In a turnine stair it is better to keep the steplength more than 16, aproxemate 24. 

Look up #define STEPSIZE here

https://github.com/id-Software/Quake/blob/master/WinQuake/sv_move.c

The height for climbing a step is applied equally for both players and monsters. But one of the differences is how smoothly the movement is applied. A player moving at 360 units per second on a modern computer would have that movement split up into 72 segments of length 5. Each movement can climb one step, so the player can comfortably manage many steps close together.

In contrast, a monster moving forwards at 360 units per second would move in just 10 segments of 36 units each. And the movement is all or nothing - if the monster would need to climb TWO steps to reach the end point, it will collide with the second step and the entire movement is aborted.

So putting more horizontal spaces between the steps will help a lot. Monsters will also never go off a ledge with drop a of more than 1 step using walkmove or movetogoal - you have to give them velocity movement if you want them to really fall. Be careful, it's easy to turn see that feature turn into an exploit as your monsters can now be lured into pit traps and completely bypassed. 

Another alternative is to split up the navigation into small segments within a frame, for example replacing movetogoal(20) with movetogoal(10); movetogoal(10); It's not always a 1 to 1 equivalence, like with lots of Quake AI it's a thing to experiment with and tune. 

This error means that you've forgotten to set something, but the error message doesn't tell you which something it is. Some possibilities are

th_stand - the AI for an idle monster
th_run - the AI for a newly alerted monster
th_pain - the AI for a pain animation
th_die - the AI for a death animation
think - the next function to run after a timer.

To try and diagnose, add this line to the START of your monster spawn function

th_stand = SUB_Null;

If that fixes the error, you know that you've forgotten th_stand - and NOW you need to fix that by giving the monster the AI, this is a diagnostic tool only. If that doesn't help, add another line

th_run = SUB_Null;

Repeat until adding a line avoids the crash, then develop a fix. 

soo... you're saying it cannot be changed via mod? it's engine based? 

Yeah, #define means it's hard-coded when the engine is compiled. 

ok i resolved the null bug - was missing the think/nextthink... i was using custom entity so walk monster start wasn't working 

It's sorta working (thanks for the findNextMonster Preach!) (monsters sometimes attack other faction monsters) but very unreliable - vs the player whom they always attack instantly on sight?

the 2 main issues I'm still trying to solve is:

1 - monsters find a new enemy after killing the current hostile faction monster; (currently they just sit there, even if new enemy monster enters their LOS)

2 - monsters commonly do not fight enemy faction monsters on sight, only sometimes?

so how can i solve these 2? do you need to see my "FindTarget" again? or? 

Ask yourself this question: why do monsters stop attacking a target when it dies? Unless there's some code that checks whether the target dies, they ought to just continue attacking a dead target in the same way they attack a living one. Your first mission is to find that location.

After that, you need to add some code into that path to make sure that your monsters find an enemy. If you think you already have code there that does so, add some dprint statements to it, to check whether your code is not running, or if it's running but not detecting a viable monster target. Come back with that more precise intel on your problem. 

it's to do with FindTarget in AI.qc and strangely ai_stand(); in the monster animations

FUCK this - man took 5h to fix thru line by line trial & error

makes me wanna stop coding/modding quake forever LOL............ 

I am defo NOT a programmer LOL

dunno how you guys can do this professionally as careers

maybe cause i don't got any former training/edu in programming, but i cannot do this "back & forth" debugging for 40h a week, will 100% die lol 

Hello everyone!

I have a wonderful modification of "TribalFX" for «QuakeSpasm Spiked» engine. In this modification the author used additional light sources for monsters attack, grenades, rockets, objects, flashlight, etc. Tribal replaced all these effects with standard commands, for example, "EF_MUZZLEFLASH" with the commands "particleeffectnum" and added their description to the file "effectinfo.txt ". But when you turn on the game with a frame rate of more than 72 FPS, there is an unbearable flickering of these additional lighting effects. It's like a strobe light effect.
In early January 2025, @Tribalquake provided me with the source files and I saw that the whole point of the problem was in the file "effectinfo.txt ". I'm not a programmer and at first glance everything looks right. Where can this flicker bug hide depending on the frame rate? All his works are similar to the modification of "AD", but made from scratch.
All files are there, including "effectinfo.txt " and the source files"*.qc". I informed the author about this problem three years ago, but Tribal abandoned it for family reasons.
Can someone help fix this bug? I just don't understand what text command needs to be added to the file "effectinfo.txt " to synchronize with the frame rate of the game.

Here is a link to a video demonstrating this flickering effect (ver.01Ufix). Comparison at frame rates of 72 fps and 144 fps:
https://drive.google.com/file/d/1V8BQy3yWHYezQ98ie8UzX10iqKowQqTo/view?usp=sharing

Here is a link to versions 01T and 01U. They are very different from each other. Wonderful new effects have been added in version 01U, but the flickering of the light spoils everything:
https://drive.google.com/file/d/18wRTcNkRXpQVvrk8-s5WO4GXOiKEIRV5/view?usp=sharing
https://drive.google.com/file/d/1r2MDg_YzPSvBctJvLVP1_243NdJxQH0h/view?usp=sharing

My email: ashalunov1980@gmail.com 

To narrow down the search, I took a look at how the flashlight was programmed in client.qc. It turns out that the flashlight uses different effects in the flash_on function between versions U and T.

In version T:

myflash.effects = EF_DIMLIGHT;

In version U:

//myflash.effects = EF_DIMLIGHT;
myflash.traileffectnum = particleeffectnum("flashlight"); //tribal glow

Presumably the fancy effects are not compatible with high frame rates in the engine, and changing back to EF_DIMLIGHT will fix the issue. 

Yes, that's right. That's exactly what I wrote about, but the effects in the new version look very good, and I'd like to keep them. It is a pity if they are not compatible with the frame rate. Then I will have to disable more than half of the new effects and return them as in version 01T. 

I got a bug that's been happening recently; when I load a saved game the models are all incorrect?

but it's seemingly fixed if i restart the map? 

Hi Ranger, this is probably a variation on the issue I warned about in post 3532
https://celephais.net/board/view_thread.php?id=60097&start=3532&end=3532

If the save file dates back to an earlier version of the mod, and you've added, removed or reordered a model precache since then, you now have an incompatibility between your mod and your save file. Having a DIFFERENT deterministic precache sequence causes exactly the same problem as a non-deterministic one. It's one of those inconveniences you hit more often as a developer, your save files won't have a long shelf life until the mod is stabilised. 

Hi Andrew, I didn't do a great job of explaining where I was coming from. When I read your original post my impression was you believed the problem lay in a change between the version T effectinfo.txt and the version U effectinfo.txt. I admit I might have inferred incorrectly.

The really key message I wanted to send is that the flashlight in version T is not using effectinfo.txt - so you won't be able to locate the key to non-flickering effects there; there's nothing you can port to version U. It also makes it much more likely that the problem really lies in the ENGINE rather than the mod, that custom effects aren't compatible with high frame rates.

If you're into updating the engine then you can focus the effort there. If all you can do is change the mod, then you need to find a workaround for the bug, and that usually entails some kind of compromise. Capping FPS at 72 might be the better trade-off, you'll have to weigh it up. 

Actually what was concerning was there were 2-3 times where I reloaded the map or typed "kill" in console and there was still a model error...
I had to boot the map/kill twice to fix it?

...on related note, any reason why don't just list every quake sound & model in the worldspawn in order to avoid precache errors? 

is it really noticeable to have any fps above 60-72? 

...on related note, any reason why don't just list every quake sound & model in the worldspawn in order to avoid precache errors?

There's a limit on how many models total you can have precached. In vanilla quake the limit is 254. And every time you add a brush entity to a map, that also consumes a precache slot. In a sense, every model you precache needlessly is one fewer brush model your map makers can use.

Of course, it's worth understanding that Quake is a 1996 game. Computers of that era didn't have the memory to precache all the models - if you look at the original ID1 maps you'll notice that they never have more than 6 or 7 types of monster in a level. This was undoubtedly a concession to memory pressure. More modern engines raise the limit, but they did have to introduce new network protocols to do so - it wasn't a trivial change.

This kind of thing probably applies to sounds as well, but the pressure is a lot lower there. While a map will routinely include a small or medium number of custom brush models, it's rare for it to introduce a single custom sound (the basic Quake mod has no facility for this, it's only possible if your mod adds it).