The Oculus [WIP]

[HumanSteak]

Speaking of axes, the axe of balance has a decent hit rate but it's damage are SO LOW that it's by far no match for the dragon axe. I hate to see such a beatiful model go to waste!

I know, that was totally offtopic.

 

[Freerad]

Speaking of axes, the axe of balance has a decent hit rate but it's damage are SO LOW that it's by far no match for the dragon axe. I hate to see such a beatiful model go to waste!

I know, that was totally offtopic.

By the way looks awesome Crow

 

[Crow]

Sorry I haven't updated in a while, I don't have a ton of time right now and the thing I'm working on right now is really big and complicated but... soon...

Also, I was looking at the Spirit of Half-Life, and... damn. It is awsome. Though I already know we've tried it or something

 

[Thothie]

What, specifically, do you want from it? After the nightmare of adding Bloom Mod, the SOHL should be much easier to integrate now, as we've got the proper GL libraries.

 

[J-M v2.5.5]

Parenting system!!!

 

[jon50559]

And particles!!

 

[Crow]

Parenting system!!!

This.

Also the locus system. And the aurora particle system.

 

[Thothie]

Dunno what the parenting or locus systems are, so wouldn't even know where to start. Maybe we could at least name some entities here?

As for the particle system, that usually entails an emitter sprite, which is kind of like a self-repeating gib_shooter with a lot more options - in otherwords, a fancy sprite that eats ten times the resources of a normal sprite. Dunno if it's such a good idea to open up such a feature given the sprite abuse we already see. :\

 

[J-M v2.5.5]

Parenting system means attaching entities to entities (doors to trains, flashing lights to moving platforms, etc.)

 

[Crow]

http://www.moddb.com/mods/spirit-of-half-life

You can download the source code, or the mod itself. If you want to see the document I'm about to quote from, or the full entity guide, download the version w/o source code. Its in the docs folder.

I realize this stuff is most likely pretty complex, and while it would be pretty cool, it' wouldn't be nearly as important as the title system

The MoveWith system allows you to make entities move around as though they were attached together. For example, you can make a lift with buttons inside, a breakable glass door, and many many other things, all with a minimum of effort.
Example:
The effect is simple to set up. Suppose you have a func_train named "mylift", and a func_button inside it. To make the button move when the lift moves, you would simply type "mylift" into the button's "Moves With" field.

You aren't limited to just one entity, either. MoveWith can be chained together, to create objects as complex as you want. For example, you could make a train, and a door that MovesWith the train, and a button that MovesWith the door, and an env_spark effect that MovesWith the button! The env_spark will now move when the train moves, and also when the door moves, and also when the button moves, all as you'd expect.
...

The info_movewith entity allows you to dynamically change what entities MoveWith. So for example, you could build a crane with a magnet. You turn on the magnet and it picks up a box; thereafter the box follows the movement of the crane.

The Locus System
The Locus system is a relatively new feature, introduced in Spirit 0.7. It's quite complex, and so far a lot of people seem to have trouble understanding it (due, no doubt, to the almost negligible documentation - which hopefully is now more helpful). If you still don't get it after reading this section, please ask. And if you can think of a better way to explain this stuff, please let me know!
The system is essentially two seperate features - a special value "*locus", and a set of calc_ entities. Each can be useful on its own - but combined, they form a weapon of incomparable power, able to level mountains with a single blow.
Or... maybe that was something else.



The value *locus:
When you're making a Spirit level in Worldcraft, you'll see that some entities have fields marked with an "[LE]". These are fields where you'd usually write an entity's name. (For example, the "Target to affect [LE]" value for an env_render). What the suffix tells you is that instead of typing a name, you may type "*locus" into that field. The field will then refer to the current Locus Entity, not something called *locus.
"But what's the current Locus Entity?"

I'm glad you asked me that. In Half-Life, there's a rarely-used concept of "who caused a trigger to be activated". Usually, this is a player. (If you've used the "Targeting: Activator" setting on a func_mortar_field, or the "Activator Only" flag on env_fade, then you probably have some idea what I'm talking about.) Essentially it works like this - if a player presses a button to open a door, the button will tell the door who it was pressed by. Equally, when a trigger_multiple gets activated, it will tell its target who walked into it.

And the Locus Entity? That's just my word for "activator". When you tell an entity to affect "*locus", you're telling it to affect whoever caused it to be triggered.
Example: an obvious use for this would be in a multiplayer level, to make a special invisibility powerup. Have a trigger_once which targets an env_render, and tell the env_render to affect "*locus". The first player who walks into the trigger will then be the "locus" of your env_render, and it will make him invisible.

There are also specialized locus fields, like

Locus Position [LP]:
This suffix appears on fields where you're asked to specify a position, instead of an entity to affect. For example, the "Initial Position [LP]" field on an env_explosion. By specifying the name of an entity in this field, you'd cause the explosion to appear wherever that entity was. (If you give the name of a brush entity, the explosion would appear at its origin brush.)

Scripted Sequences
One of Half-Life's greatest selling points has always been its scripted sequences. But did you ever find there were little niggling things that didn't let you do quite what you wanted...?
The scripted_sequence entity now has a "Turn Type" field, separate from its "Move Type". The monster will usually walk/run/do nothing according to its movetype, and then will do nothing/turn to face a particular direction, according to its turntype. So you could make a sequence where a monster simply walks to a particular point, without caring what direction he's facing at the end of it. Or you can make a sequence where a monster simply turns to face the centre of the room, regardless of where he is right now.

In normal HL, a scripted_sequence doesn't work when playing a death animation - the monster will get up again straight afterwards, and it just looks silly. The "Monster dies" flag will override this behaviour, so that those monsters stay dead. Note that if you play a non-death animation this way, the monster will end up frozen in whatever pose the animation finished with.

The scripted_action entity lets you tell a monster to fire its weapons. You can always make it simply fire - but if you want to make it fire at a specific point, you have two options.

Set the "Turn Type" to "Turn to face", and specify an "Entity to attack". This will make the monster face the entity you specified, and fire directly at it.
Set the "Turn Type" to "Turn to face", and set the "Move Type" to "No - Only turn". This will make the monster face your scripted_action entity, and fire directly at it.
Sometimes a full-on script isn't very useful, because it's not flexible enough. For example, you might want a monster to shoot at a particular object... but not if he can't see it, and not if he's in the middle of a fight. The monster_target entity is handy for that sort of thing. Monsters will treat a monster_target as another monster (of whatever type you specify), and will automatically attack it using their normal AI. A nice way to use this is to put a monster_target right next to a func_breakable, so that when they try to attack it, they'll hit the func_breakable instead. When you want them to stop attacking (i.e. when the func_breakable breaks), trigger the monster_target to turn it off.

you can also make a monster follow a path like a train does, who will attack enemies when they see them, and go back to thier path once the enemies are gone. (Thus patrolling monsters, or an escort quest made easy)

 

[PBarnum]

Yes! That all sounds very good haha

 

[The Man In Black]

We already have the SOHL code, it's just a matter of tracking done all the parts (coders often times follow the philosophy of "it was hard to write; it should be hard to read") and finding where to plug them in in our code. The main issue with the second part being that they often reference libraries and files that we don't have already, making it so we have to implement more stuff we don't understand.

Imagine it as being the manager of a company that has no idea what the company does to make things work, and the employees not being able to just tell the manager what they need, so the manager just continuously says, "Is this what you need? Does this work? WHY WON'T YOU TALK TO ME?!"

 

[Thothie]

Meh, main thing I hate about the SOHL code, and that so often makes me go cross-eyed when I look at it, is that everything is so heavily centralized. This makes sense, when coding a stand-alone mod, but given that this thing was designed for use in other mods, you think they would have used a modular approach. In many cases, we can't just toss in their core without ripping out our own core, and it makes it very difficult to track down where certain functions come from.

Bumpmod has a simpler, more modular code, and I believe it also has the "movewith" function, which is something I've found myself wanting when mapping myself. Maybe I can find the source for it again (think I lost it ages ago). If not *sigh* I'll try to detangle the SOHL code.

Locus might actually be easier to remake from scratch than try to mess with the SOHL code. Likely just a case of reserved target names for storing the locus of a trigger.

All the scripted sequences are out though. MS ripped out the core of the HL monster AI in favor of its own. It has the advantage of being more dynamic and has smarter unaided navigation (though that's not saying much on the latter), but it can't make use of nodes and the like. :\ It is possible to setup scripts that cause monsters to move from specific point to specific point though.

 

[The Man In Black]

Now that I've had time to read..

Locus is pretty easy. Triggers already have a variable to see who triggered them, so it's easy to just check if targetname is "*locus" or "*activator" and do special things if that's the case.

As for the scripting, we've been meaning to get a way to let mappers set up simple scripts for their maps. I have some ideas, so I'll start planning them out and send them to Thothie.

 

[Thothie]

Locus is pretty easy. Triggers already have a variable to see who triggered them, so it's easy to just check if targetname is "*locus" or "*activator" and do special things if that's the case.

I thought it'd be easy enough, but the locus system seems to do a bit more than this (or could do more than this). I think it stores the triggering player under a specific pre-determined target name, to do with as the mapper wilt with said stored target later. Sort of a "Store Activator" [string] property.

Some of the examples they give may not work for MSC though. env_render to change player rendering, for instance, likely won't work right (although it'll probably do something, just not what ya want).

As for the scripting, we've been meaning to get a way to let mappers set up simple scripts for their maps. I have some ideas, so I'll start planning them out and send them to Thothie.

Could stick more stuff into the world_spawn entity, to be sure, just keep not getting around to it. (Underground, or disable TOD effect would be good, for instance.) Your mapper-side scripting sounds promising though.

 

[J-M v2.5.5]

MS ripped out the core of the HL monster AI in favor of its own.

I was under the impression that monsters in MS:C had no AI at all
OK I'll stop now.

 

[The Man In Black]

AAI >_>

Locus, I think, will be fairly unnecessary, methinks. If the mapside scripting works, we can just store ent_activator or ent_locus or something and the mapper would have way more control over whoever activated it.

 

[Crow]

New Pic to front page! Sorry it's a little dark. Haven't quite figured out what I'm going to do for lighting for this room aside from the outside light.

 

[Monika's_BFFEx0256]

New Pic to front page! Sorry it's a little dark. Haven't quite figured out what I'm going to do for lighting for this room aside from the outside light.

Oh wow, it looks b-e-a-u-tiful! I can't wait to see this ingame (hopefully soon!)!

 

[Thothie]

(Ramps up gamma so he can see.) Nice to see that whoever Shahaddar's interior decorator was didn't die with Rickler.

 

[Crow]

I thought I remember that you can now scale models. I see a scale field in the env_model, but it doesn't change it's apperance in hammer.

Does this work in-game? Or am I going about it wrong?

 

[Thothie]

Scale works on env_model as of a recent patch. It does not, however, preview in Hammer.

The body property should work under MAY2010 as well, I think. Same diff though (no preview).

You can also scale monsters, somewhat, with the addparam "ext_scale;2.0" (for x2 scale - wouldn't try going much beyond 2x though). Scaling down works as well (eg. "ext_scale;0.5"). Only works on monsters with the full AI, and be more buggy on some than others.

 

[Crow]

Cool.

The body property should work under MAY2010 as well, I think. Same diff though (no preview).

Is this like solid/non solid?

 

[Thothie]

Strongly suggest always having models set non-solid, and then build a player clip around them, if you want them to block things. The model's internal collision boxes are rarely constructed well, and in many cases, just plain don't exist.

 

[Crow]

That's what I usually do, I just wasn't sure what the body field did.