Commented 20 years ago2004-08-20 03:22:08 UTC
in vault item: tournamentComment #3463
"Textures- I would do well as half of a team of two mappers... one who builds and one who textures. I hate texturing. I would build..."
Heh, true... I'm texturing now and then but I feel it's not really my thing. It takes lots of time for just a few textures, and often I'm not satisfied with them. Maybe it takes just more time to learn than mapping did...
You're right about the hint brushes, only that side is used. Beware though with using them, often they have no impact, only cases were otherwise too much would be rendered unnecessary. An important thing to know is that compile times can increase exponentionally, so only use where necessary. Read this: http://www.gamedesign.net/book/view/266 Very helpfull, and although for Quake, the principles are the same.
I had some performance issues on this map now and then, it ran on 40 fps (system specs: AMD 1800+, 384 MB RAM, GeForce FX5600) at some spots. It's a layout issue here. I'd suggest drawing out a layout first, think about what area's have line of sight to each other, then test it. After the rough layout is made you know what area's allow for more detail as they have low r_speeds, and what area's are best left less detailed as they already have higher r_speeds.
Another thing I noticed when I looked trough it again was texture stretching. Try to keep the scales equal, preferrably 1x1, this makes them look better. Oh, and while you do pay attention to detail, several surfaces were flat and boring, with nothing to break up the monotome texturing. Something I often fail on too, but it could be improved on.
Heh, and I like to give some beta-comments. Nice you like it. After all, I need betatesters too now and then and it's indeed a powerfull way to improve.
Commented 20 years ago2004-08-19 03:29:56 UTC
in vault item: tournamentComment #3441
I have now taken a look at your .rmf and maybe I can help you a bit:
1. The first thing I saw was that your brushes didn't align to the rougher grid-sizes (16 units for example). To me it seems you either use a very small grid size or you don't have Snap to Grid (Shift + W) on. I would really recommend this as it makes maintaining the map easier as well as preventing leaks. For detail brushes you would then switch to a smaller grid size (using the [ and ] keys).
2. As you may have mentioned somewhere, you covered the outside of the map with the 'null' texture. Next time, don't do that, the compile tools will cut away those faces anyway, so it's a waste of time.
3. Lots of face-consuming details, you should cut on them. Those cilinders could do with less faces, and those stacks of wooden plates could be made one cube, with some good texture usage you could simulate a stack.
4. The layout allows the player to see too much of the map at once. Hint brushes aren't going to avoid that here anymore. Maybe a radical change in the layout is the only way here...
As in reaction to your points:
1. Eye candy doesn't cope well with open layouts. It's either one or the other, or a trade-off between both.
2. You succeeded in that.
3. The textures in both area are consistent although I'm not too sure about those computer textures in the industrial site. Overall, texture usage isn't outstanding though. They make the map look so unrealistic, especially the industrial area. The office is done better, the textures 'work' well with the architecture.
4. The 'hint' brushes seem te be placed correct, but they do not align up well. See the first point of this post. It may not be absolutely necessary but I saw several thin faces in wireframe mode (type 'gl_wireframe 1' in the console) wich I think could be avoided.
5. Wouldn't it be better to test such things in small test maps? Compiles a lot faster and doesn't mess up the map you're working on... just my thoughts on it...
6. I understand you've learned a lot. Your map hasn't failed. Although you're getting sick of it, you've learned a lot of it, and so it has served a good purpose. Reminds me of the several half-finished HLDM maps I made... put a lot of work in them but never finished them as they just didn't play well.
7. Try to keep that other 5% below 1000 then. A note: area's that often see combat should have a more thight w_poly limit than area's that barely have combat in them. Not only the player models have impact on the fps but also the combat calculations, although I'm not sure how hard this impact really is.
8. The kitchen... I'd say run some playtests and see if it worked the way you planned it, or otherwise. Then decide if it's enhancing the gameplay or not.
Well, I hope this is helpfull... since that's a lot of text...
Commented 20 years ago2004-08-18 04:32:15 UTC
in vault item: tournamentComment #3397
I've only played the map now, didn't look at the rmf.
Well, the first thing that comes to mind is that the nature of the map tends more towards singleplayer than multiplayer. Highly-detailed, over-detailed at several area's (resulting in bad performance). Connectivity seems ok at most places but some area's would lend themselves better for SP, like some small dead-ends (the kitchen for example. You're not going to chrouch-jump over that obstacle to get that gun, only to find yourself being trapped in there by some grenade-launching player). Texturing let you down, especially in the industrial area. Lighting isn't really special but not bad either. Try some variation with dark spots maybe. The office-part doesn't seem to work together with the industrial part, they don't fit together the way they do now. Maybe create an outside part and have them in two different buildings? Another thing is the interactivity. It's nice and fun but I feel it's not practical here. Look at crossfire, that air raid affected the gameplay in a nice way. Here, your tricks seem to distract from gameplay. At a certain moment I thought those wheels would be turnable too, only to find them being just details... Also, doors that open very slowly break down the pace of the game. Players want action, and want it quick. Such doors are a pain when you're fraggin'... unless they're well implemented, like as an access to a super-weapon or such. Performance in this map was a bit low in some area's and I don't see hint brushes taking that away. Cut down on details, you need to. Another thing: there was a door, next to the red bath, that was especially hard to navigate trough. Something that needs to be fixed. And the music, I liked it. Too bad it's only heard a very small part of the map... I'd say you should make it a background music for the map or throw it out, as it adds quite a lot to the downloads filesize...
As for the models, they showed up just fine by me, maybe you don't have those transparancy dll's?
(Oh, and you've included all files needed to play, so that's no problem. Yeah, I've seen your first description... ;))
Commented 20 years ago2004-08-18 04:00:03 UTC
in vault item: cs_test32Comment #3396
Again, no de_airstip.wad. Please include that one in your map or zip file, or tell us that it's for CS 1.6. A bit more info is really welcome now and then, you know.
Commented 20 years ago2004-08-05 07:34:12 UTC
in vault item: The castleComment #3165
Another note: put on a screenshot if you want some attention to your map. Most people will ignore maps without screenshots. It's a bad first impression, you know...
Commented 20 years ago2004-08-05 07:33:21 UTC
in vault item: The castleComment #3164
But you've actually got elevators in your first map. Good. However, this map isn't 'finished' at all. So, let's give some advice...
First, the map is full-bright. Wich means, you have a leak, OR you haven't placed light entities in the map, OR you haven't run RAD. Maps without lighting are like Wolfenstein maps. Ugly. Second, since I was able to get 'drown' in the sky, I think you're using the old compile tools. Search Google for ZHLT, the latest compile tools.
Now onto the map itself. Crowbars are already equipped at the start of a deathmatch, so there's no need to place those in a deathmatch level. Also, monsters standard don't show up in deathmatch games, so you can leave those rats out too.
Commented 20 years ago2004-08-02 08:45:18 UTC
in vault item: Rocket Destruction2Comment #3118
As for the scripts top-side, the leader actually comes out and makes his signal. It takes quite a while before the others arrive, though. I guess it's just a bad timing issue, or because the others can't reach their scripted_sequence because someone else is still in their way...
Commented 20 years ago2004-08-02 08:43:25 UTC
in vault item: Rocket Destruction2Comment #3117
The hallways are small, wich can make your goals pretty difficult to achieve, as each grunt needs some space to move... So that's a first thing to mind.
The first three grunts should have the same squad-name, so the others will come when the leader sees you. Also place info_nodes so the grunts know where to move and how to find their way to attack you.
The scripts topside are a bit strange. Often, I became stuck in the func_wall_toggle. Place it a bit further away so players can't get stuck in it anymore. Also, set it's Render Amount to 0, as when you shoot it you see white decals, seemingly in mid-air, wich looks strange off-course. Also, suddenly locking the player in invisible walls isn't a very neat way to let him get ambushed. It feels so 'fake'...
As for the lighting, you should make those small circular lamps entities so they don't split up the ceiling surfaces, wich takes away that strange lighting issue you probably meant...
Commented 20 years ago2004-07-31 10:58:37 UTC
in vault item: LaB101 - Update 1.4Comment #3088
The moominade vending machine has no buttons...
Aside from that, nice additions.
Though r_speeds are a bit high. Probably because you've poured a lot of brushes into one entity, so that it's stretched over multiple leafs, so the engine renders the entity nearly always. I'd suggest using some more and smaller entities.
Commented 20 years ago2004-07-31 10:50:05 UTC
in vault item: Detailing HL TexturesComment #3087
Good one.
Several textures in Half-Life were designed to use across multiple brushes, as can be seen in Half-Life itself. Strangely enough, this is often forgotten about.
Commented 20 years ago2004-07-30 03:50:15 UTC
in vault item: Loser won't move!!!Comment #3058
The first target of the Gman is 1, while the door is also called 1, this could give problems. However, since the Gman can't reach the second path_corner, he'll just stop. He won't try to reach that point once he can do, this path_corner thing just doesn't work anymore. So, instead of doing it this way, you'll need to use a scripted_sequence, with Move to Position set to Walk. Leave the animation options blank as it's only about the moving.
Commented 20 years ago2004-07-30 03:40:45 UTC
in vault item: topside_warehouse_room1Comment #3057
Several entities can be used here. Func_pendulum for example, wich swings back and forth. A func_rotating as you're using right now will rotate around a certain axis (the axis can be defined in it's flags) so these might be usefull here too.
As for fully customisable beams, I don't think that's really possible with brush-based entities. You may want to use an env_beam that uses a func_train as ending point, wich can move around, so that would allow much more customizable patterns. A beam can also be set to fade at one end wich would look better here.
Commented 20 years ago2004-07-29 04:59:35 UTC
in vault item: LaB101 - Update 1.4Comment #3032
I liked the architecture and details. Really nice. Lighting is good too.
However, with gl_wireframe 2 on, I saw a lot of entities still showing up, making me wonder about your VIS-process. You may want to keep entities not too large, otherwise they can spread out over several leafs, making it hard for the engine to determine whether they're visible or not. Often, they are then always rendered, even when they're not in visible leafs...
Commented 20 years ago2004-07-28 07:43:06 UTC
in vault item: mls_darkarenaComment #3000
Things shouldn't be outside the grid limit. To solve it without getting your textures all bad aligned, tick the Texture Lock button (in one of the top bars), so it's on, then select all of your brushes and move them to somewhere in the middle of the grid. As for the rotated walls, when you press Shift while rotating you rotate in steps of 15 degrees. Rotating things 90 degrees is the most safe. For slightly rotated walls, it's best to Translate them or use the Vertex Manipulation tool. But that one requires some experience, as it can give quite some errors when you don't truly understand it...
As for the Texture Lump error, I have never heard about that before. Strange...
Commented 20 years ago2004-07-27 15:37:11 UTC
in vault item: mls_darkarenaComment #2963
A part of the map is outside the grid, move it to within the grid limitations. Some buildings are a bit rotated, this may cause some anomalies (since vertices are set to the nearest grid point, while after rotating the nearly never match up exactly, giving slightly different faces than in the editor. Sometimes this causes leaks too. So, best to keep everything 90 or 45 degree angled, or use the Translate tool instead of the Rotate tool). The map has no sky brushes around it, rather a black textured box. A sky might be better for the mood... Also, the fences around could better be made func_walls, with Render Mode: Solid, and Render Amount: 255, so the bleu parts become invisible. The overall layout is quite open, this may give high r_speeds, thus lower performance. 800-900 should be considered a good maximum for multiplayer levels, so lower-end systems can also handle the map.
As for the Texture Lump problem, I don't know. Since I don't have all the .wad files you used (and I don't know what files you used), I can't compile. However, I felt it might be helpfull to give you some tips. They might not solve the problems but it can be helpfull later on...
Commented 20 years ago2004-07-26 09:01:07 UTC
in vault item: SandyfallsComment #2900
And another note: the scripting isn't completely failsafe. For example, when the player rushes towards the zombie carrying the barney, the door closes before the zombie has gone through, so he moves through the door. Looks kinda odd. Also, the zombie breaking the door can't be killed when he does so, he dies only after his script. You may want to block the player from getting to them before their script ends.
Commented 20 years ago2004-07-26 08:56:22 UTC
in vault item: SandyfallsComment #2899
Looks nice, good scripting. You really show potential. A bit too much scripting for such a small level, but it's sure a good start.
Just a tip... brushes that touch other brushes split up faces, type gl_wireframe 1 in the console (when you run in OpenGL mode, in software mode you can use r_drawflat 1) and see what I mean. This happens with the light cables for example. You should turn these cables into func_walls so they don't split up faces. Your r_speeds are good, so it's not necessary, but it just leaves you with a bit more room for detail when you do, polygon budgetwise spoken. Also, this func_walling of small brushes will speed up the VIS process.
Commented 20 years ago2004-07-26 06:29:38 UTC
in vault item: AbandonedComment #2891
Yes, this is worth more than just 3 stars. Again, I think we have a too rough rating system. 5 stars would be a bit too high but 4 would be too low. Well, anyway, concerning the goal of this map off course.
Looks good, the machine looks indeed as if it belongs there and has a purpose, probably some tin-can packaging or such. The athmosphere could've been a bit stronger with some more sounds, and those spark sounds get a bit annoying. However, the map looks decent, I like how you used the space, it's all pretty close on each other and nicely connected. The darnkness in the map however makes the detail hard to see, so a bit more (subtle) lighting would've done your map much good.
Heh, and I like that comment in your readme... Thanks!
Commented 20 years ago2004-07-02 02:28:16 UTC
in vault item: underground_1Comment #2571
Just do a testcompile. As for complexity, no, it's actually a fairly simple map. But it's huge too... I'd say a bit too huge but that's up to you, depends on what you want the map to be off course.
Just a tip: make those lamps entities, e.g. func_wall. Good for the VIS process (those lamps don't really block visibility to other parts of the map, so why let them contribute to the VIS compile time? Nah, you'll learn about that later on), and also avoids face splitting. Not that that's really something to worry about the way you placed them, but when a brush touches another brush, the compile tools split that surface up into 4 part to avoid convex faces. When one of the brushes is an entity, they don't split up. Experiment a bit with that, and use 'gl_wireframe 1' in the console to see the effects.
Commented 20 years ago2004-07-01 08:30:59 UTC
in vault item: Weird DreamsComment #2562
I've seen it, the button. And I've well, won, so to say. Sadly nothing happened then... You should let the level at least end by fading it out, a text message like 'The End' or such thing. Would be better.
Commented 20 years ago2004-06-30 15:45:45 UTC
in vault item: Weird DreamsComment #2540
While architecture and texture usage aren't so special, the mood and overall feeling is very good. Indeed a nightmare, but a winnable nightmare. I liked it...
Commented 20 years ago2004-06-29 16:46:53 UTC
in vault item: ZeromancerComment #2521
Well, you want us to comment so it's up to you to make it easy for us. A recompile without that .wad file wouldn't be a bad move... as for versions, it may be a good habit of saving under different names (mapname_01 and so on).
Anyway, on to the map. The lighting was the first thing that caught my attention. I don't really like it. The different colors on those sections make it look so unnatural. Especially the yellow lights. Texture usage is good except for the groun on the screenshot, that's a specific ceiling texture and doesn't look well on a floor. Architecture is decent but for a storage area it looks too curved. Some straight supporting beams and such would make it look better. The overall map has a strange connection of styles, of area's. A storage facility and a sort of reception area? Doesn't really fit together in my opinion.
Overall, it shows potential, you do pay attention on details now and then, but the map needs some more coherent style.
Commented 20 years ago2004-06-29 16:31:30 UTC
in vault item: SiegeComment #2519
How you can make them better? Look at official and popular maps. This map is just bad at architecture and lighting. The idea is worth a try but that's the only thing I liked here. Just experiment somewhat first, try out maps (without releasing them please), after a while you'll get a hang of it.
And remember... it's better to come with a few stunning maps than with an overload of crap things. Not all maps have to be released, and it's not advisable to be too quick with a release.
Commented 20 years ago2004-06-29 06:59:33 UTC
in vault item: High HighComment #2516
Nice map? No. Bad texture usage, too basic architecture, not really stunning weapon placement, strange connectivity... the map lacks a lot. Probably one of your first maps, so I'd say continue mapping, learn what makes maps good and what breaks them (playing around official and popular custom DM levels can help greatly), both on gameplay and graphics, then release another map. There's room for improvement here.
Commented 20 years ago2004-06-23 09:37:34 UTC
in vault item: de_dust_wireplayComment #2453
Reminds me of de_dust... although your map has a less coherent style it looks good in most area's. Some nice architectural details (the fountain) but also some not-so convinving things (the long pillar before bombspot A). Textures are nice although I think the sand color doesn't really fit. Anyways, looks quite well besides some small things like wrongly aligned brushes (the fountain basement for example). All in all, very promising...
Too bad I don't play CS so I can't say a lot about the gameplay or layout, besides that I think the layout is decent.
Commented 20 years ago2004-06-22 03:10:24 UTC
in vault item: ka_sinkholeComment #2439
Looks very cool. I like the very natural feel of it and the rocks shape fits well. Textures suit the map and so does the lighting. And I like how you placed the grenade...
The disadvantage of such terrain however is that movement is blocked now and then. Too bad as it's a good-looking map. Oh, and one other thing: when you place a lot of masked layers (in this case the leafs of the trees) behind each other, fps halves (depending on the amount of layers that overlap each other).
I've just taken a look at your previous maps and wow, you really improve...
Commented 20 years ago2004-06-20 11:09:27 UTC
in vault item: de_clifferyComment #2420
It seems you haven't run vis... also, there was some face-splitting in the map. And it looks like you used lights outside instead of a light_environment. So far for the technical parts...
The lighting looks reasonable, texture usage and alignment isn't very well done, and the map is quite small and allows very little variety in paths to go. I'd say, take a look at some popular CS maps and you'll be able to improve a lot. Keep it up!
Commented 20 years ago2004-06-18 03:41:09 UTC
in vault item: Temperate BetaComment #2390
Oh, and the missing rock faces... it wasn't a rock, it was the base of the cut-down tree...
Another thing I just thought of: the explosion radius is pretty large but the explosions themselves are fairly small. You might change them to bigger ones for a more convincing look.
Commented 20 years ago2004-06-18 02:50:41 UTC
in vault item: Temperate BetaComment #2389
The grass, I see you're right. Sorry, my fault! Mhh, I also noticed the bushes have some strange horizontal lines above them, this is due to the texture placement. Move up the texture a pixel or two, or make the func_illusionary a few units lower.
As for glocking paradise, it's true that after a while you'll have to enter the camp in order to get ammo and use the shotgun. Yet the first 6 or 7 soldiers I was able to glock pretty well. Personally I think it's not a fun combat tactique. All you do is kill dumb enemy's from a distance without real challenge. Perhaps that the soldiers on the towers could warn those in the camp as now they look very dumb (oh, half of the camp is dead... let's just keep standing here.. ;)). Now it's just precise shooting and caring for ammo, it could be made more challenging and action-packed, maybe have the player sneak into the base with a shotgun only, so he has to go close range and use silent tactics. Also turn down the shotgun damage a bit, as being killed instantly isn't real fun (for me). Unless you want it to be more realistic, but then at least provide some kevlar...
Trees and rocks, I'd say modeling is the way to go. The cliffs and such, there are some tutorials covering different techniques of creating them, search the Snarkpit for some nice ones.
Heh, true... I'm texturing now and then but I feel it's not really my thing. It takes lots of time for just a few textures, and often I'm not satisfied with them. Maybe it takes just more time to learn than mapping did...
You're right about the hint brushes, only that side is used. Beware though with using them, often they have no impact, only cases were otherwise too much would be rendered unnecessary. An important thing to know is that compile times can increase exponentionally, so only use where necessary. Read this:
http://www.gamedesign.net/book/view/266
Very helpfull, and although for Quake, the principles are the same.
I had some performance issues on this map now and then, it ran on 40 fps (system specs: AMD 1800+, 384 MB RAM, GeForce FX5600) at some spots.
It's a layout issue here. I'd suggest drawing out a layout first, think about what area's have line of sight to each other, then test it. After the rough layout is made you know what area's allow for more detail as they have low r_speeds, and what area's are best left less detailed as they already have higher r_speeds.
Another thing I noticed when I looked trough it again was texture stretching. Try to keep the scales equal, preferrably 1x1, this makes them look better.
Oh, and while you do pay attention to detail, several surfaces were flat and boring, with nothing to break up the monotome texturing. Something I often fail on too, but it could be improved on.
Heh, and I like to give some beta-comments. Nice you like it. After all, I need betatesters too now and then and it's indeed a powerfull way to improve.
1. The first thing I saw was that your brushes didn't align to the rougher grid-sizes (16 units for example). To me it seems you either use a very small grid size or you don't have Snap to Grid (Shift + W) on. I would really recommend this as it makes maintaining the map easier as well as preventing leaks. For detail brushes you would then switch to a smaller grid size (using the [ and ] keys).
2. As you may have mentioned somewhere, you covered the outside of the map with the 'null' texture. Next time, don't do that, the compile tools will cut away those faces anyway, so it's a waste of time.
3. Lots of face-consuming details, you should cut on them. Those cilinders could do with less faces, and those stacks of wooden plates could be made one cube, with some good texture usage you could simulate a stack.
4. The layout allows the player to see too much of the map at once. Hint brushes aren't going to avoid that here anymore. Maybe a radical change in the layout is the only way here...
As in reaction to your points:
1. Eye candy doesn't cope well with open layouts. It's either one or the other, or a trade-off between both.
2. You succeeded in that.
3. The textures in both area are consistent although I'm not too sure about those computer textures in the industrial site. Overall, texture usage isn't outstanding though. They make the map look so unrealistic, especially the industrial area. The office is done better, the textures 'work' well with the architecture.
4. The 'hint' brushes seem te be placed correct, but they do not align up well. See the first point of this post. It may not be absolutely necessary but I saw several thin faces in wireframe mode (type 'gl_wireframe 1' in the console) wich I think could be avoided.
5. Wouldn't it be better to test such things in small test maps? Compiles a lot faster and doesn't mess up the map you're working on... just my thoughts on it...
6. I understand you've learned a lot. Your map hasn't failed. Although you're getting sick of it, you've learned a lot of it, and so it has served a good purpose. Reminds me of the several half-finished HLDM maps I made... put a lot of work in them but never finished them as they just didn't play well.
7. Try to keep that other 5% below 1000 then. A note: area's that often see combat should have a more thight w_poly limit than area's that barely have combat in them. Not only the player models have impact on the fps but also the combat calculations, although I'm not sure how hard this impact really is.
8. The kitchen... I'd say run some playtests and see if it worked the way you planned it, or otherwise. Then decide if it's enhancing the gameplay or not.
Well, I hope this is helpfull... since that's a lot of text...
Well, the first thing that comes to mind is that the nature of the map tends more towards singleplayer than multiplayer. Highly-detailed, over-detailed at several area's (resulting in bad performance). Connectivity seems ok at most places but some area's would lend themselves better for SP, like some small dead-ends (the kitchen for example. You're not going to chrouch-jump over that obstacle to get that gun, only to find yourself being trapped in there by some grenade-launching player).
Texturing let you down, especially in the industrial area. Lighting isn't really special but not bad either. Try some variation with dark spots maybe.
The office-part doesn't seem to work together with the industrial part, they don't fit together the way they do now. Maybe create an outside part and have them in two different buildings?
Another thing is the interactivity. It's nice and fun but I feel it's not practical here. Look at crossfire, that air raid affected the gameplay in a nice way. Here, your tricks seem to distract from gameplay. At a certain moment I thought those wheels would be turnable too, only to find them being just details... Also, doors that open very slowly break down the pace of the game. Players want action, and want it quick. Such doors are a pain when you're fraggin'... unless they're well implemented, like as an access to a super-weapon or such.
Performance in this map was a bit low in some area's and I don't see hint brushes taking that away. Cut down on details, you need to.
Another thing: there was a door, next to the red bath, that was especially hard to navigate trough. Something that needs to be fixed.
And the music, I liked it. Too bad it's only heard a very small part of the map... I'd say you should make it a background music for the map or throw it out, as it adds quite a lot to the downloads filesize...
As for the models, they showed up just fine by me, maybe you don't have those transparancy dll's?
(Oh, and you've included all files needed to play, so that's no problem. Yeah, I've seen your first description... ;))
Know that you're up against Dutch mappers...
Good luck anyway!
The scripted_sequence of the grunt torching the door, of course...
First, the map is full-bright. Wich means, you have a leak, OR you haven't placed light entities in the map, OR you haven't run RAD. Maps without lighting are like Wolfenstein maps. Ugly.
Second, since I was able to get 'drown' in the sky, I think you're using the old compile tools. Search Google for ZHLT, the latest compile tools.
Now onto the map itself. Crowbars are already equipped at the start of a deathmatch, so there's no need to place those in a deathmatch level. Also, monsters standard don't show up in deathmatch games, so you can leave those rats out too.
That's enough for now, I guess... Good luck!
http://members.lycos.nl/michielb55/MuzzleFlash/tma_room.zip
Still, you should do something about the proportions of your room, Muzzle...
After all, you're the creator of this map...
This woman is called Alizee, she's a Corsican girl and I must say, she sings pretty good.
Wich still isn't an excuse to use posters of her as wallpaper... @ Muzzle
http://collective.valve-erc.com/index.php?doc=1046839948-87698400
The first three grunts should have the same squad-name, so the others will come when the leader sees you. Also place info_nodes so the grunts know where to move and how to find their way to attack you.
The scripts topside are a bit strange. Often, I became stuck in the func_wall_toggle. Place it a bit further away so players can't get stuck in it anymore. Also, set it's Render Amount to 0, as when you shoot it you see white decals, seemingly in mid-air, wich looks strange off-course. Also, suddenly locking the player in invisible walls isn't a very neat way to let him get ambushed. It feels so 'fake'...
As for the lighting, you should make those small circular lamps entities so they don't split up the ceiling surfaces, wich takes away that strange lighting issue you probably meant...
Aside from that, nice additions.
Though r_speeds are a bit high. Probably because you've poured a lot of brushes into one entity, so that it's stretched over multiple leafs, so the engine renders the entity nearly always. I'd suggest using some more and smaller entities.
Several textures in Half-Life were designed to use across multiple brushes, as can be seen in Half-Life itself. Strangely enough, this is often forgotten about.
So, good to point it out, ZombieLoffe.
However, since the Gman can't reach the second path_corner, he'll just stop. He won't try to reach that point once he can do, this path_corner thing just doesn't work anymore.
So, instead of doing it this way, you'll need to use a scripted_sequence, with Move to Position set to Walk. Leave the animation options blank as it's only about the moving.
As for fully customisable beams, I don't think that's really possible with brush-based entities. You may want to use an env_beam that uses a func_train as ending point, wich can move around, so that would allow much more customizable patterns. A beam can also be set to fade at one end wich would look better here.
Good luck!
However, with gl_wireframe 2 on, I saw a lot of entities still showing up, making me wonder about your VIS-process. You may want to keep entities not too large, otherwise they can spread out over several leafs, making it hard for the engine to determine whether they're visible or not. Often, they are then always rendered, even when they're not in visible leafs...
As for the rotated walls, when you press Shift while rotating you rotate in steps of 15 degrees. Rotating things 90 degrees is the most safe. For slightly rotated walls, it's best to Translate them or use the Vertex Manipulation tool. But that one requires some experience, as it can give quite some errors when you don't truly understand it...
As for the Texture Lump error, I have never heard about that before. Strange...
Some buildings are a bit rotated, this may cause some anomalies (since vertices are set to the nearest grid point, while after rotating the nearly never match up exactly, giving slightly different faces than in the editor. Sometimes this causes leaks too. So, best to keep everything 90 or 45 degree angled, or use the Translate tool instead of the Rotate tool).
The map has no sky brushes around it, rather a black textured box. A sky might be better for the mood...
Also, the fences around could better be made func_walls, with Render Mode: Solid, and Render Amount: 255, so the bleu parts become invisible.
The overall layout is quite open, this may give high r_speeds, thus lower performance. 800-900 should be considered a good maximum for multiplayer levels, so lower-end systems can also handle the map.
As for the Texture Lump problem, I don't know. Since I don't have all the .wad files you used (and I don't know what files you used), I can't compile. However, I felt it might be helpfull to give you some tips. They might not solve the problems but it can be helpfull later on...
Just a tip... brushes that touch other brushes split up faces, type gl_wireframe 1 in the console (when you run in OpenGL mode, in software mode you can use r_drawflat 1) and see what I mean. This happens with the light cables for example. You should turn these cables into func_walls so they don't split up faces.
Your r_speeds are good, so it's not necessary, but it just leaves you with a bit more room for detail when you do, polygon budgetwise spoken. Also, this func_walling of small brushes will speed up the VIS process.
Looks good, the machine looks indeed as if it belongs there and has a purpose, probably some tin-can packaging or such. The athmosphere could've been a bit stronger with some more sounds, and those spark sounds get a bit annoying. However, the map looks decent, I like how you used the space, it's all pretty close on each other and nicely connected. The darnkness in the map however makes the detail hard to see, so a bit more (subtle) lighting would've done your map much good.
Heh, and I like that comment in your readme... Thanks!
hefsys, I also see the map is full-bright on the screenshot... don't you run RHLAD? Or do you have leaks? Maps really need rad for proper lighting...
Just noclip around in HL levels, you'll understand how it works.
Just a tip: make those lamps entities, e.g. func_wall. Good for the VIS process (those lamps don't really block visibility to other parts of the map, so why let them contribute to the VIS compile time? Nah, you'll learn about that later on), and also avoids face splitting. Not that that's really something to worry about the way you placed them, but when a brush touches another brush, the compile tools split that surface up into 4 part to avoid convex faces. When one of the brushes is an entity, they don't split up. Experiment a bit with that, and use 'gl_wireframe 1' in the console to see the effects.
Anyway, on to the map. The lighting was the first thing that caught my attention. I don't really like it. The different colors on those sections make it look so unnatural. Especially the yellow lights.
Texture usage is good except for the groun on the screenshot, that's a specific ceiling texture and doesn't look well on a floor.
Architecture is decent but for a storage area it looks too curved. Some straight supporting beams and such would make it look better.
The overall map has a strange connection of styles, of area's. A storage facility and a sort of reception area? Doesn't really fit together in my opinion.
Overall, it shows potential, you do pay attention on details now and then, but the map needs some more coherent style.
And remember... it's better to come with a few stunning maps than with an overload of crap things. Not all maps have to be released, and it's not advisable to be too quick with a release.
Too bad I don't play CS so I can't say a lot about the gameplay or layout, besides that I think the layout is decent.
The disadvantage of such terrain however is that movement is blocked now and then. Too bad as it's a good-looking map. Oh, and one other thing: when you place a lot of masked layers (in this case the leafs of the trees) behind each other, fps halves (depending on the amount of layers that overlap each other).
I've just taken a look at your previous maps and wow, you really improve...
As for the map, judging from the screenshot I see it's total-bright... You'd better fix that before releasing a map.
The lighting looks reasonable, texture usage and alignment isn't very well done, and the map is quite small and allows very little variety in paths to go. I'd say, take a look at some popular CS maps and you'll be able to improve a lot. Keep it up!
Ask it on the forum, then I'll answer, this ain't the place for things like that.
Another thing I just thought of: the explosion radius is pretty large but the explosions themselves are fairly small. You might change them to bigger ones for a more convincing look.
These cars are pretty good made bytheway...
Mhh, I also noticed the bushes have some strange horizontal lines above them, this is due to the texture placement. Move up the texture a pixel or two, or make the func_illusionary a few units lower.
As for glocking paradise, it's true that after a while you'll have to enter the camp in order to get ammo and use the shotgun. Yet the first 6 or 7 soldiers I was able to glock pretty well. Personally I think it's not a fun combat tactique. All you do is kill dumb enemy's from a distance without real challenge. Perhaps that the soldiers on the towers could warn those in the camp as now they look very dumb (oh, half of the camp is dead... let's just keep standing here.. ;)). Now it's just precise shooting and caring for ammo, it could be made more challenging and action-packed, maybe have the player sneak into the base with a shotgun only, so he has to go close range and use silent tactics. Also turn down the shotgun damage a bit, as being killed instantly isn't real fun (for me). Unless you want it to be more realistic, but then at least provide some kevlar...
Trees and rocks, I'd say modeling is the way to go. The cliffs and such, there are some tutorials covering different techniques of creating them, search the Snarkpit for some nice ones.