Forum posts

If you moved all of it over you would only have to implement the server's interfaces so they call scripts, everything else would be implemented in scripts. It's a fair bit of effort though, and i don't know if it will perform well.

Both of those entities remove themselves after being triggered. Unless you can count on having Metamod support to clear the FL_KILLME flag and restore its targetname, you can't reuse them.

Well, worst case scenario i can just write a program to convert vanilla HL maps to the new format. The existing interfaces aren't that complex, and the lack of more powerful entities means you'll usually have a 1:1 mapping of features. For example, making all monsters hostile by default would require the keyvalue "Is Player Ally" to be set to true. For scientists, Barneys and Op4 grunts that's easy enough to do.

I'd use component based design for reusable code. As the principle goes, prefer composition over inheritance. Schedules and tasks could be components as well. You'd have an interface like this:

class CSchedule
{
public:

CSchedule( const char* const pszName )
	: m_pszName( pszName )	//Could be ALLOC_STRING'd here if dynamic creation is needed (e.g. Angelscript)
{
}

const char* GetName() const { return m_pszName; }

virtual int InterruptMask( CBaseMonster& monster ) const = 0;

virtual int GetSoundMask( CBaseMonster& monster ) const = 0;

virtual size_t GetNumTasks() const = 0;

virtual void StartTask( CBaseMonster& monster ) = 0;

virtual void RunTask( CBaseMonster& monster ) = 0;

private:

const char* m_pszName;

};

Obviously just a quick concept, but it would allow a given schedule to be defined entirely in 1 place. Monster specific schedules can cast their monster type to a specific one, providing identical power to the current version.

By providing the monster for the interrupt and sound masks, the results can be decided based on current conditions. That's potentially very powerful (e.g. stealth mechanics where the monster can't see the player -> don't interrupt).

You'd then only have to put these schedules into an array or hash map to use them. Name lookups or special schedule ID assignments could mimic current GetScheduleOfType behavior. It would also reduce the size of the monster classes themselves, and if specific properties are made components as well (e.g. Alien Slave beams), you could make entire attack modes into components as well. You'd almost have Lego block like monster building potential.

The only issue i see with this is memory usage. The engine doesn't like to share access to its memory allocator so you're stuck with the default heap. That's a few dozen megabytes you can't make use of. Add to that the 34 or so megabytes that are wasted for both the client and server secure library code (which is obsolete), assuming it's compiled into the libraries, and you've easily lost ~100 MB worth of space you could be using for this. Then again, considering some modern game engines use component based design, it might be just fine.

Water also works upside down, since the flat plane limitation doesn't say wether it's normal or upside down.

It only uses hintbrushes, clip, null (hl1 version of nodraw), etc.

Never add more than 1 cue to a file, it'll screw things up.
Also, try to keep ambient_generic questions in 1 thread.

You're wrong, it can play any sound in the the sound/ folder.

Are you sure you let HL2 fully update?

Which can be done with a single multimanager.

E. Use a func_rot_button.

You're probably trying to create brushes with the selection tool. Make sure you've selected the brush tool.

They used Ripent for that, but you can't do much with that.

I have this error as well when using sprites for glows. I only managed to do this effect by using env_lightglow.

Just download a half-life model viewer and look at the animations yourself, it's way easier.

Did you set up Hammer properly? And brush-based entities usually only appear when tieing brushes to an entity.

I believe it has to be:

skin(integer) : "Skin" : "1" : "White" =

[

	1  : "White" 
	2 : Black"

]

I'm not sure if this will work in Source, but since it's HL: S it'll probably work.
Note: it may not be possible to choose the skin of a grunt, in half-life it uses the weapon settings for skins.

http://tf.valve-erc.com/ has all the info you need on how to do this.

I suppose it's prop_dynamic, since it has animations.