Forum posts

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.

Compile time error or game crashes?

If the game crashes when playing the sound, you gotta precache the sound in ClientPrecache().

Sound emitting is done via PlaySound(), if I remember correctly, you can find examples of its usage in ev_hldm.cpp

You don't have to bind one key to call both showhud and impulse 102.
Instead, on the clientside, inside showhud's function, you can do something like EngineClientCmd( "impulse 102" ). Dunno if it's gonna exactly work, but it could be worth a try.

Alternatively, you can do the CLIENT_PRINTF part and the sound emitting part both on the clientside, unless you really need it on the serverside.

If the EngineClientCmd part doesn't work, we can hack it.
Call EngineClientCmd( "showhudsrv" ), and in the ClientCommands function in client.cpp, add an else if line where you'll compare pcmd to "showhudsrv", and inside of that, you're gonna change the player's pev->impulse to 102.
It's a bit ugly, but, there's always a workaround for everything.

"Remember, it is not so much detailed except in the ass"

So that's how the rear end of a ship is called.

Hmm. This might be a bit more complicated since we gotta toggle a button. I'll see a bit more about this tomorrow.

But either way, input.cpp is the right place for this stuff and that's what I know for sure.

So you want to make a new key, which will basically do something completely clientside, right?
That tutorial shows you how to do things on the serverside. It is using client commands to do the job.

When you bind a key, like "firemode", e.g. bind x firemode, and then you press that key, it will send a client command, which will go from the client to the serverside.

The serverside handles it all in ClientCommand()You should know that pcmd is the string, which you are gonna compare, for example if pcmd's contents are equal to "firemode".
However, you're looking at the wrong place.

If you want to do things ENTIRELY on the clientside, you can easily do everything there. Just look at input.cpp Inside InitInput(), you can connect commands to an existing function on the clientside.
Here are several examples:However, in order to make any use of this, I gotta ask you, what are you exactly trying to do with a new keybind? Is it toggling a weapon fire mode, or is it meant to do something else?

"Oh, I agree. I'm not trying to shoot you down."

I understand, I was just letting you know that this isn't stuff I'd usually produce, since I gotta do this stuff SUPER FAST to get everything done in time. But of course, it leads to abominations at certain times.

This is the last level of my previous game (the game that took me about 45 days to get all the assets made):I got no plans to rush with Utopia at Stake, so don't worry about that one.
Thanks for pointing it out either way though. I do appreciate feedback.

Nah, it looks more like wet rubber than anything.
But, it still looks like an MP5, so the judges won't complain. (talking about the local gamedev competition)

Had I not been doing this so hastily, it would've looked much better. I gotta spend most of my time on things I'm not good at to get an acceptable result, which will mostly be the character models for the demo. Then the animations. That will probably take me a month total.

To get an acceptable result with something like an MP5, 2 days is enough for me. Maybe even one day if I do it from morning to midnight. Otherwise, if I hadn't had a tight time constraint (due to the competition), I would've worked enough to go from "acceptable" to "up to my standards", which would've been 4 to 5 days.

Now that I think about it, don't you rather mean the Beretta than the MP5? That thing looks like it was forged, LOL.

So, if anything looks like it needs some work, don't point it out. I'm not actually satisfied with any of the results, but they look acceptable and not like total garbage I once used to do. Once the demo is over though, I'm either going to rework a bunch of assets or move on to another project.

Also, someone might ask me "Why are you doing everything, even the stuff you're not good at?"
Quite simply, to get better at it. It'll take way more time than focusing on one skill, but it's sure worth it.

Thanks. <3

Speaking of speed modelling:8 days of work total. SMG took 2 days (mesh and texture), Beretta took 2 days (mesh and texture), and roughly each mesh takes about a single day. Considering that a low-poly car used to take me a frickin' week to make, which was of way inferior quality compared to this stuff, wow. :3
I've definitely improved since 2016.

I also made some changes to my old hands model:It's less blocky now. ^w^

Also, a rather not-so-nice character model:But it's my first. And considering it was made in a damn rush, yeah, not too bad.

I recommend starting with this tutorial instead:
https://gamebanana.com/tuts/12801

You'll be using VS 2017 instead of 2015 (actually, 2019 should also work) and a slightly updated version of the HL SDK which changed some of the C code into C++.

"abs" is a function that returns the absolute value of a number.
For example, abs(-20) would return 20. The ambiguous part means that abs(-20) can be interpreted in multiple ways. In other words, it is confused as to what this "-20" means in my example. It can be a whole number, it can be a real number, yada yada.
As for the overloaded part, don't worry about it for now.

How to fix it depends on the code that is calling that abs() function. However, I advise you to go with the tutorial I posted in the start of my post. (also, while installing VS 2017, check XP support, I believe it is required)

The only documentation I was able to find is right here:
http://www.slackiller.com/tommy14/hltexture.htm

They can't do much though. Due to how compilers currently work, they exclusively only, and I mean, ONLY accept !cur_90, !cur_0, !cur_270, !cur_180, !cur_up, or !cur_dwn, so nothing in between, and no suffixes like !cur_90_lab.

They work as world brushes, but they push way too fast, tschumann.
I uploaded an example map to the Vault back in 2016.

Circa line 2000, on the bottom of StudioRenderFinal_Hardware:

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

There we go. :3

It's r_drawentities 5

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

You're welcome, and thank you.

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

STATIC_BOX

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

SOLID_BBOX is compatible with hitbox collision.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Those strange cur_ textures push waaaaaay too much (you end up reaching 3000 units/sec or so), I would advise against using them. :3

Keep in mind that a value of 255 corresponds to 90°.
So 50 doesn't mean 50°, but rather 50/255 out of 90°, in other words about 18°.

And how did you fix it?

Therefore, HL3 will be released for quantum computers!
Everyone doesn't have quantum computers.

btw how long do you think until someone will create a non vr version mod ? XD

My speculation is, less than 4 months after the SDK releases, if they provide one.

NGL, I'm hyped more for the tech than the game itself, ahaha.

Who wants to buy an Admer? There is no VR hardware to be found in Bosnia, I gotta get out somehow.

They should release games more often

They should totally make games more often, since they're still good at it.

@potatis_invalid
It's for an idTech 4 game of mine. I wanted to have some modular road pieces for some flat grounds, though I'll mostly model each one uniquely, i.e. make one model that is specific to one area, because most of the terrain will be bumpy anyway.

Speaking of the game, I am implementing interactive computer terminals into it (ones that you come up to and type), and now I'm getting an idea how to do the same in my HL mod.

Check liblist.gam, I believe there are some keywords that have to be enabled in order to show or not to show the servers button.

Ah wait. Bottom right, with a Steam icon saying "Servers"? Dunno about that one, frankly. :/

OH MY GOD HOW CUTE X3

I almost died of cuteness when I saw those photos. It's soooooooo adorable!

Is it about the lighting gradients?
I notice that in the screenshot, the lightmap tries to pull off a gradient on the ceiling, but in 24-bit RGB, it's a little bit limited and you get unnatural colour "bands", noise in the colour, because there are only 256 levels of lightness available.

Try using some less-clean textures, they can help get rid of the colour bands.

This occurs when a lightmap tries to pull off a smooth gradient, but the pixel format while rendering doesn't actually provide enough colours to smoothen them well enough.

I got one idea, but it'd be too much effort.

First of all, you'd basically launch a map as soon as you got into the game. Then a custom main menu would show up.
You'd likely have to use TriAPI there if you don't wanna mess with VGUI1 (and keep in mind, there is no access to VGUI2) to render main menu elements.

And then you'd have it. A frozen player with a main menu being rendered onto the view.
To change settings, you could easily modify the CVars via these custom menu elements, I believe.

The bad thing is, it'd require too much work, basically a complete replica of the main menu code.

So yeah, as others pointed out, you could use Xash3D.

Abbadon has coding powers, so of course it's possible. The scientist class has a follow task&schedule:And it's handled somewhere in the GetSchedule function:Keep in mind that this is scientist-specific, so you don't necessarily have to make your monsters heal each other. But you can.

If you base your monster off CTalkMonster, I believe you could get such monsters (that are spawned by a monstermaker) to follow a certain thing:You can call StartFollowing and pass it the entity you need the monster to follow. I'm not exactly sure what approach you're going for, but I think this is approximately what you need to follow a monster.