In Half-Life, weapons automatically respawn in multiplayer.
Where are you mapping for anyway? Half-Life or Counterstrike? Or something else?
Forum posts
Other maps run fine bytheway?
You've probably placed them in the wrong folder...
Try running a normal map and see what happens to ensure whether the problem is related specifically to this map.
Try running a normal map and see what happens to ensure whether the problem is related specifically to this map.
In fact, any space not connected to the void gets compiled, so it's not only the case with skyboxing.
Note that any face that touches a skybrush gets compiled, wich adds a bit to your compile time.
Note that any face that touches a skybrush gets compiled, wich adds a bit to your compile time.
Then the cycler wreckage is the one to go...
Hey, why don't you try both in a test map and decide for yourself?
Hey, why don't you try both in a test map and decide for yourself?
Env_beam:
http://cariad.co.za/twhl/entityinfo.php?ent=env_beam&game=1
Select a smoke-looking sprite (smoke.spr for example) and be sure to set that 'fade end' flag of the env_beam. Well, the rest is just a bit of experimenting and tweaking.
Remember the hot damp that came of the cup of coffe the scientist was holding, just before the HEV locker room? That's the effect you're getting.
http://cariad.co.za/twhl/entityinfo.php?ent=env_beam&game=1
Select a smoke-looking sprite (smoke.spr for example) and be sure to set that 'fade end' flag of the env_beam. Well, the rest is just a bit of experimenting and tweaking.
Remember the hot damp that came of the cup of coffe the scientist was holding, just before the HEV locker room? That's the effect you're getting.
Sounds... convincing...
No, really!
No, really!
I guess that's what the previous two posts were about...
I believe anything that has an origin, but it could well be more entity types too. Just go ahead and try them out, I'd say.
Although func_train is by far most used because it allows for very customizable movement of the env_beam.
Although func_train is by far most used because it allows for very customizable movement of the env_beam.
I've never tried it but it has to do with VPN (Virtual Private Network), e.g. simulating a LAN over internet. When you're interested, I'd say contact Devastator, or do some research...
Ah, so it does work! Good...
No problem...
Giving them different names, and using two more env_renders... 
As far as I know experimenting with that flag hasn't gave any ringed beams.
I suggest you take a look at the rmf of the Laser Fun competition winner... I haven't found any env_beam with it's 'ring' flag set...
In fact, I remember having seen an example map, included in the SDK 2.3, that featured ringed beams too. They were built from individual beams, like I described before. So, I guess you'll have to do it that way...
I suggest you take a look at the rmf of the Laser Fun competition winner... I haven't found any env_beam with it's 'ring' flag set...
In fact, I remember having seen an example map, included in the SDK 2.3, that featured ringed beams too. They were built from individual beams, like I described before. So, I guess you'll have to do it that way...
Ah, I get the idea...
Well, a trigger_hurt can be reactivated by triggering it again... so all you need to do is trigger the trigger_hurt twice, first to deactivate it and then to reactivate it.
Also note that the 'reactivating' env_render renders the health icon solid, you would change it's properties to make the health icon appear like it initially did.
Well, a trigger_hurt can be reactivated by triggering it again... so all you need to do is trigger the trigger_hurt twice, first to deactivate it and then to reactivate it.
Also note that the 'reactivating' env_render renders the health icon solid, you would change it's properties to make the health icon appear like it initially did.
Info_target's are the right entities to use here.
The 'ring' flag of the env_beam probably doesn't work, so your best bet lies in creating several beams so that they link up with each other and form a circle that way.
Info_targets can be used by multiple entities, so you don't have to create a new one for each env_beam's start or end point, just use the end point of a env_beam as a start for the next one.
The 'ring' flag of the env_beam probably doesn't work, so your best bet lies in creating several beams so that they link up with each other and form a circle that way.
Info_targets can be used by multiple entities, so you don't have to create a new one for each env_beam's start or end point, just use the end point of a env_beam as a start for the next one.
To reset a game_counter you should use a game_counter_set.
To make those entities appear again, trigger another env_render that sets them back to their normal render mode.
To make those entities appear again, trigger another env_render that sets them back to their normal render mode.
Its not overly complicated just invasive and oppresive to my sucky machineThen just don't use it... simple... I mean, you could always simulate a LAN network over the internet and play against some friends...
An older, not specific Steam-user, survey shows 8%...
http://valve.speakeasy.net/
Still not a large amount, isn't it?
http://valve.speakeasy.net/
Still not a large amount, isn't it?
Andy turned to OpenGL? Now that's good news!
And I like the competition. Maybe that forces me to actually finish my map...
And I like the competition. Maybe that forces me to actually finish my map...
Personally I like to keep one and the same avatar. People recognize your posts faster that way, you know...
No, just hide...
Good luck at you too, Floater!
Good luck at you too, Floater!
God, not CP again...REVEEEEEENGE!
Sorry, couldn't resist that. About the judging, software mode has some trouble displaying transparant models, right? Does the second judge run in OpenGL? Or at least Direct3D?
Since I know you don't, Andy...
for anyone who can't get broadband.Wich is a very small percentage according to the latest hardware surveys from Valve. 4% I believe. The majority of users nowadays uses faster internet connections...
source
Nah, they're still helpfull, tutorials or no tutorials...
I just read trough the help files again and yes, I just saw something I didn't know of before... pressing the 'o' key while Clipping a brush displays the lenght of the longest sides of the brush being clipped... that comes in handy!
I just read trough the help files again and yes, I just saw something I didn't know of before... pressing the 'o' key while Clipping a brush displays the lenght of the longest sides of the brush being clipped... that comes in handy!
Best of luck!
Steam.
Changes always are difficult to accept, aren't they?
After all, noone forces you to use it... noone forces you to play HL on-line... noone forces you to buy and play HL2... so why complain? Because the WON servers stopped? They would've stopped at some time anyway, Steam or no Steam.
Changes always are difficult to accept, aren't they?
After all, noone forces you to use it... noone forces you to play HL on-line... noone forces you to buy and play HL2... so why complain? Because the WON servers stopped? They would've stopped at some time anyway, Steam or no Steam.
Those things stay funny...
Muzzle, you're on track again? This time I will beat you!
If I'm able to finish my map, that is... some more time would come in handy, but I guess we'll just have to hurry now.
Good luck anyway!
If I'm able to finish my map, that is... some more time would come in handy, but I guess we'll just have to hurry now.
Good luck anyway!
It depends on what you're aiming for. Spirit isn't meant for multiplayer although it seems to work correct for most of the entities.
If you want singleplayer maps however, it does open a whole new set of options. Maps for SoHL aren't really common as far as I know, but providing your work as a mod folder works fine. For example, several mods are based on Spirit code...
It's really up to you. I'd say: go, check it out and decide for yourself.
If you want singleplayer maps however, it does open a whole new set of options. Maps for SoHL aren't really common as far as I know, but providing your work as a mod folder works fine. For example, several mods are based on Spirit code...
It's really up to you. I'd say: go, check it out and decide for yourself.
Then it's not some odd stuff on your hardware. What happens, is that you don't see the face as it doesn't exist. During the VIS process however, it was treated just like any other world brush/face. So faces behind it aren't rendered, whether you applied the null texture to it, or any other texture.
A good trick to prevent this is to check with gl_wireframe 2 on. Can you see wires behind the whole face, from every direction? Then you won't get a HOM effect when you cover that face with the null texture.
Ah, well, you understand by now, I guess...
A good trick to prevent this is to check with gl_wireframe 2 on. Can you see wires behind the whole face, from every direction? Then you won't get a HOM effect when you cover that face with the null texture.
Ah, well, you understand by now, I guess...
Hmm... 4th place for a small community like mine... not bad, isn't it?
Not that any of you would be able to read my site...
Not that any of you would be able to read my site...
The null texture only gives a HOM effect when no faces are rendered behind, wich can only happen when you cover a world brush with the null texture.
Covering entities with this texture shouldn't give problems as these do not block VIS. And all that happens during the compile is that these faces are left out... So Seventh, did you cover an entity with the null texture, or a world brush?
Covering entities with this texture shouldn't give problems as these do not block VIS. And all that happens during the compile is that these faces are left out... So Seventh, did you cover an entity with the null texture, or a world brush?
I already though you left out some necessary information...
The func_wall can also be covered with the null texture. Then you don't need to worry about the render mode.
The func_wall can also be covered with the null texture. Then you don't need to worry about the render mode.
Maybe your best bet lies in investigating the code yourself... coders are hard to find, especially when you're new to the communities they operate in.
Well, at least I've started to code myself rather than wait for someone else...
Well, at least I've started to code myself rather than wait for someone else...
You couldn't find it on Google?
Just create a brush... world brushes always block a players movement...
1. Mitering corners. Some people seem to do it. You shouldn't. It makes brushes hard to manage, and doesn't decrease r_speeds in any way.
You see, as long as faces have exactly the same texture properties, they're combined into one surface when possible. Wich means there's no need for mitering your corners...
2. Null texture. Some people see this as the major r_speed solver. In fact, it can only reduce your r_speeds in certain situations, like when faces are rendered but never seen by the player.
Don't texture the outside of your map with this null texture, as this outside gets discarded already by the compile tools.
3. Sky. Just use sky brushes to seal of your level in open air area's, do not surround the map with a skybox. Skyboxes let the compile tools compile much more faces and space than necessary, causing longer VIS and RAD times, and often higher r_speeds.
Any surface that touches a skybrush is being compiled. It may not be seen by the player but it gets compiled. Maybe something to mind to reduce compile times a bit.
You see, as long as faces have exactly the same texture properties, they're combined into one surface when possible. Wich means there's no need for mitering your corners...
2. Null texture. Some people see this as the major r_speed solver. In fact, it can only reduce your r_speeds in certain situations, like when faces are rendered but never seen by the player.
Don't texture the outside of your map with this null texture, as this outside gets discarded already by the compile tools.
3. Sky. Just use sky brushes to seal of your level in open air area's, do not surround the map with a skybox. Skyboxes let the compile tools compile much more faces and space than necessary, causing longer VIS and RAD times, and often higher r_speeds.
Any surface that touches a skybrush is being compiled. It may not be seen by the player but it gets compiled. Maybe something to mind to reduce compile times a bit.
It was good 'for a first map', wich isn't what Seventh means. My first map was a L-shaped corridor, later extended with an elevator and some entity trickery. Nothing serious you would release to the public...
When it comes down to releasing a map, make it as easy as possible to the player. Zip the files correctly, make sure all (and only) necessary files are included. Take your time to ensure the map plays and looks well. If that takes another day compiling, then do so. Noone cares whether 'compiling took to long' or not. All the player will see is the end-result.
When it comes down to releasing a map, make it as easy as possible to the player. Zip the files correctly, make sure all (and only) necessary files are included. Take your time to ensure the map plays and looks well. If that takes another day compiling, then do so. Noone cares whether 'compiling took to long' or not. All the player will see is the end-result.
What helps me to create a coherent level:
1. Reference material. Usually I search on Google for about a 15-20 minutes to find photographs of the type of area I have in mind. This helps me create a more convincing level.
2. Draw it out. I didn't do this when I was a beginner, but I'm finding it more and more usefull to try things on paper before mapping them. This may differ from person to person however.
3. Create small test-maps for entity-setups before implementing complex entity tricks. Creating small maps to 'get the right architecture, lighting, mood, overall feeling' is a good habit too. You can copy these things into your final level and modify them so they fit with the rest.
4. Testcompile often, backup often. Usually I save to another file after each major change I made (map_v01, map_v02, and so on). Yes, that's learned the hard way...
5. Look at how others did it. Did you see a really interesting level? Try to find out what exactly made it interesting. I don't say copy, I say let yourself get influenced by others.
6. A lot of technical knowledge isn't necessary to create good maps. However, it does allow you to express yourself easier, faster and on a 'higher level'. So learn about your tools!
7. Stuck for idea's? Read some books, watch a movie, take a stroll in the park... just relax. I get most of my idea's when I'm totally not busy with mapping at all. For those with a bad memory (like me), write (or draw) it down. It may be of good use later on...
1. Reference material. Usually I search on Google for about a 15-20 minutes to find photographs of the type of area I have in mind. This helps me create a more convincing level.
2. Draw it out. I didn't do this when I was a beginner, but I'm finding it more and more usefull to try things on paper before mapping them. This may differ from person to person however.
3. Create small test-maps for entity-setups before implementing complex entity tricks. Creating small maps to 'get the right architecture, lighting, mood, overall feeling' is a good habit too. You can copy these things into your final level and modify them so they fit with the rest.
4. Testcompile often, backup often. Usually I save to another file after each major change I made (map_v01, map_v02, and so on). Yes, that's learned the hard way...
5. Look at how others did it. Did you see a really interesting level? Try to find out what exactly made it interesting. I don't say copy, I say let yourself get influenced by others.
6. A lot of technical knowledge isn't necessary to create good maps. However, it does allow you to express yourself easier, faster and on a 'higher level'. So learn about your tools!
7. Stuck for idea's? Read some books, watch a movie, take a stroll in the park... just relax. I get most of my idea's when I'm totally not busy with mapping at all. For those with a bad memory (like me), write (or draw) it down. It may be of good use later on...
Neither have I. It depends on the quality you're aiming for, and the skills you have. After a while, I just say a texture is finished because I don't have the skill to make it look better. Someone more skilled would continue and achieve a better-looking texture.
You can also use Wally's 'offset' function and remove those seams in other programs to make a texture tile correctly...
Cartoonish textures?
You may want to take reference photographs, at least it helps me to get my textures more realistic. You may also want to modify photographs instead of starting textures from scratch.
Texturing isn't something you can master easily. It'll take time and experience to get them right. I know of an artist that usually takes 3 days for 1 texture. And that's someone who's quite experienced...
You may want to take reference photographs, at least it helps me to get my textures more realistic. You may also want to modify photographs instead of starting textures from scratch.
Texturing isn't something you can master easily. It'll take time and experience to get them right. I know of an artist that usually takes 3 days for 1 texture. And that's someone who's quite experienced...
Correct, jaardsi.
So, cyanide, you'll have to develop some sort of feeling for proportions in Hammer... Don't worry, it'll come by time.
So, cyanide, you'll have to develop some sort of feeling for proportions in Hammer... Don't worry, it'll come by time.
I would strongly advise not to make textures in Wally. Instead, use other programs to create a 24 or 32 bits bmp, then insert that bmp into a wad file, using Wally. It'll automatically convert the texture into 8 bits, creating a palette that is as close as possible to the original colors. You shouldn't have a too large quality loss then.
It totally depends on how and were you search.
I started at the VERC, truly a helpfull site when I got started and still interesting after some years. Then I got in touch with The Snarkpit, Handy Vandal's, 69th Vlatitude, Wavelenght, TWHL... People don't only find things on Google, you know...
I started at the VERC, truly a helpfull site when I got started and still interesting after some years. Then I got in touch with The Snarkpit, Handy Vandal's, 69th Vlatitude, Wavelenght, TWHL... People don't only find things on Google, you know...
Another tip: my walls often are 128 units heigh. You may want to use the info_player_start as indicator for the size of something, as it's as large as you are in-game.
My advise: start with a new map and Snap to the Grid. Trying to solve all these problems would probably take more time than doing it all anew on the right scale.
Resizing things by other factors than 2 nearly always ends you up with vertexes not on the grid, wich can cause various problems, like the coplanar faces and such. One thing you should get used to is the grid. All vertexes should be on the grid.
For you, it would be best now to start with a grid size of 32 or 64 and Snap to Grid.
Resizing things by other factors than 2 nearly always ends you up with vertexes not on the grid, wich can cause various problems, like the coplanar faces and such. One thing you should get used to is the grid. All vertexes should be on the grid.
For you, it would be best now to start with a grid size of 32 or 64 and Snap to Grid.
Prefabs can be found on various sites, for those that really seek them.
As for my opinion on prefabs: since they're overused by so many mappers I wouldn't go with prefabs. The prefab system however can be used quite handy, in case of objects that appear frequently in your maps (light-bulbs, things like that).
But that's just me...
As for my opinion on prefabs: since they're overused by so many mappers I wouldn't go with prefabs. The prefab system however can be used quite handy, in case of objects that appear frequently in your maps (light-bulbs, things like that).
But that's just me...
I did once, for fun or maybe testing purpose. Just to se what would happen.
It seems VIS doesn't like too large surfaces or something like that. VIS didn't run correctly and so RAD wasn't run. I ended up with a full-bright concrete, err... thing...
It seems VIS doesn't like too large surfaces or something like that. VIS didn't run correctly and so RAD wasn't run. I ended up with a full-bright concrete, err... thing...