- Feb 15, 2011
- 333
- 344
Are you planning to add MvM and SD to the Gamemode Library at some point?
- Thread starter A Boojum Snark
- Start date
MvM seems really complicated and requires a lot more in-depth map specific stuff (mostly because of bots) to the point that having the core logic ready-made would not be as significant of a help as other modes.
I've been thinking about SD, but as I was discussing in the chat the other day, there is some consideration to be made about what is SD and what is Doomsday, since we only have one map to go by. But that along with single-stage CP are potential additions next time.
I've been thinking about SD, but as I was discussing in the chat the other day, there is some consideration to be made about what is SD and what is Doomsday, since we only have one map to go by. But that along with single-stage CP are potential additions next time.
MVM Example already is a very good start though. It contains the most basic things required for a functional mvm map but lacks a good guide on how to use them properly. Those info props lack the key information that makes it all clear. This specificly is a problem on the brush entities since those define the navigating which is what is the key part of mvm.
Your library however could still feature a simplified version of that example by giving presets of arrows and mission selection. But in the end it still wont be enough and as easy as other maps. There is too much stuff that is map specific.
You for example can just make 4 paths as seperate groups of brushes that arent actualy built into a map. People can freely choose between those on which they want to use. And ofcourse also add the supporting brushes so people can see the type and behaviour on them (although they shouldnt copy the brush itself). MvM example already does this but still looks very complex as its 1 big thing and not seperate sections.
And since manhattan that example also is outdated for more complex versions (with control points), and specificly those can help mvm mappers alot.
I have checked the decompile and its actualy a very simple trick. Respawn room visualizers are the clipping for that one (which is so the nav actualy goes on the floor and bots understand they can walk through it when the visualizer is gone). There is a push region so bots dont get stuck (since it lacks a nav on top of it) and a money collect trigger so money doesnt get stuck inside it.
And what issue of engineer bots?
If you mean placement: http://forums.tf2maps.net/showthread.php?t=21154
Its realy basic to make engineers work. And this is 1 of those things that can be copied for reference but needs changes afterward.
In my MVM experience, almost everything in mvm_example is genuinely needed.
By default, the tool textures (what is shown in the material browser in hammer) for blend materials is either non-existant (defaults to the first of the two textures being blended), a poor representation of the blending using a smooth flat gradient, or using one that isn't the blended textures at all.
My override requires changing the VMT (text-based script) that tells the engine/hammer how and which VTF (image data) to display. I make my own tool textures (VTF) that are never used by the game, only loaded in hammer, but to display them means changing the VMT to point at them.
It is possible to cheat via VMT editing, such as telling the engine to render certain materials transparent to see through walls, or make player materials render in front of everything else to see them through walls. Because of that, VMT consistency will be enforced on a server with specific pure settings.
I do not personally know how the game handles a VMT conflict if you join a pure enforced server with a customized material, so I put the warning out there in case you have problems either joining a server or things look weird in-game when you do. (If someone can direct me to a pure server, or a way to find servers with that enabled, so I can test it myself, that would be nice)
Before the steampipe conversion none of this mattered because there was a place I could put the materials that Hammer loaded but not the game, that option no longer exists.
My override requires changing the VMT (text-based script) that tells the engine/hammer how and which VTF (image data) to display. I make my own tool textures (VTF) that are never used by the game, only loaded in hammer, but to display them means changing the VMT to point at them.
It is possible to cheat via VMT editing, such as telling the engine to render certain materials transparent to see through walls, or make player materials render in front of everything else to see them through walls. Because of that, VMT consistency will be enforced on a server with specific pure settings.
I do not personally know how the game handles a VMT conflict if you join a pure enforced server with a customized material, so I put the warning out there in case you have problems either joining a server or things look weird in-game when you do. (If someone can direct me to a pure server, or a way to find servers with that enabled, so I can test it myself, that would be nice)
Before the steampipe conversion none of this mattered because there was a place I could put the materials that Hammer loaded but not the game, that option no longer exists.
Yes, most parts are needed but there are allways optional things hence my suggestion of splitting the mechanics. This way you allow players to design their own system while still helping them on the basics. Example is just an example of a full but basic mvm map. You should give players the option to make a 2 lane, 3 lane, single lane but splitting later on version and such. These can be very basic examples.
There also lacks a deathpit in mvm_example and a redirect zone example is missing. Things that all valve mvm maps have. And maybe its my version but engy nests also dont exist as example. Those are all optional but that doesnt mean it shouldnt be in the pack. You want to have an as complete as possible pack.
However, mvm_example is far from useless as it can help you setting up the basics faster.
What sv_pure setting are you looking for? I know of an sv_pure 2 server, the HK Central one ( 108.174.60.26:27015 ). Not sure how to find an sv_pure 1 either.
I'll decide that when I really look into the mvm setup. Depends how ambiguous the entities are.
The harsher the better. 2 should do fine, I will try it out.
- Feb 15, 2011
- 333
- 344
Surely it's not that ambiguous if you look at the heart of what is happening in an SD map, isn't it just a neutral flag and a cap point? Taking out all of the bells and whistles of australium and a big rocket, that's all the core gameplay of SD is.
As for MvM, it sounds like the best course of action would simply be to update the existing mvm_example to include things like Engi nests and the gate mechanics.
If all it is is a neutral flag with a mutual cap zone, why isn't it CTF? The CP designation covers many variations of "plain" capturing points, so CTF should be able to cover a basic one flag variant. Granted it could just be valve deciding to give it a different prefix for the heck of it but...
- Feb 15, 2011
- 333
- 344
Whether or not the single prefix CP should cover all of those variations and whether or not SD should fall under the CTF prefix is irrelevant, the question to answer is "What is SD?" and the answer to what makes up the gameplay of an SD map doesn't change in light of those ultimately superficial aspects.
We've only got one map to go on, I'll concede that is a sticking point for whether or not what we can gather from Doomsday is an accurate representation of the gamemode as a whole, but analysing what we have been given, an SD map is characterised by a neutral flag, picked up after a short setup time, and a control point that can only be captured by the flag carrier. Even the distinguishing elevator cap is a superficial addition, since ultimately, any cap in any gamemode could be doing that.
Not anymore, currently it is sv_pure 0, though I think the EU server is sv_pure 2, you'd have to check.
I think what Booj means is, (and what turbo says), does he include the elevator, and the rocket and all those bits, are those "SD" or should the user be left to add those bits on, like payload elevators, and forward spawns, because they are map specific.
I think that they are not, personally. With the elevator SD boils down to the same thing really despite the map, I think it'd be more beneficial to promote different styles.
I think that they are not, personally. With the elevator SD boils down to the same thing really despite the map, I think it'd be more beneficial to promote different styles.
Last edited: