I don't really have the time to make such changes, as I'm developing a game, and I have a job. I'm afraid someone else will have to do that. Hell, maybe it could be you.
@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 1 month 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 1 month 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 1 month 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 1 month 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 1 month 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 2 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.
Texturing — 10
Ambience — 10
Lighting — 10
Gameplay — 10
Or better yet.
Join the Xbox homebrewing scene and make a build for the original Xbox!
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.