Print

Add to Reputation:  

What do you think of this post?

I agree I disagree  
Comment:

[Kinky]

I thought i might as well just make one topic for this... rather than several for individual questions.

As some of you may know me and 3 others (2 artists and a coder) are working on a small Source mod for our final major at uni. Its called The Invaders: Source and is a team based 80's sci fi themed survival shooter. Can post up some stuff if anyone is interested...

Anyway onto todays issue.

We are looking at ways to get different artwork within the same level for the 2 different teams. I had a topic similar for this before but wasnt quite sure everyone was catching the right end of the stick.

It needs to be the same map so both teams can play against each other and shoot each other. But we need to look at every possible way to make the environment appear different to one team than the other (one is realism, the other is uber simplified, possibly somewhat like tron).

Sharp mentioned something about having triggers that are tied to a team that display new textures when in contact with that team (or something) but my PC crashed and i lost the convo... hopefully he can swing by and post that idea. Otherwise ive been looking at func_texturemorph?

Any other ideas?

[Mangley]

I've had some thoughts about this.. I think there are a number of ways it could be done.

Method 1: Having seperate material directories for each team and then through code determine which set of textures are displayed depending what team you're on.

For instance... lets say there's a wall textured with materials_A/walls/walltexture1.vtf this would be the texture that team A sees. Then you would have to have an alternate version of that texture in materials_B/walls/walltexture1.vtf and if you joined team B, the game will load materials from the materials_B directory and not materials_A.

I'm not sure how feasible this.. I'm not sure how source can handle exchanging textures like this.

Method 2: Using Source's built-in rendering features. This is a much simpler but quite limited way of doing it... you could almost definitely use the mat_fullbright 2 command to your advantage here... if you can code the game to enable this for one team that will make all surfaces the same flat texture but will retain shadow and normal-map detail. You may also want to look into using color-correction, HUD filters and other things like that. For instance the black and white effect you get on Left 4 Dead when you're about to die... I believe that uses color correction..

[Kinky]

Yea i believe thats colour correction; which, as entities, can be tied to team then an ef_nodraw pass in the code allows you to hide it from other teams.

Im not entirely sure what entities this works for, this'll be my next question.

Ideally though i need actual texture changes. But yea every solution/idea is useful.

Cheerz for the ideas man

[Mark [lodle]]

Kinky this would be very easy to do via material proxies. Basically the proxy can interact with the code and choose which skin to show the user depending on their team. Was thinking of doing something like this for a avp mod. http://developer.valvesoftware.com/wiki/Material_Proxy

Need any more info let me know.

[Kinky]

Dude that looks perfect. Leg end. Ill catch you on Steam sometime this week i hope to get some advice on writing this up. Much thanks man

[killermonkey]

I believe last time you also wanted to show different props. I said that was only achievable if you broke the server's heavy handed enforcement of an entity's model. I have since learned a lot about this stuff and can offer assistance. You could then, quite easily, change the entities model client side (dependent on team) or not show it at all since the server won't enforce it's settings.

[Kinky]

Awesome. You are indeed correct that i wanted to alter props based on team. Is this still using basically the same method you told me last time? Tying the entity to a team and then running an ef_nodraw or have you learnt all new methods?

Theres a fair few entities i need this kind of thing for and will be looking into the possiblities of. Most notably different types of lighting entities, colour correction and both static and physics props.

Also i need to know what entity ties can still be applied to keep this working as well as how parenting will effect things. But im guessing a lot of this is going to be fairly unbroken ground (at least for most people). Of course all assistance from everyone is GREATLY appreciated. =)

[kraid]

IMO an important question is: should the user be able to select/switch teams or not.
If not, you could bypass the server side entity problem by creating two builds of the same game, using the same prop names but different models.

For prop_physic and prop_dynamic it's no problem at all, for prop_static i'm not absolutly sure about the collision model. If you change these props after compiling, they might use the same CM as the prop you compiled the map with. Not sure about this, i simply never tried that.

For map textures, you can change them, too.

Original compile:


applied a grey basetexture + flat bump:


tried UnlitGeneric to disable shadowmaps:


since at this point the map is barely visible (only thing which keeps us from greyout are envmaps)
changed textures for better visibility:


disabled spec map:


reenabled Shadowmaps using LightmappedGeneric:


Everything done without recompiling or changing anything beside the texture.

It might be a good idea to either use a envmap texture instead of env_cubemap reflection or disable them completly for the abstract version.

[Kinky]

We kind of need team switch working as we need auto balance to keep the game from getting ridiculous (as its biased towards the stylised side to try to ween in new player audiences) so two game versions isnt really an option.

Having a look at your visual examples..

disabled spec map:

THIS, is what we need for the stylised team. Is this going to be possible via the material proxy method Lodle mentioned? From looking through the documentation for it, it would appear so. Although those are just about the most confuisng VMTs ive ever seen

If we can get that affect through material proxys and KMs system for hiding/replacing entities by tieing them to a team thing working that is absolutely perfect. It only really needs to work on color_correction_volume, env_cubemaps, prop_physics, prop_statics (hopefully this will work, i dont need different collision models as its only a need to alter the textures on props to match the brushwork) and as many types of lighting and lightmap entity as physically possible.

Cheerz for all the help guys. I will be calling on your expertise over the coming weeks. Hopefully that wont be too much hassle for y'all

[killermonkey]

You can't change static props after compile, they are literally baked into the map.

[Kinky]

Alright. Bit of an arse but theres workarounds for that. Anymore troublesome entities i should be aware of?

[kraid]

You can't change static props after compile, they are literally baked into the map.

Maybe they don't need to be changed in shape & size, but can have an alternative texture applied.
Otherwise you'd have to use only physic & dynamic props.

[Kinky]

Will material proxys work on entities as wel? (didnt even consider it, slaps self)

[Mangley]

Yes I believe they do.

[killermonkey]

Will material proxys work on entities as wel? (didnt even consider it, slaps self)

Of course they do, but the material has to have the $model 1 flag