Forum posts

Posted 15 hours ago2020-04-08 19:26:21 UTC
in A Utopia At Stake Post #344070
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.
Admer456 Admer456If it ain't broken, don't fox it!
Posted 2 days ago2020-04-07 06:42:13 UTC
in TWHL! Sound off! (who are you) Post #344034
Cheese is too cheesy without its comrades. <w<
Admer456 Admer456If it ain't broken, don't fox it!
Posted 3 days ago2020-04-06 00:17:30 UTC
in A Utopia At Stake Post #344024
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. :P
FreeImage looks good too, but I'll see about all that.
Admer456 Admer456If it ain't broken, don't fox it!
Posted 4 days ago2020-04-05 08:45:27 UTC
in A Utopia At Stake Post #344017
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.
Admer456 Admer456If it ain't broken, don't fox it!
Posted 1 week ago2020-04-01 14:13:34 UTC
in A Utopia At Stake Post #344000
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!
Admer456 Admer456If it ain't broken, don't fox it!
Posted 1 week ago2020-03-31 11:37:46 UTC
in A Utopia At Stake Post #343994
Map textures can be modified too. So that's a good thing. uwu

video
video 2

Software water effect in OpenGL, anyone? :walter:
Admer456 Admer456If it ain't broken, don't fox it!
Posted 1 week ago2020-03-28 18:59:13 UTC
in Opposing force and Blue Shift source code? Post #343985
"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.
Admer456 Admer456If it ain't broken, don't fox it!
Posted 1 week ago2020-03-28 16:20:39 UTC
in Opposing force and Blue Shift source code? Post #343982
Are you compiling both DLLs?
You should compile both client.dll and hl.dll.
Admer456 Admer456If it ain't broken, don't fox it!
Posted 1 week ago2020-03-28 09:21:39 UTC
in Opposing force and Blue Shift source code? Post #343975
"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.
Admer456 Admer456If it ain't broken, don't fox it!
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. :)
Admer456 Admer456If it ain't broken, don't fox it!
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!
Admer456 Admer456If it ain't broken, don't fox it!
Posted 1 week ago2020-03-27 16:57:16 UTC
in Opposing force and Blue Shift source code? Post #343963
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.
Admer456 Admer456If it ain't broken, don't fox it!
Posted 1 week ago2020-03-27 16:51:57 UTC
in get steam VR source 2 VHE? Post #343962
"You are correctly: Blender is brilliantly. But Unity with Probuilder or CSG Shake too."
I don't like Unity. :crowbar:
Admer456 Admer456If it ain't broken, don't fox it!
Posted 1 week ago2020-03-27 11:52:19 UTC
in TWHL! Sound off! (who are you) Post #343955
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
Admer456 Admer456If it ain't broken, don't fox it!
Posted 1 week ago2020-03-26 18:33:08 UTC
in TWHL! Sound off! (who are you) Post #343948
Oh cool, a thread where we share stuff about ourselves. :D

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. :walter:
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. :P
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. ;)
Admer456 Admer456If it ain't broken, don't fox it!
Posted 2 weeks ago2020-03-26 10:38:21 UTC
in get steam VR source 2 VHE? Post #343945
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)
User posted image
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.
Admer456 Admer456If it ain't broken, don't fox it!
Posted 2 weeks ago2020-03-20 20:54:03 UTC
in A Utopia At Stake Post #343934
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
Admer456 Admer456If it ain't broken, don't fox it!
Posted 3 weeks ago2020-03-14 20:03:35 UTC
in Post Your Timeline Post #343907
User posted image
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:
User posted image
User posted image
Been to Montenegro once, but I mostly stick around in Stolac and Mostar, sometimes but sometimes Sarajevo if I really gotta go there. ;)
Admer456 Admer456If it ain't broken, don't fox it!
Posted 1 month ago2020-03-08 00:10:00 UTC
in Sierra.avi and valve.avi video format Post #343872
@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.
Admer456 Admer456If it ain't broken, don't fox it!
Posted 1 month ago2020-03-07 18:52:19 UTC
in Sierra.avi and valve.avi video format Post #343869
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.
User posted image
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.
Admer456 Admer456If it ain't broken, don't fox it!
Posted 1 month ago2020-03-07 12:39:25 UTC
in A Utopia At Stake Post #343864
It seems that BOLIDHINT works. :D

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:
Reference - approximately 130 facesReference - approximately 130 faces
NULL - 592 wpolys, bad subdivisionNULL - 592 wpolys, bad subdivision
BEVEL - 594* wpolys, bad subdivisionBEVEL - 594* wpolys, bad subdivision
SOLIDHINT - 446 wpolys, good subdivisionSOLIDHINT - 446 wpolys, good subdivision
BOLIDHINT - 446 wpolys, good subdivisionBOLIDHINT - 446 wpolys, good subdivision
*594, probably because one of my view angles was just 1 or 2° off, but it'd be 592 otherwise. :P

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.
Admer456 Admer456If it ain't broken, don't fox it!
Posted 1 month ago2020-03-05 18:38:27 UTC
in A Utopia At Stake Post #343856
Say hello to BOLIDHINT, our new tool texture family member!Say hello to BOLIDHINT, our new tool texture family member!
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.
User posted image
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. :thebox:
Admer456 Admer456If it ain't broken, don't fox it!
Posted 1 month ago2020-03-01 08:40:08 UTC
in Post your screenshots! WIP thread Post #343835
Holy heck, so that's the room that I dreamed about last night. O.o (last screenshot)
Admer456 Admer456If it ain't broken, don't fox it!
Posted 1 month ago2020-03-01 08:38:00 UTC
in A Utopia At Stake Post #343834
"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. :walter:

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.
Admer456 Admer456If it ain't broken, don't fox it!
Posted 1 month ago2020-02-29 18:14:06 UTC
in Gilding the lilly: selective types of sttack Post #343828
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.
Admer456 Admer456If it ain't broken, don't fox it!
Posted 1 month ago2020-02-29 16:42:10 UTC
in A Utopia At Stake Post #343826
"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.
User posted image
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.
bigterrain2.bsp - J.A.C.K. could use a farther back clipping plane herebigterrain2.bsp - J.A.C.K. could use a farther back clipping plane here
User posted image
The two large maps before this one were 16k x 16k and 32k x 32k respectively.
bigterrain1.bsp - first large test mapbigterrain1.bsp - first large test map
airveh1.bsp - air vehicle testing mapairveh1.bsp - air vehicle testing map
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. :walter:
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.
Admer456 Admer456If it ain't broken, don't fox it!
Posted 1 month ago2020-02-24 18:55:38 UTC
in Shameful mapping confessions Post #343777
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.
User posted image
To be exact:
User posted image
God, forgive me for my sins...
I was even paid for that map, LOL.
But yeah, never done anything like that afterwards.
Admer456 Admer456If it ain't broken, don't fox it!
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.
Admer456 Admer456If it ain't broken, don't fox it!
"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. :)
Admer456 Admer456If it ain't broken, don't fox it!
Posted 1 month ago2020-02-16 08:51:30 UTC
in A Utopia At Stake Post #343752
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".
Admer456 Admer456If it ain't broken, don't fox it!
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.
Admer456 Admer456If it ain't broken, don't fox it!
Posted 1 month ago2020-02-15 13:20:13 UTC
in A Utopia At Stake Post #343747
"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. :o

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. :P
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.
Admer456 Admer456If it ain't broken, don't fox it!
Posted 1 month ago2020-02-13 12:36:54 UTC
in Post your screenshots! WIP thread Post #343744
Oh, just wait 'til you see them playfully flying around the place. ;)
Admer456 Admer456If it ain't broken, don't fox it!
Posted 1 month ago2020-02-11 20:42:28 UTC
in Post your screenshots! WIP thread Post #343739
Almost forgot about Valentine's Day, heh.
Time to follow my tradition again. ^^
User posted image
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. :)
Admer456 Admer456If it ain't broken, don't fox it!
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.
Admer456 Admer456If it ain't broken, don't fox it!
Posted 1 month ago2020-02-09 19:22:47 UTC
in A Utopia At Stake Post #343733
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. :3
User posted image
For 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.
Admer456 Admer456If it ain't broken, don't fox it!
Posted 2 months ago2020-02-08 16:11:32 UTC
in Post your screenshots! WIP thread Post #343731
User posted image
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.
Admer456 Admer456If it ain't broken, don't fox it!
Posted 2 months ago2020-02-08 07:08:59 UTC
in A Utopia At Stake Post #343730
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.
Admer456 Admer456If it ain't broken, don't fox it!
Posted 2 months ago2020-02-07 20:54:01 UTC
in A Utopia At Stake Post #343728
User posted image
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:
User posted image
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.
User posted image
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. :walter:
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.
Admer456 Admer456If it ain't broken, don't fox it!
Posted 2 months ago2020-02-03 05:27:53 UTC
in Post your screenshots! WIP thread Post #343721
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. ;)
Admer456 Admer456If it ain't broken, don't fox it!
Posted 2 months ago2020-02-02 18:52:48 UTC
in Post your screenshots! WIP thread Post #343719
Bro. I said about 10° to the east and a bit to the south from Turin, not the same place. :v
Admer456 Admer456If it ain't broken, don't fox it!
Posted 2 months ago2020-02-02 10:50:13 UTC
in Post your screenshots! WIP thread Post #343716
"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.
Admer456 Admer456If it ain't broken, don't fox it!
Posted 2 months ago2020-02-01 20:18:55 UTC
in Post your screenshots! WIP thread Post #343714
It is an 80s car, however, it's not a Škoda. Go a bit more to the south. :)
Admer456 Admer456If it ain't broken, don't fox it!
Posted 2 months ago2020-02-01 15:43:59 UTC
in Post your screenshots! WIP thread Post #343712
"BTW, you are using Blender, right?"
Yeah, I'm using Blender.
Also, I've been working on my 2nd car model:
User posted image
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
Admer456 Admer456If it ain't broken, don't fox it!
Posted 2 months ago2020-01-31 17:02:40 UTC
in Post your screenshots! WIP thread Post #343707
Yay. ^^
Meanwhile I made another character model. Started last night, and this is how the mesh looks at the moment:
User posted image
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.
Admer456 Admer456If it ain't broken, don't fox it!
Posted 2 months ago2020-01-29 16:47:26 UTC
in Post your screenshots! WIP thread Post #343705
That's dedication. :walter:

You still didn't answer my question though. >w<
Will there be explosive sequences etc.?
Admer456 Admer456If it ain't broken, don't fox it!
Posted 2 months ago2020-01-29 09:45:36 UTC
in Post your screenshots! WIP thread Post #343703
But the real question is:
What ships will go KABOOM when damaged enough? :o
Admer456 Admer456If it ain't broken, don't fox it!
Posted 2 months ago2020-01-26 16:56:43 UTC
in Binding new Keys that run clientside functions. Post #343699
Hmm.
TBH I don't do HL AI programming just yet, so I can't really help you on that one.
Admer456 Admer456If it ain't broken, don't fox it!
Posted 2 months ago2020-01-26 14:07:11 UTC
in Binding new Keys that run clientside functions. Post #343697
"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?
Admer456 Admer456If it ain't broken, don't fox it!
Posted 2 months ago2020-01-26 11:48:10 UTC
in Binding new Keys that run clientside functions. Post #343694
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?
Admer456 Admer456If it ain't broken, don't fox it!