INFO Download and Play MSS mod now! (Okay not really...)

[Thothie]

The Orange Box came with HL2, HL2:EP1, and HL2:EP2, so it covers this map package. That being the most common way folks got all those games in one go.

HL2DM can be acquired for free, so that was another thought... Same with Black Mesa Source, and TF2... All of which have the same problem though: missing materials/models... But I maybe able to rig up a new package that includes those, so it'd be good to know if it would be worth the upload time.

How the final product will be covered is another thing entirely... Orochi just said it'd be stand alone, but I dunno how he's gonna swing that one.

 

[Orochi]

I think you're misunderstanding what I'm saying here. Mods piggyback off a specific game ID on Steam: they run using the Source SDK Base executable, in this case the 2007 executable. All you need is Source SDK base 2007 to run this, that's it. All the files from "other games" come with it. I never mounted any additional content beyond what the default SDK Base 2007 mounts, which is the HL2DM content. You don't actually need any other games as the HL2DM content is needed is included when you install SDK base 2007 and choose make a mod from the SDK launcher.

I never said it would be standalone, you have a profound ability to misunderstand my posts entirely. The "final product" will mount the HL2DM content as all source mods do at the outset, and any additional content will be placed in with the mod installer.

The definition of "The Orange Box" has changed over the years. Originally it was the engine that TF2, HL2:EP2, and Portal ran on back in 2007. Then, they made "Source SDK Base 2007" which was a mod-platform executable that would ensure a "basic" install to create mods from. The Orange Box engine was that, until they moved ahead and improved it.

Come 2012, the "The Orange Box" was the unreleased SDK 2009, and all we had (and what MS:S is still based on, until I port the files) is aforementioned SDK Base 2007. Now, with the release of Source SDK Base 2013, Valve is letting us use the "Orange Box" engine, and keeping our mod-engine updated in lockstep with all the games that currently use the "Orange Box" engine. (TF2, CS:S, DOD:S, HL2DM...)

 

[Thothie]

I never said it would be standalone, you have a profound ability to misunderstand my posts entirely.

This is a Source SDK Base 2013 standalone mod.

Well excuse my profound abilities...

But the SDK (2007 in the case of this map showcase) does not contain all the required materials for these maps. There's a lot of references to models and materials from EP2, for instance, in these maps, that do not appear in any of the SDK's packages (not even 2013's, looking it over). :\ The VPK's seem rather stripped compared to the ones in the game installs.

And again, the ModDB... Is it time for a new one due to lost control? ...and also what of this Dangerous Pass source?

 

[Orochi]

What I meant by you misunderstanding is that you and I have different definitions of standalone. When I say it, I mean that it will run on SDK Base 2013 without mounting any additional content. I assume what you meant is that it would run without Steam, which is not what I meant at all.

We haven't lost control over the ModDB, I have all the access stuff. If you have an account there I can hook you up.

As for the Dangerous Pass source, I have no idea. I can search my folders again, but I uploaded literally everything I had in them, save for one file that was just too massive. If it exists, I've never seen it.

 

[Thothie]

I assume what you meant is that it would run without Steam, which is not what I meant at all.

Your abilities are similarly profound. I figured, both the final product and the game require HL2+EP1+EP2. I know these maps do... But if you mean you're going to use the SDK base and substitute / copy over the missing materials. I suppose that might work - although the players would still need some game that allowed them to download the Source 2013 SDK, as I don't think you can get it without purchase (and I'm not sure where to find a list of games that qualify).

We haven't lost control over the ModDB, I have all the access stuff. If you have an account there I can hook you up.

As for the Dangerous Pass source, I have no idea. I can search my folders again, but I uploaded literally everything I had in them, save for one file that was just too massive. If it exists, I've never seen it.

Well, there's pictures of it all over the ModDB. :\

I've been using EvilSquirrel's ModDB for all my MSC needs for ages, but I suppose I should use a unique account, if I'm going to try to help out with the MSS ModDB content. I know I have one here somewhere. >_> Personally, I'd upload this package, maybe the video, make a news post, and see if it sparked any interest among the hundreds of Source devs on there.

 

[Orochi]

Good plan, PM me your account details and I'll get you set up with the ability to make posts there. Now I just need to get off my ass, install VS2010, and SVN the stock SDK 2013 code so we'll have some place to start.

 

[Thothie]

Eh, just send an invite to "Thothie", I guess. I've not touched the account since 2008 or so, but I just managed to invite myself to the MSC group that way. >_>

 

[Orochi]

Sent. I'll promote you to a level able to edit the newsposts and such when I can.

 

[MS:C community]

That being said, the easiest way to reduce the alloc_blocks is to reduce the number of large rooms, lower ceilings, lower sky brushes, and, more importantly, when compiling with VHLT, using the parameter "-maxnodesize 2048" in the hlbsp phase. VHLT's non standard 1024 max node size tends to increase the number of alloc_blocks used.

I don't want to hijack the thread but I really gotta ask this anyway: I tried changing the max. node size to 2048 in an msc_vow test compile, but the difference in nodes was only 407 nodes (35.2% fulness to 34.0% fulness) and the AllocBlock didn't change at all... It's still at 60/64 and I still need to add a few things.

Also, here is a completely unrelated request: Could you please make sure that MS:C monsters you intend to add in future patches don't use clip hull 2?

 

[Thothie]

I... Can't control what hull they use - I think they all become part of the same hull - but it shouldn't affect the map compile. The monsters don't exist as anything but meaningless point entities to the compiler.

60/64 should be alright, provided you're not going to add too many more large rooms. It's just the big rooms that get you... Filling the area of the large rooms that player's can't reach with clip brushes helps a bit, and since your maps have a lotta sky, you can likely shrink some of your rooms quite a bit. (Again, sky brush looks the same regardless of distance.)

 

[MS:C community]

I... Can't control what hull they use - I think they all become part of the same hull - but it shouldn't affect the map compile. The monsters don't exist as anything but meaningless point entities to the compiler.

60/64 should be alright, provided you're not going to add too many more large rooms. It's just the big rooms that get you... Filling the area of the large rooms that player's can't reach with clip brushes helps a bit, and since your maps have a lotta sky, you can likely shrink some of your rooms quite a bit. (Again, sky brush looks the same regardless of distance.)

See the thing is: VHLT has three nifty tool textures called CLIPhull1, CLIPhull2 and CLIPhull3. As you probably know, the first hull is for standing players, the third hull is for crouching players and the second hull is (apparently) for some monsters.

If you texture a trigger_teleport in CLIPhull3, you will only be teleported if you crouch inside the brush entity. I tested this and it indeed works as advertised, quite awesome if you ask me.

But the real awesomeness comes from CLIPhull2. Or actually, the real hurt. Some monsters (animated armors, reavers, eldritch vapors) use this hull. Others (elementals, eagles, normal-sized skeletons, horrors) don't. I tested this.

I tried the VHLT BSP parameter -nohull2 (you can guess what this does) but then the aforementioned 'hull 2 users' fell through the floor and out of the map, into infinity, upon spawning. As expected... So, I figured, I'll just use trial-and-error to find out which monsters are and are not 'hull 2 users' and then place gigantic CLIPhull2 brushes in every section of my map where it won't lead to problems.
I even managed to use these CLIPhull2 brushes as replacements for func_monsterclip in order to keep some animated armors and reavers in place.

I thought you could control which hull a mob uses but as I know squat about coding I was obviously wrong. Still though, the potential benefit here is the ability to skip the entire second hull (massive clipnode optimization), if no mobs present in the map use it.

Edit: Back to nodes. Out of boredom I also tried a -maxnodesize 4096 and -maxnodesize 512 compile and, contrary to what I expected, the '512-compile' has a lower AllocBlock (59/64) and the '4096-compile' still has 60/64.
Trends noted thusfar:
Bigger max. node size ---> longer compile time ---> less nodes (obviously) ---> higher AllocBlock (??)

 

[Thothie]

I think flying and standing mobs may use different hulls because they use different movetypes, but Half-Life auto assigns entities to hulls based on their movetype and solidity (and some of our fliers are actually walkers in disguise)... I think trigger-only ents get stuck on yet another hull. It'd take a lot of researching into various engine code leaks to figure a way around that, I suspect... And as Ceriux just pointed out in another thread, Quake used an entirely different hull setup, so my usual "search-the-Quake1 engine source code" approach likely would yield no results. (Granted, is has about a 15% win rate as it is...)

But if you want only mobs to be teleported, there be a flag for that... If you want the teleporter to only work on a specific race of mobs, or certain tagged mobs, or other such craziness, that we can script up fairly easily.

As for the rest, das logic is simple. Bigger node size = larger alloc block. But below the 1024 classic standard you start getting into the Carlos Danger zone, for yes, more nodes causes other issues.

 

[zeus9860]

Carlos Danger zone

dafuq

 

[MS:C community]

But if you want only mobs to be teleported, there be a flag for that... If you want the teleporter to only work on a specific race of mobs, or certain tagged mobs, or other such craziness, that we can script up fairly easily.

Nah, no need. Was just demonstrating the awesomeness of the CLIPhull3 texture. A crouch-triggered-only teleported might be awesome for a secret room, for example.

As for the rest, das logic is simple. Bigger node size = larger alloc block. But below the 1024 classic standard you start getting into the Carlos Danger zone, for yes, more nodes causes other issues.

On the previous page you recommended raising the max. node size to lower the AllocBlock... I'm so confused.

 

[Thothie]

Oops... No... I meant to say that VHLT's default node size is 2048, and ye should use -maxnode 1024 instead, for the classic default.

The crack, clearly I must cut back.

 

[MS:C community]

Oops... No... I meant to say that VHLT's default node size is 2048, and ye should use -maxnode 1024 instead, for the classic default.

The crack, clearly I must cut back.

VHLT's default is 1024, check the compile logs...

 

[Thothie]

VL30 is defaulting to 2048 for me...

Current hlbsp Settings
Name               |  Setting  |  Default
-------------------|-----------|-------------------------
threads             [       4 ] [  Varies ]
verbose             [     off ] [     off ]
log                 [      on ] [      on ]
developer           [       0 ] [       0 ]
chart               [      on ] [     off ]
estimate            [     off ] [     off ]
max texture memory  [ 33554432 ] [ 33554432 ]
priority            [     Low ] [  Normal ]

noclip              [     off ] [     off ]
nofill              [     off ] [     off ]
noinsidefill        [     off ] [     off ]
noopt               [     off ] [     off ]
no clipnode merging [     off ] [     off ]
null tex. stripping [      on ] [      on ]
notjunc             [     off ] [     off ]
nobrink             [     off ] [     off ]
subdivide size      [     240 ] [     240 ] (Min 64) (Max 512)
max node size       [    1024 ] [   2048 ] (Min 64) (Max 65536)
remove hull 2       [     off ] [     off ]

*shrug* I had to make custom batch files for a few maps to tone it down.

 

[MS:C community]

Hahaha that is so odd
Mine defaults to 1024!

hlbsp v3.4 VL30 (Nov 23 2012)
Zoner's Half-Life Compilation Tools -- Custom Build
Based on code modifications by Sean 'Zoner' Cavanaugh
Based on Valve's version, modified with permission.
Submit detailed bug reports to ([email protected])
-----  BEGIN  hlbsp -----
Command line: hlbsp D:\Hammer\maps\msc_vow_a47.map 
Arguments: D:\Hammer\maps\msc_vow_a47.map -low 

Current hlbsp Settings
Name               |  Setting  |  Default
-------------------|-----------|-------------------------
threads             [       4 ] [  Varies ]
verbose             [     off ] [     off ]
log                 [      on ] [      on ]
developer           [       0 ] [       0 ]
chart               [     off ] [     off ]
estimate            [     off ] [     off ]
max texture memory  [ 33554432 ] [ 33554432 ]
priority            [     Low ] [  Normal ]

noclip              [     off ] [     off ]
nofill              [     off ] [     off ]
noinsidefill        [     off ] [     off ]
noopt               [     off ] [     off ]
no clipnode merging [     off ] [     off ]
null tex. stripping [      on ] [      on ]
notjunc             [     off ] [     off ]
nobrink             [     off ] [     off ]
subdivide size      [     240 ] [     240 ] (Min 64) (Max 512)
max node size       [    1024 ] [    1024 ] (Min 64) (Max 65536)
remove hull 2       [     off ] [     off ]

This is usually the part where I'd ask "Are you using the latest version?" but I really don't want to insult you with such a trivial question
I'm stumped. Oh well, as long as I use 1024 it doesn't matter what the default value is anyway.

 

[Thothie]

"Are you using the latest version?"

hlcsg v3.4 VL30 (Nov 23 2012)

I call h4x.

But again, unless you're planning to make another really large room or two, and can't shrink the rooms you got (and if the media contest variant was any indication, I'm sure you can), and can't clip some of that empty space, 60/64 isn't the time to panic on a nearly completed map.

Though it does suck when you have to start figuring out where to chop a map in half... >_>

 

[=HELLION=]

glad to see work progressing... keep it up guys!

 

[Stoned]

When do you think MSS will see completion, Thothie?

 

[zeus9860]

When do you think MSS will see completion, Thothie?

:Stoned:

Here's a hint:

??/??/3???

:roll:

 

[The Man In Black]

??/??/3???

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Python33\lib\re.py", line 214, in compile
    return _compile(pattern, flags)
  File "C:\Python33\lib\functools.py", line 258, in wrapper
    result = user_function(*args, **kwds)
  File "C:\Python33\lib\re.py", line 274, in _compile
    return sre_compile.compile(pattern, flags)
  File "C:\Python33\lib\sre_compile.py", line 493, in compile
    p = sre_parse.parse(p, flags)
  File "C:\Python33\lib\sre_parse.py", line 724, in parse
    p = _parse_sub(source, pattern, 0)
  File "C:\Python33\lib\sre_parse.py", line 347, in _parse_sub
    itemsappend(_parse(source, state))
  File "C:\Python33\lib\sre_parse.py", line 552, in _parse
    raise error("nothing to repeat")
sre_constants.error: nothing to repeat

Your regex is bad and you should feel bad.

 

[zeus9860]

Your regex is bad and you should feel bad.

/feels bad.

Nah, just kidding. Good thing i don't know what a regex is, you should feel bad for wasting your time and effort with something such as that. :roll:

 

[Thothie]

Damnit Zeus... So insensitive... Yet so sensitive... Some gods just need a hug. :\