Forum posts

I see. Only noticed it having changed my architecture inside to stop VIS having to draw so much - the outside area is quite vast so this makes a lot of sense, thanks.

I'd somewhat decided somewhere between 128 and 512 was optimal, depending which areas I wanted to have the lowest wpoly but it's clear to see why now you've said it.

So I'm really at the point where I've optimised my map a load and trying to eek the last few wpolys out of each area.

Anyway, I saw the node size 64 suggestion around this forum and while it reduces the wpoly count in most areas of the map on the outside of my base (looking in) & at the back of a big flag-room the wpoly count is actually higher than 512 or 1024 compiles. It's only a difference of ~10% but where these are my highest wpoly counts (of about 1,100-1,200) in my map I don't really want them to go up any higher.

So my query: why on Earth would a compile with -nodesize 64 give a a higher wpoly in some areas? Seems totally counter-intuitive.

Thanks again,
Jord

Looks like anything over 1000 wpoly in TFC causes problems in high-spam situations. Guess I got some work to do, and the non-fun deleting brush kind.

Ah second full map, I guess I wasn't clear! I'm afraid my RMF directory is littered with rather silly little pointless maps as well, by full I guess I meant 'of a size to be played like a real map'.

No super-genious hammer skills I'm afraid.

Just for the record, although I haven't posted here much I wouldn't have been able to do most of my entity work without this site. So thanks for the tuts guys.

So at the risk of getting in trouble by cross-linking to the map on snarkpit I'm linking to there because the files and screenshots already exist. Anyway, I have been working on this map considerably over the last few weeks but in reality the project was started a long, long time ago and never really got anywhere. I picked it up recently at pretty much newb level but have re-learnt a lot of stuff and have been over most areas of the map a few times improving on my earlier work. However, try to bear in mind this is only my second full map ever, and first in nearly 7 years.

Map info and download at http://www.snarkpit.net/index.php?s=maps&map=3458

ImagesIt seems to have gone down fairly well in the playtesting thus far but was wondering on a few opinions from mappers rather than players over what I should be improving and what really needs fixing before I eventually get round to making this a final release and starting on something new.

The cliffs outside are still my major issue but I had a few wpoly issues recently and so want to test this version runs smoothly before I go nuts with VM again.

A few notes about Team Fortress Classic. It's gameplay is very fast with grenades allowing travel over long distances (quickly) and ramps to be slid or 'bounced' off of. This is why there's so much rampy madness and why stairs or a more sensible, realistic approach to architecture is missing in a fair few places.

Anyway, I don't know if anyone will actually get round to looking at it but comments are appreciated (both the good and the bad so long as the latter remains useful).

Cheers,
J

So I'm on a bit of an optimisation course at the moment with the TFC map I've been working on for a while - anything above 2000 wpoly seems to be an issue due to the explosive nature of the game, so I'm trying to cut back a bit. I'm currently testing the effect of nodesizes on the map but I'm also curious as to what -subdivide does? The ZHLT page hints at it possibly decreasing r_speeds but with potential problems..

Also, with covering unseen faces with Null, am I right in thinking the main gain from this is it removes intersecting faces that would otherwise cause csg to cut up a brush because most of the faces the player can't see are removed in the compile anyway? Would making these bits into func_wall have the same effect so long as they weren't important VIS blockers?

And while I'm here I may as well ask about the HLRAD -maxintensity number to save a lot of trial an effort.. What kind of value would I be looking at here, 100s (like standard light), 1000s (like texlights)?

Cheers

With toggle on, -1 delay and a second MM to initiate door closing it all works perfectly and would seem to be the easiest way to me.

If you set the damage too high - in TFC at least - then the player doesn't die and only loses armour.

Excellent thanks, I'll give func_train a try at some point shortly.

Sorry, I have no idea what Spirit is. If the clip stops then the doorway will be effectively open anyway? The doorway must close so other players cannot get through.

I guess I could theoretically create a load of trigger hurts timed to appear just under the door, but that seems a little excessively difficult.

I have it set to do 1000 damage already, and it kills the player (me) no problem. The issue is the door 'bounces' off my head as well as killing me and as such remains open for another cycle.

Hi there, firstly I'd like to say how great it is to stumble across a goldsource/source mappers haven. Some of the tutorials & forum posts have been quite enlightening - especially thankful for the new vhlt tools as I was still using zoners!

Initially this was going to be a thread asking for help creating a security system for a TFC map (akin to the one on Schtop) but thanks to the MM tutorials I've been able to work most of the things out except:

I have a door that opens when security is deactivated and I want it to close when sec comes back up, however, if a player stands in the way as it closes the door will spring back open. I want it to crush the player & keep closing , I can't imagine it being difficult to accomplish so I'm wondering if I've missed something obvious.

Also, I wonder how people generally go about trigger text messages to be displayed to the players. I'm currently using the multi-manager to trigger an info_tfgoal - but I guess this entity doesn't exist outside TFC?

Cheers,
Jord.