goldsrc is forever. i'm looking for people to help me rebuild some duke nukem 3d maps

Lol, but then you'll have to recompile both DLLs to accomodate hull changes. There are plenty of places with those constants.

Yeah. Welcome to our little hell

No one mentioned G-man Invasion https://www.moddb.com/mods/g-man-invasion ? Really???

Still making your collection? There's one here https://www.moddb.com/mods/xdm/addons/half-life-dm-gold-multiplayer-maps-century-megapack1

V*LVe explicitly hates people who does this. For years I had an idea of having a txt file with descriptions instead of WAD (or bmp/tga/yougetit) textures. But that would take ENORMOUS time to generate.

There's an AI animation event for this, AFAIR.

Well, I guess I solved the mystery.

Instead of writing X Y Z like this 0 90 0
must write 0..0 90..90 0..0

Weird

If I save the game, while using
"Swizzle/replace elements": "X Y Z"
commands.
The save file does not work.

This is also the case with "Rotated by angle [PYR]" : "0 0 0" in calc_vecfromvec

Is there any solution other than not using it?

Using KillTarget will remove the monster from the game instead of killing it, which may or may not be what you want depending on whether you want it to leave a corpse or not.

If you want it to leave a corpse, the most consistent way would be using the 1000 event at the end of the animation's sequence (event 1000 tells the game the actor died on the event's frame). If the animation doesn't already have this event and if you're making a mod you can modify your mod's barney model directly, or if making a map pack you may make a copy and name it something else.

A less reliable way would be using trigger_hurt with a high damage and non-gibbing damage type (e.g. DROWN),
or if you want the monster gibbed you can just use KillTarget as above and target a gibshooter/env_shooter which should be more reliable than using trigger_hurt.

Thanks

What UbOh said.
Having Ignore Group on makes you select the brush itself instead of the entity.

Try disabling 'ignore groups' (the 'ig' button).

Go to your scripted_sequence, and in KillTarget add the monster_barney.

For some reason several brush entities "get turned" into normal brushes. Right-clicking and going into Properties only shows the visgroups config, as if they werent brush entities. They still have the prefix in the preview, but they dont get selected when clicked. It is worth noticing that this happens also to other entities like func_buttons and button_targets, so far i only tested on those, but im sure that those arent the only ones.

Hi, I'm trying to have an animation where a monster_barney is dragged into a hole in the wall and then dies after the animation is complete. I'm using a multimanager to make this work. Here's what it looks like:

multi_manager
Keyvalues:
trigger_Barn 1 (the trigger_once that activates the scripted_sequence)
deadbarney 2 (the scripted_sequence in question)
Deadguy 2 (the monster_barney himself, I don't know why I put this in here tbh)

This is one of those mod posts that are rare. Usually it's filled with one-day enthusiasm ideas, but I've saw your video and it looks like you're determined. I really hope you're able to organize your time and energy to get it to finish line.

There is something about Mars lately that gets high interest from all sorts of people. In my case, I like playing Terraforming Mars.

Will you make this mod action-themed or more suspense/horror-themed?

We'll see, I'll do my best to finish it. Made it of more or less reasonable scale. Going for short duration but high quality. I like sci-fi around Mars like many people, from movies, games to art. All of it will keep me inspired during dev. The mod will be slow-paced for the most part, you are exploring the surface level of the complex first (I'll try to create a good eerie atmosphere) and discovering various interesting things and when you go down into the sub-surface level, the action starts. Something to see down there....

Oh I remember ya from the ModDB article about making realistic, atmospheric scenes. This is lookin' pretty good!

Thx. Yeah, that's me.

Oh I remember ya from the ModDB article about making realistic, atmospheric scenes. This is lookin' pretty good!

This is one of those mod posts that are rare. Usually it's filled with one-day enthusiasm ideas, but I've saw your video and it looks like you're determined. I really hope you're able to organize your time and energy to get it to finish line.

There is something about Mars lately that gets high interest from all sorts of people. In my case, I like playing Terraforming Mars.

Will you make this mod action-themed or more suspense/horror-themed?

I see, ok. There won't be map sealing walls around these doors.

If the walls around the doors aren't used for sealing the map, they could be made into func_detail and use zhlt_hull1 and zhlt_hull3 pointing to narrower info_hullshapes (for standing and crouching respectively, with the defaulthulls key set to 0). That way it's only those specific doorways that will behave as if there was a narrower player, and not mess with any other cliphulls (and probably save some clipnodes too, relative to using global info_hullshape).

Thanks for the answer. Good to know there is an easier way to do this. I have some doors that are narrower and unpassable and widening them decreases their visual appeal. So instead I'd like to decrease the player's clip hull a bit, make it a bit more realistic.

Oh almost forgot! There's also player-entity collisions, I think those used bounding boxes. That should be in game code somewhere.

When it comes to interacting with the world, the player doesn't really have a width or height. It's just a point.
Instead it's the collision models (clip hulls) of the world that are expanded outwards by half the player's height and width. In other words, the invisible cliphulls of the game world are expanded so they meet this point in the center of the player. These cliphulls are baked into the maps themselves during compilation, so it is kind of hard-coded into the compiler. The latest VHLT (available here) does come with the source so you could change the compilers themselves to generate cliphulls according to your new player size, though an even easier way would be using info_hullshape which is a VHLT map entity that can define a new shape (including size) for the player.

So, is it possible to change player's width (GoldSrc) so one can pass through more narrow doors and such? Is there an editable file somewhere where player's width can be changed or is this hard-coded?

E X C A V A T I O N will be a short high production quality single player sci-fi mod set on Mars. The story takes place in the farther future, at a small privately owned complex set to excavate an object of an extraterrestrial origin. The excavation is taking place beneath the complex. The complex has a staff of 8 - 6 highly experienced workers who are remotely operating excavators and other vehicles, 1 excavation supervisor and 1 administrator. These two know what the object actually is, as does the funder of the operation, the workers don't. They are in it merely for the pay and know only what is necessary. Near the end of the excavation one of the workers finds out what the object they've been excavating for months is and with other workers attempts to sabotage the operation. They end up stopped by the other two and that lads us to the present time.

Both the story and gameplay are still in development. Atm the idea is that you play as a rescuer or such, who received an SOS call from the complex and has decided to fly over and investigate. The mod will begin with you in a small aircraft/spacecraft, landing on the site. You will enter the complex, the surface level, and find no one there. You will then do a bit of exploring of the interiors, playing staff audio logs, reading notes, learning about the operation through various media etc. At the end you will head down to the excavation site itself and discover what is going on.

No zombies or anything of the sort. That is done to death and so I'll be putting an effort to create something more original, more cinematic. Think of Fort Solis. Though you will likely carry a small arsenal and there likely will be a fire fight at the end, or at least as one of 2-3 possible endings.

Mod YouTube channel: https://www.youtube.com/watch?v=i5CMPrS9WXk

Map Decompiler beta 12 released

Map Decompiler beta 12 has been released: https://github.com/SamVanheer/HalfLife.UnifiedSdk.MapDecompiler/releases/tag/V0.12.0.0-beta012

Changes:

• Remove collinear points immediately to avoid merging faces into concave shapes

This fixes the Face-To-Brush decompiler generating bad brushes sometimes.

For example in ba_canal2:

Before: After: The cause of this problem was that collinear vertices (vertices that lie on the same line, like a triangle whose vertices are all in a straight line) were removed after faces were merged. The face merging algorithm (which dates back to the original Quake 3 codebase) assumes the 2 faces don't have collinear points so this sometimes resulted in concave faces being created which level editors can't reconstruct properly.

This problem could also result in some brush faces in the .map file having NaN values.

Thanks to almix for reporting this issue.

You could simply edit the model and add bodygroups, then you modify the FGD to add the variations.

Check the flag "Y axis"

so ive been trying to make a rotating door rotate down, but i dont really know what i should use to make it happen, any help?. it just rotates to the right side for some reason.

I sent you a PM

Great to hear it worked when done manually, hope the script works!

As for normal vectors, it's just a vector that stands perpendicular out from a plane, basically the plane's orientation (technically it's a vector standing perpendicular from a pair of vectors, but in this context a plane is just that pair of vectors).

Had to mess with this sort of stuff when making Map2Prop. 😄

I think I figured out your suggestion and it seems to work doing it manually, I'm now gonna write a script to do it and see how it goes. Thank you for helping me out!

So what you're saying is

• I can reuse my existing code (see below) to determine the rotation of a face in world space.
• Then, I find which world plane (like XY, XZ, or YZ), I suppose by comparing the rotation values to find what it's closest to.
• Then project from the world origin on to those faces which aligns all of them to the world uv, even if they'll be stretched by the projection (so does this give me Hammer's 'World Alignment'?)
• Last, transform the face's world UV coordinates using the face's normal vector. I assume this involves simulating the rotation of the face in the UV space?

But, isn't the original method already giving the UV a world space alignment since the camera remains at the world origin while projecting? Well, except for faces on edges, I suppose.

In those cases, even with the camera at the world origin, it treats the world UV as if it's at an angle. But with this new method, it aligns it with the world.

Still, when I transform the face by the normal, rotating it, won't that have the same result of having that rotated UV map anyway?

I've been doing Python in Blender for several years now but I'm out of my depth on this one. Never had to deal with normals and all this stuff before, not really sure how they work. Might just have to give up on this tbh, it's been a while I've been trying.

For the world planes, you can find a vertex's corresponding UV (assuming no scaling/shift/rotation) by projecting the vertex coordinates flatly onto the nearest world plane (e.g. XY for a upward facing face) divided by the texture's dimensions (since UV coords are relative to texture dimensions).

Problem is just figuring out which world plane to use (XY / XZ / YZ) which depends on the face angle.

Blender doesn't exactly have a world UV coordinate system (far as I know), at least not like Hammer does. So the problem there is what to transform the face's UV from, since Blender doesn't give you a reliable starting place.

What I tried, and which does something similar I believe, is to move the camera in to a location that directly aims at the face, rather than staying in the world origin. That way it more closely replicates this behaviour. But it still isn't accurate... ...since even face projection still takes into account the world location. Maybe what you're suggesting is using this texture projection and offsetting from that based on the world location of the face?

Have you tried, instead of projecting, to transform the face's world UV coordinates by the face's normal vector?
Essentially you want the UV coordinate plane to become aligned to the face's plane.

I've been trying to replicate Hammer's automatic face alignment in Blender using Python. I'm looking to get it 1 to 1.

I know from Valve that Face Alignment works by projecting on to the face depending on its angle.

I've written some code that goes over every face in my object in Blender, and aligns a camera (which is at the world originof (0 0, 0,) to rotate towards it and then uv project on to it. To put it another way, I'm replicating Face Alignment by getting the angle of the face, using that angle to rotate a camera (so the camera's view is parallel to the surface) and then projects a uv from the camera view on to the surface.

This actually works perfectly... for objects that are flat on the grid. But all other angles don't work quite right.

My issue is not that the process doesn't work, just that there isn't information I can find on how Hammer handles these arbitrary angles. Left is Blender, right is Hammer. The textures are aligned 1 to 1. All the mesh is "flatly" on the grid. These objects are at an angle and aren't matched up.

The following is how my script works:

The camera stays in the same location (the world origin) and rotates to match the angle of the face. It then projects the uv from the camera view. It does this for every face.

thats actually cool to know bout it is helpful

I don't know if this is helpful, but the vest and helmet are just modified battery entities...

Hi. I think it would be better if you show your previous works (maps and projects you worked on before), so people could estimate your experience.
Also tell us what you would prefer to work on. Traditional Black Mesa setting or something else?

I have plenty of ideas for HL1 mods and my team can't work on all projects at the same time (we already work on 3). But if I had more people, I could lead the development of the new project based on one of my own ideas.

Somebody on Lambda Generation was looking for mappers, here. I don't know anything about the project though, I just saw this today :]

I was thinking of trying to use func_button, it can be given a path to move along. However, I don't know if it is possible to change its path with func_trackautochange (or with func_trackchange). If you can, that would be best for me

Hey, i was really interested in adding things to the HUD, and tried to create a new ammo counter for a specific weapon.
I take a look at the code and see the DrawHudNumber that some parts of the HUD like the ammo, health and battery have, so i was triyng to get this thing to work but it doesnt seems to have a result.

I tried to take a look at the Internet to see a way on getting my HUD to work, but surprisingly, i didn't find any, and the ones on this site seems to just show things like adding sprites similar to the flash light or the CS radar.

So i wanted to ask if someone haves a better idea on how these things work or if someone has a guide that can help me.

New release

Chaneglog

• New parameter Gravity Setting for pickups (items, weapons and ammo)
• Customizable models for ammo entities.
• Add Master parameter for scripted_sequence. If the script has a master, then it won't possess the monster until the master is enabled.
• Sound Radius parameter for func_tracktrain
• Add HG_HOSTILE sentence group for human grunts to use against non-player non-alien enemies (in Half-Life they use HG_ALERT only against player and HG_MONSTER against alien monsters).
• Add Speech Group parameter for talk monsters. It's a custom prefix used by a monster. E.g. you can make Barney talk like scientists by specifying the SC Speech group. Note that the monster will still use its original pain and death sounds in this case.
• Add bigmomma_wait_fix configurable feature in featureful_server.cfg. When enabled info_bigmomma entities actually use the provided Wait value (bugged in original Half-Life).
• Fix the upper rope segment sometimes incorrectly aligned.
• env_warpball can create AI sounds now (e.g. combat sounds).
• New flags Relative Teleport and Random Destination for trigger_teleport.
• Allow +use, flashlight and other impulse commands during weapon reload (those commands are locked during reload in original Half-Life).

Hello everybody! I want to join whatever team is actively engaged in mods for GoldSource.
I am a mapper, if you have your own team or know who would need a mapper, I would be grateful.

func_guntarget can't be moved again after it is stopped. You can create identical looking func_train and func_guntarget's, trigger them at the starting position at the same time. func_train will be non-solid so the player can shoot the func_guntarget. Once func_guntarget is activated and stops, killtarget it and use a trigger_changetarget to change the func_train's target to the starting position.

damn thats real sad

func_guntarget might do it. idk if you can reactivate it after it's shot, firstly to reenable it and secondly to move it out of the way. you can test this with a func_guntarget that targets a trigger_relay, that after some delay targets the same func_guntarget. if this works and the guntarget reactivates, then you can start thinking about making the rest work with multiple sets of path_corners (front and back of the wall) and trigger_changetargets to change the paths the func_guntarget takes.

I'm not familiar with MMOD, but it looks like it doesn't support Opposing Force and Blue Shift-specific entities.

The only effect of adding these entity definitions to your .fgd file is that your level editor now lets you place these entities in a map. But that is of no use if the game or mod that you're mapping for doesn't support these entities - it will just ignore them, or maybe throw an error.