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 AddOutputting: explanation and comprehension.

Discussion in Resources & Tutorials started by enviolinador, Apr 25, 2013

  1. May 31, 2012
    After using AddOutput lately a lot (and being on my way to write a little crappy Java program to help with it) I've noticed that this output itself allows mappers gain a lot of control, to a point where we are close to being able to simulate the behavior of some plugins. It is, however, just a little tool and can't work miracles.

    I will describe a few things that can be done. As I am terrible, don't hesitate to ask if my explinations are odd/off.

    For starters, a few common uses (over players, although some others can be used over other entities):

    AddOutput -> origin x y z

    Sets the entity's position (origin) to X Y Z. It's a very cheap teleport, and can be used on any entity, almost, but it breaks shit at times (not usually, but weapon_* entities are little annoying bitches)

    AddOutput -> rendermode Val

    Sets the entity's rendermode to Val. You can read on Valve's Dev wiki about rendermodes, what each of them implies and what can you do with them.

    AddOutput -> rendercolor R G B
    AddOutput -> renderamt Val

    Sets the entity's color or alpha respectively. They require a determinate rendermode to work; I most usually use rendermode 3 (which, if I correctly recall, is the color rendermode)

    AddOutput -> max_health Val
    AddOutput -> health Val

    Those two are quite self-explaining. The first one is particularly interesting, because setting the max_health to a value different from 100 will allow a mapper to build regen areas using a trigger_hurt with negative damage.

    AddOutput -> gravity floatVal (?)

    Sets the entity's (actually, I think it only works with players, but I hate props and I haven't truly tested in depth) gravity. It can be used to substitute trigger_gravity (which doesn't work quite well either)

    AddOutput -> solid Val

    Sets the entity's solidity state. It is dangerous if used over some entities (for example, worldspawn) because terrible things can happen (and maybe even trigger a pseudo-physics glitch? it can be enabled and disabled, though). 0 or 1 mean not solid, 2 or 3 mean solid (but they are different solidity types, bounding box and vphysics, I believe; or that was collisions? if so, it is vphysics and BSP)

    There are more properties to be modified from this, and the list would probably be endless (even more considering modelindexes, speeds {can't be used direcly on players, I believe}, targetnames and classnames, basevelocities {like paranoid's bed or christmas' and faps' trampolines}, etc. Those are, however, the most important ones (well, there's a very important one related to driveable vehicles, but I'll make a thread on that later, I think) in my opinion.


    There is, however, another use for AddOutput (as described in http://plaguefest.com/threads/round...les-and-outputs-in-general.15316/#post-196312) is to add outputs. Assuming you either know that already, or you've read the previous link (even if that is just a particular case), I think it is quite easy to understand that lots of things can be done from it. This tutorial/resource thing (not really sure of what it is, since it's a bit general) will focus specially on players (because that's a problem mappers had had for longs, managing players efficiently without wasting entities), but the same can be applied to other entities.

    A naïve example of this, in order to manage players: we have a filter, TestFilter, which filters by team. This filter will allow CTs to pass, and Ts will fail it instead. When it is passed, the activator is teleported to a room in 0,0,0 with AddOutput -> origin 0 0 0; when it isn't the activator is teleported to a room in 0,0,-128 with AddOutput -> origin 0 0 -128. This would be pretty handy in a gigantic trigger that encloses the map in a randomized/mgish ZE map, for example, but I don't like gigantic triggers that much (I'm a filthy liar, I always use gigantic triggers and I tend to map like shit, who am I trying to fool?) so I think we can do better. Let's do this instead: we will add the filter to be tested to each player, and it will only be tested once; it will then be fired... How?

    OnWhateverEventThatNeedsIt -> player -> AddOutput -> OnUser1 TestFilter:TestActivator::0:1 -> 0.00

    Keeping in mind that player is a classname (so all players will get it, even specs) and we need no parameters so we put the two :: together. What to do then?

    OnWhateverEventThatNeedsIt -> player-> FireUser1 -> <none> -> 0.01

    And there you go! All players have been filtered and teleported.

    Of course, this could be used in different contexts, for example, if we want to kill a player that has a given targetname the same filter logic can be applied (there's no instakill input, sadly, and making the player's HP = 1 and igniting it doesn't always work because of the armor which can't be modified with addoutput) by teleporting said player with said targetname to a 'helproom' with a trigger hurt. This, given the fact that it uses targetname, could even not use the filter as the player could be directly addressed.

    What is so interesting from this, though? Well, I am tired of levels, plain and simple, but one idea I always liked was to level up special weapons. Mako failed at it, at least in my opinion, and I was confident it was doable without using a great amount of targetname and filter based logic. AddOutput helps in this case, as a player can fire (just like in the persistent values thread mentioned above) an input over a counter, one for each weapon. The counter can only detect values once, so the weapon can't be 'farmed' within the round. Those outputs can, in fact, completely replace filters: once you get a special weapon a new output can be assigned to you; when the special weapon button is pressed, it will fire FireUserN on the !activator and the output will be fired. This last thing, of course, would need of some 'recursion' to make it delete-able from round to round (reminder, players are persistent entities too!), so it could be deleted at round start by firing the same input (while blocking the weapons so they are unresponsive to it).

    I hope this helps you in some sort of way. I don't care about credits or being thanked, but I would thank you if you didn't use the weapon level system I described as I haven't released a map with it yet and it's one of the few things I've done I truly enjoy. You are, however, free to use it if you wish; I don't really mind that much either as there's other mappers that could make more interesting things than myself with it.
    • Mapping King Mapping King x 1