Yay.

"The only difference between the two is that one is stuck doing an idle animation whilst the other is free to move but I don't see how this would have an effect."

Think of it as one guard being busy. What does your entity setup look like? What entities are triggering what, and what keyvalues/entity properties are being used?

Write this into the console:
developer 2
Restart the map and you'll see a real-time log of what is actually going on, what entities are being triggered etc., and then try to see what's the issue.

Oh right, one more thing: the point file's lines actually do end up in the void in the end. The thing is, you gotta track the line to see if it's going through a brush or not. The lines will "find their way" through any hole in the map, basically. Watch out for teeny tiny gaps.

I didn't mean it. No need to be sorry.

"I have literally no idea why this is happening because the entire map is completely sealed off from the void."

Do you have any entities outside of the map? All entities should be inside of the rooms, even things like lights, or info_ entities etc.

"Only problem now is how I bring up these blue lines so I can see what's causing the issue."

You don't read anything I write, do you? :V

Here:

You can open your map's portal file to analyse what VIS has to calculate.
Where your .bsp file resides, there will also be a .prt file. Open it with a text editor, and you'll see something like this:

1681
3982
2
1
1
10
1
1
1
4
15
4 688 45 ( 400, 500, 600 ) etc.

You'll want to skip the first two lines, because those are the number of portals and visleaves, IIRC. Then delete whatever is between them and the coordinates (basically, delete the "garbage" numbers):

1681
3982
4 688 45 ( 400, 500, 600 ) etc.

The last line that I wrote won't actually look like the one in a .prt file, but you can get the idea.
This file is generated per each compile.
Then, you open the .prt file with the map editor: Map->Open Portal File.

BTW you might wanna check if you accidentally func_detail'ed a wall or a ceiling or something. This is where screenshots would come in handy. Does the line go through walls? If yes, then check for errors with Alt+P, there might be an invalid brush.

And don't worry about the sins, it's a joke. Mapping is no religion.

I'm still pretty much running Windows XP SP3 on two PCs, albeit I turn them on rarely. We'll see what will happen in 5-10 years.

An aiscripted_sequence forces the AI to do it. It's like the God of AI, even prevents death while it's being executed.

func_detail basically prevents the "cutting" of portals, and lets you control the contact BSP face splitting.Now what would happen if we assign func_detail to these boxes?Firstly, there would be less portals and less stuff for VIS to calculate. In this case, it's just one room, so the portal file would actually be 'empty':

mapname.prt
-----------------
1
0
6

Secondly, these boxes would not "cut" the floor into multiple faces as they did previously.I added another block there just so the portal file wouldn't be empty. Basically, func_detail simplifies the map's portals (these blue rectangles), but it should absolutely not be used on walls, ceilings etc.
It acts as a non-entity, but it'll still be treated as an entity by the compiler, so it won't block any leaks.

Here's another example. (oh the mapping gods, please forgive me as this sin is for the purpose of enlightenment)Each of these volumes defined by these blue boundaries can be considered a room. Basically, VIS thinks there are multiple rooms in there, while it's just some space around a pipe. Doesn't make much sense. So it should be func_detail. You can use func_detail on basically anything that causes unneeded complications in VIS calculations. Chairs, tables, lamps, maybe window frames, furniture, static vehicles, pipes, signs, poles etc. should all be definite func_detail candidates.

If HL VIS is stuck, your map needs some optimisation. Can you show us some screenshots of the map?
Usually, tiny brushes that are merely architectural details (or even prop-like things like signs, fences, railings, tables, chairs, lamps, small rocks etc.) should definitely be func_detail.

The compile warning is really just a warning. It also means that the geometry is a bit funky or unusual, so the compiler can interpret the geometry in more than one way (hence ambiguous). Generally, it's completely fine, not much to worry about.

Are you triggering the sequence that the guard is supposed to do? Some more context is needed, and some of the keyvalues that are being used by the entity setup. Try the aiscripted_sequence entity, too.

Not much is wrong with J.A.C.K. except for the few bugs it has and it's closed-source (and the author pretty much hasn't updated it in a while). Sledge is open-source and will surpass J.A.C.K. one day, I hope. But hey, if it weren't for those two, almost all of us would be using hacked Hammers, or Hammer 3.4, or even worse, QuArK. D:

Oh, also:
You can open your map's portal file to analyse what VIS has to calculate.
Where your .bsp file resides, there will also be a .prt file. Open it with a text editor, and you'll see something like this:

1681
3982
2
1
1
10
1
1
1
4
15
4 688 45 ( 400, 500, 600 ) etc.

You'll want to skip the first two lines, because those are the number of portals and visleaves, IIRC. Then delete whatever is between them and the coordinates (basically, delete the "garbage" numbers):

1681
3982
4 688 45 ( 400, 500, 600 ) etc.

The last line that I wrote won't actually look like the one in a .prt file, but you can get the idea.
This file is generated per each compile.
Then, you open the .prt file with the map editor: Map->Open Portal File.

Well, it's a success. I'm thinking about creating maps for this.

What if he's got an Intel GPU or something else? Then there's no other option than stuff like OBS, Action etc.

"recording things with fraps"

Not necessarily. I've recorded mine with Mirillis Action. :3

Pretty sure he'd have the same questions and problems even if he had used Sledge (if not some more stability issues too). Though, what I've just said won't be valid after the next couple of years.

Confident as in, the AI will be 100% sure what way to go. Should the way they go be correct or not, eeeeh, it depends on the mapper and how the nodes are placed.

"ai nodes"

AI nodes are just a 'GPS system' for the NPCs. When you place these nodes, you're giving NPCs confident information as to what way they can go. Without nodes, they use pathfinding and sometimes they're not too good at it.

"Also I’m trying to get a scientist to loop between two scripted sequences but the problem is that he goes to one and just stays there."

Each scripted_sequence should target one another. seq1 targets seq2 and vice-versa, for example. I've done that in my mod once, but not sure if I used aiscripted_sequence or the regular scripted_sequence.

"However the problem is that for some reason the message appears right on que but the sentence takes a few seconds to activate."

You could delay the text message.
I'm not sure what causes this. Try turning on the "multi-threaded" flag in the multi_manager. Or delay the message by 0.01 seconds, and have the sentence without delay.
(might be that the specific sentence has a delay by itself, caused by the game files?)

"I’m wondering if there’s a way to get it to make a sound without giving it a move sound"

Yeah, you can use an ambient_generic entity, with initial volume set to 10, start silent and medium radius turned on. Then as you trigger the vehicle, you will also trigger the sound-emitting entity.
The only issue there is that the sound will always be emitted from the sound entity's position, meaning that it is going to sound strange if the vehicle is already far away, but the sound remained still.

Upload it. I would take a look.

What happened is basically that HL RAD ran out of available memory. How much RAM do you have? If you've got more than 4 GB, you should definitely try running the 64-bit version of RAD.Basically, you can switch to the 64-bit version by going to your settings, and changing the build tools, or compile tools, or something third, depending on how the map editor calls it. Simple as that.
If you can't use the 64-bit version, or you have even less than 4 GB of RAM, well, you can use less textures, since J.A.C.K. can use lots of memory if you're using too many WADs. If that doesn't do it either, then you can resort to the Compilator 3. It's sweet and manages the compilation process for you, and in some cases it can make it a bit faster when the map editor is closed.

As for the leak, I'm thinking you've now made a huge hollow box around the map. Don't do that. You can read about leaks here.
If you have small gaps that cause a leak, simply close them with either extra brushes, or by extending a nearby brush.

The strange yellow particles are probably there because the scientist, or a part of the scientist, is inside of the floor or any other solid. Make sure he spawns in the air, if you can't get rid of the particles otherwise.

IIRC when I used a func_trackchange, I had to trigger it with something, like a path_track:

"the limitations of some engines simply don't let your realize certain visions."

Yeah, I forgot to mention that.
If you're making your own engine, you might as well set your own limits until you reach the hardware limits, but if you're working with an engine that isn't yours, then it's what I said. In the case you mentioned, however, one can always use a different engine.

"Engine limitations don't prevent you from making a good game. Many older games are amazing products despite (and possibly because of) their engine limitations."

An engineer's creativity depends on the limitations, be it technical (the design), environmental, or financial, or all 3. The beauty of limits is working around them, and that's what makes a clever engineer. Similar principle applies to game developers.

"No, if the engine is limited, so are you, at least if you want to do a decent FPS."

If you're getting bad framerates, I'd rather say it's your design that pushes things too far. The engine simply isn't made for it. So, you should optimise it.

Yeah. That's what's important.

"Well, I can be a bit abrupt sometimes"

Oh no, I didn't mean to imply anything like that, I'm just saying that your comment back then was 100% right. Especially the 1st sentence.

Anyway, after mostly improving the chair vehicle (which will probably appear as an Easter egg in the final mod), I've recorded some of it:However, since it's the 21st of January, that means that my winter break is over.
I won't work on this mod base very often during the next 3 to 4 months, but I'll still get a little bit of time to work on it during the weekends.
I'll likely leave the vehicle system for now, because there are a couple of entities I have to clean up and polish.

I love that War Games reference to the right.

And right before you ask me "Is it 640x480?", no. It's 800x600.

I'm glad to hear that. Especially when it's coming from you.

And you probably know why:To think that this was 4 years ago, man, it's amazing how time flies.

There will be mapping screenshots and stuff like that. But only test maps for now, until I finish most of the code base.
Of course, it doesn't mean that these dev maps won't be pretty.

My vehicle test map has got some quad terrain, and doubtlessly, so will the next few vehicle test maps. One will have a flat race track, so no terrain there, but, one will be a "4 quadrants" map having a desert, snow, jungle and rocky area, one will be completely designed for water vehicles (and air vehicles) etc.

"I'll describe them more in my next post"

So, the vehicle system is approximately like this:

A vehicle can consist of 4 types of components. Bodies, engines, seats and wheels.
Bodies and wheels are physical components meaning they're visible and you can collide with them. Engines and wheels are, on the other hand, logical components, meaning they just contain some info.

Bodies have a model, and physical info like mass, position etc. Similar thing applies to wheels.

vec3_t pos; // from the VehicleBody type
float Mass;
float Density;
string_t m_iszModel;

Seats serve as pointers to players, and they listen to commands from the player they point at. There are 4 types of seats: driver, gunner, passenger, and driver-gunner. It's pretty self-explanatory what they do, i.e. driver seats are the only ones allowed to control the vehicle, gunner seats may control the vehicle's guns, passenger seats do pretty much nothing, and driver-gunner seats combine driver and gunner seats.

VehicleSeatType type;
vec3_t pos;
CBasePlayer *pSessilis; // Never thought you'd see Latin in the HL SDK, did ya?
bool fExists;
int iSitdex; // Cool name for a seat index ;)

Engines contain info like health, gear ratios, number of gears, drive type (currently only 4: FWD, RWD, AWD and NWD a.k.a. NoWD, which is reserved for flying vehicles and other wheel-less vehicles) etc.

int              HorsePower;
float            MaxHealth;
float            GearRatios[9]; // Maximum of 7 gears + 1st neutral 0th reverse
int              Gears;
float            Efficiency;
VehicleDrive     Drive;

To test some things, I made a chair. A simple chair that consists of a body and a seat. The body is actually a brush model, but it could've also been a Studio model. It's the bounding box that really matters. Either way, this chair handles player interaction and even a very, very, very primitive movement system where the chair slides on the floor.It's a beginning.

Before I introduce the mod, let's have a little bit of history.
3-4 years ago, I started working on my first Half-Life mod. It was originally called Admer: The Game.

It actually started out as a QBasic text game. I had QBasic classes in 7th grade, and I'd finish my tasks so quickly I'd get enough time to work on a game. It was simple. You spawn in a cave, and for some reason there's a zombie in front of you. I'll write about that one in a journal.

I had an idea to make a single-player Half-Life map pack based on my text adventure. I downloaded some textures from the Internet (stock photos, lol), and I just threw them into Wally after downscaling them. The results were this:There was some dynamite at the end of the cave in the text game, so I thought I'd add it. The dynamite would explode and make a hole in the cave ceiling, so the player could exit.Soon after that, the player would encounter a small hut, with a pistol and a piece of paper. It's not important what's written on the paper.

As you can see, it looked kind of terrible. If you want, you can check out the mod on ModDB: https://www.moddb.com/mods/admerthegame
I once renamed it to An Unknown Game, because I understood that it was bad to call a mod by yourself. (in fact, I was the protagonist in the mod, lol)
The mod was supposed to get released somewhen in 2017. Clearly, it would never get to that point.

I gave up on it in Q3 2016. My programming skills sucked. I didn't know my way around the Half-Life SDK, and my mapping skills were definitely bad, as well as the rest of my skill set (except video editing, my only skill that wasn't under average).
I was lazy. All my ideas were in my head, I was too lazy to write them down and I had no mod design document, no organisation, no anything. I simply didn't know where I was going and what to do, so I half-baked everything. (ahem, quarter-baked)
I had some wacky ideas there and there, e.g. a programmable universe where people spawned things via code (scrapped, won't fit the story of AUAS). That mod is, in fact, the very origin of Jody. (you all remember her, lol)

I've occasionally visited the mod's page on ModDB in the past 2 years. I remembered the old stats, suddenly. It used to have 10s, sometimes 100s of viewers per day, and now it varies between 0 and 1. So I thought "How great would it be to do this again, except with the skills I have now?"
The time wasn't then, however,

I was analysing some progress of my skills. Since 2015, I've improved in mapping a lot, in texturing a lot, video editing significantly (I mean, not much to be improved since I've been video-editing since the age of 8), sound editing a lot, music production so-so, but there was just that one skill that stagnated. That one skill which prevented me from reviving my old mod.

It was programming. In late 2017, I started panicking due to the fact that I knew I'd have programming class the following year. So I wanted to prepare myself.
(little did I know, they hardly teach you anything here in high school when it comes to programming)

I just needed a good start. Something to jump-start my learning. And in November 2017, a guy from the 2nd or 3rd year came into our classroom, recording a promo video for the high school. We were having IT class, and our professor told us to open Dev-C++ and pretend to be typing something. They all pretended. Except me.

I opened up a source file, saw how it's written, memorised the syntax and commands within a minute, and wrote a program. When I returned home, I got VS 2010 Express, registered it and decided to make GMan vulnerable.
It was an unbelievable experience for me back then. I actually understood something for once. And all he was doing was setting his health to 50% of his max health every time he was attacked:
Now that was just the beginning. I called my little brother in and showed him that, and he was so amazed. He laughed in disbelief, because all the time he knew about HL (since the age of 2 or 3), he knew that you just can't kill GMan. Not in my mod.
But then, there was a period of stagnation. I hadn't really touched Visual Studio any more. Instead, I observed. I listened to Shepard's and Solokiller's programming lessons on the TWHL Discord (lol), I've read numerous coding stories from other developers on Quora, and so on. So essentially, I did the same as I did with mapping. First read a bunch of tutorials and documentation, and then try working on it.

In late 2018, however, I got into C++ again after a long period of not doing coding. I got my new PC in July, and that meant I could finally get my hands on Visual Studio 2017, a nice step up from Visual Studio 6.0, 2005 Express, 2009 Express and 2010 Express.
My 2007 laptop simply didn't have enough space for 2012, 2015 nor 2017.

And that meant a new beginning, a new age. I was looking for some libraries that can enable me drawing stuff to a window, and boy I found one: SDL. I learnt quite some C++ for those few months, and coming back to the Half-Life SDK once again, I finally understood most of the stuff in it. It felt amazing to finally understand something that troubled you for a few years. That age was the age of learning something I've always wanted to learn.

I had prototyped a function in AngelScript for Sven Co-op (it was my first time tinkering with AS scripting), and then I decided to implement it in the HL SDK.
It led to the creation of this mod. I'll be working on the technical part for a long time. Once it's done, I'll move onto the actual mod revival itself.

So, what is this thread about?

A Utopia At Stake

Will you save it?

There's a world out there. A world where everything is close to perfect. You move because of education, a future brighter here than on Earth, and for the fun of it. Things will look perfect, until a series of events lead to the downfall...
Its fate... is up to you.

Well, I'll just post stuff here about the mod.

Here's a summary of what I've made in the last couple of months:

• semi-auto for the pistol
• env_viewsway, an entity that messes up the player's view angles, useful for drunk effects, rocking ships etc.; is capable of inducing nausea (seriously)
• trigger_valueop, my personal favourite, as it can change any keyvalue of an entity which it targets, it's very powerful
• trigger_difficulty, which triggers something depending on the skill level, which can be easy-hard but also not easy, not medium and not hard.
• util_rotator, something that spins an entity around an axis, but it's not in a very good state at the moment (it rotates things, but eh... I feel like it should use quaternions rather than regular angles)
• util_consoleprinter, a very useful debugging entity when you're developing an entity setup or a scripted sequence series
• a customisable HUD with about 15 parameters, most of them being for the TDTR effect (The Deader The Redder - the lower your HP, the redder the health display)
• vehicle_base, a really, REALLY basic vehicle. It's a chair that you can enter and exit. But the system itself is quite flexible under the hood, allowing for multiple vehicle types, whether it's cars, planes, space ships, boats, or chairs & sofas (why not). I'll describe them more in my next post
• additions to the CBaseEntity class which allow trigger_valueop to work
• additions to the input and client commands, which allow for sprinting (and being able to control the vehicles in a more special way) - and best of all, it doesn't need more bandwidth than 1 to 2 bytes/sec per player (keep in mind that an empty map with one player is already about 27 to 50 KB/s, assuming the netgraph displays it in kilobytes/second, I could be wrong) (thanks to Solokiller for the information about pev->button)
• new view sway, viewmodel bob, you name it (thanks to Shepard for helping me with the old HL WON rotational bob, it's 1 line, but 1 important line)

Suggest me a name for this mod, because it can still be changed. For now I'm just calling it AdmerMod 2018, and the source code AdmSrc (which has no relations to Source, it's just a short way of saying "Admer's source code").

Oh right. One last thing before the next post. I'm hoping release this mod's source code when it gets to Beta or Release Candidate, maybe even earlier. It's based on Solokiller's fork of the HL SDK, that is compatible with VS 2017. I've already sent versions of the source before the "VehicleAPI" and "ControlAPI" were written, because some people simply asked for it.

"If this require to learn C# and start all from scratch, will not it disencourage people to port their mods to SL?"

In my opinion, it may do the opposite. It may encourage people. I've never used C#, but from what I hear and see here, it seems easier than C++, and that could lead to potentially more people coming than people getting discouraged. Besides, learning a new language isn't supposed to be a bad thing.
Then there's the question of doing it from scratch. If the HL SDK is ported to C#, do we replicate the changes which we made to our C++ HL SDK code over to the C# HL SDK, or something else?

@hfc
There has to be a plugin for Blender that supports GoldSrc SMD. You can find out here: http://the303.org/tutorials/gold_mdl.htm

They might not be compatible sometimes, but you can never be sure about things like these easily if it's your first time in the SDK. Trust me. Take your time and learn the basics of the SDK, because copying and pasting things you don't understand is definitely ending up in a mess at some point. But it won't be a mess if you understand most of it.

You have got a recreated (but incomplete) Opposing Force source code. You can fix whatever you can and complete what can be completed. After that, stitch some entities and features from SOHL that you need. Whether they are compatible or not, IntelliSense and the compiler will tell you that (and the engine once you test the features out, when they compile).

While learning the SDK, see how entities work. Read those tutorials up there. You'll get started with the server side stuff (entities, NPCs, weapons maybe), and then try some clientside stuff (HUD, view etc.), and then a combination of both. You may ultimately not need some (or in your case, most) of the things you make, but for the sake of learning, it's a good thing to do and try out different things. At least from my experience.

As time goes on, you will start creating your own entities from scratch without needing to look at other entities, and then you will fully know what to do.

I'm not making an entire SDK from scratch

Nobody has ever done that. Only Valve. You might be referring to recreating the Opposing Force code on top of the regular Half-Life SDK. You don't have to do that either, just take one foundation and complete it.

Yes, GameBanana has got a private messaging system.

Spirit of Half-Life as a whole is a little bit unstable. It's best to just borrow and stitch features from it.

Also, you maybe already know this, but just in case, make sure that you have permissions from Cybermax to actually use that in your mod. My mistake in 2015 was that I was just downloading models and never crediting anyone nor asking for permission.

Most of what you described in regards to changing (NV to flashlight, talking HEV suit, HUD changes) won't be hard.

operational Half-Life: Opposing Force source code engine

A source code engine. Hah.

As for the mod's concept, well, I can't say much since I'm more into total conversions. But, good luck with the mod.

I've written a small tutorial for setting up the SDK with your updated HL SDK, for VS 2017, on GB: link

And there are a bunch of tutorials I've found at Sourcemodding, and I think the SDK Basics series would be useful for this:

pev structure and entity variables
Introduction to the source code
SDK2 Basics - Looking at a simple entity class
SDK2 Basics - String handling
SDK2 Basics - Creating a new entity class, and adding it to your level
SDK2 Basics - Adding a new monster

And the mouse will only rotate the character's view by 180 degrees instead of 360 degrees.

Try turning off "Raw mouse input" in the mouse options. As far as I've seen, this type of bug seems to appear with modern Half-Life SDK sources, except it was about 90 degrees on my end.

I am asking to the code to add PRIMARY AMMO to a weapon that HAS NO PRIMARY AMMO to load in...

Oh, the joys of coding.

What exact error messages are you getting? You could try Visual Studio 2010 Express if it won't compile on VS 2017's toolset.

I don't think you can measure distance in QuArK directly. I've used it for some time, but I never found a way. Unless you turn on the grid. I remember yours was turned off.

See those green-ish dots? (might not be visible so see full image)

The option is right here:Each square on the grid is a×a units, and a is whatever your grid size is set to.

As for the bots, I'd go with a personality approach (something like int m_iPersonality, or even better, an enum) and each bot gets a random personality at spawn. And then depending on their personality, they can fire slower, faster, and even prefer weapons.

In some aspects I find it to be a CryEngine-GoldSrc hybrid. I'll definitely check it out at some point. Thanks for posting it here.

Edit: I've looked it up. It wasn't much of a problem for me.

Quake II does BSP differently as far as I've heard, so I wouldn't be surprised. It's either storing BSP files with complete brushes, or storing faces with an extra lump for the original brush data. Can't quite remember what exactly.

I think GoldSrc map decompilers will never have 1:1 results, since all the decompiled brushwork will always be the decompiler's guess. GoldSrc BSPs have faces that form one big mesh, and .map files have plane intersections that form individual volumes. It's all a big guess and approximation.

Although, it would be nice to see if we had smarter decompilers. The ones I've used didn't care for face subdivisions and they left it like that. There's also one decompiler that turns every solid entity face into a 1-unit-thin brush. Ew.

And I agree with potatis_invalid. The root of this problem is cultural (not sure if I'd call it a problem, but I guess it is). If a mapper doesn't want to release their map sources, it's their decision. It's their work, they can do what they want with it.

I'm definitely not against an effective map decompiler (I'm for it). I'm just afraid it's going to induce more laziness and potentially a more efficient way of stealing maps or parts of them.

Nice. :3
It reminds me of the style of CS 1.0-era maps.

This is really nice.

This usually happens when you have very complex geometry. You should convert these complex brushes into func_detail.

Do you want the sound to loop by itself, or do you want it to play only after a certain trigger was activated, or something else?
We need more info for that.

In the worst-case scenario, you can use a logic_timer, which will call the ambient_generic's PlaySound() function, every duration of the sound (e.g. every 5 seconds).
The ambient_generic's flags should be like this:

Play everywhere - up to you
Start Silent - check
Is not looped - check

Lastly, I'm not entirely sure about this one, but ambient_generic should only be able to playback mono sounds.

You could try two things:

1. Hide the info_texlights entity, then in the compile dialog:
Check "Save visible objects only" and compile only with HLCSG, with Only Entities, or -onlyents if you're in the Expert mode. The "Save visible visible objects only" flag basically lets the compiler know to not compile anything that is temporarily hidden.

2. Use RipEnt. I've never used it myself, but from what I know, it can be useful in situations like these.
Essentially, it rips out entity data, and allows you to edit it, and back into the map, similar to -onlyents in CSG. Someone correct me if I'm wrong.

Around 175 textures total.

Just realised I forgot to add a verb to my last sentence.
Correction:
"You should either make or edit the gameinfo.txt file."