Welcome to PlagueFest.com! Log in or Sign up to interact with the Plague Fest community.
  1. Welcome Guest! to interact with the community and gain access to all the site's features.

Tutorial (and resource) Maps that build themselves to be quite l33t.

Discussion in Resources & Tutorials started by enviolinador, Sep 17, 2013

  1. May 31, 2012
    One of the things I've always wanted the most was to be able to create a map that would build itself each time it was played. This would, with little wittle poodly poop effort, allow hours of endless (probably glitchy as fuck) fun. I've kinda had this thought in mind since I was little and mapped for Warcraft 3 TFT (in which I made a maximum-sized forest map in which the trees would randomly spawn and you'd have no unit constraints so you'd end up having laggy as fuck empires).

    I started mapping for dem CS:S and I always thought about it, but it was hard. Even if all the buildings were there and I was to draw a path/chose them, that'd be a fuckload of entities and systems and things and that's so complex I'd probably die doing it. I had to wait.

    Time forward, ZE, maps, levels, pewpew, oh func_brush is a permanent entity - GOOD, oh you can't template it - STOP RUINING MY DREAMS. Then I discovered that addoutputting 'classname func_brush' on a wall toggle made it stay forever. Good. But I had no props. Bad.

    I started looking for permanent entities. Point_viewcontrol, func_brush, info_target, trigger_soundscape... There's more than a few! Hey, what about addoutputting func_brush as a classname to anything? Oh, the door stays! Oh, the breakable window stays! Holy fuck the nuke stays and I can't spawn ever again...! But I knew this had had problems in other maps, when used on the player class (which is a permanent entity too!)... Perhaps... Perhaps point entities shouldn't have a brush entity classname? Oh, no problem, info_target is our friend. Ok. I can make that a bulding stays and that a prop stays, but if you shoot the prop out (for zm_) you're boned. Poop. Hey, what if we template all the props, and using entity makers turnt permanent, we spawn them each round? That sounds about right, yeah, let's go.

    When I had all this donely-done I mapped a fast thing (bear the horror of dev textures, awkward prop placement and having fucked the env_entity_makers up so the angles aren't being set, sorry for that), and that is zm_autoville (.rar attached with the .bsp and the .vmf, you can extract all the files from the map using bspsource + extract map contents), a map that builds itself on a simple little grid.

    The horror, the damn horror, as always, had to appear... How in the world are we going to optimize a map that is randomly generated and that requires a flat, empty area to be placed? Well... We're going to need some hinting for VVIS to take some advantage, as well as some extra walls to hide things - it won't be enough... What if we fade the playermodels and the weapons at a distance, considering they're the laggiest pieces of poopadoodle usually? Yeah, we'll do that. So we addoutput values for 'player' and 'weapon_*' for the fields of fademaxdist and fademindist. Cool. Thingies disappear in the distance, players become ghosts... what else?

    We need to initialize everything. Only once (or overlapping cities and eventually a crash will ocurr). Hrm. We can use levels like in ZE but that's boring. Oh, wait, func_brushes are permanent, so if they fire an input that is ticked with only once they won't fire it again. Cool, we'll have an initializer brush (as Taboo already uses one, in fact, that taboo doesn't crash due to classnames is the 'proof' that the system does worky-torky) that will kill himself (for if something went horribly wrong) and fire the building relays.

    What else? Nothing at all.

    Attached: The map file that explains the whole system better (because the explanation here sucks, but basically you addoutput the func_brush/info_target classname to entities and voilà, permanent).

    Attached Files:

    • Wizard! Wizard! x 1
    • Jul 20, 2012
      You are awesome as always. Is this how ZE Deja Vu was made?
    • May 31, 2012
      It's similar, but simpler. Dejavu didn't keep things from round to round, so you don't have to bother with classname changes or any change for the matter.
    • Jun 28, 2011
      Why not make prop_static models of everything you need (buildings, bridges, etc) with good collision models and use those instead of over 9000 brushes everywhere fucking it all up?
    • Feb 27, 2012
      Not sure exactly what screws up, but enviolinador actually made a ZM map with this. It fuctions very well, and there is only one glitch that happens, which is just from a badly placed prop in two parts of one building. A couch glitches into the wall on 2/4 rooms, but it's not a big deal. Other than that, it runs nice and functions well.


      If you haven't seen it before.
    • Jul 20, 2012
      Because he func_detail 'd them?
    • May 31, 2012
      The purpose of this is to make a map that builds itself every round or every time the map is played. Prop statics can't be modified on runtime, so that'd be useless. Prop dynamics could be made permanent (as stated on the thread), but prop collisions tend to be far buggier than their brush-based counterparts when the prop is big.

      Also, I like how brushes get lit better. And this post is very lucky.
    • Apr 9, 2012
      While that is true if you just use vertex lighting you can have all of your props get a much fancier look. As a matter of fact, if you ever played Lost Coast (HL2 mod) then if you decompile the level, you actually see that the entire outside walls of the monastery on the hill is one big prop_dynamic. Yet, it looks like it's all brushes, just because of the vertexlighting. I realised this only when I decompiled the map xD But ofc, brushes are still better lit