Looking at the screenshots, the map geometry is all over the place.I hope you are not putting a huge sky BOX around the map, because doing that can cause a lot of problems.
From the compile log, it seems that HLBSP just crashes at 15%:
1000...1500...

Lol, Abbadon, he was asking koe1, not you.

You can look here for Opposing Force:
https://github.com/Solokiller/halflife-op4

The Specialists definitely didn't change the player hull size.
I dunno about ESF though. I still don't quite think that's the case.

Creating massive maps needs 3 things: changing values in delta.lst, changing a couple of things in the HL SDK code, and using custom compilers that support this new boundary. Or, well, 4: a map editor that can place brushes at these large coordinates.

My latest test involved making a map that is about 57k x 57k units and it worked just fine in my mod.It wouldn't work work in vanilla HL, that's for sure.

Also, if you're thinking of decreasing the hull size, I think you're gonna have to do 2 things: use a custom hull file while compiling your map (which defines how large the hulls are, while generating cliphulls) and make modifications to the HL SDK.
I've never done it personally, because if you decrease the player's size, then you have less room for detail. 1 unit will look like 2 units to the player, or even worse, 1 unit will look like 4, depending on how much you decreased the size. So if you want it to look like 1 unit to the player, you'd have to somehow make 0.25...

My assumption is that even if you modify that texture data, you won't see any changes.
texture_t isn't exactly the same as in GoldSrc IIRC. There is a gl_texturenum for detail textures AFAIK but you need an updated com_model.h for that. uwu

This was true back in the day, but it's definitely not true nowadays, that's my point. If someone doesn't use VHLT, they're basically shooting themselves in the foot.

@tschumann I haven't even touched it, sadly. I must've forgotten again.
Anyway I am gonna take a look at it today. uwu

@Solo
Thank you very much for the info! I'm planning to poke around just in OpenGL mode, as the experimental branch is already crashing in Software mode, LOL.

Feel free to visit the TWHL Discord if nobody here at the forums is really responding.

"If your map lags - it is usually due to micro leaks your current compilers won't even detect. One more reason to use the compilers I recommended they got a very good detection system to find such micro leaks."

I'm sorry, but this is stupid. If any sort of leak happened, HLVIS and HLRAD would likely crash. In fact, HLBSP could probably crash first because some of the coordinates in the .prt file would go to infinity.
If your map lags, then your map is either not optimised at all or it's just so complicated and full of details in one big area that you can't optimise it (which is bad design).

In other words, if you're using a big hollow box around your map (as a sky "box"), then the engine is gonna render almost the entire damn map, and that is just too much for weak PCs. Maybe you are also compiling with fast VIS, which also leads to the engine rendering everything at once.

Also yes, flickering lights do cause lag because the lightmap data has to get modified by the CPU, then reuploaded to the GPU every 0.1s, which is horrible for performance.

"Ever wondered why you haven't seen a CS_superbowl map? I am not saying it can not be done, I am saying that the engine isn't up to it."

The engine can be up to it if you do it right.

Oh, we got tutorials for that here at TWHL Wiki:

https://twhl.info/wiki/page/Half-Life_Programming_-_Getting_Started

Glad it worked, though!

It'd require a little bit of programming. Each monster has got a 'classification', which can be one of the following:

• CLASS_NONE
• CLASS_MACHINE
• CLASS_PLAYER
• CLASS_HUMAN_PASSIVE
• CLASS_HUMAN_MILITARY
• CLASS_ALIEN_MILITARY
• CLASS_ALIEN_PASSIVE
• CLASS_ALIEN_MONSTER
• CLASS_ALIEN_PREY
• CLASS_ALIEN_PREDATOR
• CLASS_INSECT
• CLASS_PLAYER_ALLY
• CLASS_PLAYER_BIOWEAPON
• CLASS_ALIEN_BIOWEAPON
• CLASS_BARNACLE

So, you could download Solokiller's updated HL SDK for Visual Studio 2019 and change every CLASS_PLAYER_ALLY for example, into CLASS_HUMAN_MILITARY, then compile the .dll files.

Or you can just edit the monster relationship table:Alternatively, you could probably use Spirit of Half-Life 1.2, which allows you to set the classification for each monster individually, in the map editor. (though, it has a tendency to break other things and crash more often than vanilla HL)

I forgot I was gonna do that. Oops. Well, now is the weekend, so... time to see.

This part here:Basically, you have a 4-sided brush there, while the other 3 brushes are 3-sided.

It needs to be merged into the same corner, like this:

Are those boxes func_wall?
You might wanna switch them to world brushes, or func_detail.

Doom 3 is the best Doom IMO.

Chances are, you probably just placed the brush outside the map boundaries. Do you have any brushes that go over 4096 units, or under -4096 units?In this screenshot, for example, every single brush is within the -4096 to +4096 unit range. Regular entities will stop moving if they reach those boundaries.

Also, what compilers are you using? ZHLT or VHLT?

Also, one thing to keep in mind is, you're gonna need an updated header file for BSP models.
As for the offsets, I'll try to check these out this weekend.

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.