Since a few months, I have a growing set of functions that allow to query gameplay stuff less verbosely, and which I try to make both cgame and sgame compatible (not always possible yet but when I'll have been gotten rid of CBSE, they will).
I keep the main "lib" C-style, for various reasons, but am going to have a few classes as well (notably an iterator that does not relies on CBSE), which will live in their own headers, all is self-contained.
I believe it would help everyone.
For now, it only provides those helpers:
sgame:
bool G_IsDead( gentity_t const& ent );
bool G_IsAlive( gentity_t const& ent );
unsigned G_MaxHealth( gentity_t const& ent );
bool G_IsEnemy( gentity_t const& ent1, gentity_t const& ent2 );
bool G_IsEnemy( team_t t1, gentity_t const& ent2 );
bool G_IsAlly( gentity_t const& ent1, gentity_t const& ent2 );
bool G_IsAlly( team_t t1, gentity_t const& ent2 );
both games:
bool BG_IsMiner( entityState_t const& es );
bool BG_IsMiner( buildable_t type );
bool BG_BoundingBox( missile_t, glm::vec3& mins, glm::vec3& maxs );
bool BG_BoundingBox( buildable_t, glm::vec3& mins, glm::vec3& maxs );
bool BG_BoundingBox( class_t, glm::vec3& mins, glm::vec3& maxs );
glm::vec3 BG_CrouchMaxs( class_t pClass );
glm::vec3 AnglesToForward( playerState_t const& ps );
trace_t RayTrace( glm::vec3 const& origin
, glm::vec3 direction // passed by value as will be modified anyway
, int passEntityNum
, int contentmask
);
const classAttributes_t* BG_Class( playerState_t const* ps );
const weaponAttributes_t* BG_Weapon( playerState_t const* ps );
bool BG_HaveBuildWeapon( playerState_t const& ps );
This is a work in progress, so it's not yet perfectly consistent, but here are a few notes:
- I use a C-style API so that it does not slows down build times;
playerState_tandentityState_tare the most used structures, as they are shared between cgame and sgame;- some functions I have are not in that list because they live in other branches and I have not yet sorted everything out (such as
unsigned G_Health( entityState_t const& ); - this stuff lives in it's own folder, to reduce risk of git conflict as much as is possible. It's included like:
include <mods/mods_api.h>for example; - when I will be done with some of my personal goals, it will be much richer, and will allow to query the gameplay instead of hard-coding things (especially useful for bots);
This issue is mostly to ask for feedback: interested or not? If interested, any suggestions?
Since a few months, I have a growing set of functions that allow to query gameplay stuff less verbosely, and which I try to make both cgame and sgame compatible (not always possible *yet* but when I'll have been gotten rid of CBSE, they will).
I keep the main "lib" C-style, for various reasons, but am going to have a few classes as well (notably an iterator that does not relies on CBSE), which will live in their own headers, all is self-contained.
I believe it would help everyone.
For now, it only provides those helpers:
sgame:
```
bool G_IsDead( gentity_t const& ent );
bool G_IsAlive( gentity_t const& ent );
unsigned G_MaxHealth( gentity_t const& ent );
bool G_IsEnemy( gentity_t const& ent1, gentity_t const& ent2 );
bool G_IsEnemy( team_t t1, gentity_t const& ent2 );
bool G_IsAlly( gentity_t const& ent1, gentity_t const& ent2 );
bool G_IsAlly( team_t t1, gentity_t const& ent2 );
```
both games:
```
bool BG_IsMiner( entityState_t const& es );
bool BG_IsMiner( buildable_t type );
bool BG_BoundingBox( missile_t, glm::vec3& mins, glm::vec3& maxs );
bool BG_BoundingBox( buildable_t, glm::vec3& mins, glm::vec3& maxs );
bool BG_BoundingBox( class_t, glm::vec3& mins, glm::vec3& maxs );
glm::vec3 BG_CrouchMaxs( class_t pClass );
glm::vec3 AnglesToForward( playerState_t const& ps );
trace_t RayTrace( glm::vec3 const& origin
, glm::vec3 direction // passed by value as will be modified anyway
, int passEntityNum
, int contentmask
);
const classAttributes_t* BG_Class( playerState_t const* ps );
const weaponAttributes_t* BG_Weapon( playerState_t const* ps );
bool BG_HaveBuildWeapon( playerState_t const& ps );
```
This is a work in progress, so it's not yet perfectly consistent, but here are a few notes:
* I use a C-style API so that it does not slows down build times;
* `playerState_t` and `entityState_t` are the most used structures, as they are shared between cgame and sgame;
* some functions I have are not in that list because they live in other branches and I have not yet sorted everything out (such as `unsigned G_Health( entityState_t const& )`;
* this stuff lives in it's own folder, to reduce risk of git conflict as much as is possible. It's included like: `include <mods/mods_api.h>` for example;
* when I will be done with some of my personal goals, it will be much richer, and will allow to query the gameplay instead of hard-coding things (especially useful for bots);
This issue is mostly to ask for feedback: interested or not? If interested, any suggestions?