Before I introduce the mod, let's have a little bit of history.
3-4 years ago, I started working on my first Half-Life mod. It was originally called Admer: The Game.

It actually started out as a QBasic text game. I had QBasic classes in 7th grade, and I'd finish my tasks so quickly I'd get enough time to work on a game. It was simple. You spawn in a cave, and for some reason there's a zombie in front of you. I'll write about that one in a journal.

I had an idea to make a single-player Half-Life map pack based on my text adventure. I downloaded some textures from the Internet (stock photos, lol), and I just threw them into Wally after downscaling them. The results were this:There was some dynamite at the end of the cave in the text game, so I thought I'd add it. The dynamite would explode and make a hole in the cave ceiling, so the player could exit.Soon after that, the player would encounter a small hut, with a pistol and a piece of paper. It's not important what's written on the paper.

As you can see, it looked kind of terrible. If you want, you can check out the mod on ModDB: https://www.moddb.com/mods/admerthegame
I once renamed it to An Unknown Game, because I understood that it was bad to call a mod by yourself. (in fact, I was the protagonist in the mod, lol)
The mod was supposed to get released somewhen in 2017. Clearly, it would never get to that point.

I gave up on it in Q3 2016. My programming skills sucked. I didn't know my way around the Half-Life SDK, and my mapping skills were definitely bad, as well as the rest of my skill set (except video editing, my only skill that wasn't under average).
I was lazy. All my ideas were in my head, I was too lazy to write them down and I had no mod design document, no organisation, no anything. I simply didn't know where I was going and what to do, so I half-baked everything. (ahem, quarter-baked)
I had some wacky ideas there and there, e.g. a programmable universe where people spawned things via code (scrapped, won't fit the story of AUAS). That mod is, in fact, the very origin of Jody. (you all remember her, lol)

I've occasionally visited the mod's page on ModDB in the past 2 years. I remembered the old stats, suddenly. It used to have 10s, sometimes 100s of viewers per day, and now it varies between 0 and 1. So I thought "How great would it be to do this again, except with the skills I have now?"
The time wasn't then, however,

I was analysing some progress of my skills. Since 2015, I've improved in mapping a lot, in texturing a lot, video editing significantly (I mean, not much to be improved since I've been video-editing since the age of 8), sound editing a lot, music production so-so, but there was just that one skill that stagnated. That one skill which prevented me from reviving my old mod.

It was programming. In late 2017, I started panicking due to the fact that I knew I'd have programming class the following year. So I wanted to prepare myself.
(little did I know, they hardly teach you anything here in high school when it comes to programming)

I just needed a good start. Something to jump-start my learning. And in November 2017, a guy from the 2nd or 3rd year came into our classroom, recording a promo video for the high school. We were having IT class, and our professor told us to open Dev-C++ and pretend to be typing something. They all pretended. Except me.

I opened up a source file, saw how it's written, memorised the syntax and commands within a minute, and wrote a program. When I returned home, I got VS 2010 Express, registered it and decided to make GMan vulnerable.
It was an unbelievable experience for me back then. I actually understood something for once. And all he was doing was setting his health to 50% of his max health every time he was attacked:
Now that was just the beginning. I called my little brother in and showed him that, and he was so amazed. He laughed in disbelief, because all the time he knew about HL (since the age of 2 or 3), he knew that you just can't kill GMan. Not in my mod.
But then, there was a period of stagnation. I hadn't really touched Visual Studio any more. Instead, I observed. I listened to Shepard's and Solokiller's programming lessons on the TWHL Discord (lol), I've read numerous coding stories from other developers on Quora, and so on. So essentially, I did the same as I did with mapping. First read a bunch of tutorials and documentation, and then try working on it.

In late 2018, however, I got into C++ again after a long period of not doing coding. I got my new PC in July, and that meant I could finally get my hands on Visual Studio 2017, a nice step up from Visual Studio 6.0, 2005 Express, 2009 Express and 2010 Express.
My 2007 laptop simply didn't have enough space for 2012, 2015 nor 2017.

And that meant a new beginning, a new age. I was looking for some libraries that can enable me drawing stuff to a window, and boy I found one: SDL. I learnt quite some C++ for those few months, and coming back to the Half-Life SDK once again, I finally understood most of the stuff in it. It felt amazing to finally understand something that troubled you for a few years. That age was the age of learning something I've always wanted to learn.

I had prototyped a function in AngelScript for Sven Co-op (it was my first time tinkering with AS scripting), and then I decided to implement it in the HL SDK.
It led to the creation of this mod. I'll be working on the technical part for a long time. Once it's done, I'll move onto the actual mod revival itself.

So, what is this thread about?

A Utopia At Stake

Will you save it?

There's a world out there. A world where everything is close to perfect. You move because of education, a future brighter here than on Earth, and for the fun of it. Things will look perfect, until a series of events lead to the downfall...
Its fate... is up to you.

Well, I'll just post stuff here about the mod.

Here's a summary of what I've made in the last couple of months:

• semi-auto for the pistol
• env_viewsway, an entity that messes up the player's view angles, useful for drunk effects, rocking ships etc.; is capable of inducing nausea (seriously)
• trigger_valueop, my personal favourite, as it can change any keyvalue of an entity which it targets, it's very powerful
• trigger_difficulty, which triggers something depending on the skill level, which can be easy-hard but also not easy, not medium and not hard.
• util_rotator, something that spins an entity around an axis, but it's not in a very good state at the moment (it rotates things, but eh... I feel like it should use quaternions rather than regular angles)
• util_consoleprinter, a very useful debugging entity when you're developing an entity setup or a scripted sequence series
• a customisable HUD with about 15 parameters, most of them being for the TDTR effect (The Deader The Redder - the lower your HP, the redder the health display)
• vehicle_base, a really, REALLY basic vehicle. It's a chair that you can enter and exit. But the system itself is quite flexible under the hood, allowing for multiple vehicle types, whether it's cars, planes, space ships, boats, or chairs & sofas (why not). I'll describe them more in my next post
• additions to the CBaseEntity class which allow trigger_valueop to work
• additions to the input and client commands, which allow for sprinting (and being able to control the vehicles in a more special way) - and best of all, it doesn't need more bandwidth than 1 to 2 bytes/sec per player (keep in mind that an empty map with one player is already about 27 to 50 KB/s, assuming the netgraph displays it in kilobytes/second, I could be wrong) (thanks to Solokiller for the information about pev->button)
• new view sway, viewmodel bob, you name it (thanks to Shepard for helping me with the old HL WON rotational bob, it's 1 line, but 1 important line)

Suggest me a name for this mod, because it can still be changed. For now I'm just calling it AdmerMod 2018, and the source code AdmSrc (which has no relations to Source, it's just a short way of saying "Admer's source code").

Oh right. One last thing before the next post. I'm hoping release this mod's source code when it gets to Beta or Release Candidate, maybe even earlier. It's based on Solokiller's fork of the HL SDK, that is compatible with VS 2017. I've already sent versions of the source before the "VehicleAPI" and "ControlAPI" were written, because some people simply asked for it.

"I'll describe them more in my next post"

So, the vehicle system is approximately like this:

A vehicle can consist of 4 types of components. Bodies, engines, seats and wheels.
Bodies and wheels are physical components meaning they're visible and you can collide with them. Engines and wheels are, on the other hand, logical components, meaning they just contain some info.

Bodies have a model, and physical info like mass, position etc. Similar thing applies to wheels.

vec3_t pos; // from the VehicleBody type
float Mass;
float Density;
string_t m_iszModel;

Seats serve as pointers to players, and they listen to commands from the player they point at. There are 4 types of seats: driver, gunner, passenger, and driver-gunner. It's pretty self-explanatory what they do, i.e. driver seats are the only ones allowed to control the vehicle, gunner seats may control the vehicle's guns, passenger seats do pretty much nothing, and driver-gunner seats combine driver and gunner seats.

VehicleSeatType type;
vec3_t pos;
CBasePlayer *pSessilis; // Never thought you'd see Latin in the HL SDK, did ya?
bool fExists;
int iSitdex; // Cool name for a seat index ;)

Engines contain info like health, gear ratios, number of gears, drive type (currently only 4: FWD, RWD, AWD and NWD a.k.a. NoWD, which is reserved for flying vehicles and other wheel-less vehicles) etc.

int              HorsePower;
float            MaxHealth;
float            GearRatios[9]; // Maximum of 7 gears + 1st neutral 0th reverse
int              Gears;
float            Efficiency;
VehicleDrive     Drive;

To test some things, I made a chair. A simple chair that consists of a body and a seat. The body is actually a brush model, but it could've also been a Studio model. It's the bounding box that really matters. Either way, this chair handles player interaction and even a very, very, very primitive movement system where the chair slides on the floor.It's a beginning.

You're making a promising coding base for your mod. It will be interesting to see any mapping progress too.

I'm glad to hear that. Especially when it's coming from you.

And you probably know why:To think that this was 4 years ago, man, it's amazing how time flies.

There will be mapping screenshots and stuff like that. But only test maps for now, until I finish most of the code base.
Of course, it doesn't mean that these dev maps won't be pretty.

My vehicle test map has got some quad terrain, and doubtlessly, so will the next few vehicle test maps. One will have a flat race track, so no terrain there, but, one will be a "4 quadrants" map having a desert, snow, jungle and rocky area, one will be completely designed for water vehicles (and air vehicles) etc.

Well, I can be a bit abrupt sometimes, but I'm always happy to see that people can learn on their mistakes to make something better. And you definitely made some progress.

"Well, I can be a bit abrupt sometimes"

Oh no, I didn't mean to imply anything like that, I'm just saying that your comment back then was 100% right. Especially the 1st sentence.

Anyway, after mostly improving the chair vehicle (which will probably appear as an Easter egg in the final mod), I've recorded some of it:However, since it's the 21st of January, that means that my winter break is over.
I won't work on this mod base very often during the next 3 to 4 months, but I'll still get a little bit of time to work on it during the weekends.
I'll likely leave the vehicle system for now, because there are a couple of entities I have to clean up and polish.

Well, I can be a bit abrupt sometimes

Yes , but you help people a lot. That´s what counts in the end.

Yeah. That's what's important.

After a month of silence, it's time for some news. :3

• The FMOD implementation is so-so. It loads the library, starts the system, creates and loads a sound, but fails to play it.

Yeah. But I think I know the cause. I'll get to it later on.

• The Vehicle API has been enhanced, and simplified so I can make it easier for myself, and for others, to actually code the vehicles.

In the VehicleThink() function, you can now just place these two:...instead of manually and individually setting the origin of the player, the seats, setting the angles etc.
Basically, you have to set positions for each seat, then for the player, then the angles, listen to the commands from the player, and perhaps other things in the near future. Now you just need to call 3 functions or so, as opposed to writing 5-6 lines per seat (now imagine having a minibus vehicle with 16 seats - blimey!).

Support for studio model vehicles has been added, so now I can finally have vehicles with bones, controllers and whatnot. It was just sitting there and all I needed to do was precache and switch the model, if the mapper assigns a "model" keyvalue. It looks pretty neat:Currently this is just me debugging the seat position stuff. With the chair, it was really easy because you'd just snap the player to the centre of the chair, but now you gotta add a bit of trigonometry and vector maths.

Being based on the chair code, it behaves exactly like the chair: https://i.imgur.com/b5Bxqrn.mp4

Now, what's next?

• A seat-switching algorithm (you can switch to another seat e.g. from the driver to the passenger seat if it's not taken by a player)
• Motor/engine stuff, like switching gears according to the RPM. (manual transmission one day? Who knows)
• Binding seats to bones, and utilising controllers for special vehicles (studio model only stuff - brush-based vehicles will use my maths xd)
• Potentially a way of scripting vehicles in text files. Stuff like engine horsepower, gears, the model and whatnot. This way, it will not be hardcoded, nor "hardmapped" (even tho' you can ripent a map etc.), and it will still remain serverside.
• More complex vehicles: aircraft, boats, and ultimately... cars and... maybe if I become mad enough, NPC vehicles
• Eventually, NPCs that can drive vehicles. That would be insane, don't you agree?

Before I move on to that, I'll have to polish the current set of features and fix bugs (there's gotta be some!). I still have to code taking damage, exploding, switching the engine on and off, emitting sounds... Basically the smaller things.

What a reason to implement FMOD? You can just use Half-Life method of triggering soundtracks. FMOD is a stupid crutch, IMHO. The only reason to use it, is because it can add fading effect to tracks. But the bad part is that you must implement it, and your game code will depend on specific external library, and music will play even if you go to menu (and even if you minimize the game, AFAIR). You can use normal MP3-tracks, just replace Half-Life's ones. You can also stop a current track by triggering empty track (0).

100% because I can.

But seriously, AFAIK FMOD supports MIDI music, so something like that would be amazing, because then you can save a lot on space.
And then there's OGG support.

and music will play even if you go to menu (and even if you minimize the game, AFAIR)

Sounds and music can be paused though, can't they? As for minimising the game... pretty sure there's a solution to that too, even if it's a bit ugly coding wise.

FMOD does support MIDI out of the box on Windows. On other OSes lile Linux, you will likely need a soundfont first.

It's possible to detect if the game window has focus with SDL2 (assuming you are using GitHub SDK), I need to find the code again but it is possible.

The engine has a limit to the number of mp3 files it can play. It internally assigns an id to each one and there are a maximum of 200, which includes the files in /media. FMOD doesn't have that limit.

It's possible to detect if the game window has focus with SDL2

Yesss, that's exactly what I was thinking about!

On other OSes lile Linux, you will likely need a soundfont first.

GASP I almost forgot.
I gotta try compiling my mod's code for Linux one day. It's gonna be one hell of a ride IMO.

ADM v0.1 tech demo

Today I am releasing v0.1 of the mod base of Utopia At Stake, called ADM (Admer's DevMod). It has got the following features:

• vehicle support
• FMOD sound system implementation
• Bullet physics engine implementation
• bump-mapping (I never thought I'd reach this point)

Download the tech demo right now:
ADM v0.1
Installs like any other HL mod, just extract the .zip into steamapps/common/Half-Life.
Should not work with pre-Steampipe versions, or rather anything lacking updated SDL2 and VGUI2 libraries. (sorry pirates and WON HL players)

The source code will be released some time later.
Have a good day/night, everyone.

Yeah, screw that last post. It was an April fools thingy.
Now back onto the serious stuff.

The CBaseVehicle class is siting at around 400 lines of code right now.
Since last time, I have added multi-seat support, seat switching, and better controls. But also, a very important change for modders who decide to use this tech one day.

And that is the following: creating new vehicle classes is super duper easy.
1. Define a vehicle class e.g. CVehicleVWGolf and base it off CBaseVehicle (however, it'll likely be CBaseCar, since each base is devoted to different vehicle types)
2. Define the VehicleInit() function
3. Let the base take care of the rest

And what did I do to make the two-seated couch work?
I just defined VehicleInit() like this:

m_iSeats = 2;

v_Seats[0].Init(Driver, v_Body.pos, 0);
v_Seats[1].Init(Passenger, v_Body.pos, 1);

Of course, this is just a part of the total function, but I'm planning to make it as easy as possible. For two reasons, really. Firstly, people would have to learn the whole vehicle system (and it can only get more complex in the following months), and that is not optimal for someone who just wants to create a vehicle. Secondly, I'm just too lazy to type 400 lines for each vehicle class, and you may agree that it's a bit inconvenient too. <w<

Either way, the new controls have arrived, finally. Up until now, my controls looked something like this:
if W -> push the vehicle in the direction the player's looking at
if A -> push the vehicle negatively in the X axis
if D -> push the vehicle positively in the X axis
if S -> push the vehicle negatively in the Y axis
That is, obviously, wrong (the ADS part) because those axes are world axes, not ones that are local to the vehicle.
So what I did was, I made it more standard, how you'd usually expect a car to be driven in games.
if W -> push the vehicle in the vehicle's front direction
if A -> rotate the vehicle's direction to the left
if D -> rotate the vehicle's direction to the right
if S -> push the vehicle in its back direction

All of this new stuff was programmed just today. Lastly, the seat switching. This one was the most tedious one, but it turns out I had a small inconsistency:

// Standard for all seats - always listen to unuse and seatswitch
fCommands[bi_unuse] = pSessilis->GetKeyButton(vehicle_unuse);
fCommands[bi_seatswitch] = pSessilis->GetKeyButton(vehicle_seatswitch);

This is what it's supposed to be like ^
However, I somehow placed the seatswitch listener into the Driver seat category, so only Driver and Driver-Gunner seats could switch. D:
But it was resolved in about 30 minutes.

Here are some videos:
https://i.imgur.com/5RWNHld.mp4
https://i.imgur.com/uRG4rmv.mp4
https://i.imgur.com/94xW83F.mp4

What's next?

Engines/motors. There's already some code, including the jokes:

void VehicleEngine::Damage(float hp)
{
    if (MadeInGermany)
        return; // engine was made in Germany, can't break

This is an actual part of the code and it'll stay that way.
Either way, the engines will be responsible for the vehicle performance. Think of RPM, gears, shifting and perhaps fuel if we want to be that realistic (though I don't really wanna add fuel). Either way, the engine will be damageable, and if it's broken, the vehicle cannot accelerate etc.

Wheels. Currently only the struct definition.
Wheels are interesting. They define the grip of the vehicle, and its handling. They will also be damageable, except the vehicle will still be able to operate after these are destroyed.

However, I will eventually create a new vehicle class to utilise all the 4 components: the body, the seats, the engine and the wheels.
A couch won't cut it. Once I get to the cars, then I can show the real power of the vehicle system.

I mentioned some seats there, but I haven't explained these in detail.
There are basically 4 types of seats: Driver, Driver-Gunner, Gunner and Passenger.
Driver -> vehicle accepts the driver-specific commands from this seat. Can turn on the vehicle's lights (if any), can toggle the motor etc.
Gunner -> controls the weapon component of the vehicle.
Driver-Gunner -> combination of both. Think of the HL2 jeep's tau cannon.
Passenger -> the simplest type. Does not control the vehicle, only sits there. Can only switch seats and/or exit the vehicle.

The weapon components are the next thing to be done, once the engine and wheel components are finished.
Tanks will require a weapon component, absolutely.
Now, Driver-Gunner seats and Gunner seats are the ones that can utilise these vehicle weapon components. Such a seat has to be linked to a weapon component, otherwise it'd be exactly the same as a passenger seat.

Another question might appear, and that is: are seated players able to use their own weapons? I'll let that be an option. If you want seat A to allow that, just flip the flag for that in the init function.
You'll likely want to disable the flag for driver seats, for example, and enable it for passenger seats. But this is something I'll definitely work much later on. For now it's a concept.

An example of a weapon component is a mounted MG on a Humvee. Even stuff like a mounted M60 on a helicopter. Either way, these will have to be attached to seat bones, for the sake of simplicity. This may or may not be the final decision for that, but we'll see.
Basically, seats assume that seat bones are the last seats of a model.
So you've got the following
Bone 0 - root
Bone 1 - something
Bone 2 - something else
Bone 3 - seat 1
Bone 4 - seat 2
But if we were to add more stuff, eeeh, it'd get complicated. They will likely use attachments then. We'll see. shrug

I realised that I should perhaps write things down. My mod failed in 2015-2016 because I didn't write almost anything. Seriously.
So I am trying to do something about it.Later on, I'll have to write a list of core features, then the actual story, individual missions, short mod design document and then I got a plan to stick to.

My teammate made a significant addition, having thought of a new character, which will definitely make the mod's story more interesting. (and for the player to care about and become allies with )

As for the vehicle system, I got a CBaseCar class now, with a different movement algorithm. I haven't yet tested it in-game, but it compiles fine. The vehicle engine is now more complete, with functions for acceleration, toggling etc., wheels now have a part of their own logic, and the vehicle manifests all that together.
The plan is to make a NEW test model because CBaseCar handles bones differently. It takes into account the root bone (that is bone 0), followed by potentially 4 wheel bones, so that's an offset of 5 bones. Therefore bones 5 and 6 will be driver and passenger, in this test model.
The model will actually be a bath tub, cuz' why not.

I just read through all that.

You have so much enthusiasm, and you're willing to learn from your mistakes. Those attributes can take you far.

Keep going and keep learning. You still need more structure and planning before embarking on a project. Having a strategic plan will save you time and frustration.

You still have much to learn, young Padawan.

All of this is just preparation, I believe. This is why I'm writing everything down. I need priorities. Back in 2015, I only had a rough idea and I was making things up as I was going. That clearly led to nowhere with potentially large projects like that.
The year after, I started working on a Far Cry mod that would act as a 'sequel' to this one, that failed in 2015. That is where I discovered the concept of planning.

The few rules I came up with were to first write some documentation, then develop and implement features. Only then, once those two are done, I can do the actual content (that is most of the assets). This is the principle I'm working by, and it's the reason why a relatively smaller project like de_kobbl managed to succeed, and I even managed to pile together a whole game demo in 2 months, mostly from scratch.

The difference is, this time I'm focusing a lot more on the 1st part, the documentation. And that involves planning, alongside everything else (the descriptions, the story, the missions, the designs). And this time, I'm not alone, unlike before.

Thanks a lot for reading, and for what you said. I know I've got a long way to go.

Update time.

New features:

• trigger_date, an entity that can only trigger something whether the actual date matches the entity's properties (e.g. you trigger something every Christmas)
• trigger_date2, an entity like trigger_date, except for hours, minutes and seconds (3 AM horrors :D)
• func_loadbar, an entity that moves in a direction, and loads from 0 to 100%, has 5 trigger-able percentage levels defined by the mapper (e.g. trigger a "Just a little more!" sound when it reaches 90%)
• view bobbing + view camera overhaul
• horizontal offset of the thirdperson camera
• temporarily broke func_rotating
• trigger_timer, triggers something periodically, can trigger randomly between a min and max interval as well
• car prototype, with a working gearbox, needs steering implemented
• actual physics test - it's possible now
• new main menu UI colours

Physics test

Man, man, what a fool I was.

"The FMOD implementation is so-so. It loads the library, starts the system, creates and loads a sound, but fails to play it."

When I tried to do FMOD, I was doing it upside down.

I tried implementing it on the server side. XD
The sound entity would basically directly call FMOD's sound playing functions. Horrid. D:

It'd look something like this:

void CNewSound::Use( CBaseEntity *pActivator, CBaseEntity *pCaller, USE_TYPE useType, float value )
{
    g_SoundSystem.PlaySound( m_sound );
}
// where m_sound is a member variable of this sound entity

// meanwhile PlaySound is defined as:
void CSoundSystem::PlaySound( FMOD::Sound *snd )
{
    result = system->playSound( snd, NULL, 0, NULL );
    ERRCHECK( result );

    result = system->update();
    ERRCHECK( result );
}

Something like that. Point is, this is entirely server side.
Yes. I was an idiot. Laugh at me as much as you want.
Gonna quote Shepard on this one: "My god! What are you doing?"
Back then though, I didn't quite know how to do client messages yet. Now that I do, though, I might as well try it the proper way.

For now, I'm planning to do a simple "music player" on the clientside, then I'll try to do more than that. FMOD Studio seems really pretty.

Also, in DevVideo 3, I mentioned some stuff about bounding boxes and vehicles. TL;DR you can't rotate an AABB with pev->angles properly. But, a friend told me about a special model flag, that's used by monster_tentacle, which essentially uses hitboxes for collision. Mmm, definitely seems better than AABB, even though I'm pretty sure this will have its own flaws too. But I'm more willing to accept those flaws than the ones of AABB.

Also, something I haven't shown in the video, but probably have shown here (or not?), physics.
Here's a link. The Bullet physics engine integration is going fine enough. Just gotta set up some debugging lines so I can see my collision shapes. Stuff seems somewhat off already.

FMOD now works.

Long story short, now I can play music with it. There's a special "music" folder inside the mod folder, so when you use a sound name like "abcd.ogg" in a music entity's keyvalues, it'll look for modfolder/music/abcd.ogg
Also, the DLL file is now in cl_dlls, instead of the Half-Life directory! Yay! (big thanks to Solokiller)

Currently, it works by sending a user message with a string. What this means is, it would be very far from optimal when it comes to network performance. So for entities that emit sound, like monsters, breakables etc., that would be a lot of bandwidth. So I'm thinking about replacing a variable number of bytes with just 2. Up to 65535 sounds should be able to be precached per map, cuz' c'mon, who's gonna precache more than that in a GoldSrc mod? Sheesh.
Now, I believe that I could stick to sending strings for music entities, as long as short filenames are used. But then again, 65k is more than enough IMO, so I guess music could go to the "sound cache" as well.

Now, something more conceptual, that I haven't started working on yet.
Do you like bows in games? I personally do, especially the one in Crysis 3. ^^
I think a lot of cool puzzles could be made for it. There will be a jungle area where the player is alone most of the time, so it'd be pretty nice to have that instead of firearms.

Do a compound bow please. With modable strenght for different purposes... and also different arrows!!! (explosive, hunting, shredding, poisonous, flammable...).

I was thinking of a more primitive one at first, then you pick up, or upgrade to a compound bow later. And of course, there will be different types of arrows.

I´ll keep an eye on UAS!!.

I had a fascinating playtest session with my brother last night. The vehicles work rather well in multiplayer. So yeah, vehicle deathmatch is definitely gonna be a thing. Sure, it's never gonna be as smooth as it is in singleplayer, but the vehicles are very driveable.

Originally, I was going to do a simulation for cars, but hey, this is an action comedy type of thing (apart from the other characteristics of the mod). So I'll do a bit of more liberal car physics. Think of GTA: San Andreas for reference.

I could do what Gran Turismo 1 & 2 did, which is having a separate mode for arcade and simulation driving, though that's pretty much 2x more work. On top of that, you gotta remember that racing sims use really high-poly tracks so that they're smooth enough for the simulation to be accurate. It'd require QUITE some clipnodes for that. Unless I use Bullet for the simulation mode, where I could easily use the external physics mesh.

Hmm... for now, let's just stick to GTA:SA style arcade driving. Also, for the sake of network performance, I'll have to ditch the idea of assembling a car out of different pieces. I mean, let's take into account a veh_car_base, with 4 veh_wheel entities, and a player in the car. That's 6 whole entities! That means it'll take 3x more origin and angles sets. According to my calculations, that's 96 bytes + vehicle itself + the player = 144 bytes total. (only taking into account sending the floats in pev->origin and pev->angles).
Now, sure, I'll keep all the functionality, but for MP maps, you're just gonna have to use 'whole' vehicles if you want better network performance.

For the entire picture, here's the plan:

• veh_car - car entity that supports all kinds of parameters set by the mapper: model, seat number, engine characteristics etc. Only potential issue with this entity is the fact that this is gonna take up quite some data in the entity lump. There are gonna be many parameters to be defined, most of which should have default values, however.
• veh_car_base - car entity that "assembles". You attach other entities onto it so it can become drivable. (implemented)
• veh_[insert a real-world car name] - a preset car entity. For example, veh_yugo - acts like a Yugo 45, looks like a Yugo 45, drives like a Yugo 45.
• veh_base - the original drivable chair entity. (implemented)
• veh_base_ms - the original drivable couch, multi-seated entity. These two might get removed or renamed. (implemented)
• veh_seat - a seat that you can place. This would be a normal chair that you can sit on. No driving. By itself, it's actually an invisible point entity, and yes, you can use it to attach to veh_car_base. (implemented)
• veh_wheel - a wheel. By itself, it does nothing. Naturally, it might roll away if it's on a slope. In a veh_car_base, it'll act like it's supposed to. (implemented)

Now, if we go a bit farther into the future:

• veh_tank - self-explanatory.
• veh_boat - regular boat. You can choose it to be a motorised boat or a boat that you row, which you'd have to use a special weapon for.
• veh_boatmg - boat with a mounted machine gun on it. Motorised by default, but you can also choose to row it.
• veh_sub - a submarine type of vehicle. Moves only under water, and players in it won't drown.
• veh_heli - a helicopter type of vehicle. W and S control it vertically, while A and D rotate it left-right. To steer left, for example, you'd have to pull your mouse to the left, rolling the helicopter left. Then you'd push the mouse backward (or forward) to tilt the helicopter up. Think of it as a joystick.
• veh_plane - an airplane type of vehicle. Controls are just like the helicopter's.
• veh_ufo - imagine the submarine, but in the air. It's basically not affected by gravity. It's controlled like a helicopter.
• veh_sship - a spaceship type of vehicle. It's controlled like a plane, except it isn't affected by gravity.
• veh_bike - a bicycle or motorcycle type of vehicle, depending on the mode. Just like the boat, it can be motorised (hence it acts like a motorcycle), or it can be powered by cycling, which would act rather similarly to GTA:SA. If you hold W down, it's cycled normally. If you tap W fast, you'll cycle faster.

Lastly, imagine almost all of them with "mg" variants. There would be some sort of weapon, either a machine gun type, laser type, or rocket launching type. Now, of course, you'll be able to choose whether the vehicle will have the driver as the gunner (like in HL2 when you use the airboat, or the buggy), or if you'd rather have a separate seat for the driver and the gunner.
In the far future, we might have NPCs that drive vehicles, and, heck, even ride-able NPCs. Imagine riding a Gargantua, LOL.

You might be asking, why all of this? Will all of them be used in UAS? Not all in the singleplayer campaign. Vehicles that the SP campaign doesn't utilise can be found in some of the MP maps, as well as minigames, which are accessible in singleplayer. However, keep in mind that this is not only a SP-MP mod, but also a mod base which others could use in the future. :3 (the 'base' can be downloaded separately)

Anyway, I mentioned rowing a boat. A row would not be a weapon in this case. This mod's gonna have 'tools', which are basically weapons but instead of damaging entities, they provide certain functionality with them.
The most obvious example is a paddle tool to row a non-motorised boat. Of course, it can be used as a melee weapon. Some tools can double as weapons.
Other tools will include:

• Worldcraft WC2.0 (original) - yes, a multimetre. You'll have to measure electricity in the mod at some point. You'll see why. If you don't mind the spoilers, I'll tell ya right away.
• Lockpick. This is pretty self-explanatory.
• Rock. To distract enemies a la Far Cry 1.
• Car keys. Logically, to start a car, you need its keys. Either that, or try jump-starting the engine, which is gonna take longer.
• Phone. You heard it right. A phone is going to be quite useful in the mod. Organise actions in missions, call people, and whatnot. Unlike GTA, however, you'll have to charge it wherever you find a power source. Some sockets won't have voltage in them, and you'll use your trusty WC2.0 to check if they have them. But don't worry, the battery should last long enough.
• Universal Remote. Simply put, imagine controlling a little rocket launcher from the distance, or a mini RC car.
• Grappling hook. Very good for setting up a rope to the top of a tower. Or if you wanna do bungee jumping. However, don't let someone shoot it. It has its counterpart.
• Climbing axes. You can climb walls with ease.
• Parachute. Self explanatory.

There's more stuff than this, but I don't want to count all of them. Now, you might say that's a lot. And you're right. But you can't carry it all at once. Well, you can, but you'd be VERY slow. Items, tools and weapons will have their own masses, and the greater the mass, the bigger the slowdown will be.

So, next up: physics.You might notice that the boxes clip into the floor by approximately 1 or 2 units. That's because I currently don't have a proper thing for map collision. Instead, I made a phys_staticplane to prevent the boxes from falling through what we see as the floor.
I'll resort to an external mesh for this type of stuff. Reading geometry from the BSP is cool and all that, but what if we want a separate physics mesh for the map? Eh?
As of right now, the system goes like this:

mapname.bsp - actual map
mapname.bsp.obj - .obj model file made from an exported .map file. It's easy to do with tools like Crafty or Noesis or whatever you use.

However, I might end up writing a tool that reads a .map file and just converts the thing to .obj. It'd be kinda cool to add new stuff to my mapping workflow. (or whoever ends up working on the mod, or using the mod base)
Obviously, I'm not planning to replace GoldSrc's physics anyhow. Just adding special physics entities on top of the whole thing. And NO, no ragdolls. I know I'm crazy, but not THAT crazy.

Of course, maps will have the option to have or not have physics. It's as simple as that. Vehicles may or may not require physics. I'll have to see about that at some point. Probably not though!

Either way, currently I'm juggling through pointer hell, because there seems to be some stuff about the map collision mesh. Pretty sure it's a null pointer somewhere. Read access violations can be a beach. (you know what I really wanted to say)
bvtBvhTriangleMeshShape is being used. Though I guess I just need to read the documentation a bit more.

New year, new post.
It's certainly been a while since the last time I posted here.

I made a Trello board for the mod's base, ADM, so anyone can see where the progress is at: https://trello.com/b/mbpXU4ffI also found some time to develop a bike vehicle, not for this mod originally, but considering it uses the vehicle base of my mod, you can expect it to look like this.
(note: bike model not mine, skybox not mine, that mod in the video is cancelled - the footage is from the time I was briefly working on it)

Vehicles will be a bit different than what was described in previous posts. Precisely, the wheels. For optimisation reasons (which includes network performance, the number of entities occupying the edicts etc.), I decided that veh_wheel wouldn't be a good idea. Imagine if the engine had to manage 5 entities per vehicle (1 body + 4 wheels) instead of just managing one. Especially if the wheels are simply following the vehicle.
So, both the wheels and the body will be in a single .mdl file.

Now, veh_wheel won't actually be gone. Imagine the car explodes suddenly, and wheels go flying around kinda like in GTA:SA. Separate wheel entities would be okay in that case, as a sort of special gibs. Ideally, these would be temporary entities that clients simulate for themselves, but depending on the size of the wheel, you might just wanna have it as a serverside entity. Imagine the wheel of a monster truck, and one player sees it next to a tree, while the other player sees it in the first player.

Last but not least, I set up a GitHub repo for the mod's source code a while ago. For now, it's private, but once we reach version 0.1 (current is 0.03), or maybe even sooner than that, it'll be public.

Nice job :3

Thank you. :3
There's much more to come once it's May or June.

I freak out with how you progress in coding, Admer.

Oh, it's nothing. I haven't made much progress on the mod itself, but I have certainly improved my skills while working with idTech 4.
In fact, from idTech 4 I got some ideas on what to implement into ADM. (hint: computers with GUIs on them)

Complex collision for vehicles is now a thing.
Traditionally, GoldSrc uses AABBs (axis-aligned bounding boxes) to check for collision between point entities.(keep in mind that these aren't accurate representations of their bounding boxes, but they are close enough)

There is a bit of a problem with AABBs though...
They cannot be rotated. Sure, that makes collision detection really easy to solve, simply check the minimum and maximum XYZ values of both entities, but my vehicle system is gonna need something better.

One might wonder, how did monster_tentacle handle its collision then? You can even get stuck in the tentacle if it touches you!
Its bounding box is otherwise HUGE, so no way that is being used.The answer is: hitbox collision.I once heard about a certain flag in models, which lets them use complex collision via hitboxes (CCHB for short from now on).
It took me a good while to get this working. Anybody I asked about it, they used Svengine for their mod so it automatically meant things are gonna work better. But I wanted to see how I could get it working in vanilla GoldSrc, because there was clearly at least one entity capable of utilising this collision system.

The work eventually paid off. Here it is on the bike vehicle:
video
You can notice that grenades bounce off the hitboxes, the player gets blocked by the hitboxes and so on. For collision with the map geometry, it still uses its AABB (hardcoded in the engine, probably, so I can't change that).

This is great news for at least two things:
1. Static props
2. Vehicles

For static props, this means you don't have to overlay them with CLIP brushes any more. Saves time for the mapper, and saves clipnodes too. Slightly more work for the modeller tho'. :/
For vehicles, this means players won't get blocked by some invisible matter if the vehicle is turned by 45° or so.

And that's about it for this small update. uwu

Nope, none of those 3.
I made it by myself, while analysing monster_tentacle and talking to people (OSC dev, SC devs etc.). Everyone was getting different results, and everyone was using Svengine, except me. I wanted to find a way to get hitbox collision to work in vanilla GoldSrc.
So I came up with the following:

In the model's QC file, $flags 512 must be turned on, and your model must have a hitbox at least.

pev->solid must be SOLID_BBOX
pev->movetype can be anything in theory. Guaranteed to work are MOVETYPE_NONE, MOVETYPE_FLY, MOVETYPE_TOSS and MOVETYPE_PUSHSTEP.
UTIL_SetSize must be called in Spawn(). If your entity will perform thinking, then also call UTIL_SetSize inside Think().

Also, you might need to define the SetObjectCollisionBox() function in your entity if it moves dynamically. Maybe.

In fact, I don't think anyone wrote any articles about this specific stuff - except maybe the Russians at HLFX. But, I'm not sure, I haven't been there long enough.

This uses hitbox collision. That is very different from the default GoldSrc collision.

No, it is not correct. It was there since Half-Life 1.0.0.0, but only monster_tentacle used it. I'm now using the latest Steam version of Half-Life.

STATIC_BOX

Sadly, GoldSrc doesn't support that. You can't have custom collision meshes inside the MDL file. And besides, pev->solid can only have the following values:
SOLID_NONE, SOLID_BBOX, SOLID_TRIGGER, SOLID_BSP.

SOLID_BBOX is compatible with hitbox collision.

Ohhh I don't know before if I used Quake Engine with obj files as "Spawnflag" "2" into collision / clip solid brush.

Well, Quake is still a bit different than GoldSrc, so...

I imagine about nice prop models for Goldsource Engine. like you create bridge what do you should make sure for hitbox / collision?

A bridge? Well, it depends.
If the bridge is far away, or it's part of a background, then it doesn't need collision.
However, if I really need to make a bridge with collision for players, then I will place bones carefully, and from these bones, hitboxes can be generated. Then, I can tweak these hitboxes to match the shape of the mesh.

However, a bridge would be better made with brushes. Maybe a better example would be a static car. In that case, yeah, you can have one big hitbox for the body, one hitbox for the roof, 4 hitboxes for wheels etc.

Do you assign 3 or more static mesh like Source Engine / Portal prop models?

No, it is a single MDL file for one entity.

You're welcome, and thank you.

How do you draw the AABBs? I think it's r_drawentities for the hitboxes.

It's r_drawentities 5

In the studio model renderer, you gotta find a certain function, where you'll see r_drawentities being referenced. There you'll add an if check for value 5, and then, call the function to draw the absolute bounding box. In theory, it should draw a box from pev->origin - pev->mins to pev->origin + pev->absmax, but sometimes it will differ from the actual collision box you get. Still a pretty good approximation. I'll find the time later today to grab the exact code.

Circa line 2000, on the bottom of StudioRenderFinal_Hardware:

else if ( m_pCvarDrawEntities->value == 5 )
{
    IEngineStudio.StudioDrawAbsBBox();
}

There we go. :3

I totally gotta write some more stuff down. I wanna reach 20 pages by August.
But, in this post, I wanna focus on a certain set of features that may end up being in the hub maps.

Precisely, those features are all about time. Years, months, days, hours, minutes, seconds. Everything your heart could want.
Currently, I only have trigger_date and trigger_date2, but I feel like that is not enough for what I'm gonna do with the mod. (at least the free-roam part of the mod)

One of the things I've been thinking about was a day-night cycle. It's possible within certain limits. Obviously, you're not gonna get a smooth transition for each hour of the day (keep in mind a day on the mod's planet lasts 48 hours, heh), but since each 'hub' may have up to several connected maps which you can travel between, I can do something about it to give the player a sense of a continuous day-night cycle.

Most likely, there will be a couple of states for each time of day. Ideally, I'll have 4 or eventually 6 of them, and then 1 for night time.

Here's a little illustration, hopefully you can get the idea:The fun part is, you may be changing from hub1a.bsp to hub1b.bsp, and in case your time crosses the line, the next map will actually load a version with different lighting. E.g. hub1b_an.bsp (afternoon). If you then returned to hub1a.bsp, you'd notice that the lighting has changed.

Due to the way it works, the lighting won't change if you stay in one place constantly. But then again, it's not like you're gonna be playing for so many hours to notice it, lol.

For a direct example of how Earth time and UAS time relate, let's assume the time in the mod follows our system clock, and we convert that to UAS dates.Since one UAS day is 48 hours, it's basically 2 Earth days. This is pretty useful because of someone plays the mod just at night, for example 20:00, they can see UAS's world when it's 20:00 (almost noon) and 44:00 (close to midnight). Otherwise they would never see the day in the mod.

But, of course, it doesn't have to follow the system clock. It can just count time independently, and keep track of the time in savefiles. So load a save, it's gonna have the same time as when it was saved.

Technical detail: the concept of time will be exclusively serverside. So if you got a multiplayer game going on, it doesn't matter if your client is from the other side of the world. They're gonna see sunsets whenever you (or your server) see(s) them too.

Now, there WILL be trouble when it comes to handling stuff like endings of months, regarding the conversion to a calendar more known to us.
In the mod, the number of days in a month is basically split in half compared to Earth time, lol. So instead of 30 days for April, you got 15 days, so they could match up with Earth time decently enough. Stuff gets tricky with different month endings, where the first day of the next month can be 0 instead of 1. Ouchie.

So yeah, the calendar's gonna be a little bit complicated. But you don't have to worry about it at all, since there will be an in-game clock that you can see anyway.

But alas, if you care about it, just get used to the mod's calendar and you'll be fine.
One of the things I can imagine in the mod is the player getting confused whether "a day" means "24 hours" or "48 hours". I'll leave this one for the manual, as well as many other little things. You can think of the mod's manual as a tourist's guide for getting used to life on the mod's planet.

Now, another idea I had were events happening in certain times of the year. E.g. maps get Christmas-y when it's about that time period. Certain maps may have snow during the winter months. But, that's something I'll talk about next time.

Interesting - I hadn't considered the problem of .bsp files needing different lighting. I guess that's not controllable via client.dll

Well, here's the thing. You could have up to 4 'sun states' in a single .bsp, in the form of light_spot entities which are toggled on and off.

But the problem with that, IMO, is that 1) you can only have 4 lightstyles per face, so you won't get the ability to have any other switchable lights; 2) it would lag A LOT while switching between those states, because you'd have to update 70% to 90% of the faces in the map with the new light state. (assuming most of the map is outdoors)

What client.dll will allow me to do, of course, is to blend and manipulate multiple skyboxes neatly (with Triangle API). So that will help smoothen the transitions. And perhaps some other effects. I can have a moving sun sprite in the air, for example.

Otherwise, if you can find a way to manipulate lightmaps at runtime, then tell me, lol.

Entities could theoretically go up to +-16M units, but I'm not gonna take that much. Just +-65k.
For years, I believed that world boundaries for entities were hardcoded in the engine. That is until a buddy of mine told me otherwise.
So yeah, for the most part, they actually aren't limited.

The first step was to raise this limit inside the HL SDK. There was a function in CBaseEntity that would check whether an entity is inside the world boundaries.
However, entities would still get stuck at +-4096. The player would go up to +-8192 and then get stuck. Interestingly, moving entities like func_train would still keep their collision until +-8192.

Video

It's time for the second step. If we look at the files in the mod folder, there is a delta.lst file. In a nutshell, it defines how many bits are used to carry entity data (position, angles, velocity etc.) and at what precision. More about it can be found in NetworkEntity.doc inside the HL SDK.
I'll put up a part of it here:

The format for delta.lst is straightforward. The only lines that require additional explanation are the actual definitions, which take the form:

DEFINE_DELTA( origin[0], DT_SIGNED | DT_FLOAT, 21, 128.0 ),

This definition specifies that the x – array index [0] -- coordinate of the field named origin ( a three component vector field in this data structure ) represents a signed floating point value. When sending this value over the network, the value should be multiplied by 128.0, converted to an integer, and sent in 21 bits ( 20 for the value, 1 for the sign bit ). The receiving side will know to cast it to a floating point value and divide by 128.0 to obtain the final value on the remote side.

So, what does this mean? Imagine the player is located at 2050 units on the X axis. This gets multiplied by 128, and it's 262400. So, the engine is gonna send this number to us. We receive it, then divide by 128, and we get 2050. For example, if we were located at 0.5 units on the X axis, which is perfectly possible, the engine would send 64 to us. We divide by 128, and we get 0.5 again.

Alright. So we have 20 bits for the absolute value, and that means that the maximum value for origin[0] is 1048576. When we divide that maximum value by 128, what do we get?
I'll let the reader guess. :^)

So, in order to increase that limit, we can do two things here. Either decrease the multiplier, which will decrease our precision from 1/128th of a unit to, say, 1/64th, oooor, increase the number of bits being sent. I went with the latter, giving me a total of 31 value bits, which corresponds to about 16 million when divided by 128. 16 million units. Dayum.
Now that I think about it, it would be smarter to decrease that to 16 + 7 + 1 = 24 bits. It'll give me about +-65k units to work with.

Now, the third step, obviously, was to modify the compilers to allow for this kind of thing.
God. VHLT source code is a mess. But I can handle it. I added a simple compile parameter (-maxentrange, defaults to 32768 units) that will let you set your own world boundaries, so for example, if an entity goes outside of +-65k units, it warns you about it.

Either way though, all this work resulted in this:
Video

So, this is basically gonna allow me (and potentially, you) to make larger maps. :3For the hub maps, this will be amazing. For some certain missions in the mod, it will be amazing as well.

Any kind of entity is gonna work in this new range. Now, in the beginning of the post, I actually said "for the most part". This has its limits and I'll work around that. The limit I'm talking about are things like particles, explosions and stuff like that. Can't recall if decals are affected as well.

I might write about this in more in an actual tutorial. So we'll see.
Obviously, I still have the clipnodes limit, AllocBlock, and the rest. I can't change those. But, considering the level of detail this mod's levels will have, it's fine to me.

Yeah not sure - there is lighting data in the model_s struct in client.dll but I suspect it's read only (maybe?) and you'd need to write your own lighting rendering to use that data.
Or you could use dynamic lights but I haven't played with them enough to know their limitations.

And with the map coordinate bounds I thought that server to client messages 1 through 64 (or whatever is handled by the engine) might have clamped coordinates - is that right?

"And with the map coordinate bounds I thought that server to client messages 1 through 64 (or whatever is handled by the engine) might have clamped coordinates - is that right?"

Well, it seems so. Any TE_ message has clamped coordinates. Hence explosions end up spawning at 0,0,0 if they're outside of the +-4096 range. :/

"Or you could use dynamic lights but I haven't played with them enough to know their limitations."

God no. Dlights are horrible for performance. And there can't be many of them either at the same time.

"there is lighting data in the model_s struct in client.dll but I suspect it's read only (maybe?)"

Speaking of model_s, after some brief experimentation with reading vertices from the map model (one way was getting the worldspawn entity with gEngfuncs.GetEntityByIndex(0) and the other was IEngineStudio.GetModelByIndex(1)), I've come to a conclusion that some things are surprisingly not just read-only.

m_pWorld = gEngfuncs.GetEntityByIndex( 0 );

if ( m_pWorld )
{
    m_pWorld->model->leafs[ 0 ].firstmarksurface[ 0 ]->polys[ 0 ].verts[ 0 ][ 2 ] += m_flWave;
// etc. etc.

This here is a really quick test to see if I can manipulate the Z position of the first vertex, of the first polygon, of the first marksurface, of the first leaf.
m_flWave is a simple triangle wave which moves from -1.0 to +1.0.
So yeah, you can apparently manipulate some BSP data at runtime.

Here are the results:
Video 1 - moving the vertex along the Z axis
Video 2 - moving the vertex along the Y axis

That's what happens while manipulating the "GL polys". However, if I went ahead to manipulate these:

// first vertex of the first edge in the map model
// NOT the same as pModel->vertexes[0].position.z
pModel->vertexes[ pModel->edges[ 0 ].v[ 0 ] ].position.z += m_flWave;

or something like that, it wouldn't change anything, at least visually. This seems like pretty dangerous stuff, to be honest.
Now, manipulating lightmap data is still an unanswered question. I'll try to find that out, and will tell the results in the next post.

Also, slightly unrelated to this, but maybe an in-game cliphull visualiser could be written one day, so we can actually see the clipnodes.

Edit:
Did a quick test and from what I've seen, lighting data is pretty much read-only and shouldn't be attempted to be modified.

if ( m_pWorld )
{
    msurface_t* surf = m_pWorld->model->leafs[ 0 ].firstmarksurface[ 0 ];

    surf->polys[ 0 ].verts[ 0 ][ 2 ] += m_flWave;

    for ( int i = 0; i < 64*64; i++ )
    {
        surf->samples[ i ].r += 1;

        if ( surf->samples[ i ].r >= 255 )
            surf->samples[ i ].r = 0;
    }
}

"samples" is allegedly the actual lightmap data of a surface.
And... changing it doesn't seem to do anything.
Changing 64*64 to 72*72 either crashes the game or certain polys disappear, or you start falling through the floor. The actual surface this was done to was 64x64 units in surface area, at a texture scale of 1 for X and 1 for Y.
Chances are, if the surface was 128x128 units, 128*128 would work for this array. But, that's something I'll not investigate right now.

Ultimately, if I wanted to do such modifications to lighting, I would throw lightmaps away entirely.
But I don't have the time to write an entire custom renderer, and even then, that is not in the scope of this project.

Interesting - I figured not all of it would be read-only (though I feel like not all texture data is exposed? some of it must be a summary). Entities would be read-only for sure.

I think client entities are not read-only. Once the client receives all the data about the entity, then they should be able to write to them as they wish, without affecting entities on the server.

In hud_bench.cpp, I've seen something around line 750, where cl_entity_t's are getting modified. However, I'm not exactly sure how you meant "entities would be read-only".

Oh I meant model_t.entities would be read only but a lot of the others should be modifiable.

"entities would be read only but a lot of the others should be modifiable."

Yes, but what do you exactly mean by "entities"? cl_entity_t, sending the modified data back to the server etc.?

Anyway, I accidentally came across another little thing inside model_t:
char* entities;
Only worldspawn has this set, and apparently, it stores the whole entity lump of the BSP. So, that's cool. :3
Not that we can really use it for anything, but it's nice to know.
the image is a bit tall, so

Algorithm: (can be put in some of the HUD classes)

for ( int i = 0; i < 120; i++ )
{
    cl_entity_t *pEnt = gEngfuncs.GetEntityByIndex( i );

    // this doesn't guarantee that the entity exists or doesn't exist
    // but we needed something quick and dirty
    if ( (pEnt->curstate.origin != Vector(0,0,0)) || i == 0 )
    {
        if ( pEnt->model )
            gEngfuncs.Con_Printf( "\nEntindex %i - model->entities %s", i, pEnt->model->entities);
        else
            gEngfuncs.Con_Printf( "\nEntindex %i - no model here", i );
    }
    else
    {
        gEngfuncs.Con_Printf( "\nEntindex %i - no entity here", i );
    }
}

And it looks like vertex manipulation just isn't gonna work on studio models.Can't even read, let alone write to it, LOL. It looks like model_t only provides all data for brush models. For sprites and studio models, it doesn't do much.

In other news, yesterday I made a 65k x 65k units test map.The two large maps before this one were 16k x 16k and 32k x 32k respectively.This bigger size required a slight change in the map compilers (specifically HLCSG), so that the BOGUS_RANGE macro refers to g_iMaxEntityRange instead of a hardcoded value.
g_iMaxEntityRange is, of course, set by the -maxentrange param in HLCSG.

In spring or summer, I'm gonna test a 131k x 131k map, and then I'm done with testing large maps.

I'm very curious to see how feasible large maps will be. Because I'm pretty sure mappers can cram a lot into them even on that scale.
This test map ate 20% clipnodes (14% with -nohull2) and almost 10% AllocBlock. The other lumps were below 5%.
Considering the fact that this is basically a big box map, this could just be one of the worst possible scenarios, and with enough CLIPping etc., I'm pretty sure making large GoldSrc maps is very doable.
I'll talk about this mod's open map design in one of the future posts.