Forum posts

Posted 14 years ago2009-08-18 02:33:52 UTC
in r_speeds - epoly count Post #272139
A simple rule to null, texture every face (with null) a player never could see ingame.
Although it CAN cause problems, under certain circumstances!

While developing my canyon_redux map, I started having bad lagging problems which I finally traced back to a particular set of NULL surfaces. They couldn't be seen by the player, but they seemed to allow the engine to see out through the void and back into another section of the level. Whenever you were near that other section (which was, itself, rather complex) the game would lag horribly. I went through, grouping and turning off all sorts of details to no avail. Finally, I set those NULL textures back to standard wall textures, turned everything else back on, and it worked fine...

YMMV! :-)
Posted 14 years ago2009-07-07 23:00:08 UTC
in Super Half-Life Tools 3.9 Post #269650
Furthermore, now that I'm actually using these tools (very tentatively at first) I note that the texture limit has been expanded from 4Mb to 32Mb!

Awesome - it will allow me to address the numerous comments I had with my Canyon_Redux level not having enough texture variety - but does the engine cope okay with all that extra texture data?

Guess I'll have to have a play and find out! :-)
Posted 14 years ago2009-06-12 21:27:32 UTC
in Removing spawn points Post #268234
To toggle them, I guess you'd need two env_globals and two triggers, one to turn the global state master on, one to turn it off.

Unless env_global has a "Toggle State" option? Without looking, I'm fairly sure it does... shrug

Oh, and whether it works for "CS + TDM" I couldn't say; I only know the HLDM entities... :-)
Posted 14 years ago2009-06-11 08:58:53 UTC
in The "Official" Competition 27 Post #268195
Nice work, Strider - and here I was, wondering how I was going to get the organic "coastline" shape into Hammer so I could follow it; I guess you've answered my question for me! :)

I think I shall give this a shot, if I find the time. Goldsource as usual for me, although I might try the new compile tools and see if they free me up a little... I've already got the basic floor plan blocked out (to scale, of course...) Hope I get to go further with it...
Posted 14 years ago2009-06-11 08:47:58 UTC
in Super Half-Life Tools 3.9 Post #268194
The increased LEAF limit would have allowed me to do more with my Lab11 level.

Hmmm... :-)
Posted 14 years ago2009-06-10 23:20:40 UTC
in Removing spawn points Post #268184
I did exactly this in my lab17_flood. I thought I had a notes.txt file somewhere in which I wrote up what I did to achieve the effect, but now I can't find it.

Searching, searching ... aha! :-) Here's what I wrote up to remind myself how to do it... (I apparently used it in one of my no-longer-existing necropolis levels too!) And to have them ACTIVE until triggered you just need to reverse the on/off logic...

SPAWN POINTS INACTIVE UNTIL TRIGGERED:

A spawn point (info_player_deathmatch) can have a "Master" value, which can be used to specify a multisource entity. If that multisource entity is "on", the spawn point will be active; otherwise it will be inactive. To set one (or more) spawn points to be inactive until triggered, we will need:
* Our spawn point(s) with their "Master" field set to "SP_LOCK1".
* A trigger (which type of trigger, or hown many, is determined by the design of the level) with its target set to "SP_TRIGGER1".
* A multisource with the name of "SP_LOCK1", and a "Global State Master" set to "SP_ACTIVE1".
* One env_global with a name of "SP_TRIGGER1", and its "Global State to set" pointing to "SP_ACTIVE1". Assuming we want our spawn points to be activated by our triggers and to remain active from then on, we need the "Initial State" to be "Off" (and, of course, "Set Initial State" ticked) and the "Trigger Mode" to be "On". (For our spawn points to be deactivated by our triggers and to remain inactive from then on, we need the "Initial State" to be "On" and the "Trigger Mode" to be "Off".)
Posted 14 years ago2009-06-10 23:08:13 UTC
in Echo Post #268183
@srry: Likewise ... and I might just investigate doing that in the code next time I've got nothing to do... :-)
Posted 15 years ago2009-04-28 03:09:23 UTC
in Tex lights not lighting? Post #266077
hlrad will actually read both 'lights.rad' and 'mapname.rad'. For some time during the development of lab11_lavalab I had a lights.rad file (unwanted) sitting in the directory with the compile tools, and it read that AND my lab11_lavalab.rad file. Had me a little confused for a while, till I realised where the extra lighting information was coming from...
Posted 15 years ago2009-04-23 17:10:46 UTC
in Selection Order Post #265933
The obvious fix is to go into Hammer's Options dialog, select the "3D View" tab, and untick "Reverse Selection Order".

If that box is not ticked, you could try ticking it, I guess, to see if that solves your problem.

Edit: Oh yeah, I see you already tried that... /Edit

Alternatively, if you hunt through the Windows settings (via Control Panel) for your Display driver (or possibly your mouse driver) for a setting called "Z-Buffer sorting" or something similar, toggling that may fix the problem... I can't find that on this machine, but I'll have a look on the work machine when I get there, to see if I've got it on that one. (This machine won't run Hammer properly anyway. Curse you, ATI Radeon drivers...)
Posted 15 years ago2009-04-07 06:57:27 UTC
in Changing turret rate of fire Post #265151
Which mod is this for? I don't have a turret.cpp in the HL SDK (as far as I can see, anyway!)

However, I looked through the func_tank.cpp file on the theory that the concept was the same, and found that m_fireRate variable is actually fed in from the map itself (ie, the func_tank entity has a "rate of fire" value.) Does the same apply for turrets?

Just thinking out loud; obviously I don't have a turret to play with...

Edit because ... well, just because!

D'oh! Of course turret.cpp is in the single-player code (which I've deleted from my working copy of the SDK!) As far as I can see, the rate of fire of the turret should be controlled by the pev->nextthink line that Daubster pointed out. However, changing that delay time won't change the animation speed... But if it's not working ... dunno.
Posted 15 years ago2009-04-07 02:07:28 UTC
in Exceeded MAX_PATCHES and I can't seem to Post #265155
A couple of comments, from my own recent experiences trying to get past MAX_PATCH errors:
  • By all means, NULL faces which are not visible to players within the level (don't bother with EXTERIOR faces though; they get discarded by the compile procedure and hence have no impact on lighting.) Be wary, however; NULL does not seem to block VIS as promised, and if you NULL a face which sees through the void to another section of your level, it can/will cause major problems with your level's playability (I think due to confused VIS information...)
  • I did quick-compiles of my level with -chop 96, and it really didn't look too bad! (Compared against final compiles of -chop 72 -sparse...)
Posted 15 years ago2009-02-24 23:28:28 UTC
in Cordon Tool Destroyed My Map Post #263200
True it omits everything outside of its extents ... but if you enclose a large section of void, that gets included into your BSP file -- along with all the exterior surfaces which would not ordinarily be compiled, thrown into the mix because they are now INTERIOR surfaces...

So yes, it throws out everything outside of the cordon, but includes EVERYTHING inside the cordon. It WILL extend your compile time of you use it unwisely! :-)

(And while I'm fairly sure that I ran into this limitation while developing my latest level, I have just done a test on a tiny one-room level. Adding a cordon that is too large (cutting off some of the level but extending out into the void) increased the BSP from 87kb to 299kb! The BSP viewer clearly shows the extra "skybox-like" room around the original...)

Edit: Admittedly that MAY have been because the top of my room was sky; I'll do another test later to see if the same thing happens without sky involved... But then, it's not like sky is completely unheard of... ;-)

Further Edit: Replaced the sky with a light-emitting texture and it produced a large "outside" room and had to do all the lighting calcs. Definite slowdown.
Posted 15 years ago2009-02-24 07:44:37 UTC
in Anyone ever done this? Post #263196
The biggest problem ANY time you have multiple entities moving in synch is that they get out of synch if one is blocked -- and there's no way for you to detect the blockage and trigger the other entities accordingly. The only solution, as srry said, is to apply large amounts of damage so it doesn't actually stop moving.

The rest is all just juggling of path_corners! Good luck! I've got a 3-level (simple platform) lift in my Lab11 level with call buttons at each floor. Adding doors would be intriguingly complicated. Better yet, you really need a pair of doors which moves with the lift, and a pair of doors covering each entry to the lift shaft... ;-) Ooh, now there's a thought...
Posted 15 years ago2009-02-24 07:37:30 UTC
in Cordon Tool Destroyed My Map Post #263195
I always forget about the cordon tool until I've been sitting through painfully long test compiles for a week or two. Then it works like a charm. Of course, it essentially just places a big black box around the volume you select; if you're trying to compile a major portion of the map this is much like enclosing your map in the dreaded skybox, and can actually hurt your compile... Also, occasionally, I've had it cause an invalid entity (no doubt depending on where you place the cut...)

Never lost a level though. You MUST be working ONLY with your MAP file and not saving as RMF.
Posted 15 years ago2009-02-24 07:29:31 UTC
in A couple of questions Post #263194
I've seen many comments about nulling the faces that you can't see but I can't find the null texture anywhere
I read somewhere that NULL blocks VIS but I don't believe it! In the process of tring to reduce light patch usage on my latest level, I NULLed some faces which faced out into the void -- and from there back into another part of my level. It caused a VIS nightmare which made the level act horribly, and it took a week to figure out what was causing the problem!

In summary, NULL applied to brush entity faces = GOOD, NULL applied to world brushes > use with caution! :)
Posted 15 years ago2009-02-24 07:20:41 UTC
in Trigger_teleport problem -- VERY weird Post #263193
8 hour compiles FTW! :-)

I suppose the other question worth asking is: where ARE the dodgy teleporters taking you? Is there an entity there that they are targetting?
Posted 15 years ago2009-02-24 07:13:26 UTC
in Making func_recharge/healthcharger charg Post #263192
"That is probably hardcoded. Nothing you can do about it."

Except dive into the code, of course... ;-) If you do that, you'll find the value in dlls/multiplay_gamerules.cpp. (The weird thing is, multiplay_gamerules overrides the value of "suitchargerCapacity" to 30, but says nothing about "healthchargerCapacity"; the latter gets its value, according to gamerules.cpp, from the CFG file (apparently at skill level 1, 'cos you get 50 from them...)

If you wanted to dive into the code, it shouldn't be too difficult to add a "Max charge" value to your in-game funcs so that you can define them on a per-map (or even per-location) basis. Hmm, that has possibilities... :-)
Posted 15 years ago2009-02-24 06:31:02 UTC
in Rad issues? Post #263189
Yeah, I'd definitely recommend you switch to ZHLT...

That aside, though, it does seem to be an awful lot of lightdata for a 2 minute RAD compile. Either your rooms are really large, or you have a leak (you DID compile with CSG/BSP before VIS and RAD?) or you have a few switchable lights. (Offhand I believe a switchable light effectively doubles the lightdata for the illuminated area, since it has to generate both on and off lighting.) Or, uh, all three...
Posted 16 years ago2007-07-30 11:31:39 UTC
in Ridiculously Long VIS Compile Time Post #230774
5 minutes isn't evil? Tell me by the way, am I being told this from people whose computers can run Source games fairly well (like mine) yet think GoldSrc is cooler for mapping, or are you the guys who map for GoldSrc because you run on Commodore 64s?
My most complex level (lab17_quake) has a compile time of 22 hours, running on a 3GHz P4. Of course, probably 2/3 of that was RAD, but much of the rest would have been VIS...

No, 5 minutes is nothing! ;-)
Posted 16 years ago2007-07-18 08:01:45 UTC
in The Free Texture Thread! Post #229432
Nice volcanic textures there, srry! I might have a use for them in the level I'm currently working on; if I use 'em I'll credit you (and let you know!)

As for textures I've made: nothing really worth speaking of. Level-specific signs, mostly, and a couple of textures built from other people's images for a specific purpose... And I made a tiled floor texture from a digital photo of my own tiled floor -- but then it got deleted from the level I'd used it in ('cos the room in which I'd used it had to go, for space reasons...)
Posted 16 years ago2007-05-21 04:19:34 UTC
in func_door_rotating "bounce" problem Post #222802
Yeah, thanks for the input guys.

I wouldn't have gone so far as to call it a bug; I was just hoping there was something simple I was missing which would prevent it from reversing direction as it does -- even if it could just hold position as the func_train does.

I might consider looking into the func_door code when I get the time -- but I've so far resisted the urge to do any coding for my DM levels (although at work we have them installed in a standalone minimod directory so I guess it's only a matter of time before I venture down that path...)

Cheers,
Pete.
Posted 16 years ago2007-05-17 19:23:59 UTC
in func_door_rotating "bounce" problem Post #222481
If a player gets caught between a func_door_rotating and a solid brush, the door inflicts the specified amount of damage and then changes direction. If it was closing, it bounces open; if opening it bounces closed. Even if the damage inflicted is high enough to instagib an entire regiment of players, the door still changes direction.

Is there any way to prevent this? For a small door, it sorta makes sense, but for a big heavy door (or other simulated effect) it is rarely what you want!

The same problem occurs with ordinary func_doors too, but at least with those you can substitute a func_train (although even they pause if they don't instantly kill the player (and sometimes even if they do) which can throw out your timing...)

Edit: I should add that, in the particular case I'm trying to build at the moment, I want to be able to reopen and reclose the doors numerous times... ;-)

Thanks.
Posted 17 years ago2006-09-18 00:36:50 UTC
in Leaf portals Post #196816
Glad you think it's useful! ;-)

The code was a bit quick 'n nasty, but it does the job!

If I understood the RMF format I might have been tempted to modify that directly ... but OTOH, working with the MAP file might be a little more fiddly, but it's also a lot more portable and should work for other editors as well as Hammer...
Posted 17 years ago2006-09-18 00:04:16 UTC
in Black Mesa Complete-comming late 2007 Post #196815
Doom was the first game that was truely 3d because it was the first game to use height differences.
Indeed. Although once you start mapping for it, you generally start thinking of it as 2.5D. It took some extremely tricky ... uh ... tricks to simulate having one level physically above another; it was really more of a 2D layout with, as you say, height differences.

In fact, back on topic, sorta -- I've occasionally thought of rebuilding the DOOM levels for the HL engine... Never have, because I never have that sort of time available...
Posted 17 years ago2006-09-07 01:56:35 UTC
in "invisble one-way wall" problem Post #195838
@ rowleybob:

I had one of those that was driving me crazy. I'd put a new tunnel through somewhere that hadn't had one originally. It was narrow, but should have been wide enough to fit through -- but when I tested I couldn't get through. Spent an hour carefully widening it (lots of fiddly brushes, not much room to work with) and tested again. Same thing. Suddenly it clicked...

Went into Hammer and turned my "clipping" level back on. Sure enough, I had a clipping block right through that area (to simplify calcs for a complex-but-unreachable bit the other side of the wall...)

sigh

:D
Posted 17 years ago2006-09-06 23:32:58 UTC
in Teleporters Post #195835
I have a level that I want to do that to myself, as soon as I have the time!

There's a technique for generating randomness - whether it be random targetting via trigger_changetarget, or anything else you want to trigger randomly - using, I think, an env_beam with multiple targets, and multiple func_buttons.

I thought there was a tutorial on TWHL I could link you to, but a quick glance through the list didn't reveal it to me...

Basically, you place an env_beam entity, place a single info_target (with name "beam_source" or whatever) as starting point and multiple info_targets (name "beam_target") as ending points, arranged in a rough circle around the source. Use as many ending points as you have events - or, in your case, info_teleport_destinations - and set the beam to cause damage. Between the source and each target, place a func_button with a damage value of 1 (so it will trigger its target when it takes damage.)

The env_beam, when triggered, will randomly select from its available start and/or end points - in this case, randomly firing at one of your "beam_target" entities. The beam does damage, so it triggers the func_button between the two - which can then change the target of your trigger_teleport appropriately (or, of course, trigger any other random event you like...)

I don't remember who originally came up with this method - but I'd like to thank them! It's really rather brilliant! ;)
Posted 17 years ago2006-09-06 22:28:25 UTC
in Leaf portals Post #195828
The "Leaf portals saw into leaf" error won't necessarily cause a fullbright compile; my last map had three or four such errors (and ran fine for months) before I finally put some effort into tracking them down and eliminating them.

FWIW, I wrote a PERL script to assist me in tracking these errors down. If anybody wants to use it, you're welcome to it. (I'll post the code below; just copy-paste into a file called leafsaw.pl - and, of course, install PERL! :))

It works fairly simply. Just run it in the directory which contains both your mymap.map file and your mymap.log file. It will generate a mymap_leafsaw.map file which you can oepn in Hammer; the new map has a red light entity (with targetname = leafsaw) at each of the coordinates listed in the error. These can be easily searched for with Hammer's entity report, marked, etc, giving you a very good idea of the bit of space where the error has occurred. Then just switch back to the same place in your RMF file (don't forget to work on your RMF rather than the _leafsaw.map; I did that a few times...) and tweak the architecture a bit. (Generally you'll see the lights line up along a particular edge, telling you exactly which brush needs revising...)

The code is as follows:

#!/usr/bin/perl -w

use strict;
use File::Copy;

foreach my $f (<*.log>) {
  print "Reading $fn";
  my $fn = $f;
  $fn =~ s/.log//;
  my $map = $fn."_leafsaw.map";
  copy($fn.".map",$map);
  open LOG,$f;
  open MAP,">>$map";
  my $lcount = 0;
  my $lpsil = 0;
  foreach my $line (<LOG>) {
    if ($line =~ /Leaf portals saw into leaf/) {
      $lpsil = 1;
      }
    next unless $lpsil;
    chomp $line;
    if ($line =~ /(([-.0123456789]+) ([-.0123456789]+) ([-.0123456789]+))/) {
      my ($x,$y,$z) = ($1,$2,$3);
      $lcount++;
      print MAP "{n"classname" "light"n"_light" "255 0 0 500"n";
      print MAP ""targetname" "leafsaw"n"origin" "$x $y $z"n}n";
      }
    elsif ($line eq "") {
      $lpsil = 0;
      }
    }
  close MAP;
  if ($lcount) {
    print "Recorded $lcount Leaf_Saw_Into_Leaf marker lights into $mapn";
    $lcount = 0;
    }
  else {
    unlink $map;
    }
  }

print "nPress [Enter] to continue ... ";
<STDIN>;
Posted 17 years ago2006-09-06 21:47:33 UTC
in Black Mesa Complete-comming late 2007 Post #195823
When I first read about this, it certainly struck me as being a personal passion. Sounds like an amazing project, and one I look forward to having a wander around.

The big question that occurs to me is, with all the research you've obviously done on this, have you found any parts where the complex overlaps itself spatially? I guess that all depends on whether Valve designed the complex as a whole, or simply treated each level (or perhaps a section of a few levels) individually. I guess the most troublesome areas would be the meshing between the separate games...

(And yeah, I realise it won't matter because you're not RELEASING it as one big map... :-))
Posted 17 years ago2006-09-04 23:32:08 UTC
in xt_flora.wad Post #195661
Cool. Must try that. I've got just the spot in one of my older levels to place a tree... :D

As for the x_flora.wad ... well, if I ever get around to trying this (I'm way too busy these days!) I'll probably go for a walk with my digital camera and make up my own wad for the occasion. If I do, I'll make it available... ;-)
Posted 17 years ago2006-08-27 04:47:16 UTC
in Necropolis: Mausoleum updated Post #194721
For those who have already taken an interest in my Necropolis: Mausoleum level, or commented on it, you may like to know that I have finally uploaded the revised, "new and improved" version 1.1 of the map.

It's only taken, what, 4 months?! :nuts:

I took on board many of the comments already made on it -- specifically adding ambient sounds a-plenty, fixing up a few minor texture mismatches, and [hopefully] fixing the problem with occasionally getting squished at the top of the elevator (although only time will tell with that one; either way, I don't see anything more I can do to resolve it...)

:D
Posted 17 years ago2006-06-18 01:09:52 UTC
in lights Post #185570
plus you can't have flickering texture lights
Actually, you can have flickering texture lights, in much the same way as you can have switchable texture lighting. If you bind the brush with the texture in question to an entity, you get the "Texlight style" option, which can either be set to grouped (so that it will be on or off depending upon the like-named light) or to any of the flickering options...

Of course, entity texture lighting actually seems to be calculated differently to world brush texture lighting, so YMMV...
Posted 17 years ago2006-06-18 00:59:02 UTC
in 1st time using something's wrong.. Post #185569
As others have said, if you UNCHECK "Use independent window configurations", you will then get one big window with four sub-windows. However, it doesn't seem to take effect immediately; you have to close Hammer and reopen it before it takes effect.

OTOH, if you have that option CHECKED - as you currently do - you will get one window, but you can then open as many individual "New Windows" as you require from the "Windows" menu -- and set them up accordingly. (You can open new windows no matter how the "Use independent window configurations" is set, but it's not overly useful to have multiple subdivided windows, as far as I can see...)
Posted 17 years ago2006-06-08 00:19:30 UTC
in Entity text too long Post #184244
FWIW, both to the OP and those attempting to answer him, I actually did run into such problems when I switched from the ZHLT2.5.3 compile tools I had been using quite successfully to the new (at the time) ZHLT 3.0 tools. A map which had compiled successfully with 2.5.3 now triggered a "Fatal Error" in HLBSP.exe (or possibly HLCSG.exe).

After spending some time tracking down an increasing list of problems - everything I managed to get passed revealed another crash further down the chain - I gave up and went back to 2.5.3 because, hey, it worked.

I recently tried out 3.3 or 3.4 and ran into similar issues. I'm still using 2.5.3.

If such problems were normal, they would undoubtedly have been fixed long ago, so I can only assume there is some particular system configuration which causes the new compile tools to become unstable. However, since 2.5.3 still gets the job done, I really havben't been interested in spending any time trying to figure it out...

shrug

*EDIT*: I suspect my reply probably belongs in the other thread Sidon linked, rather than this one. Sorry...
Posted 17 years ago2006-05-31 07:58:24 UTC
in Proximity sensor Post #182889
Thanks. Interesting method. As I understand it, it's two triggers, of which only one is active at a time, as controlled by state of the multisources, and the mm toggles back and forth between the two states.

I think if I were trying that, I'd have placed the triggers closer together and have each one target a trigger_relay -- but I'd need to test it to see if it would work the same way.

Perhaps I should have mentioned that I want to do this in a DM environment -- and specifically, therefore, if the player within the proximity zone should happen to die or be killed, the lights would then be switched off just as if the player had left the zone voluntarily. Which this method, interesting though it is, would not achieve... (Also, if a second player triggered the "Close" sequence after the first player triggered the "Open" sequence, these doors would close with both players within the proximity zone...)

;-)
Posted 17 years ago2006-05-31 07:05:59 UTC
in Proximity sensor Post #182876
Hi all,

I'm trying to create a proximity sensor, such that when you enter a certain area an event can be triggered on, and when you leave the area the event is triggered off.

Specifically I want to switch a light on and off (among other things).

I've played around with the method for creating proximity doors (trigger_multiple repeatedly triggering a momentary_rot_button which targets a momentary_door -- which actually didn't work too well last time I tried to use it to build a door; it seems to have problems if the speed is too high. But that's a separate issue!) I figured that since the momentary_door has "target" and "fire on close", I could use them to turn the lights on and off. That didn't work, though...

Is there another way to achieve this? Something I'm missing? Has anybody successfully gotten this sort of thing to work?

Cheers,
Pete.
Posted 17 years ago2006-05-25 20:10:46 UTC
in Lava Tut please? Post #182078
I believe for my "lavalab" level I just used "!fluid2" which is in one of the standard WAD files -- because that was my first level, long before I even considered using non-"standard" textures. I don't actually have my RMF file handy, but I'm pretty sure it was "!fluid2".

And then, to make it look good, I added a suitable light colour to that texture in my RAD file...

Admittedly it still looks a little too fluid to be lava, but it's pretty effective...
Posted 17 years ago2006-05-24 21:06:05 UTC
in Weird buzzing sound, help me Post #181924
Maybe, but why would it just start craping out on me now?
Cards die. Solder cracks, connections fail, the vibrations from the cooling fans shake the whole thing apart.

Actually, if you've got a stand-alone soundcard (as opposed to an on-board one) it might be worth removing it from its slot and re-seating it. (Obviously you want to unplug all power sources first... ;-)) Sometimes - especially if it wasn't quite seated properly initially - cards can actually vibrate out enough that they're no longer making proper contact...
Posted 18 years ago2006-05-09 00:42:53 UTC
in This should be simple but isn't... Post #179136
I don't know enough about CS to be sure this would work, but in HLDM I'd try something like having a Master on the trigger_multiple which is Enabled by something triggered by level start, then Disabled by the multimanager which it actually triggers (and which also delivers the grenade...)

I don't have the time at the moment to work out the specifics, but if you need more than that let me know and I'll look into it later...
Posted 18 years ago2006-03-22 10:03:41 UTC
in Glass/Model Problem Post #170183
Actually, I saw something similar to that once when I was doing some test compiles to determine how the different render modes worked (or didn't...) It seemed to be related to "Glow" or "Colour" modes -- and possibly to how many such entities were visible at one time.

It's all I can think of...
Posted 18 years ago2006-03-21 08:04:49 UTC
in MSVC++ Post #170018
Okay, thanks for that.

I've actually already downloaded the Visual Studio Express files (last year sometime) but never went so far as to install them or anything. I was mostly unsure whether other versions of MS Visual C++ would work, since everything I've seen specifically mentions 6.0...

Oh well, I guess I'll give it a try sometime. :-)
Posted 18 years ago2006-03-20 01:47:25 UTC
in MSVC++ Post #169631
Is Dev-C++ useable for HL mods?

I was gonna try 'n track down a copy of Visual C++ 6.0, but if another compiler will do the job just as well, I'll go with that instead...
Posted 18 years ago2006-03-09 22:28:04 UTC
in Weird button problem Post #167342
button is texture {blue , rendermode - solid, fxamount - 250
If this is intended to be triggered when somebody enters the zone - which would seem to be the case, since it's set up to be invisible - shouldn't it be a trigger_multiple rather than a func_button?

(In which case, texture AAATRIGGER should be fine...)
Posted 18 years ago2006-03-09 01:24:38 UTC
in env_beam doesnt work Post #167105
I found that to get a vertical circular env_beam, I had to place the two target entities slightly offset from one another. Rather than having one directly above the other, offset them by one or two units in the X or Y direction... (Which way you offset them should determine which way your circle is drawn...)
Posted 18 years ago2006-03-07 22:30:16 UTC
in The Steam "Preloaded" Post #166916
I believe there is a setting somewhere in Steam which determines whether a program is kept up to date. (There's a global setting, I think, and a per-program setting.) Perhaps that (or a similar setting) also determines whether the preload occurs automatically.
Posted 18 years ago2006-03-04 02:35:04 UTC
in Getting stuck on elevator (func_train) Post #166206
Well, I have one final report to make on this issue.

To add insult to injury, I have since discovered that I now sometimes get stuck at the very top of the lift's path. Since it's no longer moving I don't take damage, but I'm stuck until it moves down again.

This was an easier one to fix, though. I just reinserted a path_corner 4 units above where it is supposed to stop, so that it actually moves higher than originally intended, and then drops down a few inches, freeing anybody who happened to get stuck. (I'm almost confident this time... :D) And it fits nicely into the theme, since it's a rickety old wooden elevator rumbling up the inside of a 3000 year old stone tower... :-) I added a ratchet sound as it locks itself into place for a while before the descent.

This time fer sure!
Posted 18 years ago2006-03-02 18:58:35 UTC
in Getting stuck on elevator (func_train) Post #166012
Final result:

Based on a couple of successful play sessions (with two to four players) it seems that deleting the additional path_corner with the speed change has solved my problem...
Posted 18 years ago2006-03-01 19:57:58 UTC
in How can I make stuff fall on me? Post #165842
Use func_doors and func_door_rotating for individual stuff like girders, ceiling tiles, light frames, etc
The only problem with func_door and func_door_rotating entities - unless I'm missing something(?) - is that if they hit the player they will reverse direction and return to their original position. In one of my levels I've got a func_door_rotating coke machine which, at one point, explodes and falls over. I had to go to great lengths to ensure that anybody actually standing under it was not in the way (either "blown out" by the explosion, or dead) when it "fell"; otherwise it bounced back up...
Posted 18 years ago2006-02-28 09:53:51 UTC
in HOW THE HELL!? Post #165487
I discovered one of my maps on a site that I certainly never submitted it to. It was actually taken from the site I placed it on before I signed up with TWHL, and was submitted under my username from that site.

I might not have minded too much, but it was submitted in an HL2DM area and it was "only" an HLDM map (LavaLab) -- somebody might have downloaded it and formed the opinion that I was an idiot for posting in the wrong place.

I contacted the site admins (I actally had to sign up with them first before I could actually send them a message) and they deleted it immediately...
Posted 18 years ago2006-02-27 06:56:15 UTC
in OH NOES! BEEDOGS! Post #165278
... and the weird thing is, when I saw the title of the thread, I figured you were talking about the HL critters. :D
Posted 18 years ago2006-02-27 06:53:42 UTC
in Getting stuck on elevator (func_train) Post #165277
An ORIGIN brush is only required when making an func_train that travels a very long distance, like 5000 units or more.
Indeed...

Whatever the cause of my problem, adding an ORIGIN brush to my func_train did NOT fix it.

:(

So it looks like I'm back to plan B; removing the speed change which appears to be the culprit...