Forum posts

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.

I think it's possible.

Taking a look at the source code reveals that "framerate" is actually a float. Here's the entire thing (not all keyvalues are included here as some entities have their own ones):

typedef struct entvars_s
{
    string_t    classname;
    string_t    globalname;

    vec3_t        origin;
    vec3_t        oldorigin;
    vec3_t        velocity;
    vec3_t        basevelocity;
    vec3_t      clbasevelocity;  // Base velocity that was passed in to server physics so
                                 //  client can predict conveyors correctly.  Server zeroes it, so we need to store here, too.
    vec3_t        movedir;

    vec3_t        angles;            // Model angles
    vec3_t        avelocity;        // angle velocity (degrees per second)
    vec3_t        punchangle;        // auto-decaying view angle adjustment
    vec3_t        v_angle;        // Viewing angle (player only)

    // For parametric entities
    vec3_t        endpos;
    vec3_t        startpos;
    float        impacttime;
    float        starttime;

    int            fixangle;        // 0:nothing, 1:force view angles, 2:add avelocity
    float        idealpitch;
    float        pitch_speed;
    float        ideal_yaw;
    float        yaw_speed;

    int            modelindex;
    string_t    model;

    int            viewmodel;        // player's viewmodel
    int            weaponmodel;    // what other players see

    vec3_t        absmin;        // BB max translated to world coord
    vec3_t        absmax;        // BB max translated to world coord
    vec3_t        mins;        // local BB min
    vec3_t        maxs;        // local BB max
    vec3_t        size;        // maxs - mins

    float        ltime;
    float        nextthink;

    int            movetype;
    int            solid;

    int            skin;
    int            body;            // sub-model selection for studiomodels
    int         effects;

    float        gravity;        // % of "normal" gravity
    float        friction;        // inverse elasticity of MOVETYPE_BOUNCE

    int            light_level;

    int            sequence;        // animation sequence
    int            gaitsequence;    // movement animation sequence for player (0 for none)
    float        frame;            // % playback position in animation sequences (0..255)
    float        animtime;        // world time when frame was set
    float        framerate;        // animation playback rate (-8x to 8x)
    byte        controller[4];    // bone controller setting (0..255)
    byte        blending[2];    // blending amount between sub-sequences (0..255)

    float        scale;            // sprite rendering scale (0..255)

    int            rendermode;
    float        renderamt;
    vec3_t        rendercolor;
    int            renderfx;

    float        health;
    float        frags;
    int            weapons;  // bit mask for available weapons
    float        takedamage;

    int            deadflag;
    vec3_t        view_ofs;    // eye position

    int            button;
    int            impulse;

    edict_t        *chain;            // Entity pointer when linked into a linked list
    edict_t        *dmg_inflictor;
    edict_t        *enemy;
    edict_t        *aiment;        // entity pointer when MOVETYPE_FOLLOW
    edict_t        *owner;
    edict_t        *groundentity;

    int            spawnflags;
    int            flags;

    int            colormap;        // lowbyte topcolor, highbyte bottomcolor
    int            team;

    float        max_health;
    float        teleport_time;
    float        armortype;
    float        armorvalue;
    int            waterlevel;
    int            watertype;

    string_t    target;
    string_t    targetname;
    string_t    netname;
    string_t    message;

    float        dmg_take;
    float        dmg_save;
    float        dmg;
    float        dmgtime;

    string_t    noise;
    string_t    noise1;
    string_t    noise2;
    string_t    noise3;

    float        speed;
    float        air_finished;
    float        pain_finished;
    float        radsuit_finished;

    edict_t        *pContainingEntity;

    int            playerclass;
    float        maxspeed;

    float        fov;
    int            weaponanim;

    int            pushmsec;

    int            bInDuck;
    int            flTimeStepSound;
    int            flSwimTime;
    int            flDuckTime;
    int            iStepLeft;
    float        flFallVelocity;

    int            gamestate;

    int            oldbuttons;

    int            groupinfo;

    // For mods
    int            iuser1;
    int            iuser2;
    int            iuser3;
    int            iuser4;
    float         fuser1;
    float         fuser2;
    float         fuser3;
    float         fuser4;
    vec3_t        vuser1;
    vec3_t        vuser2;
    vec3_t        vuser3;
    vec3_t        vuser4;
    edict_t        *euser1;
    edict_t        *euser2;
    edict_t        *euser3;
    edict_t        *euser4;
} entvars_t;

vec3_t -> string
edict_t -> don't list these as keyvalues
string_t -> string
byte -> normally you shouldn't do this, but it'll be an integer
int -> integer
Also, everything after // For mods shouldn't be included in FGDs.

Quite simple:

If it's a whole number, then integer. Candidates: 0, 1, 2, 3 etc.
If it's a real number (such as a delay in seconds), then string. Candidates: 0.1, 0.2, 2.0, 0.2948 etc.
String is rather used for alphanumerical values, but since there's apparently no floating point type in FGDs, we improvise.

If you don't provide a value for a keyvalue, then that keyvalue won't be written into the .map file.
As such, it's gonna default to 0 in-game.

The safest (but also the longest) way would be to take a look at the HL SDK code, and see each KeyValue() function of each entity (as well as the definition of the entvars_t structure). There you'll know for sure which keyvalue is supposed to be which type.

I think the problem is, he wants to have so-called "lazy viewmodels". There, the viewmodel 'reacts' to changes in the view angles, by sort of lagging behind the current view angles.

You could log all subsequent angles into an array, then calculate a reaction based on that, or you could calculate the difference between the current and last view angles.

Do keep in mind that you'll have some problems with the yaw, since the yaw in view angles is -180 to +180. Once the last angle is 179, and the next angle is -179, the algorithm will think it's a difference of 358 degrees, which will "punch" your screen. I solved that somehow, can't remember exactly how I did it now.

So good luck. I might share some code later. Alternatively, look at Doom 3's view swaying code.

You'll need some programming knowledge.
I got some stuff written about that:

Introduction to Half-Life programming
Better view bobbing - basics of view swaying.

TL;DR
If you go the 1st route (the one that Bruce said), you'd need Visual Studio 2017 Community Edition, and preferably a HL SDK fork that works with VS 2017, like Solokiller's fork. (I mean, it doesn't really matter. You can use Visual Studio 6.0 from 1998, and HL SDK 2.3, but I'm saying VS2017 and a modified fork just because it's nicer to work in a modern environment)

Then you'll have to go to view.cpp on the clientside project, and do your maths there.
You'll get this sort of end result:If you want to achieve the Black Mesa style "weapon lag", like in the GIF, then you'll need to interpolate the angles, or alternatively, log a series of positions and use the last logged position, and that again, needs a bit of maths.

If you go the 2nd route, well, there isn't much to say there. Find a programmer to do it for you, or pay them (or don't, if they work for free).

No need to get angry, some people simply read too fast then they don't understand the question.

But yes, there are no tutorials for that sort of thing yet. There's one called "Dead NPCs for HL1 and CS" but it uses cycler entities which is not in the scope of this thread.

As you said, one of the ways to do it is to use monster_generic with the model you're looking for, then trigger an aiscripted_sequence when the map starts (so that the model starts with the corpse animation).
Or actually, you can define the Animation Sequence keyvalue right away, which is what you did. Good job.

Start off with photo-sourcing. Go out, take a photo of the floor or something, and turn it into a texture. Later on, you'll likely learn to hand-paint textures with various brushes.

With models, it'll be better to hand-paint them or mix textures from photos together. So good luck. There are hundreds of ways you can make textures, even procedurally.

That is called learning. No need to be sorry.

"took me a about a day to find out how to do it."

Same. When I started using 3ds Max 9 in 2015, it basically took me a day to get a texture up on a simple cube.
Any modern modeling program is like that, really.

It's a different philosophy from Hammer, where you simply right-click a face in the Texture tool.
Meanwhile in modeling programs, you create a material, give it an image, and apply it.
Furthermore, you don't have the Select tool, you don't have the Clipping tool and whatnot. Instead, you got a different set of tools that are suited for both organic and anorganic geometry, so you got functions like Bevel. In Hammer, you'd have to use the Clipping tool, then cut the edge off diagonally. If you wanted it to be smoother, you'd have to cut the edge multiple times. Meanwhile in Blender, you select an edge, use Bevel, and set the parameters, like how many cuts, how smooth, you get the point. Combined with Blender's hotkeys, it's a pretty fast way of modeling things.

It is that different philosophy and way of thinking, which you have to learn. Once you're over that obstacle, you'll be skyrocketing in modelling.

Or rather, if you're using Blender 2.80, press Z then either click Rendered or LookDev.

You can find the Materials tab on the bottom-right portion of the window. Blender is designed for modern workflows so it supports something called materials, which is a bunch of different texture maps that define a surface. GoldSrc only uses diffuse maps, or Base Color if we speak in Blender terms.

I highly suggest you to find some beginner tutorials for Blender. They can get you started quickly.

In the FGD entity definition, add studio().
@PointClass base(Target) studio() = env_something
Not sure if you gotta make the following change as well, but:
model(string) : "Model" should he changed to:
model(studio) : "Model"
Note: this is just an example, there is no env_something.

Hammer 3.4 doesn't support models, if I recall correctly. 3.5.2 beta does, however.

Sure thing. I'm quite interested to see how it goes.

Yeah, I never drank alcohol myself. :s
About jumping, I'm only afraid that the device would break or something like that. I have that feeling when walking over bridges, lol.

But yeah, it seems pretty cool. I could help you with a part of the electronics since I got a bit of knowledge.

I wasn't making fun out of you. Good lord, people never understand me. <-<

The drunk part was referring to the fact that it's a very cheap system, so perhaps it'd not be very accurate in tracking. Hence you'd feel easily nauseated and drunk. But that's just my assumption until I see more specifications.

Well, I think it is. Especially if you wanna feel drunk while playing or something.

Well, it requires Cg Toolkit, which I currently don't have installed. Pretty sure it's some old version of it that we can't find any more.
Other than that, it's got some errors of its own, like with the particle system.(DirectInput as well?)

I'd spend more time on it and set up everything (should work with Cg 2.2, I believe), but I'm in the middle of multiple projects. So I can't do it right now. (maybe another time)
Either way, if you got Visual Studio 2017 or 2019, you should be able to get the source code to compile if you fix everything. Here's Cg 2.2.

Well, it's a bit complicated.

You'd have to analyse the maths behind Half-Life 1 player movement, then analyse the maths behind HL2's player movement. Then you compare them, to see where they differ. Then, you just copy the changes from HL1 movement to your source code.

Sadly, I haven't worked with any player movement codes myself, so I can't help much here. I suggest you to learn a bit of Source SDK like how to create a new entity class, in order to understand how things generally work in it. Then player movement will be easier to understand, and in the end, easier to edit because you'll know where to look for things to edit.