STL provides a string class. Not a 'fundamental' type perhaps, but a usefull one nonetheless. It's member function c_str() returns a char* just in case you need that for function passing and whatnot.
I usually don't work with char arrays, but char pointers instead. Though these seem to be similar, using char* rather than char[] gives different results. For example, the == operator does actually compare the strings they contain:
char* a = "hello";
char* b = "hello";
if(a == b)
cout << "True";
else
cout << "False";
This prints True to screen. Changing b to "hello1" gives False. Comparing a string (#include <string>) with a char* gives the same results.
As far as I understand, the == operator compares char pointers as if they were null-terminated strings, comparing char by char, while it compares char arrays by their adresses.
I tested casting char arrays to char pointers, too, which gave interesting results:
((char*)s == (char*)t) == false, while
((char*)s[0] == (char*)t[0]) == true, provided both are assigned the same string value.
Not everything is clear to me, but there's a subtle difference between arrays and pointers. &s, for example, is the adress of the array, and while it's the same adress as the first element in the array (&s[0]), it's not of the same type: (&s + 1 == &s[0] + 1) == false.
Forum posts
Ant... lion? Hehe... hehehe... 
Those checkboxes are for texture alignment. They're not magical stuff - in the end it's just texture coordinates for the engine to handle, all the same.
Usually, you only notice the difference on angled faces. With world alignment, all textures are aligned along the axis. If you have an angled face, the texture looks stretched (because, the texture is applied as if you were looking at it from one of the 2D views - from that particular view, the texture looks ok, but an angled face is always longer than you can see in the 2D view).
Face alignment aligns the texture taking the surface normal (direction) into account, solving the stretching problem.
This is why flat, axis-aligned surfaces have both checkboxes checked, but other surfaces can have only one checked.
Aanyway, onto those surface extends, those are usually caused by extreme texture scales. Above mentioned alignment modes have no effect on this as far as I know.
Usually, you only notice the difference on angled faces. With world alignment, all textures are aligned along the axis. If you have an angled face, the texture looks stretched (because, the texture is applied as if you were looking at it from one of the 2D views - from that particular view, the texture looks ok, but an angled face is always longer than you can see in the 2D view).
Face alignment aligns the texture taking the surface normal (direction) into account, solving the stretching problem.
This is why flat, axis-aligned surfaces have both checkboxes checked, but other surfaces can have only one checked.
Aanyway, onto those surface extends, those are usually caused by extreme texture scales. Above mentioned alignment modes have no effect on this as far as I know.
@BJ: I assumed he meant "s" rather than a generic string, but even then, the == operator works just fine. Both for char* as for string. Unless you really need non-case-sensitive checks. 
I like that elite combine smiley. Very recognizable.
ROFL!
Now I just need the solution for the second task.I've given you some pseudocode, it shouldn't be too hard from there.
1 idea, 2 minutes, 3 smileys (well, in total now :P):
Nice Kirby bytheway.
I had a few minutes to spare... 
Take a look at the properties of the path_corner entity. I'm sure the teleport flag and the wait-here property will be interesting to you.
1 is pretty much a mathematical problem, one which I'm not going to solve.
2 is easier. A possible solution would be to use two loops, the outer loop going over all rows and the inner loop checking a decreasing amount of cells. Some pseudocode to get you started:
string matrix[width][height];
for(i = 0; i < height - 1; i++)
for(j = 0; j < width - i - 1; j++)
if(matrix[j][i] == "s")
return true;
2 is easier. A possible solution would be to use two loops, the outer loop going over all rows and the inner loop checking a decreasing amount of cells. Some pseudocode to get you started:
string matrix[width][height];
for(i = 0; i < height - 1; i++)
for(j = 0; j < width - i - 1; j++)
if(matrix[j][i] == "s")
return true;
I don't agree with you, Tosse.
I've seen too much trouble come from careless carving. I assume you didn't test carving a wall that touches the void, so you didn't stumble on a microscopic leak or something else? Also, I assume you didn't compare poly counts with a non-carved equivalent map?
And is the resulting mess really that easy to work with when the map gets larger and more complex? I'm afraid it's getting quite difficult to maintain such a map over time.
But, in the end, it's about the result, not the tools used, so if you can carve without taking down performance or making it difficult for yourself to keep working on a map, then I see little reason not to use a tool. I just don't find the carving tool very usefull when I compare it's advantages against it's disadvantages, and those of other tools.
I've seen too much trouble come from careless carving. I assume you didn't test carving a wall that touches the void, so you didn't stumble on a microscopic leak or something else? Also, I assume you didn't compare poly counts with a non-carved equivalent map?
And is the resulting mess really that easy to work with when the map gets larger and more complex? I'm afraid it's getting quite difficult to maintain such a map over time.
But, in the end, it's about the result, not the tools used, so if you can carve without taking down performance or making it difficult for yourself to keep working on a map, then I see little reason not to use a tool. I just don't find the carving tool very usefull when I compare it's advantages against it's disadvantages, and those of other tools.
I think they made some entities for that, Muzzle. Why let mappers do the hard job when the coders can make it easy for them once and for all?
The compile tools may not snap vertices to the grid, but Hammer does when your map is saved to the .map format - which happens to be the file used by the compile tools.
This can indeed be a source of trouble sometimes - surfaces that seemed to be right (and probably were) get messed up after some vertices are corrected.
So, it's a little more than just a good habit to keep the grid in mind.
This can indeed be a source of trouble sometimes - surfaces that seemed to be right (and probably were) get messed up after some vertices are corrected.
So, it's a little more than just a good habit to keep the grid in mind.
but will also make some most annoying soundsSuch as... splash?
Nah, I just saw why you asked this question. That map turned out pretty nice man. I'm not sure if those floating objects really added something though, they were more annoying for movement and looked too dark compared to the slime, but hey... you did a great rowleyjob, so I shouldn't complain...
Look, now we're getting somewhere. Good to see such a media burst.
Sketches and models look very promising, I'm looking forward to see more work. Are the code and level-design departments keeping up the pace too?
Oh, btw, get rid of that logo page. Only slows people down.
Sketches and models look very promising, I'm looking forward to see more work. Are the code and level-design departments keeping up the pace too?
Oh, btw, get rid of that logo page. Only slows people down.
HL2 materials are much more advanced than HL textures - special properties like animation or movement are defined within the .vmt files, not through texture names.
A scrolling texture is done as following:
[quote]
"LightmappedGeneric"
{
For more info, check the Valve wiki.
A scrolling texture is done as following:
[quote]
"LightmappedGeneric"
{
"$basetexture" "vtfname""Proxies"
{
"TextureScroll"
{
"texturescrollvar" "$texture2transform"
"texturescrollrate" 0.1
"texturescrollangle" 90
}
}For more info, check the Valve wiki.
They will always degenerate after a certain time, unless they're held in those energy fields. No way around that.
What were you trying to achieve, then?
What were you trying to achieve, then?
As far as I know, it's pretty difficult to detect the round start in CS, but wasn't there a trick for it with a door or such?
Once you get that sorted out, darkphoenix' method will work just fine - an env_global that always sets the master to on should be triggered on round-start, and an env_global that always sets the master to off should be triggered when you run through the specific trigger_multiple.
Once you get that sorted out, darkphoenix' method will work just fine - an env_global that always sets the master to on should be triggered on round-start, and an env_global that always sets the master to off should be triggered when you run through the specific trigger_multiple.
The solution is simple. Use the advanced entity mode and enter the pitch yaw roll key with a value yourself. Look up in normal HL entities how the key is actually called.
Alternately, you can modify the spirit.fgd.
Another, evil, solution would be to manually type the key into the .map, .rmf or .bsp file...
Alternately, you can modify the spirit.fgd.
Another, evil, solution would be to manually type the key into the .map, .rmf or .bsp file...
You may want to compile your map soon - 1024 and 512 are pretty large measurements. A normal hallway is usually around 128 units high.
Compiling often helps detecting leaks as soon as possible, and working on the grid helps preventing them. From what I've heard, leaks aren't an issue for Unreal mappers, right? It may be some getting used to...
Compiling often helps detecting leaks as soon as possible, and working on the grid helps preventing them. From what I've heard, leaks aren't an issue for Unreal mappers, right? It may be some getting used to...
You could also use a beam, with a chain-like sprite. Always faces the camera so there's no need for a second layer, perhaps the quality loss doesn't look that bad with that distance... an advantage would be the more flexible movement beams allow you...
Heh heh, the old argument about carving/clipping/vertex manipulation pops up again, complete with name calling and insulting.
Just use the tools you're comfortable with, as long as you're able to create good maps with it. A close look at HL (and HL2) maps reveals that these aren't always up to par to 'our technical standards'. While it certainly helps to know the advantages and disadvantages of the tools you work with, it's not really that important in the end (assuming you aren't misusing your tools in such ways that they cause significant performance or workability issues...).
Oh, Kasp: VM operations would be to create a brush, select the yellow nodes on one side, press Ctrl + F, move the corner vertices, and repeat those three actions for the other side. Still not really a timesaver, but not taking more brushes.
Just use the tools you're comfortable with, as long as you're able to create good maps with it. A close look at HL (and HL2) maps reveals that these aren't always up to par to 'our technical standards'. While it certainly helps to know the advantages and disadvantages of the tools you work with, it's not really that important in the end (assuming you aren't misusing your tools in such ways that they cause significant performance or workability issues...).
Oh, Kasp: VM operations would be to create a brush, select the yellow nodes on one side, press Ctrl + F, move the corner vertices, and repeat those three actions for the other side. Still not really a timesaver, but not taking more brushes.
Just something odd that messes up the decompiler. Those programs can contain bugs, too...
This last one was really shocking. Point lights and opaque blue water? I thought only n00bs did that!6 years ago... new technology... deadlines...
We've got a lot more time on our hands to get the most out of an engine, since we don't have deadlines tied to our salary and all. Plus, we're with many mappers, sharing knowledge. Well, you get the idea, you can't simply compare things that easily.
As far as I know, the Express editition doesn't include windows libraries so there's no way to compile programs or .dll's that make use of those libraries. You may want to get another version to compile the code. You should be able to compile the .dll's with the 2003 edition, personally I use MSV.NET 6.0 which is capable of handling it.
Heh, fun. Looks like the top crate almost hits the ceiling, perhaps that has some influence?
Looks like the top crate almost hits the ceiling, perhaps that has some influence?For whatever reason, rotating multiple compex objects using CTRL-M will cause 100's of Erroneous "Invalid" errors!The actual reason is as following:
Surfaces must be planar, that is, completely flat. Programming-wise, grid locations are integers (0, 1, 2, etc), not floats (0.5, 2.0, etc). As a result, rotating brushes may cause vertices to go off the grid. In the editor, that's fine, seemingly they're treated as floats there. But the compilers will cast these to integers, causing some (usually minor) differences, often enough to make surfaces not completely planar. That's where errors start popping up.
So, I would advise not to stick to degrees as a valuable measurement. Personally I don't really stick to precise and exact placement of objects anymore, as it often results in over-tidy, too clean feeling maps. In real-life, not everything matches precisely, not everything is rotated perfectly or constructed exactly to the millimeter. Take some care with the technical aspects for performance and workability reasons, but don't limit yourself with artificial rules like tidyness. Of course, sometimes there's a place for these, some map themes require tidy placement, but keep in mind it's just a rule that you should break when you need to.
Edit: there's another kind of overlap consisting of simultaneous brush faces occupying the same place in the map. This should of course be avoided!It's called z-fighting, two surfaces 'fighting' to be drawn first. May also happen on large distances, when the distance between each other is relatively small compared to their distance to you. Not a pretty sight indeed.
I don't know what that means. File, meaning the model file? I need to know why it's black.Had nothing to do with your problem, but with the fake .png that really is a .bmp... which is evil when used on the web. The screenshot hardly shows anything anyway since it's pretty small too...
Nah, no, a torus isn't hollow per definition. Your donut is fine.
Binding +showbudget to a key to bring up the nice budget panel is a handy thing, too... tells much more than just the fps.
Of course, it happens, and there's nothing wrong with it, but a too low ratio isn't really encouraging in the end...
welcome to my world. i've finished a whopping 13% of my maps.That's actually a high finish ratio...
With the ever so powerful CPUs Intel and AMD are churning out, I am not sure whether a physics card would be necessary.There's a limit to the amount of physics to process when you also have to run AI routines and a lot of other stuff on it at the same time. In the past, before 3D cards existed, the rendering would be run on the CPU as well.
Now I agree with you when you doubt it's usefullness, as not every game needs physics as much as rendering, but it might be a nice addition anyway. Perhaps it'll stimulate some innovation in games?
As for the review, fair review, but I don't agree with the author on all parts. Especially the story - there's a lot of info for the observant ones, which I think is a sort of reward for those that seek it. The Combine walls weren't a weapon against Gordon - to me it was obvious it was their way to slowly process earths capitals. And the unknown things leave room for speculation. I do agree that the end was rather abrubt and less satisfying though.
Oh well, it's his review, not mine, and it's interesting to see how others think about games, so yeah...
How about blocking off area's in those large area's, like the Combine did in the train station at HL2's start? Or some collapsed parts (though that would probably mean you'd have to create more damaged area's to keep the map consistent).
Obviously, I prefer Carceri. Especially the outside looks nice. The inside looks interesting but at the same time monotone because of the repetetious architecture parts (damaged parts would definitely 'break' it up there) and it's essentially one playable plane. I prefer multi-leveled combat.
As for modern transport being out of the question... a racing part with the sandbuggy through an ancient temple/palace doesn't sound too bad too me...
Obviously, I prefer Carceri. Especially the outside looks nice. The inside looks interesting but at the same time monotone because of the repetetious architecture parts (damaged parts would definitely 'break' it up there) and it's essentially one playable plane. I prefer multi-leveled combat.
As for modern transport being out of the question... a racing part with the sandbuggy through an ancient temple/palace doesn't sound too bad too me...
You can use both XSI and Milkshape for both engines - modelling packages usually aren't made for games specifically, and even when they are there's usually an exporter available.
Personally I stick to Milkshape, as I only do low-poly models. For characters and such, 3ds Max or XSI are more appropriate, and of course you can use them for low-poly models as well.
Personally I stick to Milkshape, as I only do low-poly models. For characters and such, 3ds Max or XSI are more appropriate, and of course you can use them for low-poly models as well.
Might be an auto-detecting system for unknown, porbably alien and hostile, .dll's in place?
Of course you're right...
Of course you're right...
I didn't have any problems with them when I put them in my HL folders when I still didn't use Steam, but backing up the original ones (do they actually overwrite any?) is never a bad idea.
Just open the project file or the solution file with Visual Studio. Then, I'd recommend compiling it first to check if everything works as intended. You may need to change a few things to get it working with your compiler (at least I had to, and several others judging by the articles on Wavelength), more info on that can be found here: Building the Half-Life DLLs with the Microsoft Command-Line Compiler.
Hey, finally someone who read the boards descriptions.
Feel free to ask your questions in the Engine Discussion boards, those are the question boards.
Feel free to ask your questions in the Engine Discussion boards, those are the question boards.
Check the material files (.vmt), this is a material property. It's easy to copy an existing .vmt, rename it and change it's properties - you can simply use the already existing textures (.vtf), all you need to do is to include this custom .vmt with the map.
First, there's no need for swearing.
Second, get Steam (and yes, Steam contains the .dll's that are responsible for the transparant model rendering).
Second, get Steam (and yes, Steam contains the .dll's that are responsible for the transparant model rendering).
The client .dll contains the client-side code, and since a HL server doesn't care about the color of his clients huds, you can feel safe about that.
That shouldn't be necessasy actually, the wad name without extension suffices. I'm with Kasp here: there's probably something else wrong.
Have you checked this site already: ten four? Many mod reviews over there...
I meant, they add to the square feeling of the map. Rounded corners won't do the trick (they probably look out of place as a parking lot itself is indeed usually square) - rotating the parking lot on itself will do, I think.
That's good to hear. Luckily a first reaction isn't always the final reaction.
Yes, I received yours. Sorry I didn't reply - I've written a new journal entry now in which I said thanks, perhaps it would've been better to reply immediatly by PM. Well, thanks again.
Relationships go deeper than we think when we still have them, yeah... one of my best friends died last week and was buried today. Man, it seems only then you know who you miss. I'm so glad God is there for us to help us through when we need it... and that He provides good times too.
Oh yeah, Seventh, phone numbers... lemme see... ow, I still remember it, though vaguely. The tunes I used to hear while calling still stick to my head sometimes...