Cheese is too cheesy without its comrades. <w<

This must use software scaling. That's what I meant. However, if UV coords have a range of 0.0 to 1.0, then I'm completely fine, I won't have to resize the texture or anything.

DevIL supports Targa too:

Truevision Targa - .tga
Tagged Image File Format - .tif
Gamecube Texture - .tpl
Unreal Texture - .utx
Quake 2 Texture - .wal
Valve Texture Format - .vtf

Oh, look at that, one can potentially implement Source texture support in a HL mod.
FreeImage looks good too, but I'll see about all that.

I could just create new textures, probably.
What textures have is an "OpenGL texture number". So by creating a new texture, we're creating a new texture number. Which means I can just do this:

GLint myNewTexture;
... // after some TGA parsing with DevIL and texture creation via gl functions
texture->gl_texturenum = myNewTexture;

As for resizing, i.e. updating the original texture, we'll see. I am definitely thinking of writing some tutorials about this.

Definitely gonna have to finish that feature one day. Right now it only supports this on a single texture.
It's gonna affect any texture beginning with water or !, but I'm thinking of potential applications of this elsewhere too.

Since this works by modifying the texture's pixels in real-time (NOT affecting the actual WAD file itself), I think we can accomplish real-time moss growth, and potentially many other things!

Map textures can be modified too. So that's a good thing. uwu

video
video 2

Software water effect in OpenGL, anyone?

"Now i'm getting a "could not load library" ctd."

Are you trying to run it on WON Half-Life or Steam Half-Life? If you got any pre-2013 Half-Life version, that ain't gonna work.

Are you compiling both DLLs?
You should compile both client.dll and hl.dll.

"Compiles but produces no .dll"

Explain. How are you compiling? What are you using to compile? Are there any errors in the compile log? Etc.

No problem, lol. Just contact me on Discord or something and I'll try to send it tomorrow, I don't think I can do it tonight. I'm too lazy to upload to MEGA and whatever. <w<

As for the source code, in case you want it:
https://github.com/Solokiller/halflife-updated
Then get Visual Studio 2019 Community and compile that thing. It's more straightforward nowadays compared to several years ago.

I think you can actually remove the effect from the code, if you're going to do that.

// Raise monster off the floor one unit, then drop to floor
if ( pev->movetype != MOVETYPE_FLY && !FBitSet( pev->spawnflags, SF_MONSTER_FALL_TO_GROUND ) )
{
    pev->origin.z += 1;
    DROP_TO_FLOOR ( ENT(pev) );
    // Try to move the monster to make sure it's not stuck in a brush.
    if (!WALK_MOVE ( ENT(pev), 0, 0, WALKMOVE_NORMAL ) )
    {
        ALERT(at_error, "Monster %s stuck in wall--level design error", STRING(pev->classname));
        pev->effects = EF_BRIGHTFIELD;
    }
}

Around line 2085, in monsters.cpp

Remove the line with pev->effects = EF_BRIGHTFIELD; and you should get rid of the yellow aura.

Also, if you can, please try to avoid using Spirit of Half-Life. Lots of things don't work, lots of things don't, and depending on the version of it, chances are, it might break the HL campaign.

"using the Spirit engine"

...

"engine"

URBY!

For Opposing Force, you can use this:
https://github.com/Solokiller/halflife-op4/tree/dev

Alternatively:
https://github.com/malortie/halflife/tree/branch-malortie-op4/gearbox

For Blue Shift:
https://github.com/malortie/halflife/tree/branch-malortie-bshift/bshift

There isn't any official source code that was published for them, so yeah, all there is are community efforts to replicate it as authentically as possible.

"You are correctly: Blender is brilliantly. But Unity with Probuilder or CSG Shake too."

I don't like Unity.

We're gonna have a fight about the mushrooms, though

I'm afraid I'm gonna have to double down on this one. Mushrooms can fuck off forever.

Mushrooms are nice. They're especially good on pizza. uwu

Oh cool, a thread where we share stuff about ourselves.

About You

Name: Admer Šuko (note: the Š is pronounced like a "sh" in "shoe", or more precisely, the "sch" in German, like in "Schuko")
Age: 18
Hometown: Stolac, Bosnia and Herzegovina (well, to be exact, I'm in a village called Ošanjići)
Relationships: 9 previous, none at the moment.
Occupation: Just a high-school student, though I am an assistant to a couple of teachers there, responsible for my own group of classmates etc.
Current goal(s): Getting my idTech 4 game demo done, working on Advanced Development Mod until it's considered feature-complete, then work on Utopia at Stake. Other than that, I badly wanna start a game studio in my country, since there are none. And in life? I wanna make someone happy.
Politics: NO. My country is run by clowns and that's the only thing I can talk about in politics.
Religion: Not that I am very religious, but my religion is Islam.

Favourite Things

Food: Burek, ćevapi, chicken breasts, pizza. My favourite fruit definitely has to be the tangerine.
Drinks: Pomegranate juice, quince juice, liquid yogurt etc.
Snacks: I dunno. Don't really have any favourites, and I don't even eat them often. Though, I do like chips with tomato sauce flavour or whatever.
Movies: Just like TV, I haven't really watched any since 2015. I don't have any favourites nor favourite genres.
Videogames: I only play through games once. I had great times in Call of Duty 1 to CoD:MW3 and BO1. The Half-Life series is the only exception to my "only play once" sorta rule. Enjoyed Far Cry 1 a lot, as well as the Crysis series. I still gotta finish Deus Ex and Doom 3, I absolutely love those... As for game engines, I like CryEngine 5 and idTech 4. Source 2 SDK will be right around the corner, but I don't think that's gonna be usable for standalone game development.
Music: Disco folk, Yugoslav wartime songs, Haris Kostopoulos, Yugoslav rock, typical Krajina folk stuff, and Yugoslav classics from the 80s. Possibly the most unpopular music taste here, lol.
Other: I'm also into electronics, I got into Arduino last year, and I'm thinking of a project that I could start doing with it one day. Sometimes I go outside and ride a bike or walk, soon I'll be driving a car too. I haven't driven one in 4 years, lol. I generally don't do anything else other than developing or making stuff, school and stuff like that.

Disliked/Hated Things

Food: Cheese. I am not really a fan of cheese itself. Sure, it's good on a pizza, or in certain sandwiches, but alone? Nope.
Drinks: Alcohol and stuff. I for sure will NEVER drink stuff like beer, rakija, vodka, or other alcoholic drinks. Might try wine one day though, just out of curiosity.
Snacks: None. They're all fine.
Movies: None that I've watched. I don't watch horror movies because I actually do get scared.
Videogames: Never hated any, except CS 1.6 in 6th grade, but that's a funny story and I like CS 1.6 nowadays. I don't have interest in sports games, strategy games, isometric RPG games, any 2D game out there, any pixel-art style game and so on.
Music: Rap, hip-hop, most things young people listen to in my country (the godawful abomination that started as an experiment of combining folk and auto-tune).
Other: Going to parties or events with lots of people. Smaller scale stuff just works better for me.

I tried out Hammer 5 / Source 2 Hammer yesterday. I absolutely love it.

I did something really quick just to see how brushwork is done in there and I'm pretty satisfied with the tools. (forgive that the architecture doesn't make sense in the following screenshot)Since it was my first time, it definitely took me about half an hour to get this done.
But I guess that's still fast because if you tried to do that many smooth corners in good old VHE 3.x, it'd take you a bit longer than half an hour, lol.

I did almost everything in the 3D viewport, I used the bevel feature a lot, as well as extruding faces and edges where I needed that. It basically feels like I'm using a Hammer'ed version of Blender, really. It's brilliant.

If Valve provides a Source 2 SDK (and they most likely will in several months), with source code so we can build mod/game DLLs, then I'm probably gonna ditch Unreal Engine 4 and idTech 4.

slams table
Model data CAN be written to! :3

After grabbing a studiohdr_t pointer (header in the example code), we can access the bodygroup, then the submodel of said bodygroup, and then the vertices of the submodel.

void StudioExampleStuff( studiohdr_t* header, mstudiobodyparts_t* bodygroup, mstudiomodel_t* submodel, Vector& vert, int cntr )
{
    static float flWave = 0.0;

    flWave += M_PI/240.0;

    if ( flWave > M_PI )
        flWave *= -1;

    if ( header )
    {
        bodygroup = (mstudiobodyparts_t*)((byte*)header + header->bodypartindex);

        if ( bodygroup )
        {
            submodel = (mstudiomodel_t*)((byte*)header + bodygroup->modelindex);

            if ( submodel )
            {
                for ( int i = 0; i < submodel->numverts; i++ )
                {
                    float* vertFl = (float*)((byte*)header + submodel->vertindex) + i;

                    float indexWave = (float)i / (float)submodel->numverts;
                    float indexOffset = (indexWave * 2.0) - 1.0;
                    indexWave *= 4.0 * M_PI;

                    vertFl[ 2 ] += sin(flWave + indexWave) * 0.004 * (indexOffset*2.0) + sin(flWave*4.0 + indexWave)*0.01;
                }
            }
        }
    }
}

So, they aren't read-only.

Video: https://i.imgur.com/kYnorpP.mp4

This definitely opens up some new opportunities, such as having custom waves without the need of any vertex shaders (that alone would require doing... stuff to the renderer).
Of course, keep in mind that when one model is changed, it is common for all entities using that model. Meaning if you have 40 entities using models/something.mdl and you change the vertices on it, you will change it on them all. Maybe some mods will have a use for this, where for example, if the player damages one object and its vertices bend, it affects basically every other object in the map.

Imagine literally melting a Gargantua tho'. It'd look hilarious. Deforming terrain, yet again, except this time in the form of a 3D skybox. Anything can be done, really. Unfortunately, depending on the complexity of the model, it can potentially cause performance issues.

In other news, I made a small change to BSP and VIS. Now, BSP outputs two .prt files.
mapname.prt
mapname_viscache.prt

An example mapname.prt looks like this:

539
1330
4 0 123 (28672.000000 12288.000000 0.000000) (32768.000000 12288.000000 0.000000) (32768.000000 12288.000000 16384.000000) (28672.000000 12288.000000 16384.000000)
4 1 122 (28672.000000 12288.000000 16384.000000) (28672.000000 12288.000000 20480.000000) (20480.000000 12288.000000 20480.000000) (20480.000000 12288.000000 16384.000000)
4 1 28 (20480.000000 12288.000000 16384.000000) (20480.000000 12288.000000 20480.000000) (20480.000000 28672.000000 20480.000000) (20480.000000 28672.000000 16384.000000)
4 2 10 (26624.000000 28672.000000 1419.636364) (26624.000000 28672.000000 16384.000000) (26624.000000 30208.000000 16384.000000) (26624.000000 30208.000000 1280.000000)

mapname_viscache.prt:

539
1330
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
4 0 123 (28672.000000 12288.000000 0.000000) (32768.000000 12288.000000 0.000000) (32768.000000 12288.000000 16384.000000) (28672.000000 12288.000000 16384.000000)
4 1 122 (28672.000000 12288.000000 16384.000000) (28672.000000 12288.000000 20480.000000) (20480.000000 12288.000000 20480.000000) (20480.000000 12288.000000 16384.000000)
4 1 28 (20480.000000 12288.000000 16384.000000) (20480.000000 12288.000000 20480.000000) (20480.000000 28672.000000 20480.000000) (20480.000000 28672.000000 16384.000000)
4 2 10 (26624.000000 28672.000000 1419.636364) (26624.000000 28672.000000 16384.000000) (26624.000000 30208.000000 16384.000000) (26624.000000 30208.000000 1280.000000)

539 stands for the number of visleaves, 1330 is the number of visportals.
The 1s are the result of a recursive function called WriteLeafCount_r, so basically, each node writes its number of visleaves.
The problem is, map editors like J.A.C.K., or generally any map-related program like Crafty, not read the .prt file correctly because of these 1s.
Normally, you'd have to use a text editor and remove these 1s, but hopefully, once I release my compilers, there will be no need for that.

An optimisation could be made. Instead of mapname.prt and mapname_viscache.prt having the same content apart from the 1s, mapname_viscache.prt can ONLY have the 1s, and later on, VIS will read both and 'merge' the data.
Alternatively, per seedee's suggestion, VIS can just delete the 1s from mapname.prt once it's done its job.

Either way, this should speed up the workflow a little bit, at least for people who wanna optimise their maps and preview the effects their HINT brushes have on the portals.

Here's a video of it in action: https://i.imgur.com/N7al7uJ.mp4

I uh... always disable location on my phone. :v

But let's imagine I did. It'd look something like this if we zoomed in:Been to Montenegro once, but I mostly stick around in Stolac and Mostar, sometimes but sometimes Sarajevo if I really gotta go there.

@Oskar Potatis

I didn't say it must be DivX exclusively. 1024x768 is just the maximum, also.
But yeah, the documentation is pretty poor about which attributes to use, I can't even remember where I got my info from, LOL.

The video format is AVI, with DivX encoding, and it's 1024x768. The audio is mono, 32kHz. I think the audio can be different, but that's what I used in 2015.As for tools, well, Sony Vegas could work if you got it, really, even old versions like Sony Vegas 9. Handbrake only does MP4 and M4V, so that's a no-no. You could use ffmpeg.

It seems that BOLIDHINT works.

In my test map, bigterrain2.bsp (shown somewhere above), I textured all the backfaces (except the one of the very flat ground) with BEVEL, NULL, SOLIDHINT and then BOLIDHINT. The results are kinda interesting.

Firstly, let's take a look at the wireframes:*594, probably because one of my view angles was just 1 or 2° off, but it'd be 592 otherwise.

So, if we look directly at the wireframes, BOLIDHINT is apparently the same as SOLIDHINT. However, now let's look at the clipnode counts:
NULL - 7148 clipnodes
BEVEL - 4318 clipnodes
SOLIDHINT - 7158 clipnodes
BOLIDHINT - 4122 clipnodes
NULL and SOLIDHINT aren't supposed to create the same number of clipnodes, considering the fact that SOLIDHINT generally produces less wpolys. Keep that in mind.
Worldfaces, worldleaves, marksurfaces, vertices, nodes, leaves, surfedges and edges are smaller with SOLIDHINT and BOLIDHINT compared to the other two.

So, what do these results mean?
Not much. I think this texture is mostly applicable on terrain, and to be exact, ground terrain made out of quads and/or triangular prisms. I haven't tested this yet on tetrahedra. I don't think it should be used for walls (cliff sides, vertical terrain sides etc.) because the player can get kinda wedged into an edge. But those should be CLIPped to simplify their collision anyway.

The other day, I was thinking about how SOLIDHINT was nice, but it didn't have the properties of BEVEL.
And that was a real dilemma for my terrain design decisions. D:
Should I use SOLIDHINT and have cleaner BSP cuts, or should I use BEVEL and have smoother collision on edges of brushes?

So, I thought to myself, why not both?
Today, I went ahead and made that happen. It works!

Definitely gonna release the compilers as soon as Advanced Development Mod 0.1 comes out.
In other news, I restructured the mod base code a little bit.The next step will be to separate all classes into their own files, since there are tons of .cpp files with multiple different entity classes defined in them. Yuck.
Next post will probably be in summer.

Holy heck, so that's the room that I dreamed about last night. O.o (last screenshot)

"I remember trying to get the texture data for models or sprites but couldn't find a way."

At that point I'd probably do a MDL and SPR parser, if I just wanted to read the texture data. It'd be easy too, there are several open-source apps doing that stuff, so, we can use it as a reference / steal the code.

And thanks, I will most likely write it around late May or early June. I'm trying to focus on my game project, school and some tough emotional problems, so it's gonna take a while.

One way of doing it would be like this:

if ( FClassnameIs( pEnemy->pev, "monster_something" ) )

This will work if the monster has already chosen an enemy and is about to attack it.

"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.

In January 2018, if I remember well, I needlessly used a BUNCH of path_corners instead of just having a multi_manager + trigger_relay system for looping.To be exact:God, forgive me for my sins...
I was even paid for that map, LOL.
But yeah, never done anything like that afterwards.

It has been known for a long time that naming two entities identically triggers them both, however, in the case of a trigger_teleport, it kinda makes sense that the multi_manager would get used as a teledestination.
Thing is, the order of entities in the .map file dictates which one will get triggered 'sooner'. So it doesn't necessarily just swap their functionality.

For example, if you have two light entities with identical names and one is checked with "start dark", both the lights would start dark.

This also makes sense to an extent, however, this is likely done on the compiler level. HLRAD probably works like a state machine when it's dealing with flags of lights. It treats one 'name' as a single entity, but radiates light for each of them individually. It associates the 'start dark' flag with that one name because one of the entities happens to have it.
However, I can't say for sure without looking into how HLRAD works. :s

Either way, it's a cool finding.

"Hm, I wonder why it was software only."

Because of graphics programming.
When you write your own software renderer, you have complete control over how things render. When you use an API like OpenGL, 1.1 at the time, you get a lot of features, however at the same time, you can't get the easy per-pixel control as you'd have with a software renderer. (it gets a bit complicated)

One would either have to write a pixel shader (which wasn't available back then), or maybe modify the current texture for the current wpoly, before rendering it.

I'm guessing the algorithm went something like this for each pixel in the texture:

if ( texturePalette < 224 )
   color = textureColor * lightmap;
else
   color = textureColor;

This is the kind of 'control' that I'm talking about. We're basically modifying the texture before uploading it to draw the current wpoly. But, this isn't my area yet and I'm likely incorrect.

Modern Quake sourceports like Quakespasm and Mark V (the ones I've used) support this feature in OpenGL mode, so it's probably not that much of a trouble.

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".

From my experience with the Quake engine, if the colours were from the fullbright range, they would render as such, no matter the prefix.
I got some Quake WADs, and none of them have ~prefixed textures, so.

"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.

Oh, just wait 'til you see them playfully flying around the place.

Almost forgot about Valentine's Day, heh.
Time to follow my tradition again. ^^I should make the heart a bit brighter, but either way, there's the idea. There won't be much gameplay, just use a certain object and... yeah. There will be stuff though.

If I recall correctly, it means it's a light-emitting texture. They don't work out of the box though. Gotta define their light values inside lights.rad.

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.

Enemy model in progress. :3 (intentionally a bit more reflective, from the heat and sweat)

As for the car, nobody has guessed it yet. I'm letting anyone guess 'til I finish the model, so maybe by the end of March.

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.

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.

No no no, I said 10° to the east of Turin. Keep in mind we're in the 80s, so don't forget which country was there at the time. The name of the car will be very clear then.

Bro. I said about 10° to the east and a bit to the south from Turin, not the same place. :v

"some Fiat"

Close, now take Fiat's home and go approximately 10° to the east. Maybe a degree or two to the south as well.

It is an 80s car, however, it's not a Škoda. Go a bit more to the south.

"BTW, you are using Blender, right?"

Yeah, I'm using Blender.
Also, I've been working on my 2nd car model:Its mesh is missing some details like door handles (likely will be in the texture), the paddles, the speedometer, rear view mirrors etc. Mostly indoor stuff. Either way, it's getting there.
Cookies for anyone who guesses the car. :3

Yay. ^^
Meanwhile I made another character model. Started last night, and this is how the mesh looks at the moment:The topology is now much better compared to my first one, so this means it won't look like a weird abomination when the bones get twisted enough.

That's dedication.

You still didn't answer my question though. >w<
Will there be explosive sequences etc.?

But the real question is:
What ships will go KABOOM when damaged enough?

Hmm.
TBH I don't do HL AI programming just yet, so I can't really help you on that one.

"They must get close to the trolley guys, as a bodyguard."

Still doesn't tell me what exactly the movement is supposed to be.
Is it aerial?

EMIT_SOUND is for the serverside.

On the clientside, you can use something like this:

gEngfuncs.pEventAPI->EV_PlaySound( idx, origin, CHAN_WEAPON, "weapons/pl_gun3.wav", gEngfuncs.pfnRandomFloat(0.92, 1.0), ATTN_NORM, 0, 98 + gEngfuncs.pfnRandomLong( 0, 3 ) );

Or a much simpler version, which can be found in `cl_util.h`:

inline void PlaySound( char *szSound, float vol ) { gEngfuncs.pfnPlaySoundByName( szSound, vol ); }

Example usage:

PlaySound("common/wpn_moveselect.wav", 1);

As for the gunners following the trolleys, I dunno, how do you exactly mean following them?
Are they in-air, on-ground, or?

Correction, the compilers should also accept !cur texture names with suffixes.

if (name[0] == '!') //optimized -- don't check for current unless it's liquid (KGP)
{
    if (!strncasecmp(name, "!cur_90", 7))
        return CONTENTS_CURRENT_90;
    if (!strncasecmp(name, "!cur_0", 6))
        return CONTENTS_CURRENT_0;
    if (!strncasecmp(name, "!cur_270", 8))
        return CONTENTS_CURRENT_270;
    if (!strncasecmp(name, "!cur_180", 8))
        return CONTENTS_CURRENT_180;
    if (!strncasecmp(name, "!cur_up", 7))
        return CONTENTS_CURRENT_UP;
    if (!strncasecmp(name, "!cur_dwn", 8))
        return CONTENTS_CURRENT_DOWN;

Location: VHLT v34, HLCSG, brush.cpp, TextureContents()

According to the code here, the compilers check for the first several characters in the texture name.
So longer names like !cur_90_alternate will also work.