Forum posts

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.

In Half-Life 1, you'll find the player movement code in sources prefixed with pm_, as it stands for "player movement".
For example, pm_shared.cpp. There, you will see player movement for GoldSrc, which you'd have to adapt for your Source mod.

Also, what exact errors are you getting? Are you opening a single .cpp file then trying to compile it, or do you open the appropriate .sln (solution) file and then compile?

As for DLLs, you can't "explore" them, because they're compiled. For a beginner, let's just say they're executable, just like .exe, but you can't execute them directly. The SDK code is meant to compile new DLL files (client and server), so if you wanna know how some entities work, you would look at the source code in the Source SDK.
Alternatively, you can disassemble a DLL with some programs, but for someone who's new to programming and modding in general, let's not talk about them.

Bosnian village roads.
Also, an offroad variant:

"I tried coding, whatever I do, I can't get it to compile."

Which exact source code were you compiling, and what compiler did you use? Chances are, you used Visual Studio 2017's toolset on something that can't compile on anything after Visual Studio 6.0 from 1998. Or even something totally different, like Dev-C++ or Code::Blocks.

Precisely, that'd be FCVAR_ARCHIVE.
If the hud_color console variable doesn't have that flag enabled, it won't get saved. So, we'd have to look at the SOHL source code then. Think of hud.cpp or any place like that.

So, next up: physics.You might notice that the boxes clip into the floor by approximately 1 or 2 units. That's because I currently don't have a proper thing for map collision. Instead, I made a phys_staticplane to prevent the boxes from falling through what we see as the floor.
I'll resort to an external mesh for this type of stuff. Reading geometry from the BSP is cool and all that, but what if we want a separate physics mesh for the map? Eh?
As of right now, the system goes like this:

mapname.bsp - actual map
mapname.bsp.obj - .obj model file made from an exported .map file. It's easy to do with tools like Crafty or Noesis or whatever you use.

However, I might end up writing a tool that reads a .map file and just converts the thing to .obj. It'd be kinda cool to add new stuff to my mapping workflow. (or whoever ends up working on the mod, or using the mod base)
Obviously, I'm not planning to replace GoldSrc's physics anyhow. Just adding special physics entities on top of the whole thing. And NO, no ragdolls. I know I'm crazy, but not THAT crazy.

Of course, maps will have the option to have or not have physics. It's as simple as that. Vehicles may or may not require physics. I'll have to see about that at some point. Probably not though!

Either way, currently I'm juggling through pointer hell, because there seems to be some stuff about the map collision mesh. Pretty sure it's a null pointer somewhere. Read access violations can be a beach. (you know what I really wanted to say)
bvtBvhTriangleMeshShape is being used. Though I guess I just need to read the documentation a bit more.

Pretty much that. ^
Log to the console whenever you can or are having trouble.

Sometimes you can also use a debugger, for stuff that goes too fast or is too complicated to track via the console. (e.g. buncha nested for loops or a dozen variables you gotta keep tracking)

Well, something could be done about that too, though I can't say much right now.

I used the number 1 because each "finger" has two bones: its own bone, and its child bone. Each finger attaches itself to a child bone.
So I was thinking of a chain, where each finger has a parent and a child. Finger A is the parent, finger B is the child, but a parent to finger C, for example.However, of course, you can easily achieve a swarm like what you said. In theory, at least.
It'd look something like this:At least the way I imagined it.

I think you'd still have to change the angles, but nonetheless, it'd be a really flexible system where you can detach a group from the parent to have its own AI, for example.

Also, LOL, yeah, I learn fast when I'm panicking for my future. I've been learning programming since 2015, I just had a chance to start doing it practically last year.

There we go:For example, you could make a "chain" of entities that attach to each bone.
Those entities could use the 'target' as the parent bone entity.

What this means is, you would do something like this:

CBaseEntity *pParent = UTIL_FindEntityByTargetname( NULL, STRING( pev->target ) );

GET_BONE_POSITION( ENT( pParent->pev ), 1, pev->origin, pev->angles );
UTIL_SetOrigin( pev, pev->origin );

This is the most basic way. Of course, there would have to be more checks, and stuff.
For example, you can write the entity class to have m_pParent instead of allocating it in the Think() function every time.
A think function is required for the entity to update its position fast enough, basically, or else it'll appear choppy.

So here's what you could do: (alert: this isn't the finished code, it needs some extra security checks to avoid crashing etc.)

CAbbadonChain::SpawnThink( void )
{
    m_pParent = UTIL_FindEntityByTargetname( NULL, STRING( pev->target ) ); // find our target

    SetThink( &CAbbadonChain::Think ); // we've spawnthought, now it's time to attach to the bones
    pev->nextthink = gpGlobals->time + 0.1;
}

CAbbadonChain::Think( void )
{
    GET_BONE_POSITION( ENT( m_pParent->pev ), 1, pev->origin, pev->angles );
    UTIL_SetOrigin( pev, pev->origin ); // to make me physically move to that origin, after I've visually moved there

   pev->nextthink = gpGlobals->time + 0.01;
}

And of course, somewhere in the Spawn() function, you'll SetThink( &CAbbadonChain::SpawnThink ); and maybe pev->flags ^= FL_ALWAYSTHINK; if you want your entity to think every frame.
Don't forget to put EXPORT in the declarations too:

void EXPORT SpawnThink( void );
void EXPORT Think( void );

Lastly, remember that this method might be a little bit network performance unfriendly, because you're now managing 3 or more entities instead of just 1. But if it's a singleplayer mod, then go for it.

I'm surprised you haven't heard of this one before.

Basically, you can use a certain macro that calls an engine function, to attach stuff to a bone, or attachment if you use that. I'll post more about it when I wake up, as it's currently very late at my place. xd

You can always attach stuff to bones, though. Either via attachments or directly attaching to a bone.

Yes.

I had a fascinating playtest session with my brother last night. The vehicles work rather well in multiplayer. So yeah, vehicle deathmatch is definitely gonna be a thing. Sure, it's never gonna be as smooth as it is in singleplayer, but the vehicles are very driveable.

Originally, I was going to do a simulation for cars, but hey, this is an action comedy type of thing (apart from the other characteristics of the mod). So I'll do a bit of more liberal car physics. Think of GTA: San Andreas for reference.

I could do what Gran Turismo 1 & 2 did, which is having a separate mode for arcade and simulation driving, though that's pretty much 2x more work. On top of that, you gotta remember that racing sims use really high-poly tracks so that they're smooth enough for the simulation to be accurate. It'd require QUITE some clipnodes for that. Unless I use Bullet for the simulation mode, where I could easily use the external physics mesh.

Hmm... for now, let's just stick to GTA:SA style arcade driving. Also, for the sake of network performance, I'll have to ditch the idea of assembling a car out of different pieces. I mean, let's take into account a veh_car_base, with 4 veh_wheel entities, and a player in the car. That's 6 whole entities! That means it'll take 3x more origin and angles sets. According to my calculations, that's 96 bytes + vehicle itself + the player = 144 bytes total. (only taking into account sending the floats in pev->origin and pev->angles).
Now, sure, I'll keep all the functionality, but for MP maps, you're just gonna have to use 'whole' vehicles if you want better network performance.

For the entire picture, here's the plan:

• veh_car - car entity that supports all kinds of parameters set by the mapper: model, seat number, engine characteristics etc. Only potential issue with this entity is the fact that this is gonna take up quite some data in the entity lump. There are gonna be many parameters to be defined, most of which should have default values, however.
• veh_car_base - car entity that "assembles". You attach other entities onto it so it can become drivable. (implemented)
• veh_[insert a real-world car name] - a preset car entity. For example, veh_yugo - acts like a Yugo 45, looks like a Yugo 45, drives like a Yugo 45.
• veh_base - the original drivable chair entity. (implemented)
• veh_base_ms - the original drivable couch, multi-seated entity. These two might get removed or renamed. (implemented)
• veh_seat - a seat that you can place. This would be a normal chair that you can sit on. No driving. By itself, it's actually an invisible point entity, and yes, you can use it to attach to veh_car_base. (implemented)
• veh_wheel - a wheel. By itself, it does nothing. Naturally, it might roll away if it's on a slope. In a veh_car_base, it'll act like it's supposed to. (implemented)

Now, if we go a bit farther into the future:

• veh_tank - self-explanatory.
• veh_boat - regular boat. You can choose it to be a motorised boat or a boat that you row, which you'd have to use a special weapon for.
• veh_boatmg - boat with a mounted machine gun on it. Motorised by default, but you can also choose to row it.
• veh_sub - a submarine type of vehicle. Moves only under water, and players in it won't drown.
• veh_heli - a helicopter type of vehicle. W and S control it vertically, while A and D rotate it left-right. To steer left, for example, you'd have to pull your mouse to the left, rolling the helicopter left. Then you'd push the mouse backward (or forward) to tilt the helicopter up. Think of it as a joystick.
• veh_plane - an airplane type of vehicle. Controls are just like the helicopter's.
• veh_ufo - imagine the submarine, but in the air. It's basically not affected by gravity. It's controlled like a helicopter.
• veh_sship - a spaceship type of vehicle. It's controlled like a plane, except it isn't affected by gravity.
• veh_bike - a bicycle or motorcycle type of vehicle, depending on the mode. Just like the boat, it can be motorised (hence it acts like a motorcycle), or it can be powered by cycling, which would act rather similarly to GTA:SA. If you hold W down, it's cycled normally. If you tap W fast, you'll cycle faster.

Lastly, imagine almost all of them with "mg" variants. There would be some sort of weapon, either a machine gun type, laser type, or rocket launching type. Now, of course, you'll be able to choose whether the vehicle will have the driver as the gunner (like in HL2 when you use the airboat, or the buggy), or if you'd rather have a separate seat for the driver and the gunner.
In the far future, we might have NPCs that drive vehicles, and, heck, even ride-able NPCs. Imagine riding a Gargantua, LOL.

You might be asking, why all of this? Will all of them be used in UAS? Not all in the singleplayer campaign. Vehicles that the SP campaign doesn't utilise can be found in some of the MP maps, as well as minigames, which are accessible in singleplayer. However, keep in mind that this is not only a SP-MP mod, but also a mod base which others could use in the future. :3 (the 'base' can be downloaded separately)

Anyway, I mentioned rowing a boat. A row would not be a weapon in this case. This mod's gonna have 'tools', which are basically weapons but instead of damaging entities, they provide certain functionality with them.
The most obvious example is a paddle tool to row a non-motorised boat. Of course, it can be used as a melee weapon. Some tools can double as weapons.
Other tools will include:

• Worldcraft WC2.0 (original) - yes, a multimetre. You'll have to measure electricity in the mod at some point. You'll see why. If you don't mind the spoilers, I'll tell ya right away.
• Lockpick. This is pretty self-explanatory.
• Rock. To distract enemies a la Far Cry 1.
• Car keys. Logically, to start a car, you need its keys. Either that, or try jump-starting the engine, which is gonna take longer.
• Phone. You heard it right. A phone is going to be quite useful in the mod. Organise actions in missions, call people, and whatnot. Unlike GTA, however, you'll have to charge it wherever you find a power source. Some sockets won't have voltage in them, and you'll use your trusty WC2.0 to check if they have them. But don't worry, the battery should last long enough.
• Universal Remote. Simply put, imagine controlling a little rocket launcher from the distance, or a mini RC car.
• Grappling hook. Very good for setting up a rope to the top of a tower. Or if you wanna do bungee jumping. However, don't let someone shoot it. It has its counterpart.
• Climbing axes. You can climb walls with ease.
• Parachute. Self explanatory.

There's more stuff than this, but I don't want to count all of them. Now, you might say that's a lot. And you're right. But you can't carry it all at once. Well, you can, but you'd be VERY slow. Items, tools and weapons will have their own masses, and the greater the mass, the bigger the slowdown will be.

Since you mentioned epolys, you could flip EF_NODRAW in pev->effects.
The entity will remain in the memory, and it will "live", but it shouldn't be rendered, so you can use the same one again.

However, if you want to remove them from memory, just kill them.

That place is amazing. uwu

I was thinking of a more primitive one at first, then you pick up, or upgrade to a compound bow later. And of course, there will be different types of arrows.

FMOD now works.

Long story short, now I can play music with it. There's a special "music" folder inside the mod folder, so when you use a sound name like "abcd.ogg" in a music entity's keyvalues, it'll look for modfolder/music/abcd.ogg
Also, the DLL file is now in cl_dlls, instead of the Half-Life directory! Yay! (big thanks to Solokiller)

Currently, it works by sending a user message with a string. What this means is, it would be very far from optimal when it comes to network performance. So for entities that emit sound, like monsters, breakables etc., that would be a lot of bandwidth. So I'm thinking about replacing a variable number of bytes with just 2. Up to 65535 sounds should be able to be precached per map, cuz' c'mon, who's gonna precache more than that in a GoldSrc mod? Sheesh.
Now, I believe that I could stick to sending strings for music entities, as long as short filenames are used. But then again, 65k is more than enough IMO, so I guess music could go to the "sound cache" as well.

Now, something more conceptual, that I haven't started working on yet.
Do you like bows in games? I personally do, especially the one in Crysis 3. ^^
I think a lot of cool puzzles could be made for it. There will be a jungle area where the player is alone most of the time, so it'd be pretty nice to have that instead of firearms.

Man, man, what a fool I was.

"The FMOD implementation is so-so. It loads the library, starts the system, creates and loads a sound, but fails to play it."

When I tried to do FMOD, I was doing it upside down.

I tried implementing it on the server side. XD
The sound entity would basically directly call FMOD's sound playing functions. Horrid. D:

It'd look something like this:

void CNewSound::Use( CBaseEntity *pActivator, CBaseEntity *pCaller, USE_TYPE useType, float value )
{
    g_SoundSystem.PlaySound( m_sound );
}
// where m_sound is a member variable of this sound entity

// meanwhile PlaySound is defined as:
void CSoundSystem::PlaySound( FMOD::Sound *snd )
{
    result = system->playSound( snd, NULL, 0, NULL );
    ERRCHECK( result );

    result = system->update();
    ERRCHECK( result );
}

Something like that. Point is, this is entirely server side.
Yes. I was an idiot. Laugh at me as much as you want.
Gonna quote Shepard on this one: "My god! What are you doing?"
Back then though, I didn't quite know how to do client messages yet. Now that I do, though, I might as well try it the proper way.

For now, I'm planning to do a simple "music player" on the clientside, then I'll try to do more than that. FMOD Studio seems really pretty.

Also, in DevVideo 3, I mentioned some stuff about bounding boxes and vehicles. TL;DR you can't rotate an AABB with pev->angles properly. But, a friend told me about a special model flag, that's used by monster_tentacle, which essentially uses hitboxes for collision. Mmm, definitely seems better than AABB, even though I'm pretty sure this will have its own flaws too. But I'm more willing to accept those flaws than the ones of AABB.

Also, something I haven't shown in the video, but probably have shown here (or not?), physics.
Here's a link. The Bullet physics engine integration is going fine enough. Just gotta set up some debugging lines so I can see my collision shapes. Stuff seems somewhat off already.

"Goldsource is quite robust and there is no need to stick to the terribly outdated WorldCraft 2.0 prefabs."

Pretty much. ^

The GitHub repo there contains the source code, at least. So if there are no DLLs, one can always compile them manually.

If you don't know how, I could do it if you want.

As I said, AK47nator, there's a map file that contains each WorldCraft prefab, so you can just select a group of brushes, copy, go back into your map, and paste. uwu

Personally though, as I'm trying to be outside of HL's universe as much as possible, I got no use of the vanilla prefabs.

Therefore, if you wanna compensate for the lack of prefab libraries, make a separate folder called "Prefabs" and save map files there that only contain prefabs.