Forum posts

Looks like...
SoHL but for HL2? COOL!

Edit: Just watched the entire thing. Yep. It's A M A Z I N G for Source mappers.
I seriously hope it won't have many bugs.

P.S. it's not a set of tools (Hammer, compiling tools etc.), but rather new and improved entities.

Update time.

New features:

• trigger_date, an entity that can only trigger something whether the actual date matches the entity's properties (e.g. you trigger something every Christmas)
• trigger_date2, an entity like trigger_date, except for hours, minutes and seconds (3 AM horrors :D)
• func_loadbar, an entity that moves in a direction, and loads from 0 to 100%, has 5 trigger-able percentage levels defined by the mapper (e.g. trigger a "Just a little more!" sound when it reaches 90%)
• view bobbing + view camera overhaul
• horizontal offset of the thirdperson camera
• temporarily broke func_rotating
• trigger_timer, triggers something periodically, can trigger randomly between a min and max interval as well
• car prototype, with a working gearbox, needs steering implemented
• actual physics test - it's possible now
• new main menu UI colours

Physics test

I always wanted to say this:

In collaboration with Trempler and AlexCorruptor:What an honour this is.

Very, very surprising. Much better than I thought.

On average, there are 900-1300 wpolys, in some areas they're as low as 400 wpolys. In the worst case (only on one spot), almost 3000 wpolys. I'm getting 400 fps on my GTX 1050 Ti PC there.
The epolys, while playing alone, vary from 3k to 5k - take into consideration the giant cliffs, sand, rocks ("3D skybox") and the helicopter. The heli itself is probably about a 1000 tris, and the outer, inaccessible terrain model is about 1600 tris.

I'll test it on my 2007 laptop, because these numbers seem pretty good.

The map takes a while to compile, especially VIS, but with terrain like this, eh, I'm glad it compiles. This super open design needs at least about, I dunno, 30 minutes of VIS (with -full), but it's worth it. You cannot really optimise it further unless you turn it into some sort of maze.

ts_untergrund2019 is almost ready.

Me: Hey GoldSrc, will you open this map for me, pretty pleas-
GoldSrc: NO! NOOOOOOO! GET AWAY FROM ME! YOU MONSTER! YOU WILL KILL MEEEE!!! jumps and kicks all over the place
Me: It won't hurt, I promise. Come on... :3
GoldSrc: sigh Fiiiine. loads the map Holy hell, I never knew I can take so much. >-<

This is ts_untergrund. I'm finishing it this summer and it'll be released. I promise.

But then again, I haven't even tested what I proposed, so no-one knows if it's gonna really work.

All of this is just preparation, I believe. This is why I'm writing everything down. I need priorities. Back in 2015, I only had a rough idea and I was making things up as I was going. That clearly led to nowhere with potentially large projects like that.
The year after, I started working on a Far Cry mod that would act as a 'sequel' to this one, that failed in 2015. That is where I discovered the concept of planning.

The few rules I came up with were to first write some documentation, then develop and implement features. Only then, once those two are done, I can do the actual content (that is most of the assets). This is the principle I'm working by, and it's the reason why a relatively smaller project like de_kobbl managed to succeed, and I even managed to pile together a whole game demo in 2 months, mostly from scratch.

The difference is, this time I'm focusing a lot more on the 1st part, the documentation. And that involves planning, alongside everything else (the descriptions, the story, the missions, the designs). And this time, I'm not alone, unlike before.

Thanks a lot for reading, and for what you said. I know I've got a long way to go.

That would work too, but would require many path_corners for very precise fills.
Also, how would you handle the button that fills the bar more than the other buttons?

I realised that I should perhaps write things down. My mod failed in 2015-2016 because I didn't write almost anything. Seriously.
So I am trying to do something about it.Later on, I'll have to write a list of core features, then the actual story, individual missions, short mod design document and then I got a plan to stick to.

My teammate made a significant addition, having thought of a new character, which will definitely make the mod's story more interesting. (and for the player to care about and become allies with )

As for the vehicle system, I got a CBaseCar class now, with a different movement algorithm. I haven't yet tested it in-game, but it compiles fine. The vehicle engine is now more complete, with functions for acceleration, toggling etc., wheels now have a part of their own logic, and the vehicle manifests all that together.
The plan is to make a NEW test model because CBaseCar handles bones differently. It takes into account the root bone (that is bone 0), followed by potentially 4 wheel bones, so that's an offset of 5 bones. Therefore bones 5 and 6 will be driver and passenger, in this test model.
The model will actually be a bath tub, cuz' why not.

@zeeba-G
Thank you.

Here are some of the others:

I remember a map that had something similar.

My idea is a high-speed func_train, that stops itself automatically after either 0.05 seconds or 0.10 seconds, depending on the button.
More the time, the more distance the bar will travel.

Now, the way this would be done is not hard, I believe.
You've essentially got 3 main entities: a func_train and two func_buttons. Then you've got peripheral entities that do the logic: two multi_managers and two trigger_relays.

A func_button will trigger a multi_manager, which triggers the train, and the relay. The relay will, after 0.05 seconds, trigger the train, making it stop.
Another func_button will trigger a different multi_manager, which triggers the train, as usual, but this time, a different relay (the one with a 0.10 secs delay).

Essentially, what happens is the following:
If you press button A, the train will start moving, and stop moving after 0.05 seconds and move, say, 8 units. It'll give an effect that you are filling the progress bar with each press.
If you press button B, the train will start moving, and stop moving after 0.10 seconds, and move 16 units. Same effect, but with a bigger fill.

The func_train will have a set of 2 path_corners, and once it reaches the last one, it will halt, and it can then trigger something the moment it hits the end.

Early compile! And it runs like a charm. 4.5k wpolys max, averaging around 2k on the outdoors, and less than 1k on the indoors.
I'll try to reduce these numbers. Oh yeah, definitely.

Next thing to do would be to detail the indoors, and then I'll make the vegetation for the outdoor areas.

Any chance you could be more specific? ^^I'm assuming it's this one. But yeah, it'll probably get converted to a texture during the "great optimisation" phase.

Whew, this one will need AlexCorruptor levels of optimisation to get running on a 2007 laptop. But I can do it. I HAVE THE POWER.

You said "I don't know".
The moment you say "yes", then we're talking.

The new member I mentioned is someone I met a few weeks ago, they were interested in the mod, willing to work on it, contributing to the story and sharing their ideas (proposed a few vehicles, added a new character too, massively improved the plot and gave more sense to it). They make me happy.

So, a classmate of mine approached me and asked me about the school map. I told him "I'm still working on it", even though I actually hadn't been. So this progress was made in the last 2 days. Classrooms, rooms, slight basement expansion, 4 buildings (one hotel-like, two houses, one gym which can be fully entered), some new textures and so on.
I'm hoping to push out a playable version by the end of June, as well as a finished ts_untergrund, because when it comes to ts_untergrund, literally the only few things left to do are to finish the helicopter texture, and do some optimisations.

For the ones who don't know, here's what it'll be like:And then? Gonna work on UAS and the CryEngine 5 game demo thingy. I'm so excited since I also got a lovely new member in my mod team now. ^^

Likely a formatting mistake.

[http://example.com/|link text]
[http://example.com/|opengameart.org]

They all use the same model, so they are exactly the same, lol. Different scaling and rotation would surely help a lot.
After all, I said it needed tweaking.

Now I'm working on the layout of a map that will actually be in the game:The original game idea was in the Bosnian War setting with a story about a journalist who struggles to survive until he reaches the coast. Then he escapes with a boat and goes to Italy, ending the game.

Sadly, because I only had 2 months to work on it, I cut 60% of the game, replaced the Bosnian War setting with a "Martian soldiers invade Bosnia" scenario, and on top of that, the assets were half-made. Everything was rushed etc. But now I'm taking it slowly but surely, and in CryEngine instead of idTech 4.

I'd say it needs tweaking, but that's about it. Now I got an idea for next year's gamedev challenge. I might work on my HL mod alongside this in parallel. It's feasible because I would be making assets for both, just high-poly for one, and converting to low-poly for the other.

Back to the place that started it all.
The engine that cries, version 5 this time. (to clarify, the place that started it all was version 1, and later 2)

Just gotta add the trees, the grass, the clouds, and maybe set up a day-night cycle and this test scene is done. And yes, most assets were made by me as well. UwU

I mentioned some seats there, but I haven't explained these in detail.
There are basically 4 types of seats: Driver, Driver-Gunner, Gunner and Passenger.
Driver -> vehicle accepts the driver-specific commands from this seat. Can turn on the vehicle's lights (if any), can toggle the motor etc.
Gunner -> controls the weapon component of the vehicle.
Driver-Gunner -> combination of both. Think of the HL2 jeep's tau cannon.
Passenger -> the simplest type. Does not control the vehicle, only sits there. Can only switch seats and/or exit the vehicle.

The weapon components are the next thing to be done, once the engine and wheel components are finished.
Tanks will require a weapon component, absolutely.
Now, Driver-Gunner seats and Gunner seats are the ones that can utilise these vehicle weapon components. Such a seat has to be linked to a weapon component, otherwise it'd be exactly the same as a passenger seat.

Another question might appear, and that is: are seated players able to use their own weapons? I'll let that be an option. If you want seat A to allow that, just flip the flag for that in the init function.
You'll likely want to disable the flag for driver seats, for example, and enable it for passenger seats. But this is something I'll definitely work much later on. For now it's a concept.

An example of a weapon component is a mounted MG on a Humvee. Even stuff like a mounted M60 on a helicopter. Either way, these will have to be attached to seat bones, for the sake of simplicity. This may or may not be the final decision for that, but we'll see.
Basically, seats assume that seat bones are the last seats of a model.
So you've got the following
Bone 0 - root
Bone 1 - something
Bone 2 - something else
Bone 3 - seat 1
Bone 4 - seat 2
But if we were to add more stuff, eeeh, it'd get complicated. They will likely use attachments then. We'll see. shrug

Yeah, screw that last post. It was an April fools thingy.
Now back onto the serious stuff.

The CBaseVehicle class is siting at around 400 lines of code right now.
Since last time, I have added multi-seat support, seat switching, and better controls. But also, a very important change for modders who decide to use this tech one day.

And that is the following: creating new vehicle classes is super duper easy.
1. Define a vehicle class e.g. CVehicleVWGolf and base it off CBaseVehicle (however, it'll likely be CBaseCar, since each base is devoted to different vehicle types)
2. Define the VehicleInit() function
3. Let the base take care of the rest

And what did I do to make the two-seated couch work?
I just defined VehicleInit() like this:

m_iSeats = 2;

v_Seats[0].Init(Driver, v_Body.pos, 0);
v_Seats[1].Init(Passenger, v_Body.pos, 1);

Of course, this is just a part of the total function, but I'm planning to make it as easy as possible. For two reasons, really. Firstly, people would have to learn the whole vehicle system (and it can only get more complex in the following months), and that is not optimal for someone who just wants to create a vehicle. Secondly, I'm just too lazy to type 400 lines for each vehicle class, and you may agree that it's a bit inconvenient too. <w<

Either way, the new controls have arrived, finally. Up until now, my controls looked something like this:
if W -> push the vehicle in the direction the player's looking at
if A -> push the vehicle negatively in the X axis
if D -> push the vehicle positively in the X axis
if S -> push the vehicle negatively in the Y axis
That is, obviously, wrong (the ADS part) because those axes are world axes, not ones that are local to the vehicle.
So what I did was, I made it more standard, how you'd usually expect a car to be driven in games.
if W -> push the vehicle in the vehicle's front direction
if A -> rotate the vehicle's direction to the left
if D -> rotate the vehicle's direction to the right
if S -> push the vehicle in its back direction

All of this new stuff was programmed just today. Lastly, the seat switching. This one was the most tedious one, but it turns out I had a small inconsistency:

// Standard for all seats - always listen to unuse and seatswitch
fCommands[bi_unuse] = pSessilis->GetKeyButton(vehicle_unuse);
fCommands[bi_seatswitch] = pSessilis->GetKeyButton(vehicle_seatswitch);

This is what it's supposed to be like ^
However, I somehow placed the seatswitch listener into the Driver seat category, so only Driver and Driver-Gunner seats could switch. D:
But it was resolved in about 30 minutes.

Here are some videos:
https://i.imgur.com/5RWNHld.mp4
https://i.imgur.com/uRG4rmv.mp4
https://i.imgur.com/94xW83F.mp4

What's next?

Engines/motors. There's already some code, including the jokes:

void VehicleEngine::Damage(float hp)
{
    if (MadeInGermany)
        return; // engine was made in Germany, can't break

This is an actual part of the code and it'll stay that way.
Either way, the engines will be responsible for the vehicle performance. Think of RPM, gears, shifting and perhaps fuel if we want to be that realistic (though I don't really wanna add fuel). Either way, the engine will be damageable, and if it's broken, the vehicle cannot accelerate etc.

Wheels. Currently only the struct definition.
Wheels are interesting. They define the grip of the vehicle, and its handling. They will also be damageable, except the vehicle will still be able to operate after these are destroyed.

However, I will eventually create a new vehicle class to utilise all the 4 components: the body, the seats, the engine and the wheels.
A couch won't cut it. Once I get to the cars, then I can show the real power of the vehicle system.

QuArK has an FGD converter, I believe. So just download VHLT v34, and convert its FGD.

You're not disappointing anybody here.

To me, it just sounds like you weren't interested in any of this. But I'm likely wrong, since you looked like you were willing to learn.
You could've asked questions here, or even on the TWHL Discord, because people are out there, willing to help with modding problems and whatnot.

You need a func_tracktrain for that.

It has to face east, and you'll set its angles with the compass in the object properties.
Otherwise it should work like a func_train.

"my mouse gets locked in a box"

Turn off raw mouse input. This same problem is present in the latest Half-Life SDK.

Also, models can have as many polys as they like. It's just that you can have a maximum of 2048 vertices per SMD.

Now, I believe 1600 polys is a bit too much for a donut box.
My 2007 laptop will probably agree with me. But regardless, maybe your model is too tiny to be seen. This is just a wild speculation though. Blender units should, I believe, be equivalent to GoldSrc units. So you'd generally make a 24x16x12 box or something around those dimensions.

Or maybe it's so so huge, that you gotta zoom out a little bit in the model viewer. That can happen as well.

Does the model viewer display the number of drawn polys correctly for that model?

As for the cup, maybe the polys' faces are flipped.
Not sure how to do this in Blender 2.79 and before, but in 2.80, you gotta select the object, go to Edit Mode -> Mesh -> Normals -> Recalculate outside. Something like that.

I highly suggest you to enable backface culling in Blender's 3D viewport, so if faces are facing the wrong direction, you'll be able to see it.

Maybe it just needs a restart. I've done a quick test just now and when I configured the compiling tools, I went ahead to compile the map.Threw the same error.
I restarted Sledge and it worked.

Alternatively, if all fails, you can try out J.A.C.K. It's free, even though you might get confused seeing it on Steam: http://jack.hlfx.ru/en/download.html

Woah, I love those screenshots.
One of the screenshots does indeed look like Uplink.Now, it's been a while after I posted those screenshots up there. After some technical problems, I eventually got these hands to work.The Old Bridge in Mostar.
It's going to be in the intro, basically. (no, it won't get destroyed xd)Missing slide lock mechanism, magazine and trigger are unfinished. But it's all fine for now.
It works in-game, even:I'll likely fully finish the model after the competition. I don't have time for smaller details right now. :/The Zastava M70. Not an AK-47, but it's pretty much based off the design. I'm pretty much making the "as-is-poly" model and throwing it into the game, just as it is. No high-poly-to-low-poly workflows, none of that stuff. I don't quite have the time to get used to that right now, so I paint my bump maps manually. (well, all the other maps as well; never used stuff like Substance Painter)

The to-do list is pretty broad, but actually a tiny bit smaller than the "have-done" list, comparing the number of lines:

• make textures for the M70
• rig and animate M70’s viewmodel
• import M70 into the game and write a script
• convert soldier models from Battlefield Balkan, rig and animate
• write NPC scripts
• make a bunch of textures from existing photos, reuse older textures
• make materials for bullet holes, blood, and particle effects for gun smoke, explosions and whatnot (20%)
• make map 1
• make map 2
• make map 3
• make map 4
• make map 5
• make credits
• make music?
• make a full main menu UI
• make a HUD
• submit the game (15th May) - development deadline
• make a trailer and a presentation
• present the game (23rd May)

In a matter of 3 weeks, I did more than I'd do within 3 months. So I realised, deadlines make me run really fast.

I believe it's got something to do with this: (cl_dll/battery.cpp)

rc.top  += m_iHeight * ((float)(100-(V_min(100,m_iBat))) * 0.01);

So replace 0.01 with 0.02. I haven't tested this, but it should be that. It's around line 103, right after the #else line. Either way, the code for drawing that stuff on the HUD is there, so change it as you need.

You're welcome.

I recall doing something similar (increasing it to 200) in 2015. Basically, you'll have to change a line in weapons.h, in the HL DLL project.

Around line 95:
#define MAX_NORMAL_BATTERY 100
Set the number to something else you'd like. It will affect battery pickups.

For the chargers, you'll have to go to h_battery.cpp and manually change some stuff: (starting at line 164)

// charge the player
if (m_hActivator->pev->armorvalue < 100)
{
    m_iJuice--;
    m_hActivator->pev->armorvalue += 1;

    if (m_hActivator->pev->armorvalue > 100)
        m_hActivator->pev->armorvalue = 100;
}

I think that's about it.

I got you covered: Creating new entities

Also, here's a bit of material to understand the SDK itself:

Looking at a simple entity class
Creating a new entity class (my tutorial up there is this, but far simpler - I should port it to TWHL soon)
Finding your way around the SDK
Printing to the console with ALERT()
Engine functions
String handling in GoldSrc

The specific entity that you'll wanna make will need these three:

• traces
• some func_train code (imagine that our player is a func_train)
• some vector maths and logic

"QuArK can open .bsp as well"

I wanted to check this. It is true.

Thank you.
If I hadn't gone out more, I wouldn't have even taken these photos.

BUMP uwu
I haven't posted in almost a year here.Remember this photo?Here's the view from the other side (there's a bridge there too, you just can't see it in this photo xd):Ever since my 2nd year of high school, I've been going outside more, and I've been walking more. So I thought I'd take photos of things along the way:Green river Bregava. :3

Also, a bonus one:R.I.P. resistor, as part of a demonstration of power ratings, for my classmates.

And I thought I was presenting something complex.
But yeah, having 50 entities or so, each doing a part in the entire thing, it can take up more entity data in the BSP, entity slots, and it might have an impact on performance too.
Either way, can you program this, or should I provide you all the code?

ADM v0.1 tech demo

Today I am releasing v0.1 of the mod base of Utopia At Stake, called ADM (Admer's DevMod). It has got the following features:

• vehicle support
• FMOD sound system implementation
• Bullet physics engine implementation
• bump-mapping (I never thought I'd reach this point)

Download the tech demo right now:
ADM v0.1
Installs like any other HL mod, just extract the .zip into steamapps/common/Half-Life.
Should not work with pre-Steampipe versions, or rather anything lacking updated SDL2 and VGUI2 libraries. (sorry pirates and WON HL players)

The source code will be released some time later.
Have a good day/night, everyone.

RB-DOOM3-BFG?

Hot damn, very close. RBDOOM3-BFG has shadow mapping IIRC, and this one has it too. Buuut, it's not RBDOOM3.

@abbadon
But I don't like MS3D. :/

@Screamernail
Because I never worked in the Cafu engine and I don't know what it's like yet. I know Source and GoldSrc workflows but they're proprietary engines. :/
I was thinking if I should use Quake 2's idTech 2, or Quake 3's idTech 3, but then I realised, idTech 4 is so damn powerful yet so damn rapid for development.

Edit: now, onto the weapons...I haven't modeled weapons in a while. This Zastava M57 will probably be done by the end of the week.
Also, hooray, I finally made the switch to Blender. UwU
Now my Free Development Arsenal is even more complete. :3

"I think the best way to define grindable rails is point entities that define the rails like path_track does. When a player comes close enough you snap them to the rail and move them relative to the lines between points."

This. Except I had an idea about checking whether the player is touching the line between the two points. "Close enough" is a bit harder to do.

"Speaking of triggers, I believe with zhlt_noclip they wouldn't work because clips are their essence."

I was talking about the illusionaries. And here's the concept.
rs1 checks traces between pt1 and pt2. If the player, for example, jumps on it, then rs1 will take that player and check the velocity. It'll determine the direction of movement according to the velocity, and accordingly, it'll snap the player to that traceline, and move the player smoothly to either pt1, or pt2, depending on the direction.

As you can see, the minimum keyvalues required for the entity to work are the start and end path entity. It's quite simple.

Now, in this case, three things can happen:

1. Player jumps off the rail
This is really simple. Check pev->buttons and dismount the player, maybe add a number like 50 to velocity.z.

2. Player arrives at pt1
Same thing as case 1. We have no neighbouring railslide node, so dismount the player (also, don't forget to 'lose' the pointer that points to the player entity, cuz' the player no longer belongs to rs1).

3. Player arrives at pt2
This is where things get interesting. The entity loses control of the player, and tells rs2 to handle the player. Then rs2 will move the player to rs3, and if the player reaches pt3, they will be dismounted.

Now, I believe that this specific way won't work for multiplayer. :/
It'd take some extra work to optimise this for multiplayer, since you have to take multiple players into account and thus somehow point to multiple entities at once, usually done with a for loop iterating until it hits the max player count.

On another thought, maybe you could just take one func_railslide and let it take on an entire group of path entities? Kinda like a func_train.

I believe you can do that without triggers.
Instead of trigger_railslide, let's imagine a point entity called func_railslide. It sends a trace between one path_corner and the other. If the player is in the trace, it starts working just like trigger_railslide would.

I drew the concept on paper today, I'll explain it in detail when I get home.

400 illusionaries eat up 22.2% of clipnode limit

Even with zhlt_noclip 1? Hmm.

Doom 3's engine

You got a cookie!
Now guess the fork and you'll get a cake.

After 22 photos of my left hand, I managed to do it:Here are some earlier renders:Did the mesh in 3ds Max, did the texturing in GIMP, and the last touches in Blender.
This is gonna be used in my game about the Bosnian War. I had to make something to replace these hands which came with a starter asset pack:( Guess the engine and you'll get a cookie. )

SoHL can be pretty unstable to work with sometimes, at least in the latter releases, as far as I've seen.

Not doable unless you code it into the engine, and I don't see that being an easy task either.

into the game*
We don't have access to the engine. XD

BUT, it's possible. And here's one of my ideas. Defining an entrance trigger for the slide, and using path_corner entities to slide between. Then simply interpolate the player's position to the next path_corner, depending on what they're facing, and what they're closest to. It'd take some maths and time, but it's certainly possible.

Essentially, you'll get some sort of trigger_railslide entity, which detects whether a player is inside, and when the player enters it, it'll move the player as if the player were a func_train. Then, it checks which path_corner the player is closest to, and it takes the player's original position, and interpolates between that and the path_corner's, so that the entrance could be smooth and arbitrary.
I'd do a proof of concept (this stuff requires coding just one entity), but it's 01:24 here, so. :/

Don't angles work on func_wall too?
It's a very old and useful mapping trick.

I had done some testing, and it seems that J.A.C.K.'s UV-lock works best with triangles (was mentioned briefly in my ATC tutorial). But ONLY if you move the vertices in a single axis, and nudge them with arrow keys. Otherwise it's gonna be a load of texture baloney.

So yeah, either skew with the select tool, or nudge vertices carefully if you're using triangles.
ToTac has got some really neat guides that rely on the UV lock, actually. The thing is, the texture scale gets messed up, but the projection angles are right! This needs some more studying and documentation.

Also, do NOT use the clipping tool while the UV lock is on. It's gonna screw up the textures because it doesn't know how to project them.

Just toggle it, and skew the brush. It's like an additional texture lock.
Otherwise, you gotta use that method which may or may not work. xd

From what I see, there is no other way. If you use J.A.C.K., there's the UV lock option: you can just skew a brush and it'll skew the texture properly in most cases.
In some Radiant editors (you're very likely not using these), there are actual UV map editors, but they work the best with triangles and (not a GoldSrc thing) patches.