@Meerjel01:
The logic itself is mostly the same, but I did refine the graph generation code as much as possible.
@Admer456:
I use the MIT license for Pathos. The headers for the model format are available, along with the actual render code. I personally am not thrilled at the idea of adding support for another model format, but who knows? Maybe future forks will do that.
Commented 2 months ago2024-03-06 03:37:03 UTC
in wiki page: Tools and ResourcesComment #106037
I edited in the note panel on Wally, after seeing one too many cries for help on textures being wrong in game due to the use of Wally. I hope it's not too patronizing.
Commented 2 months ago2024-03-05 19:38:09 UTC
in vault item: 2024 Exercise #6: CombatComment #106034
Thanks! Yeah, I couldn't come up with any reasonable objects to put in the centre of the plaza and by that I was too far along to change the theme (that's why you dev texture first, past me!) so the cover is a little lacking, I admit.
I'm def. looking forward to playing around with it when it gets released, doing some experiments and whatnot. Maybe I'd even port my real-time moss mod to it. My only hope is that Pathos will be licenced under something permissive like Apache-2.0, BSD3 or MIT.
Honestly the model format isn't a huge deal. If we get the headers for it, someone else can fork TrenchBroom and add support. An alternative is to add GLTF support to the engine, something I'd probably be willing to do, and TrenchBroom would then automatically be supported. J.A.C.K. isn't exactly a custom Hammer binary BTW, it's a Qt project likely built from the ground up.
Commented 2 months ago2024-03-04 03:40:25 UTC
in vault item: Find the way outComment #106026
Cool map, I like it. I wish it was a little longer - I was thinking that I was moving towards the big action, but the map suddenly ended.
I lost a bit of health when I jumped in the pipe, the height of the drop is too big. It's better to either place some water at the bottom or make a slide to break the fall. Unavoidable damage sucks.
Commented 2 months ago2024-03-04 00:39:33 UTC
in vault item: 2024 Exercise #6: CombatComment #106025
Just gave the level a try and it was a cool experience. I liked the various enemy types, the different entry points for them, as well as the friendly AI that came in. The environmental hazards added a nice challenge when navigating the map. One thing to maybe make the map a little more interesting to play in is having some sort of structure in the middle. Something to block off enemies from directly jumping/shooting at you. Maybe you can climb up it? A few more cover pieces for the combine soldiers to hide behind (or me) would have been nice too! Good job, keep it up!
To trigger the same target multiple times, subsequent keys should be suffixed with #N where N is a number. This is simply because key names need to be unique to be exported to .map properly. The game code drops the suffixes when reading the entity keyvalues.
Commented 3 months ago2024-02-29 00:09:02 UTC
in wiki page: path_cornerComment #106019
Fun fact: the logic of picking movement waypoints of a func_train is entirely within func_train itself. It is therefore possible to make a valid path with other entities mixed in. I've successfully mixed path_corners with momentary_doors like this:
path_corner (p1)
target = m1
wait = 0
spawnflags = Teleport (2)
momentary_door (m1)
target = p2
wait = 0
path_corner (p2)
target = m2
wait = 0
spawnflags = Teleport (2)
momentary_door (m2)
target = p1
wait = 0
I can then use momentary_rot_button to move the momentary_doors around and vary the distance the func_train has to travel.
It is a setup for an experiment where I can vary the time a func_train spends on one part of the map vs the other because it's being used to occlude LOS between me and a monster to test its AI schedule but that's off topic.
But you can likewise use it to have dynamically timed sequence with the mom_doors and func_trains off the playable areas.
My theory is that func_trains check the keyvalues of the entities it uses as paths (usually path_corners) without checking that their classname is actually path_corner. You can therefore use any entity as long as it has keyvalues that concur with that of path_corners: a target, optionally a wait, message (fire on pass) or speed, and spawnflags that don't conflict with that of a path_corner (therefore flag 1 will stop the func_train, flag 2 will teleport, etc.)
Not that I know of. You could propably script it with replace but since they all have different names and also different characteristics (size and so on) it propably isn't worth the hustle.
I could just implement an parent_model key, where the value is another func_map2prop that becomes a template so to speak.
Perhaps add a spawnflag "Is submodel" that makes the mesh of this entity become a submodel of the template's model (or the worldspawn model, if no parent_model is set).
I have some ideas for skeletal stuff, but I'm saving that for post-release.
A way to place/reuse the model multiple places in the map. Maybe a point entity that targets the main func_ entity, inheriting the func_'s convert_to.
Technically you can do this with MESS that runs after map2prop, but why use 2 tools when 1 tool do job.
Using brush entities that inherit others is actually mighty useful actually, to get the right sizing and positioning in the map. Maybe something like zhlt_usemodel approach is more ideal. Maybe do both.
More bones 🦴, a way to assign different parts of meshes to different bones, and a way to set bone hierarchy (easy enough using target keyvalue)
A way to create separate meshes (i.e. separate bodygroup parts) that is later combined into a single model. Probably separate entities that has a shared keyvalue (like MESS). Probably needs a way to set the main entity from the group too (also like MESS).
So your mock-up was not far off, just missing some of the QC options.
Also instead of an offset key the mapper should just use an ORIGIN brush to set the model origin. It's a practice most mappers should be familiar with already. 🙂
The source code repo is still private, waiting until v1 to open that one.
Commented 3 months ago2024-02-23 10:56:45 UTC
in wiki page: game_textComment #106006
There should be more information about character sets: what the game supports, how to get the best results on displaying most languages in whatever charset env is necessary (like VNs requiring shift-jis system charset).
Decided to test for myself.
Vanilla Half-Life's text engine seem to be broken for anything that's not ASCII. It consumes single-byte character sets (presumably ANSI/Windows-1252/system locale) but the text rendering is consuming UTF-8. This results in the broken text consistent with the table in this page: https://www.i18nqa.com/debug/utf8-debug.html
Haven't looked at the other SDKs or engines (candidates include Updated/Unified/Featureful/Xash-fwgs/Pathos) on how they handle text. Hopefully better than the unrecoverable mess vanilla is in right now.
ALSO, JACK will purposefully mangle non-ASCII texts. You'd need to edit the .map directly and feed it to the compilers yourself.
They have the option to flee, and also plenty of ways to avoid confrontation as they figure out how to flee. Also, two to 4 direct hits to the sack gibs the thing and I've loaded them up on armor and health is available.
I guess I won't know if it's too difficult until I get it playtested.
That's all good advice, thank you. Unfortunately I start them out with a gonarch (that they can run from). But I suppose I will not proceed with my plan to put them up against a voltigore shortly afterwards :-/
If you give the players no other options, they will eventually get used to using only melee.
Just be careful about the difficulty ramp. Warm them up with some headcrabs and breakables first and slowly increase the encounter difficulty instead of dropping the player directly into an arena with several gonomes and bullsquids. Let them become comfortable with it before challenging them, so to speak.
If the enemies have ranged attacks, give the player plenty of cover so they don't end up feeling defenceless (which in turn is experienced as unfair and difficult by the player).
The logic itself is mostly the same, but I did refine the graph generation code as much as possible.
@Admer456:
I use the MIT license for Pathos. The headers for the model format are available, along with the actual render code. I personally am not thrilled at the idea of adding support for another model format, but who knows? Maybe future forks will do that.
Honestly the model format isn't a huge deal. If we get the headers for it, someone else can fork TrenchBroom and add support. An alternative is to add GLTF support to the engine, something I'd probably be willing to do, and TrenchBroom would then automatically be supported. J.A.C.K. isn't exactly a custom Hammer binary BTW, it's a Qt project likely built from the ground up.
-hostages need to be both used by players (+use) and be in rescue zone to be actually rescued
I lost a bit of health when I jumped in the pipe, the height of the drop is too big. It's better to either place some water at the bottom or make a slide to break the fall. Unavoidable damage sucks.
Addendum
To trigger the same target multiple times, subsequent keys should be suffixed with#N
where N is a number. This is simply because key names need to be unique to be exported to .map properly. The game code drops the suffixes when reading the entity keyvalues.boop
0.01
boop#1
0.5
boop#2
0.9
boop#3
1.2
boop#4
1.4
boop#5
1.5
boop
.If you're already past that then resize to multiples of 16.
Protip: use a calculator.
func_train
is entirely within func_train itself. It is therefore possible to make a valid path with other entities mixed in. I've successfully mixed path_corners withmomentary_doors
like this:p1
)target
=m1
wait
=0
spawnflags
= Teleport (2)m1
)target
=p2
wait
=0
p2
)target
=m2
wait
=0
spawnflags
= Teleport (2)m2
)target
=p1
wait
=0
It is a setup for an experiment where I can vary the time a func_train spends on one part of the map vs the other because it's being used to occlude LOS between me and a monster to test its AI schedule but that's off topic.
But you can likewise use it to have dynamically timed sequence with the mom_doors and func_trains off the playable areas.
My theory is that func_trains check the keyvalues of the entities it uses as paths (usually path_corners) without checking that their classname is actually
path_corner
. You can therefore use any entity as long as it has keyvalues that concur with that of path_corners: atarget
, optionally await
,message
(fire on pass) orspeed
, andspawnflags
that don't conflict with that of a path_corner (therefore flag 1 will stop the func_train, flag 2 will teleport, etc.)They look very good!
Not that I know of. You could propably script it with replace but since they all have different names and also different characteristics (size and so on) it propably isn't worth the hustle.
parent_model
key, where the value is another func_map2prop that becomes a template so to speak.Perhaps add a spawnflag "Is submodel" that makes the mesh of this entity become a submodel of the template's model (or the worldspawn model, if no parent_model is set).
I have some ideas for skeletal stuff, but I'm saving that for post-release.
convert_to
.zhlt_usemodel
approach is more ideal. Maybe do both.target
keyvalue)Also instead of an offset key the mapper should just use an ORIGIN brush to set the model origin. It's a practice most mappers should be familiar with already. 🙂
The source code repo is still private, waiting until v1 to open that one.
Have you already opened the repo?
I like that smart idea of using 'contentwater' for mirror faces
What entities (and keyvalues) do you have in mind for the fgd?. I made a small mock-up in case you haven't thought of one yet, maybe this can help:
Decided to test for myself.
Vanilla Half-Life's text engine seem to be broken for anything that's not ASCII. It consumes single-byte character sets (presumably ANSI/Windows-1252/system locale) but the text rendering is consuming UTF-8. This results in the broken text consistent with the table in this page: https://www.i18nqa.com/debug/utf8-debug.html
Haven't looked at the other SDKs or engines (candidates include Updated/Unified/Featureful/Xash-fwgs/Pathos) on how they handle text. Hopefully better than the unrecoverable mess vanilla is in right now.
ALSO, JACK will purposefully mangle non-ASCII texts. You'd need to edit the .map directly and feed it to the compilers yourself.
I guess I won't know if it's too difficult until I get it playtested.
Just be careful about the difficulty ramp. Warm them up with some headcrabs and breakables first and slowly increase the encounter difficulty instead of dropping the player directly into an arena with several gonomes and bullsquids. Let them become comfortable with it before challenging them, so to speak.
If the enemies have ranged attacks, give the player plenty of cover so they don't end up feeling defenceless (which in turn is experienced as unfair and difficult by the player).