Frikbot bounces

[Cobalt]

Im converting the Frikbot to use Spawnclient () in DP. So far I have deleted the scoreboard stuff. Not sure so I left b_client alone because I thought I saw somewhere its using that in its waypoint system. Is the switch_wallhug time what it uses to stay on the ground withoug bouncing? I was tinking maybe sv_addgravity was effected but I cant tell. Or is the physics_ent the real culprit?

[Cobalt]

Well Frikbot seems to have repaired itself lol. FRik had told me a while ago that the phys_ent's would be better off as movetype_fly. SO I had tried that , and it didnt fix the problem, but the next day, Frikbot no longer bounces...so Im not sure if I tested before the compile or something else I did fixed it, but no more bouncing.

Also there was a problem where the mod Im working with has a machine gun firing very fast using basicly the shotgun code as one bullet with a tiny spread, and for some reason the bots presence would corrupt the aiming using that weapon, and force the results of (makevectors) to be that of the bots calculated values for the aim results. After a long time troubleshooting, I had to modify the call for makevectors which is present in the playerprethink() so that only human clients (real clients not bots) would be executing makevectors in the playerprethink(). I suppose the timing of the Frikbots is calling that too often and there was no time for it to clear the next frame....? Im curious if it would be better to .float the results of those globals as opposed to always relying on the globals which I guess can be compromised at the higher framerates... ?

[mankrip]

It sounds like the "self" global is being assigned to the bots before you call the function. Be aware that "self" and "other" are reassigned to different entities dozens of times on each frame, so you can never rely on it staying the same across different events (playerprethink, playerpostthink, .think, .touch, putclientinserver, etc.).

And it is definitely not related to the framerate.

[Cobalt]

[Cobalt]

UPDATE:

On the makevectors problem, I wound up trying seperate .floats for v_up,v_right and v_forward , just assigning those to real client ents in the prethink and only to be used in the machine gun firing as well as the traceattack () function. IE: bots still use the global v_up, v_fwd etc, while clients use the .float versions to calculate firing direction and traceattack calcs.

Seems to be working ok...and this mod is calling the furebullets essentially from the last animation frame for the machinegun, and can also be calling them from the other if the fast firing rate is held down (button3)....so the animation frames also effect the .think , and I believe this was most likely the cause of the problem.

[Cobalt]

Ok seems like I posted the good news too early above.

I decided to move the Botframe() call out of startframe completely, and placed it in Playerprethink() , called for only botclients. This seems to make more sense and so far the bots behaviour is not changed except it seems perhaps hes thikning too often or moving a bit faster , not sure on that yet. But it did break my fix for the makevectors I described. What I did next was call makevectors in the corresponding firing animation frames for the machinegun, just before it goes to the actual firemachinegun() code, and this seems to have got it working almost perfectly, except at great diustances with multiple bots firing the wep, the traceline seems to be ending above the target about lalf the size up of the bot.

I am curious if I am right to assume makevectors can be safely called only once per frame, perhaps by looping through all the client slots then assigning seperate .vfwd,vrt, .vup floats to each one so that they have their own seperate values, rather than repetitive makevector calls like many mods do in multiple functions such as the weapons and other physics related stuff? If I understand the eng right, the beginning of the frame's values for this function should not change all through postthink until the frame ends and next one is called?

[mankrip]

[Cobalt]

[mankrip]

PlayerPreThink and PlayerPostThink are not .think functions. They occur every server frame.

The player's .think function only occurs in the time specified in its .nextthink field. Repetition is not automatic, so if .nextthink is set to a time in the past (e.g. zero), .think will never be called. This is why animations always set .nextthink to time+something, to ensure that .think will be called again in the future.

In the vanilla code, .nextthink is never set to a future below time+0.1, so animations are never faster than 10 fps.

[Cobalt]

[frag.machine]

[Cobalt]

Yea you are right, good point. As a work around I'm only going to enable speed change if (time < self.attack_finished) , this way if in an attack mode the animations wont be altered. Thanks for the feedback.

[quote="frag.machine"
Pretty much, it's a very common technique btw. Be aware that other behaviours need to be frame rate independent tho. Nailgun fire rate would be affected, for example.[/quote]