Technical reasons. I added an artificial 1-second delay before the Gonarch can begin its charge, otherwise the oddly-inconsistent entity I/O setup that it uses won’t fire properly, which would make it look really weird. So I compensated by allowing it to charge a lot faster than normal.
Also, there was no feasible way I could come up with for having the spitball attack work like a well-aimed arched mortar like the original. So I made it fire directly at the player, then tweaked the speed of the projectile until it was fast enough to be challenging, but still feasibly dodge-able if you pay attention and see it coming. This is more of a balance thing though. Subject to change, and all that.
It’s definitely something that I’ve considered before, and might consider doing.
You have no idea how many mind-numbing, hair-pull-worthy bugs and glitches I had to sort out in order to get to the current state of things. And even now in the video you can clearly see a few… oddities.
Fantastic!
So you are in fact using path_tracks, in conjunction with triggers that detect the player’s position, for the movement? Looks like, at least.
Those func doors for the legs and physboxes look nice for the moment, but have you considered something more… gonarchy … for the release? I’d love to help with this thing. I’m still trying to get that bullsquid-based model-replacement thingy to work. Movement is now based on an hgrunt standing invisibly beneath the ground, that the gonarch is parented to.
The obvious advantage is, that an hgrunt automatically follows the player (he can see through the 1% translucent ground) and can be scripted to go anywhere.
One issue remains: How can i make the engine properly reload a model that is already cached, because it has been used on the previous map? I have to include a modified bullsquid.mdl in my BSP zip lump. I’d need something like sv_reloadmodel …
PS: how are you going to solve the babyheadcrab problem? how to differentiate between baby headcrabs and ordinary ones? I still have no idea how to do that…
To answer your more technical questions: I am using path_tracks and func_tracktrains (yes, plural) in conjunction with a clever system of func_tanks, point_templates, env_entity_spawners, a lot of carefully-tuned parenting via I/O, and an almost-hackish setup involving multiple logic_measure_movement entities. Needless to say, it’s very complex, and is very prone to random, difficult to trace I/O glitches, but I like to think that so far I’ve done a decent job of setting the screwup-to-functional ratio at an acceptable balance.
I think I’d just leave the headcrabs as they are, since really I see no feasible way to implement a babycrab system. Plus, there’s something satisfying about swarms of normal-sized headcrabs that you can actually aim at and shoot, IMO.
About your model assets question, sorry I have no real answer to that… I don’t usually map with custom models. Maybe someone around here with more experience than I do can answer that.
As for visual direction… Honestly I have no idea what I’ll do in terms of an aesthetic approach to the Gonarch. Really I’ve been going off of this really old Black Mesa lol mediaz picture the whole time:
To be honest, I never intended the whole Xen thing to be taken seriously at all. It was more meant to be a joke, based on the juxtaposition of the crappy HL:S geometry/textures with the hi-res Black Mesa weapons/NPCs. My use of the angryfaced-nyan-arch was supposed to be an extension of that attitude.
But since everyone has had such positive actual feedback, I really am considering a far more serious approach to this now. If you want to help me out with that, I’ll be more than happy to accept whatever you have to offer, and really, what anyone else has to offer as well. I’m open to this. I don’t have to be the only one working my ass off on what was originally meant to be a half-assed joke project, you know!
I see. You seem to have developed a quite complicated system. Good to know it works so far. My approach can not be used. I did not find a way to cleanly replace the Bullsquid model with the Gonarch model from HL: Source. It’d work if the player restarted the engine everytime he wants to play a map involving the Gonarch, but that does not contribute to continuity.
I did however find a way to parent a Bullsquid to the top of the Gonarch model (in that case, the Gonarch would be a prop_dynamic). The bullsquid is made invisible and mounted in the right spot, so that it can spit. This concept could also be integrated with your solution, if you choose to use a model for the Gonarch. However, there may be problems with solid geometry: The bullsquid must freely move where it is mounted. Physboxes hinder it’s movement and it does not spit.
Can you find a way to damage a prop_dynamic by shooting at it? In my experiments, prop_dynamics (yes, they had a collision model) did not lose health or break when being shot at.
You could do something similar with an invisible parented func_breakable surrounding the “hitbox” of the prop. The func_breakable’s OnHealthChanged would trigger a SetAnimation input for the prop_dynamic to make the prop react in some visible way (like a jiggling sack or something).
The prop would be non-solid, of course. And I can already think of some problems you might run into.
Already tried the ‘func_breakable’ solution. Like with a physbox, it’s blocking the Bullsquid, which intersects the func_breakable, from turning around, so it cannot spit. I really want to use the spit from a Bullsquid, it’s perfect in terms of visual quality. I must find something that (1) can be damaged, (2) can report that it has been damaged and (3) is not in the same CollisionClass as the Bullsquid. @Ronster: That would be nice, but we do not have access to the code. So we cannot port the npc_gonarch entity, but have to construct a hackish approximation in Hammer.
Sometimes you need to make sacrifices in order to get things done. In this case, there’s always my hackish func_tank solution that I’ve already implemented. It’s not perfect, but it works.
If you can find me the proper particle system names, I might be able to implement the bullsquid effects to my current spit system.
Edit: Okay, so checking on particles it looks like the closest to it is grenade_spit.
However there are some models in the root model folder that are named spitball_large and spitball_small that look like they might be it. They might be used in combination with the particle effect.
I currently use a prop_physics_override combined with a sprite for the spit. The prop model is a spit glob that I found in the BM files. It’s honestly very bland and looks nothing at all like what the bullsquid spits at you.
Judging from the pattern of these projectile entities, I’d think that grenade_spit refers to the actual spit entity that is launched by the bullsquid. I’m guessing that it uses a combination of that model and the particle effect.
Physics tab in the model viewer (with the large model at least) shows “bullsquid_spit_large_phy.” I think the blandness is due to it not illuminating itself like ingame.
I’m almost positive that there is a particle system involved though.
I pretty much have the first Xen map down, but thanks.
If you want to help, how about trying Interloper?
EDIT: I was also meaning to mention at one point. When I decompiled the final Black Mesa Lambda Core map and linked it to my Xen map, apparently something got screwed up, and there are a few glaring issues with the areaportals. Anyone up for taking a look and seeing what they can do to help fix them?
Founded in 2004, Leakfree.org became one of the first online communities dedicated to Valve’s Source engine development. It is more famously known for the formation of Black Mesa: Source under the 'Leakfree Modification Team' handle in September 2004.
.
Maybe someone around here with more experience than I do can answer that.