Commented 1 year ago2024-01-05 12:12:36 UTC
in wiki page: func_tracktrainComment #105848
Some findings about func_tracktrain:
wheels distance is only measured forward from origin. To make the train travel as much on the path as possible, the origin needs to be located at the center of the back axle.
wheel distance defaults to 100.
target of a path_track is fired when the origin passes the path_track.
the position and angle is set wrt the origin point as follows:
trace a line forward.
if there's enough distance to the end of the current path, keep heading
if wheel distance > distance to next path, subtract current distance to next path, then iterate the path forwards until the distance fits the path. the point where distance is 0 is the new heading.
origin moves forward
angle is adjusted to point to the heading. this will in all cases be shorter than wheel distance; the sharper the curve the more noticeable. this also means the front wheel part will always overshoot the path. but the origin is guaranteed to always be on the path.
[2024-05-12] While I am a proponent of the origin at the back axle, more realistically moving trains, I can see how it is totally incompatible with track [auto]changers. Gotta have to pick your poison, I guess.
[2024-05-13] Also, a tutorial for track trains is needed.
[2024-07-10] You can control a func_tracktrain remotely using game_counter_set entities. Value 1 throttles up one notch, -1 down a notch.
pretty comfy, nicely detailed and good music choice, the shaking is a bit too strong imo though.
I feel like this could be used as one of those "waiting for players to join" rooms along with the start button that some SC maps have. It'd be pretty cool and fitting to wait in a place like this.
PS: I managed to jump on that window and saw the secret texture : )
It'd be pretty cool to use the visgroups to assign attribution e.g. all of sir's prefabs is assigned a visgroup to his name. This is to comply with the "BY" aspect of the CC license.
textures can be scaled as need because now lightmap can be recalculated after any changes.
You still need to be careful because the maximum lightmap size for a face is apparently 16x16 luxels. A lot of faces you'll find in maps are already at 16 luxels on either (or both) sides. GoldSrc doesn't support lightmaps larger than that size, and scaling down a texture that results in a face with lightmaps over that size crashes the engine. (IDK if it's supported on svengine). Hence my verdict is don't do it.
As for vertex editing, I just don't recommend it at all too. It's way more cumbersome, and way way harder to get satisfactory result than to get completely broken result. I honestly don't know how a face whose vertices are non-planar would act inside the game. If there's face splitting ability in world faces and easier vertex shifting via handles vs textboxes then it might be feasible, but still not recommended because of the non-planar thing. *
The main takeaway is that just because it's doable with the BSP structure doesn't mean the game engine that's going to parse and run the BSP would like it. If the game engine doesn't like it, don't do it.
I still don't have any draft for a part 2 of this tutorial. 😅
EDIT 1: * Tested face vertex editing. It messes up lightmaps elsewhere on a map.
From reading the code it seems that sv_skyvector_* and sv_skycolor_* are the culprits of models forcibly taking the sky's color, because from looking at texlight data itself there's nothing to discern sky light from normal light. The engine probably trace a vector set in sv_skyvector_* from the origin (feet) and if it hits the sky texture, overrides the model's lighting with the sv_skycolor_*.
sv_skycolor_* is read from the brightness value of light_environment at map load, and sv_skyvector_* from the entity's angle also at map load.
[2024-09-12] I think I solved the black_hidden debacle. It's hidden as world brush BUT visible when made part of a brush entity. the folks who saw the texture probably didn't realize that it won't work on entities.
[2024-09-15] A primer about origin would be good. Models whose origin are inside the walls won't get lighting and be rendered black, and a way to shift it with QC and HLAM. Additionally, a way to have wall-mounted models take lighting from the walls instead of the floor when you shine a flashlight around, for example. I touched on the latter in my tutorial about model health/hev chargers.
Commented 1 year ago2023-12-31 15:43:44 UTC
in vault item: spooky_transitComment #105820
Honestly, nice map the are a few problems, like the lighting brushes s
Are weird, and a bit the level design of the map, which Is a bit boring to walk in a straight line. But the rest...
Is good! I like the details you putted in there. I Wish It was bigger, but in these condition Is ok. Btw great work
You're welcome! Just glad to help out with these things. Would be a shame if you or someone else had to do severe cuts to their map just because of wasted clipnodes :p
Thanks for the help with this on Discord too! I was hitting the clipnode limit because I thought func_illusionary brushes didn't count to the clipnode limit. Now that I've applied the noclip flag fix, I'm still at 57.1% on my clipnode budget even as I start hitting some world and model limits
Commented 1 year ago2023-12-30 12:38:07 UTC
in wiki page: Specification: JMFComment #105812
With the December 2023 update the JMF version was changed to 122, now including a data for background images in the 2D displayports.
From what I've found so far, the new structure looks like this:
typedef struct {
char[4] magic; // File format magic number, "JHMF" in ASCII encoding
int32 version; // File format version (currrently 122)
int32 ep_count; // Number of recent export paths
p_char[ep_count] export_paths; // Recent export paths
bg_image[3] bg_images; // Background images
int32 group_count; // Number of groups in the map
Group[group_count] groups; // Group objects
int32 visgroup_count; // Number of VisGroups
VisGroup[visgroup_count] visgroups; // VisGroups objects
Vector cordon_min; // Minimum corner of the Cordon box
Vector cordon_max; // Maximum corner of the Cordon box
int32 camera_count; // Number of Camera objects
Camera[camera_count] cameras; // Camera objects
int32 path_count; // Number of path objects
Path[path_count] paths; // Path objects (created with the Path tool)
Entity[] entities; // All entities including worldspawn, read until the end of the file
} Jmf;
I lived up to or made progress on all of my goals except for learning to play the piano and getting a driver's license. And I did spend too much time on my phone. But the rest I'm pretty proud of!
Commented 1 year ago2023-12-28 05:24:14 UTC
in wiki page: Tutorial: Coding FogComment #105803
This article is outdated and should be updated for the 25th-anniversary update. Legacy GL functions are not functioning in the latest version of HL engine.
I have my own version of func_detail, had it for a long time now. It's basically a func_wall with zhlt_noclip always set to 1, and it's set to SOLID_BSP in the entity code. This way, bullets and other objects will still collide with it. For player/npc collisions, I can just wrap it up in a far simpler CLIP brush(this bruh not being tied to the entity). This has allowed me to save a lot on clipnodes.
[2024-05-12] While I am a proponent of the origin at the back axle, more realistically moving trains, I can see how it is totally incompatible with track [auto]changers. Gotta have to pick your poison, I guess.
[2024-05-13] Also, a tutorial for track trains is needed.
[2024-07-10] You can control a
func_tracktrain
remotely usinggame_counter_set
entities. Value1
throttles up one notch,-1
down a notch.It's made for the competition and is ready to run on any server.
I feel like this could be used as one of those "waiting for players to join" rooms along with the start button that some SC maps have. It'd be pretty cool and fitting to wait in a place like this.
PS: I managed to jump on that window and saw the secret texture : )
Keep up the good work man!
There we go.
As for vertex editing, I just don't recommend it at all too. It's way more cumbersome, and way way harder to get satisfactory result than to get completely broken result. I honestly don't know how a face whose vertices are non-planar would act inside the game. If there's face splitting ability in world faces and easier vertex shifting via handles vs textboxes then it might be feasible, but still not recommended because of the non-planar thing. *
The main takeaway is that just because it's doable with the BSP structure doesn't mean the game engine that's going to parse and run the BSP would like it. If the game engine doesn't like it, don't do it.
I still don't have any draft for a part 2 of this tutorial. 😅
EDIT 1:
* Tested face vertex editing. It messes up lightmaps elsewhere on a map.
sv_skyvector_*
andsv_skycolor_*
are the culprits of models forcibly taking the sky's color, because from looking at texlight data itself there's nothing to discern sky light from normal light. The engine probably trace a vector set in sv_skyvector_* from the origin (feet) and if it hits the sky texture, overrides the model's lighting with the sv_skycolor_*.sv_skycolor_*
is read from the brightness value oflight_environment
at map load, andsv_skyvector_*
from the entity's angle also at map load.[2024-09-12] I think I solved the black_hidden debacle. It's hidden as world brush BUT visible when made part of a brush entity. the folks who saw the texture probably didn't realize that it won't work on entities.
[2024-09-15] A primer about origin would be good. Models whose origin are inside the walls won't get lighting and be rendered black, and a way to shift it with QC and HLAM. Additionally, a way to have wall-mounted models take lighting from the walls instead of the floor when you shine a flashlight around, for example. I touched on the latter in my tutorial about model health/hev chargers.
Are weird, and a bit the level design of the map, which Is a bit boring to walk in a straight line. But the rest...
Is good! I like the details you putted in there. I Wish It was bigger, but in these condition Is ok. Btw great work
That's fine. It's a bridge between two worlds.
Awkook, it's the textures in zhlt.wad, which should be included with your compilers (VHLT or ZHLT)
From what I've found so far, the new structure looks like this: and for the background image struct:
The cvar
waterroom_type
(default 14) controls which env_sound Room Type is applied when the player is underwater. It's seemingly unused in the game.