Forum posts

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.

Prefabs are for pussies. Lol.
There are, however, all of the WC prefabs packed together in a single .map file somewhere, so you can just copy them into your map.

Once I'm done with the brushwork, I'll definitely have to make some textures for this stuff.

J.A.C.K., VHLT v34 (Vluzacn's Half-Life Tools), and HL Texture Tools.

J.A.C.K. provides a nice set of features:Direction arrows for light_spot, light_environment and other entities that need such a thing, faithful model rendering, long file path support (Hammer never liked paths with spaces or ones that were too long, no more need to store stuff in C:/Hammer ), a much more comfortable-to-use Vertex Manipulation tool that now finally selects all parallel vertices when you try to select multiple ones with a single click, still runs on my 2005 HP Compaq yadda yadda yadda.
It's free, the paid version on Steam is... not something you'd wanna invest into right now. It's on hlfx.ru somewhere. Here, to be exact.

Either way, it has less quirks than Hammer. One of the quirks is to install J.A.C.K. somewhere NOT in Program Files or Program Files (x86) because it then wouldn't be able to write to its config files. Otherwise, should work just fine and peachy.

Vluzacn's fork of ZHLT, called VHLT, latest version being v34, is the state-of-the-art set of compilers for GoldSrc mapping. Basically, CSG, BSP and VIS are much faster, RAD takes a bit longer but delivers more beautiful lighting. It has func_detail, which is often useful if you've used func_wall a lot for small props and whatnot, though this feature has been available for a while, I believe. Same thing goes for ZHLT 2.x era light flags, where "blue" masked textures can cast shadows.HL Texture Tools is pretty straightforward for WAD and sprite creation. WADs are standard, you just gotta have 8-bit BMPs, and in the case of masked textures, appropriate colour palettes. HL Texture Tools with sprites also allows you to easily change their orientation settings, something that can be pretty useful if you want 'fixed' sprites that don't face the player, but rather only a specific direction:Welcome back to the glorious mapping land. ^^

Oh wow.
Nice.

Well, it's both fortunate and sad. Fortunate because now you can make HUGE maps.
Sad because it's gonna be a lot more complex, buuut, it's UE4 after all.

Keep going, mate.

Well then, for that matter, I'm gonna use my phone for the review.

"I didnt even know Wally could do that."

Since when? I don't remember Wally having a feature like that. Though there's this program called AutoSeamer that I once used in 2015. (it's not really good, lol)

"But if you are more experienced one, just use Wally."

Or HL Texture Tools.

Personally, I don't like the idea of web apps, but hey, it's really good for beginners who wanna make a WAD real quick. I will post a review sometime soon.

Been using a knife since I was 8. Did quite some things with it, accidentally cut myself quite a few times, but never badly.
Live your life, just don't live it fast.

But this is fun! I'm only 17, I wanna have fun before real life catches up. Besides, this thing is now off my bucket list, probably won't attempt it again.

Edit: Also, it was just one neighbour. I was basically showing this stuff off to my cousins and other kids in the village. I wanted them to see it once in their life.

sigh

Good thing Mum didn't find out, lol. I would've done it again, but... the neighbours found out and told me to not do it again. D:

Remember that talk about guns we had a couple of years ago?

Today I tried a homemade "flamethrower".As calm as I usually am, I like being crazy too sometimes. :3

It looks nice. :3

"I don't even know if it's free cause the one I had is a trial version."

Visual Studio Community Edition is free.
You only need a free Microsoft account to unlock the trial.

When I used Visual Studio 2010 Express, it actually had a trial which required an activation key, but all I had to do was create a MS account to get access to the key.