Forum posts
2600 or such. So what?
Heyhey, why should I batch compile if compiling from Hammer is easy to work with? I'd take the little resource loss for granted just because it lets me compile faster... I also can jump straight back to Hammer after a test-run, without ever accessing another program.
That's just personal preference. Not a general rule or something that has to be done. Just like carving - if that works for you, do it.
Another, general, tip:
Save up on idea's. You might be able to use them later even while they're of no use to you right now. They can give inspiration or form great idea's when mixed up with others.
Also, don't stop working on a project to chase another, 'better', idea. Having finished something counts for much more than having thought up on a 'good' idea. Idea's are plenty, results are not. Go for the result, perhaps use the idea but otherwise save the idea for later, as stated above.
Just my point of view on idea's. Hope it helps you some.
That's just personal preference. Not a general rule or something that has to be done. Just like carving - if that works for you, do it.
Another, general, tip:
Save up on idea's. You might be able to use them later even while they're of no use to you right now. They can give inspiration or form great idea's when mixed up with others.
Also, don't stop working on a project to chase another, 'better', idea. Having finished something counts for much more than having thought up on a 'good' idea. Idea's are plenty, results are not. Go for the result, perhaps use the idea but otherwise save the idea for later, as stated above.
Just my point of view on idea's. Hope it helps you some.
1. Terrain in HL is a pain. Not only does creating smooth terrain cost a lot of time, there's also the buggy movement issue. I'd say, Keep It Simple Stupid. Is that smoothness really worth your time and polygons, or are those resources better invested otherwise?
Anyway, perhaps some clip brushes will help, and you should use lighting to your advantage to give the terrain more shape. But perhaps you can give a much simpler version of the terrain a similar look through lighting, so again, is that smoothness worth it?
2. Probably a problem with maximums or such? You're not getting the maximum amount of light styles per surface error?
3. Not the complex bits, at least not the small complex bits. About the lifted brushes, are those large and potentially effective at VIS-blocking? Then don't lift them - face splitting isn't that bad, especially not if it saves the engine from having to render a whole other region.
It may well be a more structural problem bytheway. Perhaps your layout doesn't allow so much detail, so you'll have to cut down on some less important details, or rework the layout a bit. It may also be usefull to just deny access to an area where the player can see a lot of poly's (as in, the player sees a lot of poly's when he's in corner A and looks at corner B. Instead of blocking sight to corner B, why not dump some obstacles in A so the player can't get there anymore?).
4. No. It only blocks light. This increases compile times radically though.
Anyway, perhaps some clip brushes will help, and you should use lighting to your advantage to give the terrain more shape. But perhaps you can give a much simpler version of the terrain a similar look through lighting, so again, is that smoothness worth it?
2. Probably a problem with maximums or such? You're not getting the maximum amount of light styles per surface error?
3. Not the complex bits, at least not the small complex bits. About the lifted brushes, are those large and potentially effective at VIS-blocking? Then don't lift them - face splitting isn't that bad, especially not if it saves the engine from having to render a whole other region.
It may well be a more structural problem bytheway. Perhaps your layout doesn't allow so much detail, so you'll have to cut down on some less important details, or rework the layout a bit. It may also be usefull to just deny access to an area where the player can see a lot of poly's (as in, the player sees a lot of poly's when he's in corner A and looks at corner B. Instead of blocking sight to corner B, why not dump some obstacles in A so the player can't get there anymore?).
4. No. It only blocks light. This increases compile times radically though.
I've learned Tycell a thing or two (actually more but hey) about working with Milkshape. Obviously this is his first model, but within 2 hours I think he's gotten the hang of it pretty well - it took me a month or so to learn the basics from the few tutorials around.
Perhaps I really should write a Milkshape tutorial one day...
Perhaps I really should write a Milkshape tutorial one day...
Looks very nice for a HL remake. Lighting indeed needs that little extra contrast and either scale is a bit too large or there's too little objects, but it looks good nevertheless.
There's other faces that don't contribute to the collision hull(s), such as those of func_illusionary entities.
There surely are collision nodes, afaik they're rooted into the bsp-tree just as the visual hull. Bsp's are nice thingies when it comes to picking the data you need to check collisions against or checking what to draw.
There surely are collision nodes, afaik they're rooted into the bsp-tree just as the visual hull. Bsp's are nice thingies when it comes to picking the data you need to check collisions against or checking what to draw.
Yer fast, Muzzleh... 
I guess you could jump from the HEV platform back up to that console, and with the elevator ladder you could jump down and catch it just before you hit the ground. At least that's what I remember from another HL speedrun I saw once.
Not that I'll ever do it that fast...
I guess you could jump from the HEV platform back up to that console, and with the elevator ladder you could jump down and catch it just before you hit the ground. At least that's what I remember from another HL speedrun I saw once.
Not that I'll ever do it that fast...
@Muzzle: Nope. Has nothing to do with the clipping tool, but the 'noclip' cheat should give you an idea of what this means. Afaik it's the brushes that get discarded when building the clipping hulls.
Incidentally I was investigating collision hulls yesterday, hence my knowledge here...
Incidentally I was investigating collision hulls yesterday, hence my knowledge here...
About CS maps, that's what the players like to play so give it them. Otherwise, don't map for them but for another public - or purpose. Basically you want a map to be found good by others (and granted, that's what we all like, right?) who just don't like your kind of maps. Are we pushing it into their face, are we going to whine about their 'wrong mindset' or are we going to take it to heart and either pick another market or change according to their demands?
// Not that I like those kind of maps, so I'd pick another market. My mapping purpose basically is to create something that's fun to play for a select group of friends/community people, so I don't care about those CS players with their different point of view on maps.
Oh, and we're all way too much upset about numbers and soulless ratings. They don't say nothing, just for that single reason called opinion.
My 2 cents.
// Not that I like those kind of maps, so I'd pick another market. My mapping purpose basically is to create something that's fun to play for a select group of friends/community people, so I don't care about those CS players with their different point of view on maps.
Oh, and we're all way too much upset about numbers and soulless ratings. They don't say nothing, just for that single reason called opinion.
My 2 cents.
Try something with length_constraints. I don't know on top of my head if you can change lengths but you surely can detach objects so they fall down. I believe you can also restore this attachment to jump the object back into original place, ready to be used again. Look at some of the give example maps in the sdk folders to find out.
You can also teleport objects bytheway, as seen in Kleiners lab level in HL2. Might be of use to you.
You can also teleport objects bytheway, as seen in Kleiners lab level in HL2. Might be of use to you.
Looks ok. A bit over-the-top use of colors, while the sky really fits with the mood of the level, the levels look itself is not so subtle.
Also, the missing snow on the road and other concrete objects is striking... And the BM logo placement is odd - why behind a pipe? Above the tunnel doors would fit better methinks. Other than that it looks fine though. Me likes the comm. tower.
Also, the missing snow on the road and other concrete objects is striking...
And the BM logo placement is odd - why behind a pipe? Above the tunnel doors would fit better methinks. Other than that it looks fine though. Me likes the comm. tower. The approach I often take is: if I admire someone's mapping abilities, I value their comments much more. If someone says negative things about my maps while his own maps are, in my eyes, of far less quality, then I usually don't care much about those comments.
Besides that, this community isn't the most mature one around, neither the most skilled. But it's one of the few quite active HL mapping communities these days, so yeah.
Besides that, this community isn't the most mature one around, neither the most skilled. But it's one of the few quite active HL mapping communities these days, so yeah.
You made sure you also changed that other scientists name according to the new target monster name? Might sound obvious but perhaps you forgot that?
Also, are you trying to get them to talk at the same time, or after one another?
Also, are you trying to get them to talk at the same time, or after one another?
Checking for problems often doesn't detect the problems that I stated in my previous post, as they only surface during the compile process. Check your compile logs, often there are references to the brush numbers that caused the problems.
I think you mean a 'gameplay' rating, sort of ripping the rating apart into sections like visuals, gameplay, technical excellence, and so on...
Might work, might not work. Personally I think comments convey this much better, but it might be a better indication than the current system (which honestly, I don't think is very well, maybe because of the limited range (1-5 feels much less solid than 1-10 to me) or because of previous flaws with the system...)
Might work, might not work. Personally I think comments convey this much better, but it might be a better indication than the current system (which honestly, I don't think is very well, maybe because of the limited range (1-5 feels much less solid than 1-10 to me) or because of previous flaws with the system...)
Probably, highly probably, caused by vertices off the grid (which happens a lot when you're carving with any brushes more complex than a cube, or with rotated brushes). Those vertices are put on the nearest grid point during the compile process, which sometimes results in non-planar (not completely flat) faces. That's a source of trouble...
I'd advise using multiple brushes in such situations, rather than shaping one single brush as much as possible. Also, clipping instead of carving, and vertex manipulation (though you'd better learn how to work with it before you go crazy with it, it's easy to create trouble with it).
I'd advise using multiple brushes in such situations, rather than shaping one single brush as much as possible. Also, clipping instead of carving, and vertex manipulation (though you'd better learn how to work with it before you go crazy with it, it's easy to create trouble with it).
You'll need a mapname.res file for that, one that contains the paths and filenames of the additional files. Look at the maps you got from those servers to see how it's done. They're just text files, nothing fancy or difficult (though embedding files into the .bsp is indeed much less cumbersome, but that's not possible with HL, only Source maps).
So, problem solved then?
If not, can you tell us the exact properties of the func_conveyor?
If not, can you tell us the exact properties of the func_conveyor?
The cubemaps are stored into the .bsp file itself, hence the need to restart the map after running that command. So unless you overwrite your .bsp (after a re-compile, for example), the cubemaps and HDR effects will stay with the map. They're part of it.
If it's all about a different model, then take a look at headcrab.cpp. The baby headcrab is class derived from the headcrab class, with the spawn and precache functions overridden from the headcrab one so it can have a different model. Might be much easier than just copying that whole barney file. I still think you need to add the things Muzzle said, but it surely saves you some code.
A bit like planetside but a lot better grin -What makes your idea better?
You can always make you game using the lower/cheaper options and then when its starts making money start developing a newer version with the best graphics etc.Creating a simple and fast-to-create prototype before starting production is a very usefull way to find out if your idea is actually fun to play - you don't want to waste thousands of dollars and years of time to find out the game just doesn't have that 'thing' that makes it fun to play. There's a nice article about prototyping on Gamasutra.com, where a team of students each created a game prototype per week. It resulted in some interesting game idea's, worth to work out. Most prototypes just didn't have it, though, which I think stresses the importance of an early test version or prototype.
However, if you start with a version of the game on one engine, it may take quite some effort to port over. If you'd only do that for better graphics, then I'm not sure if you've set your priorities right. Improving the gameplay each release is probably a better approach as it really adds the content, the solidness of the game. Visuals help sell a game and may improve the experience greatly, but they come at a high cost these days. It's difficult to compete with retail games on the visuals part, so perhaps it's better to focus on other area's.
I am more than willing to test anything you come up with, im currently learning Java and then C++ but i doubt id be of any use with it. I am very good at developing ideas, problem solving and research.I started with C++ and greatly like it over Java (which I have to use at school now), but of course I'm biased since I like raw performance and abilities over platform-independence and faster production times.
/rant
A scripted_sentence is usually the entity to make monsters talk. But I see now you want them to look like they talk only rather than having them talk for real?
Anyway, the action animation is executed once and then the target of that aiscripted_sequence is triggered. My idea would be to trigger a button, which in turn triggers the aiscripted_sequence. By controlling the state of the button you can break the loop, stopping the animations from repeating. The advantage of this setup over killing the entity is that you can reuse the loop later on.
I guess looking into the Repeatable flag might be usefull, too.
But scripted entities are sometimes a bit awkward to use. My way may not work correctly, I think it comes down to some experimenting anyway. I'm not really sure what you are trying to achieve either, since you've put the trigger to stop them from talking at their location, which says to me you want them to stop after one animation cycle... so perhaps it's good to explain what exactly you want to achieve?
Anyway, the action animation is executed once and then the target of that aiscripted_sequence is triggered. My idea would be to trigger a button, which in turn triggers the aiscripted_sequence. By controlling the state of the button you can break the loop, stopping the animations from repeating. The advantage of this setup over killing the entity is that you can reuse the loop later on.
I guess looking into the Repeatable flag might be usefull, too.
But scripted entities are sometimes a bit awkward to use. My way may not work correctly, I think it comes down to some experimenting anyway. I'm not really sure what you are trying to achieve either, since you've put the trigger to stop them from talking at their location, which says to me you want them to stop after one animation cycle... so perhaps it's good to explain what exactly you want to achieve?
For a shooter UT is quite a classic on LAN. We sometimes play it on the school network here.
Why point your light_environment straight down? Usually an angle creates much more interesting shadows... anyway, you can use other light entities to cast light on walls wherever you need them to. Don't use multiple light_environments, that's of no use: one will cause every sky brush to emit light like defined in there.
A func_train can follow a chain of path_corners, it's quite easy once you figure it out. Check Akilling.org for some interesting tutorials - there's about 3 or 4 about trains on the main page alone already.
As far as I know camera's aren't made to show players. Maybe there's a workaround or such, but I wouldn't give it much chance.
A func_train can follow a chain of path_corners, it's quite easy once you figure it out. Check Akilling.org for some interesting tutorials - there's about 3 or 4 about trains on the main page alone already.
As far as I know camera's aren't made to show players. Maybe there's a workaround or such, but I wouldn't give it much chance.
Try triggering their scripted_sentences through a looped multimanager, triggering them once in a while or so. If you want to be able to interrupt this cycle, make the multimanager trigger a button or trigger, of which you can control the state. This button or trigger should then trigger the multimanager again, so you've got a cycle, but once the state of this button is set to off, the cycle is interrupted.
I agree with the others here, one number for each weapon. The slot system is a nice way to deal with 10+ weapons, it let's you organize the different types better too, but 5 distinct weapons just don't go with one slot/number to cycle through.
Looks very neat though. Modelled that OICW yourself? Impressive.
Looks very neat though. Modelled that OICW yourself? Impressive.
Wouldn't it be better to rewrite the code so that there isn't a projectile that needs a speed, instead having a direct-hit code like most other weapons use? I don't know how difficult this would be but it'd be easier to work with in the end, don't you think?
As if that'll hold back people...
Programmers aren't hard to find. They're just not found in the HL communities as much. I think it's for obvious reasons: they didn't start with mapping and rolled into those communities - they started in different area's and are probably programming their own small games or other stuff.
Programmers aren't hard to find. They're just not found in the HL communities as much. I think it's for obvious reasons: they didn't start with mapping and rolled into those communities - they started in different area's and are probably programming their own small games or other stuff.
Probably a custom version of the model, where the grunt is duplicated, scaled up a bit, faces inverted and textured black.
It's called cell-shading, bytheway.
It's called cell-shading, bytheway.
wpoly's are 240x240 texels, you probably mean luxels, Kasp.
But then again, a polygon is cut at 15x15 luxels as far as I know...
As for your question, Elon, in such cases your rooms are divided into more than just one leaf. A cubic room would often end up as a leaf, as would a straight corridor. If you'd put a simple pillar in the room, it would split that room into 4 leafs, and for each of these leafs the compiler checks what other leafs can be seen (by tracing lines to them, done during the VIS process). The game looks up in the resulting table what leafs are visible from your current position, and then draws their content.
Too bad we can't see our leafs in HL, but you can to some extend predict how they will go, and influence this process with hint brushes (that force a leaf split). Anyway, more complex situations still follow the same rules, it may be more difficult for us to predict the leaf process though.
But then again, a polygon is cut at 15x15 luxels as far as I know...
As for your question, Elon, in such cases your rooms are divided into more than just one leaf. A cubic room would often end up as a leaf, as would a straight corridor. If you'd put a simple pillar in the room, it would split that room into 4 leafs, and for each of these leafs the compiler checks what other leafs can be seen (by tracing lines to them, done during the VIS process). The game looks up in the resulting table what leafs are visible from your current position, and then draws their content.
Too bad we can't see our leafs in HL, but you can to some extend predict how they will go, and influence this process with hint brushes (that force a leaf split). Anyway, more complex situations still follow the same rules, it may be more difficult for us to predict the leaf process though.
Ah, looking interesting. Nice stuff. Supposed to be a Greek temple or such?
Only thing I'd say is that the floor in shot 3 looks too flat, while the ceilings look very natural with those height and shape differences. Perhaps upping some floor parts and putting small steps between the different levels, just a small height difference.
Perhaps you should also work on those stone textures somewhat, they get repetetive after a while with those yellowish shades. Nothing too worse, but could get improved on.
Oh, and in shot 4, I'd say putting some lighting on that large symbol on the wall would give a nice effect rather than putting in light beams from the top only.
Keep it up man.
Only thing I'd say is that the floor in shot 3 looks too flat, while the ceilings look very natural with those height and shape differences. Perhaps upping some floor parts and putting small steps between the different levels, just a small height difference.
Perhaps you should also work on those stone textures somewhat, they get repetetive after a while with those yellowish shades. Nothing too worse, but could get improved on.
Oh, and in shot 4, I'd say putting some lighting on that large symbol on the wall would give a nice effect rather than putting in light beams from the top only.
Keep it up man.
Heh, today I've got some more spare time than others, and I've started something new. It's in the same style as Trirena, which I wanted to finish up some day but I figured there were some flaws to it that were hard to work around. So, I'm going with a new layout and a more impressive sort of area's. I hope it works out well.
As far as I know it's not possible with plain HL. In cut-scene's it's easy to simulate, but with a free moving player you'll need some custom code.
@Tycell: I got the original here, which I pathed up but still can't get to play. Perhaps there's some workaround for it but I haven't found it (yet?).
@Elon: I couldn't get Z to work but I really liked Z: Steel Soldiers, although it takes some time to get used to the way battles are fought there. Some more unit differences between the two sides would've been good, too, but I guess that's not what Z is about.
@Elon: I couldn't get Z to work but I really liked Z: Steel Soldiers, although it takes some time to get used to the way battles are fought there. Some more unit differences between the two sides would've been good, too, but I guess that's not what Z is about.
Interesting background. No game story, though.
What I mean is: this isn't the story that unrolls directly as you play. That story is what you experience as you go. You'll probably get to know bits and pieces of what you just wrote, but there's a more direct storyline.
Anyway, is there more to your mod than a different story, like a different gameplay? Doesn't have to be, but if there is anything particularly interesting besides this, I'd like to hear.
What I mean is: this isn't the story that unrolls directly as you play. That story is what you experience as you go. You'll probably get to know bits and pieces of what you just wrote, but there's a more direct storyline.
Anyway, is there more to your mod than a different story, like a different gameplay? Doesn't have to be, but if there is anything particularly interesting besides this, I'd like to hear.
Games I play, only now and then these days, that still hold up for me:
Raptor: Call of the Shadows
Warzone 2010
Raptor: Call of the Shadows
- Good graphics (for it's time, but still decent enough nowadays) and good fun to play.
- For some reason just addictingly fun to play.
Warzone 2010
- RTS with some very interesting concepts.
Uhm... so what is this project really about? You may want to give some more info if you want people to get interested...
May have been included in the .bsp file, otherwise they go in your model and material folders.
I also think it's known by now why that happens, but let's rehash it in a clear way:
Face splitting happens when two brushes touch or intersect. The surface of one is splitted into convex surfaces, so the touching surface can be safely removed.
If you were to tie this touching brush to an entity, the face splitting wouldn't occur, but there would also be a small part of that otherwise splitted face that is never seen.
In fact, face splitting happens between every brush that's in the same entity. You can see world brushes as being part of the big world entity here, as a matter of speaking. So for a railing, if they're part of the same entity, then splitting occurs and naturally also the unseen face removal.
The natural solution is then to put both brushes in different entities.
On a vaguely related note, putting too much opaque surfaces in front of each other (sprites and beams count as well here), you're filling the fillrate, which means, the scene needs to be recalculated for every of those surfaces. Needless to say, that hurts performance a lot once you've used enough layers. Polycounts don't matter here.
Not that most of us will ever do things like this, but hey.
Face splitting happens when two brushes touch or intersect. The surface of one is splitted into convex surfaces, so the touching surface can be safely removed.
If you were to tie this touching brush to an entity, the face splitting wouldn't occur, but there would also be a small part of that otherwise splitted face that is never seen.
In fact, face splitting happens between every brush that's in the same entity. You can see world brushes as being part of the big world entity here, as a matter of speaking. So for a railing, if they're part of the same entity, then splitting occurs and naturally also the unseen face removal.
The natural solution is then to put both brushes in different entities.
On a vaguely related note, putting too much opaque surfaces in front of each other (sprites and beams count as well here), you're filling the fillrate, which means, the scene needs to be recalculated for every of those surfaces. Needless to say, that hurts performance a lot once you've used enough layers. Polycounts don't matter here.
Not that most of us will ever do things like this, but hey.
What do you mean with that lighting talk? You want lightmaps on models, or such? Or bake the lighting in their textures beforehand (some HL2 turbine models have this)?
Probably multiple brushes. Curves take several brushes, you know, and in case of a texture change, you'll need another brush indeed.
Give overlays a try - they're more flexible than decals.
Probably multiple brushes. Curves take several brushes, you know, and in case of a texture change, you'll need another brush indeed.
Give overlays a try - they're more flexible than decals.
I found the inside shots to be very yellowish, not in a good way. You've used colored lighting too strong, try to tone it back somewhat to make it look more natural. The outside looks better, though that one is perhaps a bit too dark and it feels narrow in the meaning of limited - there seems to be nothing outside the rock wall boundary. Change the height of those rocks some more and add some stuff in the 3D skybox, like electricity poles (?) and generator housings at the top, for example. A few buildings or whatever is around those places should do.
I still think hand-picking maps is a better idea - some people (like me ;)) disable(d) ratings because of those rating spams, other maps get 5 stars for no good reason at all... the rating system is quite flawed here I think. But that may also depend on the maturity of the community or parts of it, maybe?
Actually, this top map feature resembles the 'featured' feature of sites like Mapcore and Thewall.de. Those are hand-picked as well, though they show the same projects for a longer time untill a better one comes by.
Actually, this top map feature resembles the 'featured' feature of sites like Mapcore and Thewall.de. Those are hand-picked as well, though they show the same projects for a longer time untill a better one comes by.
There's nothing that prevents a lockup caused by mirroring mirrors in Quake3? Wow...
Why use lots of polygons when you can overload the fillrate too? Give me some opaque faces and I'll brow a nightmare fps for ya without going over the top with faces.
@Strider: probably not, because it may take some technical insight before you can create a fps abomination. N00bs often only accidentally hit these limits. Seems like Murphey's law applies to them quite well...
@Strider: probably not, because it may take some technical insight before you can create a fps abomination. N00bs often only accidentally hit these limits. Seems like Murphey's law applies to them quite well...
I can't remember my first mistakes so much.
What I do remember though, is that the first few months I didn't know how to compile my maps... all I did was creating buildings and stuff in Hammer and stare at it. Fun times.
What I do remember though, is that the first few months I didn't know how to compile my maps... all I did was creating buildings and stuff in Hammer and stare at it. Fun times.
I program more than I play or map these days.
At the moment I'm programming a small game prototype, console styled, including a level script system. Fun stuff, just to see if my little game idea is fun to play.
At the moment I'm programming a small game prototype, console styled, including a level script system. Fun stuff, just to see if my little game idea is fun to play.
3D skyboxes really aren't high-tech stuff or such, we've programmed such a feature for our harbour simulation at school too. Now I don't know how difficult resetting the z-buffer is with the HL code, so it still looks like some work to me.
Bytheway, is your 3D skybox always being rendered or only when there's a skybrush in the visibility set?
Nevertheless, nice you've got this working. That'll make building some exterior area's a much less painfull job.
Bytheway, is your 3D skybox always being rendered or only when there's a skybrush in the visibility set?
Nevertheless, nice you've got this working. That'll make building some exterior area's a much less painfull job.
No major game has ever been made purely over the internetOh, it's not impossible, but it's just not something to be taken lightly. Take a look at 0 A.D., for example - it surely is possible. Note that what you see there is the result of about 4 - 5 years of work and it's not finished yet, so again, it's not as easy as it looks. On the other hand, it's not as impossible as it looks, either.