Making an Intel Invisible?

Discussion in 'Mapping Questions & Discussion' started by English Mobster, Jan 13, 2012.

  1. English Mobster

    English Mobster L6: Sharp Member

    Messages:
    355
    Positive Ratings:
    225
    I've struggled all morning trying to get this to work, and I give up.

    Basically, for the Dynamic Payload contest, I want to add in some extra non-essential CPs that modify the speed of the cart (double it or halve it, depending on which team capped the point).

    But since we can't hybridize the HUDs due to them being hard-coded, I'm forced to rely upon other audiovisual cues, mainly the Announcer, game_text_tf, etc.

    For Arnold's/Honeymustard's cp_Konkreet, they used a rim light similar to the one seen around the intel or Payload cart around each active point. I took a look at the decompiled version of their map, and what it did is parent the active CP's prop to an Intel (Red, Blue, or Neutral), making sure to disable the collisions on the CP's plate model. The Intel, being rimlighted itself, would extend its rimlighting to the new child, effectively "highlighting" it on the map. To keep the Intel itself from showing up, they used what appears to be an invisible model (considering it's a model called "invisible model"). I don't have access to that, as custom models don't get decompiled.

    I have copied that setup and got it working ingame, but in addition to the rimlights, I can see the Intel models through the walls. I have tried to replace them with an invisible custom model, but I've hit a snag.

    • First, I tried compiling just a static_prop bone with no model attached. Everything compiled, but the game crashed when it attempted to load the map, spitting out an exception that says "Game error: glow_red (or blue or neutral; it varies) has backwards mins/maxs" (sic).
    • This is what the Wiki had to say about the error:
    • Now, that isn't directly for TF2, but rather for Source mods in general, and I don't believe I'm calling "SET_SIZE." Another thing I noticed is that the error is prefaced with "Host error" rather than my "Game error," so this might not even be the right problem. But that's the only lead I have, as Google turned up zilch otherwise.

    • Seeing as my "glow_red" entity is the Intel case, I figured that was probably the game freaking out over a bone with no model.
    • I made a custom texture, null.vtf (there probably already was one, but I wanted to make sure). It's a 2x2 pixel black dot with a black alpha. The VMT reads like so:
    Code:
    "UnlitGeneric"
    {
        "$basetexture" "models/props_spytech/null"
        "$alpha" 0
    }
    
    • To go with this custom texture, I re-exported my invisible Intel model with a 1x1 box parented to the bone, textured to "null." I had the same result.
    • I expanded the box to be 16x16. Same thing.
    • I imported the actual intel model and reskinned the entire thing to "null." Same error.
    When the Intel models are normal, everything is fine, but you can see the Intel models through the wall. Obviously, making the Intel models disappear must be possible, else it wouldn't have been done in Konkreet. What am I doing wrong?

    Or, better yet, does anyone have a working invisible prop_static (or prop_dynamic, or whatever kind of prop) that they can give me?

    Thanks in advance.
     
  2. C00Kies

    C00Kies L3: Member

    Messages:
    132
    Positive Ratings:
    21
    I may be under-thinking this, but in the same way that they parented the cp prop with and intel and this is a PL map, couldn't you just parent the prop with the cart to get the glow? I do see a problem that it will probably move with the cart but if you could figure out some how how to get around that... Just another idea to think about.

    Like I said, Im probably some how seriously under-thinking this but who knows.
     
  3. gamemaster1996

    gamemaster1996 L13: Stunning Member

    Messages:
    1,065
    Positive Ratings:
    131
    If you want an invisible intel wouldn't you just create a blank prop?
     
  4. Sergis

    aa Sergis L666: ])oo]v[

    Messages:
    1,871
    Positive Ratings:
    1,131
    what i did once to hide intels was using the door model from team select menu and turn it away from the map so no polygons are visible to players and therefore there are no polygons to outline
     
    • Thanks Thanks x 4
  5. honeymustard

    honeymustard L9: Fashionable Member

    Messages:
    698
    Positive Ratings:
    273
  6. tyler

    aa tyler snail prince, master of a ruined tower

    Messages:
    5,032
    Positive Ratings:
    3,979
    [​IMG]
     
    • Thanks Thanks x 1
  7. English Mobster

    English Mobster L6: Sharp Member

    Messages:
    355
    Positive Ratings:
    225
    That is correct, the points would move with the cart. There is no way to not make them do so without unparenting it, which would remove the glow. Besides, I need Red and Neutral glows as well, which would mean I would have to make the gamemode PLR (and I don't even know if Neutral cart glows can be done).
    I made the mistake when I was first testing this out of not making the cap plate non-solid; I walked over it and picked up the giant cap prop on my back. It was rather comical.

    I have been attempting to do so, and it's been crashing my game. The Intel isn't a prop in itself; rather it is an item_teamflag which I can use to specify a custom model. It has been my attempts to specify this model that have been crashing TF2.

    I'll try this; good idea.

    Credit will be given where it is due, no worries. I didn't take anything from the map, as per the contest rules, I just took the chat's recommendation to decompile Konkreet and see how it was done, then I emulated that to the best of my ability. Blame them. :p
    However, if you'd like me to remove it, I shall.
     
  8. honeymustard

    honeymustard L9: Fashionable Member

    Messages:
    698
    Positive Ratings:
    273
    Nah it's fine, but if you'd asked me I would have saved you the effort and just given you the files :D
     
    • Thanks Thanks x 1
  9. grazr

    aa grazr Old Man Mutant Ninja Turtle

    Messages:
    5,436
    Positive Ratings:
    3,562
    One question. Out of all the unique mechanics you can have a control point do, why have you chosen for it to do a mechanic that already exists in payload, as a part of the payload mechanic no less.

    Locking the track under various aesthetic circumstances i could understand. But replicating a mechanic that already exists and isn't even necassery to progress... it just seems to me there are far better alternates to make your map different and interesting.

    ...and whether you've taken the ability for more players around the cart to speed the cart up away or not, i think you've greatily misunderstood what makes payload and KoTH superior/dominantly more fun/popular in TF2.
     
  10. English Mobster

    English Mobster L6: Sharp Member

    Messages:
    355
    Positive Ratings:
    225
    I got it working using Sergis' method, thanks!

    And Honeymustard; I'll be honest: for some reason, I had thought you were long gone from these forums. I have no idea why I thought that, but it didn't even cross my mind to ask if you had the assets. I only decompiled to see how you did it because I asked the chat and they told me to do it. :p

    *Ahem*

    Brace yourselves, this is going to be a longpost. I'll put the tl;dr here:
    tl;dr: Heavies in Payload suck, so this makes Scouts more viable.


    The idea arose from a complaint where the slow, heavier classes tend to dominate a Payload game, whereas classes like Scout see less playtime due to their inability to function well outside of a harassment role, unlike in 5 CP, which has the opposite problem.
    I am keeping the 3x multiplier cap on the cart's speed itself as per regular Payload, but think of the control points in terms of cp_Steel: one can cap the last point at any time.
    Either team can make it easier for themselves by capping the secondary points: RED has the cart speed clipped to half of what it would be normally upon capture of a Generator (what I call my secondary points; I'll refer to them for the rest of this to avoid confusion), thus impeding BLU's progress and giving them an advantage.
    On the other hand, BLU would have the cart speed doubled if they cap the Generator, making it go significantly faster than it would with the max amount of people pushing.
    Another way to think about it is it gives the player more control over how fast the cart goes. Typically, the cart will max out at its top speed (ignoring a rollforward or other extenuating circumstances). That top speed is static in Payload games; unless you activate some sort of rollforward or the like, it will never go any faster, no matter the external factors.
    BLU is therefore not encouraged to hold anywhere but the immediate track around the cart; capturing a flank has no benefit other than being able to flank the enemy.
    RED likewise has no reason to truly defend a major flank. Even though it is superior to their usual position next to the large ammo pack, it's very rare an Engineer sets up a Sentry on the left flank of Badwater prior to CP 3 being captured (after CP 3 is captured you'll see them up mainly to defend BLU forward nests from Spies).
    RED also is helpless if BLU puts 3 Heavies on the cart under normal circumstances. Provided the Heavies know what they're doing, a Spy can't come close without being shredded. Snipers become the real issue, but anyone else can't touch a Heavy on the cart, let alone 3. The cart will move forward at max speed, creating an incentive for people to go Sniper on RED and Heavy on BLU.
    By adding in the new Generators, RED now has the ability to halve the speed of the Heavy onslaught with less risk to themselves, thus allowing them more time to stop it. It isn't a perfect solution: as the main CP will always be more important than the Generators, Heavies will still be seen on the cart and can only be delayed.

    There is only one Generator active initially, and so controlling that first is the utmost priority. If BLU captures it, then the SetSpeedForwardMultiplier is doubled from 1 to 2, thus meaning the lowest RED can bring it down to is to halve it from 2 back to 1, negating the gain but not furthering any true objective themselves.
    If RED captures it, the opposite is true: SetSpeedForwardMultiplier is halved from 1 to .5. The highest BLU can restore it to with just that single point is 1; now they can't reach the magical "true" double speed.
    The latter situation is what will probably happen 9 times out of 10. RED will typically be turtling on the Generator during setup, and the moment the gates open and the Generator becomes active, they will begin capturing it. But due to the flow of a game, they'll be cleared out and BLU will more than likey recapture the Generator.
    The first one is set up to be a "tutorial" of sorts; it's very biased towards BLU overall, being right outside their spawn, so they will eventually cap. But due to setup, RED negates that advantage and can literally be right on top of the point when it becomes available, showing BLU that there's a point there and what it does if they don't cap it. Player instinct would lead them to capturing the Generator, thus showing them what it does it their team captures it.
    The second Generator is the truly "neutral" one; it has equal walk time from both spawns. It is based in the middle of an important flank; if a team controls the area, they can get behind the other team for the main CP, in addition to the speed up/slow down effect. This Generator is designed to be the Generator that can win the game for either team; BLU has to get through a chokepoint to get to their main CP, and if RED manages to hold the Generator and the point, BLU will have a hard time capping.
    The last Generator is biased towards RED, to create an "epic" feeling for BLU. The first main CP is designed for an approximate 75% cap rate for BLU; the last is designed for a 50% win rate. Much like how BLU can easily hold the first Generator, RED can easily hold this last Generator once it becomes active, negating the advantage BLU has from the first one.

    By giving the players incentive that they can still make the cart go faster/slower (if RED has been overwhelmed on the track, for example, they can regroup on a point to achieve their objective of impeding the cart's progress), it will hopefully encourage a more complete battle for an area.
    For example, on Badwater second, BLU can still cap if RED holds the roof. BLU has no incentive to clear out the players other than to get rid of the height advantage. If a Generator was up there, suddenly the area becomes much more important. Now BLU needs to clear them out not just to get rid of a height advantage, but also to prevent RED from further sabotaging their progress. It is much more likely that BLU will send Scouts ahead to prevent RED from capturing upcoming Generators.
    It'll also force RED to get more aggressive as they now have two goals: defend the track, thus furthering the overall objective, or capture the Generator, making the overall objective easier to achieve. If they turtle on the point without getting aggressive, it hurts them, which should hopefully encourage lighter, aggressive classes.

    Another factor that should encourage the capturing of Generators is the lack of CPs on the track: the track is set up Gorge-style, with 2 CPs that count towards the actual objective. That means only one CP adds time to the countdown, and by default it takes the cart 1 minute and 40 seconds to reach it and cap (compared to Gorge's 1 minute 15 seconds).
    If BLU captures the Generator first, then that time is cut to 50 seconds. Generally, RED would cap first and BLU would retake it shortly afterward to negate the generator's effect, however, so after about 15 seconds of pushing at normal speed, the "neutral" generator becomes available. If BLU captures this, they could theoretically match Gorge's cap time of 1:15.
    Of course, if RED manages to hold the neutral generator, that 1:15 turns into 2:30, a significant difference that you couldn't see under normal Payload conditions.

    Yes, you CAN theoretically win the game without capping the control points, just like in Steel. If you remove the Generators, then it is balanced just like a regular Payload map. The Generators are there to encourage constant movement by both teams in addition to the turtling default Payload encourages. Yes, the mechanics ARE there by default in a regular Payload game, although not NEARLY as effective as the Generators at helping/hindering progress.

    I understand Payload works because it's simple: push cart to point, get time, push cart to next point, get time, repeat 2 more times, win. The same with KOTH: hold point for 3 minutes, win.
    I want to make these elements as unobtrusive as possible while still making a difference. I'm doing everything I know to push players towards the points subconsciously, from subtly brighter lighting to large "capture point" overlays and hazard stripes to sound cues to various visual tricks outside of modifying the HUD.
     
    • Thanks Thanks x 2
  11. Empyre

    Empyre L6: Sharp Member

    Messages:
    286
    Positive Ratings:
    136
    Another way to make the intel invisible would be to put it far far away, so it won't render.
     
  12. A Boojum Snark

    aa A Boojum Snark Toraipoddodezain Mazahabado

    Messages:
    4,769
    Positive Ratings:
    5,527
    This is the part where snark comes in and simplifies a giant thread into an easy solution with one sentence.

    Send the TurnOff input to the intel.
     
    • Thanks Thanks x 3
  13. honeymustard

    honeymustard L9: Fashionable Member

    Messages:
    698
    Positive Ratings:
    273
    Then whatever is parented to the intel will also receive that input?
     
  14. A Boojum Snark

    aa A Boojum Snark Toraipoddodezain Mazahabado

    Messages:
    4,769
    Positive Ratings:
    5,527
    The intel having TurnOff is a byproduct of whoever coded it reusing prop_dynamic code. The input tells the entity to stop rendering the model, and back before they added the custom model key, it was how you made a custom intel (parent you own, turn off the original).
    I have not actually used it since the addition of outline glow, but I see no reason they should have changed how it functions, as it is a shared input not unique to the intel.
     
  15. English Mobster

    English Mobster L6: Sharp Member

    Messages:
    355
    Positive Ratings:
    225
    Ah, Snarky. Gotta love ya. I'll try it out and see what happens. <3

    E: It turned off the rimlights as well, which was the entire reason for having the Intel in the first place. Oh well. Back to using the Arena UI doors.
     
    Last edited: Jan 14, 2012
  16. Empyre

    Empyre L6: Sharp Member

    Messages:
    286
    Positive Ratings:
    136
    Try also my idea, placing it far far away so it won't render, maybe way above or below the rest of the map, unless somebody knows a reason why that is a bad idea.
     
  17. tyler

    aa tyler snail prince, master of a ruined tower

    Messages:
    5,032
    Positive Ratings:
    3,979
  18. English Mobster

    English Mobster L6: Sharp Member

    Messages:
    355
    Positive Ratings:
    225
    Right now until I finish the last cap my map is cordoned off, so I can't place it far away without increasing compile times.
    However, being as they're based off of a stock prop_dynamic, I don't think Intels have a fade distance by default. I don't think it would work unless you added in a keyvalue, but that's considerable effort compared to using the arena doors, which works and is a million times easier.
     
  19. C00Kies

    C00Kies L3: Member

    Messages:
    132
    Positive Ratings:
    21
    So I wanted to try this out with my map and I cant seem to get it to work. I believe I am using the right model [(models/vgui/ui_arenadoor01.mdl) Right?] and I have flipped the prop both ways to make sure and neither way worked.

    I cant manage to find what it did wrong. They are dynamic.

    -Thanks
     
  20. English Mobster

    English Mobster L6: Sharp Member

    Messages:
    355
    Positive Ratings:
    225
    What do you mean by "They are dynamic"? You shouldn't be placing any props, just an item_teamflag for each color glow you want.
    Here's what mine are set to:
    Code:
    Name: glow_red (or neutral, or blue)
    Game Type: 4 (You need to turn of SmartEdit for this; otherwise the AI bugs out if you're using them to help test)
    Team: Red (or Any or Blue)
    Pitch Yaw Roll: 0 270 0 (they are the farthest point "down" in my top viewport)
    Model Override: models/vgui/ui_arenadoor01.mdl
    All other settings are default. It has no outputs or inputs (you should be targeting the prop you want to add a glow to and sending a SetParent output with the parameter set to the name of which color intel you want it to glow).
     
    • Thanks Thanks x 1