Figure out; Change Entity system in some way, I don't know!

[ACBob]

No description provided.

[ACBob]

Looking at JUST a simple server-side entity (as source has a... "robust" separation of client/server) of my own, there seems to be macro hell.
Code like that will fit right at home in the sauerbraten source code!

Entities seem to have a "DATADESC" about them, as referenced by BEGIN_DATADESC.
This data description lists attributes and inputs/outputs.

Sauerbraten's (less intuitive) entity definitions are... Practically non-existent, it seems.
It's not Object-Orientated like Source's, and actually just seems to be C code slapped into a C++ file!

This may be an EVEN BIGGER task of reinventing the wheel and making an entity system.

[ACBob]

Gonna be a case of rewriting the entity system. Whee!

[ACBob]

Note to self: Stop going to the deep end of the pool! Learn the engine before making such brash decisions!
Indeed, the entity system appears to not be object orientated. But there appears to be enough here that it could simply be converted to use objects of some kind, or maybe have a more Source-like API.
A more thorough investigation is required, it's 1 in the morning, so I'm about to go to bed.

Entities do not appear to get updated, however monsters do. It may be possible to move the update function to entities on their own, but my tired brain doesn't understand this fully. It appears to loop over all monsters and call a function? Monsters seem to be treated as players... and there's no plain and simple update()!

"Moveables" also get updated in this loop, but their code doesn't seem quite as useful.

[ACBob]

After a quick round of "search around the repo for 'ent'", I've discovered the following structs(!!) that relate to entities.
They're laid out like this to show inheritance!

entity
└ extentity
  └ fpsentity

entitylight

physent
├ dynent
│├ fpsent
││└ monster
│├ movable
│└ hudent
├ fireballent
├ dropent (engine/physics.cpp AND fpsgame/collect.h)
├ vertent
└ bouncer

For the actual in-game entities, we'd be looking at physent. One of few comments in the sauerbraten code describe it as a "base entity type, can be affected by physics". That seems completely relevant.

void monsteraction(int curtime), the closest function to an "update" or "think" appears to ONLY be defined by monster. A quick and hacky "sourcify" that'd open more possibilities is to rename it to void think(int curtime), and have monsters define it themselves. This would however, turn it into a virtual function, which opens us up to lovely OO goodness, none of which the cube source code is prepared for. Which structs might not support, although they seem to be pretty much the same as classes in C++. - which might just allow changing struct -> class and then doing all of it!

Interestingly, there is no "player" entity. Players are simply an fpsent. Seems my initial suspicion of monsters just being fancy players was true. It's not a bad way of doing it, Monsters in Cube 2 appear to just be glorified bots. - Similarly, the bots appear to be glorified NPCs.

However, consideration must be taken for the entity class, as it defines some things to do with editing? It defines the 5 attributes, and what it is, and its' position. Additionally, we need to wrap the entities system around this, so care must be taken to not interfere with the rest of the engine.

This change will however require that we build some compatibility stuff into the engine!, The header should be changed (and the map version lowered possibly?), and then the engine should detect that it's loading a sauerbraten map, fling it through the usual, and then convert the entities. Also spit some nice warnings to console to taste!