I worked with protobuf in c++ a few years ago, and recently succeeded in getting protobuf-c to work. I've only just started looking into the server/client messaging side of quake source, but I'm already wondering could this code be cleaned up, simplified and made more flexible with protobuf? 

Started learning QuakeC a couple days ago, and have been doing pretty simple stuff just to get the hang of things. When I say simple things, I mean VERY simple stuff like:

if(self.key_bind4 == TRUE)
{
self.walkframe = 109; //play an animation from the mdl
}

I wanted to know if there was some way for me to add a damaging hitbox to the player when they hit this button and the animation plays. An example would be an animation of the player swinging a bat or something, and a hitbox being created where the bat physically is. I'd appreciate any help! 

Quake is a much more abstract game than that. The hitboxes don't rotate, and the physics is modelling everything as a particle (at best). The Quake axe just traces a straight line a short way down the crosshair line, like a bullet with a 4 foot range. This isn't through lack of imagination or because it produced better gameplay - it's simply the kind of thing the engine is built to do.

With the technical limits set aside, I think there is an argument that first person games favour melee weapons that produce a precise stab of damage rather than a long swing. The problem is the player can freely move their camera between frames of a swing, If they move in the direction of the swing, they might stretch it out further than you intended, either leaving gaps the swing does no damage on, or dealing damage in a huge area of effect. On the other hand if they rotate against the direction of swing, they might inadvertently cause a whiff, or stack multiple hits in one spot. 

Hello, I'm new to Quake modding, and am currently trying to add a new enemy to the game. I have the enemy modeled, rigged and all that, but when in the game, the texture doesn't show up. It shows up when placing in TrenchBroom, but doesn't show in the game, and the enemy is just black. Is there anything I may be missing? BTW, I've tested it in both QuakeSpasm and FTEQW, in case that was the issue. 

Are you sure the new model has the Quake1.pal? 

How and where do I need to put that? 

Download qmle, and see how it turns up in the editor.
From there you can vieuw the skin file.

https://renep.home.xs4all.nl/quakeme/ 

How do I get access to the registercvar function FTE supports doing things in vanilla quakeC sources? There is declaration for the function in fteextensions.qc file but I neither can include it into progs.src nor copy-paste registercvar related stuff to defs.qc as it ends up into errors during compilation 

What error message do you get if you add the declaration to the bottom of defs.qc? 

It says that the function is redefined because there are 2 registercvar prototypes in fteextensions, but if I define only one of them it works. 

I want to create a stealth system for quake, but am unsure of how and where to start. I have a general plan on how to create a rudimentary stealth system, which involved taking the location/light level of the player in the level and connecting it to an awareness system for the monsters. The lower the brightness, the less the awareness. I'm looking to implement this using QuakeC but am unsure of how to get the players brightness levels or lightmap locations for this sort of thing.

And yes, I have played In The Shadows. It's cool, but not the sort of stealth I have in mind. 

One of the obstacles is that basic Quake engines don't give you a way to detect light levels. You'll need a custom engine that support the DP_QC_GETLIGHT extension (for example Darkplaces).

Once you have that, you can tell the light at a given coordinate. Worth remembering that Quake doesn't actually have a 3D representation of lighting - a model is lit according to the light level of the floor directly below it. That's what the function will give you, so plan accordingly when placing shadow areas in your map.

What you do with the light level is a whole other matter. In basic Quake, AI awareness is an on-off affair - either the monster is entirely ignorant of you or they are actively attacking and have omniscient awareness of exactly where you are. You'd probably want to invent at least two other states of behaviour:

- Monster is not alerted to you yet, but saw something in the shadows they want to investigate
- Monster was alerted but lost sight of you, and now wants to hunt in the area they last saw you

You'll have to add a field to store the monster's alertness level and make it behave differently at each level. One idea to try out is to create two different sequences of walking functions for e.g. patrol and investigating, which can share the same animation frames but pair them with different AI functions.

Another thing to add to the monster is a vector field to store where they think the player is - crucial to keep this updated when they can see the player (including when they see what they suspect to be the player but aren't sure) and equally important to stop updating it when they can't see you.

Once you have this, the refinements can pile on top. Maybe you give some monsters higher intelligence and have them anticipate where you were heading when they're in hunting mode - offset the last-seen location a short distance in the direction you were moving. Perhaps let even let them take another random guess if they arrive and see you aren't where they expected. 

I'm working on the stealth system as detailed above, and I'm making steady progress. One thing I'm not sure how to do is use the getlight command from Darkplaces in/as a function. Once I get that part figured out, the rest should be smooth sailing. Any and all help is greatly appreciated.

Also, what sort of light values does getlight output, RBG or just a general light level? 

Latter question is a quick answer, it's return a vector with RGB components - you can add them together to get an overall light level.

Basic way to access the function
1) Download the DarkPlaces mod from
https://icculus.org/twilight/darkplaces/download.html
2) Look at the QC that comes with the mod and find dpextensions.qc
3) Open dpextensions.qc and search for the code that defines getlight
4) Copy that code and add it to the bottom of your mod's defs.qc file.

You can repeat steps 3 and 4 for each DP extension you would like to use. Or if you prefer the kitchen sink approach, just add the entire dpextensions.qc file to your mod. 

I'm working on the stealth mod detailed in my previous posts, and I've run into a conundrum that I'm not sure how to solve.

I want to get the players origin whenever they are visible and assign it to an entity that tracks their last visible position. Whenever I try doing this, the entity just gets assigned to [world.origin].

I'm new to QuakeC but am making steady progress, any and all help is appreciated, thanks! 

In your design are you planning:

1. To have a global record of the last place any of the players were seen by any of the monsters

2. To have a record on each player of the last place they were seen by any monster

3. To have a record on each monster of the last place they saw their current enemy

Option 1 is different to option 2 when you think about co-op. To be more blunt, option 1 doesn't work very well in co-op. 

A [self.think] statement seems to be missing from the ai.qc script (or another related script). Whenever I attack an unaware/passive enemy, the level will crash and boot me to the command menu. Does anyone know where the missing [self.think] statement should go for aggro-ing an enemy?

For context, I'm using StealthQuake by RenegadeC as a base for this mod and I've changed up quite a bit of stuff because the base mod pretty much entirely changes up how Quake plays. 

Never seen the source code for StealthQuake, but I can explain how a similar crash can happen in vanilla Quake and that might point you in the right direction. Take a look at HuntTarget

void() HuntTarget =
{
self.goalentity = self.enemy;
self.think = self.th_run;
self.ideal_yaw = vectoyaw(self.enemy.origin - self.origin);
self.nextthink = time + 0.1;
SUB_AttackFinished (1); // wait a while before first attack
};

This function runs when a monster spots a player, and the dangerous line is self.think = self.th_run. The idea is th_run contains a think function bottled up for future use, and HuntTarget finally uncorks it. But if th_run is empty, then you've just scheduled an empty function to run in 0.1 seconds, and a crash is imminent.

Have a look at your code to see if the same transfer from th_run to think is happening when a monster wakes up, or if a similar transfer is happening from a different field. Then make sure that when you create your monster you populate that field with the correct ai function. 

ok you know how normally quake monsters attack only players on sight, and infight with dissimilar monsters?

...how do i do these changes?

1 - specific monsters are on another "team" and attack other monsters/players who are not on that "team"

2 - to prevent specified team's monsters from infighting (while other team's monsters may still do?

3 do i have to do these changes to every monster's qc or is there a way to do this "globally"? 

Also how can I edit ATTN_NONE ATTN_NORM ATTN_IDLE etc?

I want the distance of explosions and gunshots to go further 

Gonna take a whole post over answering each of these, and I'm gonna start with "prevent specified team's monsters from infighting (while other team's monsters may still do)".

Did you know that there's already an exception to the normal infighting rules? Two Grunts will infight even though they are the same class of monster. It's the opposite way round to what you're trying to do because it causes MORE infighting. But locating the code where this exception appears is a good way to learn how to set up the rules we want.

  if ( (self.flags & FL_MONSTER) && attacker != world)
  {
  // get mad unless of the same class (except for soldiers)
    if (self != attacker && attacker != self.enemy)
    {
      if ( (self.classname != attacker.classname)
      || (self.classname == "monster_army" ) )
      {
        if (self.enemy.classname == "player")
          self.oldenemy = self.enemy;
        self.enemy = attacker;
        FoundTarget ();
      }
    }
  }

This code is found in combat.qc, and it applies to all monsters, so you can make a change centrally and create the team functionality.

We need a way to record which team things belong to. We could call it .float monster_team, with the idea that monster_team = 0 represents membership on no teams and each other team gets a unique number. Then we can change the test to
if ((self.classname != attacker.classname && (self.monster_team = 0 || self.monster_team != attacker.monster_team)) || self.classname == "monster_army")

That should make it so that monsters assigned the same team will forgive friendly fire from teammates rather than retaliate (although I've left the exception in place for Grunts for flavour). If you had something a bit different in mind - e.g. a "team" of drones who forgive all friendly fire and focus exclusively on the player, that's possible too. Just write a different rule for which pairs of self and attacker cause self to target attacker.

Next time I'll return to question 1, a more thorny problem...