Forum posts

I can't tell from your words, but the master of the 4 button should be a multisource triggered by the 8 button. The 8 button shouldn't itself be the master of 4.

The problem was, indeed, a bad link, pepper.

I downloaded >300mb of XSI EXP stuff after searching the world over for someone who didn't want to charge me for the file or the download. Got it from zdnet (God bless the Limeys). Also got the Valve Source addon. The activation went as advertised and I can now export smds, apparently in several flavors. Have to see how to learn to use XSI now.

Is anyone doing modeling using something other than XSI? The freebey download is apparently no longer supported by SoftImage. It required activation for smd exporting and the activation page isn't there anymore. The latest version runs 500USD, which is a bit steep for playing around.

I've tried Blender and successfully done 1 test model. Blender exports only a reference model smd and I had to create several text files (qc, a couple more smds, etc.) and several batch files. Got it done but it was sorta complicated.

Milkshape says it's expired and doesn't support smd export until registered. I just downloaded it but that appears to be part of the pitch. The download page says saving and exporting are disabled. So I can't tell what smds it will export, etc., unless I pay up. As I don't feel like forking over 25USD till I know what it'll do, I'd like to find out:

• what other modeling programs others are using
• if other progs (e.g., Milkshape) export more than reference smds

Suggestions? Other help?

Not to be too cynical, but they're advertising for some pretty important positions in Aug 2005 to have an advertised release of "early 2006." With a mod that ambitious, I have to wonder at the schedule.

You can choose from some 18 or so sky textures that come with HL. None of 'em look like neighborhoods, I'm afraid. There are, however, dozens (100s?) of sky textures on the web which you can download. Google for them.

You can also create your own, but it's a pain. A big pain.

Oof! My wrist began hurting. It was really difficult to lift and reposition the mouse.

Gave up on level 8.

It's easier to get help if you explain what it is you're trying to do.

However, with regard to using a multimanager, in HL2, you can use the outputs from a triggering entity instead.

http://developer.valvesoftware.com/wiki/Converting_Entities is a good place to start.

As relayed to Elon, the problem is with the game_player_hurt.

In Elon's medkit, it's triggered by a path_corner. However, a game_player_hurt, to apply health to a player (or hurt them), has to "know" who triggered the hurt event. By using a path_corner's fire-on-pass, it's the func_train and not the player that initiates the event.

It's pretty subtle, but the entity description for game_player_hurt says it's applied to the player triggering the event. Not obvious at all, but logical.

I gave Elon some suggestions, such as naming a master for the game_player_hurt, triggering the game_player_hurt directly and disabling the master when the last path_corner is reached.

PM sent, Elon. Hopefully, you know that by now!

I looked at his map. It has a game_player_hurt with a name and negative damage.

I built a quick map with a trigger_hurt (to give some damage to play with) and a button which triggers a game_player_hurt with negative damage.

It works as advertised.

Your problem must be in your logic, Elon.

The "Leaks Explained" article url'd above explains how to find a place to start after loading a point file.

I suggest that, as a courtesy, for maps in the vault which aren't labeled as HL, HL2, etc., the author state in the description what mod (such as SvenCoop) is needed to play.

Can't tell from the jpg. It's a bit small.

However, with the layout you have, you could use the "big block" method. Surround everything but one room with a big brush of some obvious texture. It may take a couple of brushes. They shouldn't be hollow and they should completely surround a couple of rooms plus hallways, etc. By surrounding a room with a big brush, any leaks in that room will be temporarily eliminated.

Make sure your player_start is not embedded in a block!

To save time, compile without vis or rad, just csg and bsp. Just look for the bsp result. If it says you have a leak, keep surrounding parts of what's left with big brushes until you don't have a leak.

Then make one of the big brushes a little smaller until the leak appears again. The leak is in the area you uncovered last. Look carefully in the area for the leak. Or load the point file which, with everything pretty much blocked off, should be easier to follow.

Fix the leak and compile again without changing your blocks to make sure you stopped the leak and to ensure there aren't multiple leaks (which you may very well have).

Keep reducing the size of blocks (or delete them) until you have all the leaks fixed.

Suggestion: Compile often! Say after adding just a few brushes. If you turn off vis and rad for those "quick" compiles, they'll go very quickly. With a map the size of yours, I would've compiled dozens of times. Taking 15 seconds to do a quick compile a dozen times is only a few minutes, a much shorter time than you're spending now finding a leak (or multiple leaks).

Much better on the rubble. Looks much more like it "flowed" into position.

Create a brush for your train, create an origin brush, group the origin and the train brush, and tie the group to a func_tracktrain. Give the tracktrain a name.

--> for the tracktrain entity, under properties/Class info/Change angles, select "Never (fixed orientation)" and tick the "Fixed orientation" flag under the Flags tab. This will keep the train in the orientation in which you build it and prevent it from changing angles at path_track nodes.

Also, set the "First stop target" as the name of the first path_track, say "pc1."

Setup path_track entities as you would path_corners in HL. I setup 2 path_tracks named pc1 and pc2, each with a "Next stop" of the other path_track.

Trigger the tracktrain by name to start it moving.

E.g., with a tracktrain named "train1," create a func_button with an output of "On Pressed, train1, StartForward."

I discovered all this by just playing around for 10 minutes. Set up as described above, the train stays in the same orientation and goes back and forth between the path_tracks, just as it would in HL1.

Just experiment a bit.

http://twhl.co.za/tutorial.php?id=40 gives a lot of important dimensions.

The dimensions give you minimum heights and widths to start with but, as mentioned above, the size of something has to look right in its surroundings.

http://developer.valvesoftware.com/wiki/Leaks_explained does a good job with techniques for finding leaks. If HL2 but applies equally to HL1.

Ensure the textures meet well (if not perfectly) at the edge between flat faces and avoid lighting the walls from the side. The textures on either side of an edge should be illuminated the same to avoid highlighting the edge.

Mismatched textures at edges and lighting that reveals those edges emphasizes the intersection between flat surfaces.

If the cave-in is intended to cover the metal walkway on the left, the interface dividing rock from metal would be more sloped and rubble on the walkway would be spread toward the viewer in this picture.

The entire pile of rubble would be sloped (google for "angle of repose") with few if any "overhangs" as shown on the left a couple of feet above the walkway.

Rubble would not meet the wall on the left at a sharp angle.

Pour a couple of handfulls of rice or sugarcubes onto the end of an eggcarton or into the end of a short piece of toiletpaper tube and look how the "rubble" spreads to against the "walls" and "floor" and mimic it.

Let gravity be your designer.

Very impressive, RM! Looks like you're hooked up with an on-going concern. Thanks for the heads-up!

I thought it was different styles of light, not their names...

It's a combination, Mephs: if they switch on and off together, they're one lightmap.

It may help if you think about what the lighting engine does during complilation to figure out how your textures will look when the map is played.

In general..

1. For speed's sake, there is no actual lighting that's calculated during the map-play itself, with only a few exceptions (your flashlight, rocket flame as it travels along and, I think, the power-up light the alien slave does before it fires. Stuff like that). The various brightnesses of each brush (or texture leaf - just an educated guess there) from "fixed" lights are calculated during compilation.

2. As lights are turned on and off during map-play, those various precalculated texture brightnesses are rendered.

3. So, during compilation, each combination of brightness from the various on-or-off lights that fall on a brush is calculated to store for display during the play.

4. If a bunch of lights all have the same name, the lighting engine knows they will all be on at once, or off at once. It only has to calculate the brightness at a brush for that one bunch as on or off.

5. The lighting engine then calculates the various combinations of brightnesses for all the "bunches" of lights that may illuminate a brush. The map is capable of storing only a limited number of brightnesses for each brush.

6. It's apparent the lighting engine doesn't evaluate the switch logic to determine how lights are turned on and off, it just assumes each light with a different name may be switched on or off independently and counts that toward the total (limited) number of ways a brush may be lit.

7. If you have a lot of lights with different names, whether they're switched on and off as a group, each light counts as a separate contribution to the total number of combinations allowed.

Since you posted to the HL Design Questions forum, your question is what?

If bush strikes them they will strike bush

Actually, if Bush strikes them, they'll strike innocent people. It would be great if they did strike Bush.

It would be nice if we could get the terrorists to ask people if they agreed with Bush or not, and retaliate as appropriate.

It looks like you have a big solid cube with no inside.

Make sure you have an open area in the map somewhere.

Gotta consider Doom and Quake.

I still play Doom and Quake once in a while. And it still takes forever to kill that (Quake) huge white blue-flame shooting thing.

Yeah, that's good stuff.

I'm not saying it does harm. And certainly don't delete it just 'cuz I don't like it. I just said it's my personal preference. An extra click? I'm an old guy and may not be around that much longer. An extra click is milliseconds out of my life!

Hey, if you like it and it serves your purpose, that's cool.

You are doing a nice job with the site.

Just from years of experience, I'd suggest cleaning up things until you get no compile errors. Besides, it'll take maybe 1 minute to fix.

You think you have texlight problems and you're getting warnings about your texlights file. Something ring a bell here? Hmm? :

Also, funny things can happen if you have a brush that overlaps at all with a brush with a texlight texture applied.

Also, you can't have a texlight texture applied to an entity and expect normal lighting.

Just things to check.

Personally, I don't care for sites with flash intros or pages with just links to get into the site. I click on a link to get to the site. Then I have to click on a link to get to the site.. what's the point?

IMO

Excellent, excellent!

For continued fun in that vein, take a look at the www.engrish.com site mentioned.

You have some weird stuff going on.

for one, hlvis doesn't appear to be run during your compile. Notice the warning "..no vis information.."

Also, it appears you have duplicate entries in your lights.rad file. I suggest cleaning that up, at a minimum.

You using Hammer to compile or batch file or..? Take a look to see where you've missed running hlvis.

You might be able to make the water a func_door so you can do the texturing. Make it passable so it can be walked through.

Put an invisible trigger_hurt in the area where the tub fills to and trigger it with whatever you use to trigger the func_door.

If you have the breakable target a multi-manager, the multi-manager can toggle the two light entities directly. You don't need trigger-relays for that. Just give each light a name and target each by name with multi-manager entries.

Also, the Repeat Rate is supposed to be in milliseconds.

With a repeat rate of 0.001, you're requesting the sequence be run every 0.001 milliseconds, or a million times a second.

Depending on the sequence, maybe once every 4 or 5 seconds (or longer) which would be a repeat rate of 4000 or 5000 (milliseconds).

Just to let you know what's going on..

when hammer gets confused, it causes windows to give misleading error messages

Actually, that's not true. Hammer does not 'cause' windows to give misleading messages. Windows was asked to run one of the ZHLT tools (HLCSG.EXE or one of the others) and it did that successfully. HLCSG.EXE was loaded and it ran.

However, after it was loaded and running, HLCSG reported it could not execute the requested command. Windows did not have an error; HLCSG.EXE did. It appears to be confusing because of the way Hammer reports the results.

Take 15 minutes and read the tutorial on Changing Levels. All your questions are addressed there.

SM-

The smilies on forums.php look the same with IE6 (1024x768 and 1152x864)) & Windows XP. I.e., row of 8, row of 2, row of 8.. ( 6 rows total).

Using Safari under Mac OSX at 1440x900 and 1024x768, there are 3 rows of 10.

SM- No special settings I know of. This is at my work station so it's under Windows 2000 Pro but I wouldn't think that'd make any difference.

I'll check again when I get home in a couple hours (Windows XP and Mac Safari) and compare.

It isn't a big deal to me, by the way. I mentioned it only to corroborate someone else who posted saying something similar.

SM - I'm using IE6 at 1024x768.

I don't know what algorithm is used, but I get six rows of smilies in the "Post a reply" box also.

A row of 8, a row of 2, a row of 8, a row of 2..

And the Post button is quite a bit right of center.

It'd be nice if the map vault had << and >> nav buttons at the bottom of the page (which is where I normally am when looking at each page for something).

I would strongly advise you not to delete your zhlt tools. If you can compile other maps without any problem, it's probably not corrupt tools.

If you have sky texture in your map and no lights, you'll get full brightness everywhere. Could that be the problem?

Congratulations!

Nice job, 7M. Gettin' into the php thing, eh?

I don't have an IDE (Integrated Development Environment) right now as I just upgraded machines and my old Borland software won't run on XP.

I'll probably get MS Visual C++ here pretty soon.

Getting a free compiler is fine for starters, PaLO. Get a decent "How To" book (lots of those come with a compiler). Work through it thoroughly.

Remember, though, with regard to compilers, that you pretty much get what you pay for. That is, a free compiler may be just a compiler - like hlbsp.exe. No interface, no editor, no WYSIWYG. You may have to edit files in Notepad or the like and feed the compiler manually.

The concept is similar to HL mapping, though. A GUI interface (integrated editor, debugger, project manager) like VHE, a compiler that you can launch from the interface or commandline like hlbsp, and the final platform your product is to run under - HL for mapping, Windows for C/C++.

If you want to mess with the HL SDK, be forewarned. Just setting up your compiler, batch files, etc., to compile it successfully before you even mess with the code will be a pretty big challenge. It would be similar to someone giving you a .rmf to modify that should run under Steam. You haven't a clue at first as to how to set up your compiler for steam. Only setting up an SDK is a lot harder.

Working with the HL SDK means you'll be modifying code to compile into hl.exe or one of its dlls (you'll have to figure out where the code is that does what you want to change). Then, after you compile, you'll run HL to see if you did what you want to do. And there's very little you can do with hl.exe or its dlls to find out why it doesn't work, particularly because it's working behind an OpenGL or DirectX mask. You ever try to get out of a graphics program that isn't working right?? And it won't, the first time.

Spend time in the C and C++ programming newsgroups and programming forums like you would with HL mapping. There are programming communities out there very similar to TWHL.

If you do get into C/C++ programming, I recommend sticking with Microsoft products. That really hurts to say because I do not like Microsoft Corp. and I really love Borland products. However, when you google for help, 90% of it is going to be for Microsoft stuff and developer.microsoft.com has most of the manuals available online.

Hope that helps.

BJ... since when has CP been posting as me?

Sorry about that! Mea culpa, mea culpa, mea culpa.

Once you've got the basics of C++ down, you'll need the Half-Life SDK.

I've been working in C and C++ for about 25 years and I suggest that once you get the basics down, play around with advanced stuff for maybe 3 to 6 months before even thinking about messing with the SDK.

Compiling and debugging dll's is not for the faint of heart.

If you're serious about it, visit http://msdn.microsoft.com/visualc. A development environment capable of working efficiently with the SDK will run you about 100 to 200USD.

For the stationary platforms, you don't need an entity. For the moving ones you can use a func_train or a func_rotating.

/me remembers Janis Joplin..

"Lord, won't you buy me a color PC. The monsters of Half-Life are trying to find me.."