View Full Version : For the mappers!
Koochy
December 14th, 2004, 06:05 PM
This is a thread dedicated to all the mappers out there who have requests for ideas to be added to the .fgd
To me, TFC was all about fun / skill maps. There are a lot of people out there who don't just play TFC for it's competitive side. The HL / TFC .fgd was great, but still lacked a few things that blocked large sections of skill / fun map ideas being made :(.
Ideas!
item_weapon
Just a simple point based entity allowing you to select which weapon spawns in the map to be collected via trigger / running over it. TFC had this, but not as easy as a simple entity.
Weapon specific reactive entities
This means, buttons that can only be opened via a conc explosion, or a rocket! Could be defined in the properties of any entity that allows damage to be dealt to it.
Physics reactant tf_goals
Kinda hard to explain this, but lets say I make a map to practice aim. 3 barrels are standing on a pillar across the map. Each must be shot to open a door. This could be done easy enough with some TFC entities, but what if barrel was launched mid air and had to be shot IN the air to open the door? You get what I mean? Just like, brushes / models which have properties that allow only activate when shot in the air or only activate when shot moving etc etc.
Thats all for now that I can think of in my head. Feel free to speak out mappers! I'm especially meaning you trepid Jon / Jesse. You 2 are my hero's :D.
Ps: GL with the mod and hi Kerm :D?
MeestarK
December 15th, 2004, 12:47 PM
lol your third entity sounds fun, but is it really even possible? If so, you could totally have an airshot competiton map :eek:
MikeQuist[x7]
December 15th, 2004, 11:11 PM
Tis possible for the game engine to recognize "air"?
Mulchman MM
December 15th, 2004, 11:48 PM
Yeah, probably. You could traceline to the ground and see what distance you are from it (or maybe some easier way).
ReEn
December 15th, 2004, 11:57 PM
an entity that enables scoring by putting a 'ball' somewhere, such as a hoop or goal without you having to hold it would add a lot of potential fun, but is it possible?
Defrag
December 16th, 2004, 12:10 AM
How dare you steal my avatar, mulch.
sgx_d
December 16th, 2004, 01:01 AM
Just food for thought for the mappers.
A) Source supports a much larger map size
this means something for a few kinds of people
Concers and other skill maps
ADL mappers
escape mappers (k_thegame?)
4 team mappers
cz type maps could really prove difficult in conquring
another thought would be the objects you can place in the levels. A barrel or 2 nearby criticle concing areas can assist the D greatly. Or perhaps the rare random and hilarious conc throwing a barrel for kill. HL2 grav gun demonstraits this very well lol.
Mulchman MM
December 16th, 2004, 07:49 AM
How dare you steal my avatar, mulch.
I told you straight up in our #love_channel I was going to steal it. :) I did have to shrink my big head to fit catacombs standards, though.
colin
December 16th, 2004, 11:22 AM
an entity that enables scoring by putting a 'ball' somewhere, such as a hoop or goal without you having to hold it would add a lot of potential fun, but is it possible?
i've wanted that one a couple times
colin
December 19th, 2004, 11:19 PM
how about this:
an optional heads up display that mapmakers can have entities report to. obvious examples would be things like lasers on/off or even the oppose2k wallboard intruder alarms.
other examples might be reporting who (what team namely) has the ball in maps like push and murderball, what jump people are on in skill maps, etc etc
i think it has a lot of potential for improving map quality.
edit: i should stop double posting on every topic, because then everyone has to look at Thrash that much more. would've just editted the old post if it wasn't several days old.
Clank
December 20th, 2004, 03:48 PM
we need a randomizer or something of the sort.
it might already be in hl2 I havn't look that closely into its mappnig yet.
but something that just generates a random number, each time its called.
for example "I make a teleport entrance, with 3 seperate destinations. I want the destination to be generated at random, so have a key calling the randomgen for a number, and based upon that number thats where I teleport.
have it so you can limit the scale of the number.
Minimum Value: 1
Maximum Value: 5
Scale: 1
so it would generate numbers 1-5 and whole numbers only. (the scale)
===================
Another thing i've always wanted, was the ability to make a wall, that only people with a certain item, can walk through. I don't mean a door that one person can open, and others can walk through. I mean a wall that he just walks through.
EX. you have the flag, item_no 20 and the func_wall/trigger_hurt/trigger_push is passable with those holding item_no 20. So he can walk right through the lasers/wall/push without being affected, because he has the flag. If anyway tried to follow him, they would be stopped/killed/pushed.
trepid_jesse
December 20th, 2004, 07:33 PM
Mad, what you described up there.. can already be achieved in TFC. Maybe you were thinking of something else?
As far as how the entities are going to be translated over, I'd like to see a couple of things improved upon:
One such thing would be "randomization" of a particular event. It's long been known/used that an env_beam has the "Random Strike" flag, and it requires a bit of trickery to take advantage of that "random"-ness -- so, it would be nice to set a series of nodes that are part of a group that allows randomization. Granted, no real randomization can exist inside of a computer program, but I digress.
Further support of the model replacement feature, that I only saw available in TFC, would be nice. As it is now, the way that model replacement works in TFC is somewhat limited. One of the biggest "drawbacks" is that once you replace someone's model it will remained replaced until it is replaced again. So, if I replace someone's model with the barney model, they will remain as the barney regardless of team and class switching. The effect can only be masked by replacing their model with another model.
I would mention increasead model support, but the Source engine already takes care of this department. Of course, just to point it out, models in TFC are static if placed as anything other than an item_tfgoal. So, mappers that want to use animated models have to use item_tfgoals or cycler/cycler_sprites to portray models. It would be nice to have the option of either having a model static/animated when placing them as opposed to having seperate models.
Seeing the capablities with the Source engine, these problems are pretty minimal and I would imagine are quite easy to overcome. The biggest "problem," I would think, would be that coding the TFC entities for FF -- as they existed in TFC -- is probably a rather involved task. TFC entities are so robust and provide so much functionality, and it would be a shame if all of that functionality isn't carried over, and it'd be a waste to not have that functionality expanded in Source.
The stripping/giving of weapons should be greatly improved, too. The ability for the mapper to strip away all/select weapons, and give all/select weapons would be a nice feature. This is horribly supported in TFC; although, it's there. It would nice to see this also including grenades. So, you could make some novelty map where HWGuys could be given concussion grenades.
There's also exists some weapon specific damage. You can check for the Engineer's spanner, detpacks, and the Pyro's IC (I feel like I'm missing something?), but not the other more generic things. It would be nice to check to see: "If damaged by: " and have a bitfield for a weapon. Or, actually, have a another attribute that works inconjunction with it. So, something like...
"Team Allowed to Use Goal: Blue"
"Playerclass Allowed to Use Goal: Soldier"
"If Damaged By: SuperShotgun"
So, only a Blue Soldier could activate say a func_button, func_door, etc.. by shooting it with his shotgun. Those two first bitfields already exist -- it's just the third one that's missing.
Anyway, I could ramble on indefinitely...
colin
December 20th, 2004, 07:57 PM
last time i looked, the only way to make a randomizer was to set up a series off laser target entities with the same name and place a damage activated button in front of each so when the original laser ent is triggered it will randomly shoot to one of the targets and trigger the button on that path.
maybe someone's devised a less complicated way, but this way is a little stupid.
Clank
December 21st, 2004, 12:01 AM
why not make it easy? and add a randomizer?
another thing I just thought off..
a func_buildable.
a surface/texture/brush ent that will allow you to build an sg on top of it.
this way, you could build sg's on top of glass, { textures, and any sort of func_wall. make it able to be grouped with a func_train so you can have a sentry riding ona train (muhahah) if the mapper so desires.
One of my first map designs (on graph paper at least) I had planned to have a train that ran around the outside of the map, and I thought it would be the coolest thing ever, to be able to build a sentry on the train, and send it chugging into the enemy base.
FOR A POSSIBLE HAZARD COURSE (maybe even some map implantation)
an entity that instantly changes the player class, that bypasses server class limits, and doesn't cause the player to die.
it just strips their weapons/nades/ammo then adds the new classes ammo/weapons/nades(variable controlled on the amount added) and turns them into that class.
so you can start out asa scout for basic movements/concing, then it will change you into a soldier when you step into the entity, then it will teach you solly basics, then you can go demo/engi/etc/etc.
Dunno if this is mapping or not, but the model animations should be able to demonstrate concs/rjumps/sg builds/detpacks/pipes that sort of thing. Like the lady in the hl1 hazard course.
MikeQuist[x7]
December 21st, 2004, 09:50 AM
Yes, a tutorial screen with the option of seeing one class would be nice.
colin
December 21st, 2004, 02:03 PM
improving func_train or whatever it might be called would be cool. maybe that was just a shortcoming of the HL1 engine and is inherently fixed with source.
Koochy
December 23rd, 2004, 01:45 AM
Thanks for the input guys :D! Now for a recap on some of the ideas.
player_class_config: Point based
An entity capable of swapping the current players class attributes to another class.
Example: You're playing Soldier. The entity is triggered and you're class is swapped to Engineer! Player doesn't die, (maybe an effect is triggered on the screen) just instantly swaps.
phsyics_tf_goal: Model or brush based
You know in TFC, when the flag is thrown onto a cap point nothing happens? Thats fine. What if certain entities were recognised by touch and not by the aid of the player holding the goal?
Example: Grav gunning a barrel through a hoop. When barrel passes through an entity; (lets say an i_t_g) a point is scored! No player input other than the throw. Think of the sports maps!
logic_random: Point based
Basically what JesteR suggested.
we need a randomizer or something of the sort.
it might already be in hl2 I havn't look that closely into its mappnig yet.
but something that just generates a random number, each time its called.
for example "I make a teleport entrance, with 3 seperate destinations. I want the destination to be generated at random, so have a key calling the randomgen for a number, and based upon that number thats where I teleport.
have it so you can limit the scale of the number.
Minimum Value: 1
Maximum Value: 5
Scale: 1
so it would generate numbers 1-5 and whole numbers only. (the scale)
func_wall: Brush based
Just a more improved func_wall with the capability to recognise tf_goals. What I mean is, people carrying Flag [a] can walk through Wall [a] where as people who are NOT carrying the flag or a different one, cannot.
As for func_push and trigger_hurt entities JesteR, this is already possible <3.
weapon_ceasefire: Brush based
When the play enters the brush tied to this entity, the players weapon is dropped (much like when looking at friendlies in HL2:SP). Shots are able to be fired into the brush, whether or not they can be registered as hits on a player inside the brush.. you guys can decide on that :D.
Ummmmmmmm, I'm just reading through the thread and taking some peoples ideas and just writing up about them. Since Jesse cover's lots, I'll just quote him :p.
Mad, what you described up there.. can already be achieved in TFC. Maybe you were thinking of something else?
As far as how the entities are going to be translated over, I'd like to see a couple of things improved upon:
One such thing would be "randomization" of a particular event. It's long been known/used that an env_beam has the "Random Strike" flag, and it requires a bit of trickery to take advantage of that "random"-ness -- so, it would be nice to set a series of nodes that are part of a group that allows randomization. Granted, no real randomization can exist inside of a computer program, but I digress.
Further support of the model replacement feature, that I only saw available in TFC, would be nice. As it is now, the way that model replacement works in TFC is somewhat limited. One of the biggest "drawbacks" is that once you replace someone's model it will remained replaced until it is replaced again. So, if I replace someone's model with the barney model, they will remain as the barney regardless of team and class switching. The effect can only be masked by replacing their model with another model.
I would mention increasead model support, but the Source engine already takes care of this department. Of course, just to point it out, models in TFC are static if placed as anything other than an item_tfgoal. So, mappers that want to use animated models have to use item_tfgoals or cycler/cycler_sprites to portray models. It would be nice to have the option of either having a model static/animated when placing them as opposed to having seperate models.
Seeing the capablities with the Source engine, these problems are pretty minimal and I would imagine are quite easy to overcome. The biggest "problem," I would think, would be that coding the TFC entities for FF -- as they existed in TFC -- is probably a rather involved task. TFC entities are so robust and provide so much functionality, and it would be a shame if all of that functionality isn't carried over, and it'd be a waste to not have that functionality expanded in Source.
The stripping/giving of weapons should be greatly improved, too. The ability for the mapper to strip away all/select weapons, and give all/select weapons would be a nice feature. This is horribly supported in TFC; although, it's there. It would nice to see this also including grenades. So, you could make some novelty map where HWGuys could be given concussion grenades.
There's also exists some weapon specific damage. You can check for the Engineer's spanner, detpacks, and the Pyro's IC (I feel like I'm missing something?), but not the other more generic things. It would be nice to check to see: "If damaged by: " and have a bitfield for a weapon. Or, actually, have a another attribute that works inconjunction with it. So, something like...
"Team Allowed to Use Goal: Blue"
"Playerclass Allowed to Use Goal: Soldier"
"If Damaged By: SuperShotgun"
So, only a Blue Soldier could activate say a func_button, func_door, etc.. by shooting it with his shotgun. Those two first bitfields already exist -- it's just the third one that's missing.
Anyway, I could ramble on indefinitely...
As for your func_buildable JesteR; why not just allow the building of SG's to be possible (by the game) to be built on top of entities? If the mapper didn't want a Disp on the lift on SD2, then a func_nobuild will be placed over it's path of movement. That's all that's stopping building of SG's ontop of entities; TFC itself (I think :D).
- - -
That's just some NEWER entity ideas written up. There's LOT'S of improvements on the old ones that I know people want, but I thought let's start with some newer idea's ;).
I'm not expecting the developers to fu-fill all of our wildest requests! But it would be nice to see some of these entities be added to broaden the mapping possibilities for TF:F.
<3.
vBulletin® v3.7.4, Copyright ©2000-2008, Jelsoft Enterprises Ltd.