Forum posts

-wadinclude is abit obsolete since all it does is bundle a .wad file into the map. Of course for Source .wad files aren't used anymore and the materials are individual so you have to include each of them.

Map analyst is also another viable alternative to BSPzip. I'm not familiar with the differences between them; they should be functionally the same. You're going to have to use an external program from hammer, though, there is no internal function for bundling files (I suppose you could add a BSPzip parameter to advanced compile options, but that'd take abit of time and effort to work properly, easier to just use a GUI interface I think!)

You need to bspzip them. Commandline is abit tedious so you can use a program called Pakrat for an easier interface.

I've had a lot of fun with BC2:V so far but what do you think about the maps? They seem abit unbalanced in places. And one of them is a complete clusterfuck for the attacking team.

I've been playing SimCity 4 (in multiplayer o_O)

Specifically, you have to send it a 'skin' input and the skin you want it to change to to get dynamic props' skins to change.

they'll be waiting a while

No, prop models won't split brushes beneath them so it's good to avoid splitting and other nasty things which happen during BSP.

Yes; source has a defined limit on brushes, brush faces, verts etc. Also when you func_detail things and they touch world brushes they create waterindices/t-junctions which can prevent a map from compiling at all if you get too many. Converting everything to a prop_static significantly reduces these counts but won't impact performance, necessarily. Also the difference is that props are vertexlit or lit from their origin while brushes are lightmapped, so the lighting on props looks much worse. You can avoid this in the orangebox by using -staticproppolys and -staticproplighting in the vrad parameters, although you might have to split your model into a few pieces instead of one giant brush.

I hope you didn't speak too soon

Could an administrator clean up in this mess of a thread?

Yeah, I'll get right on that...

[m]not...[/m]

At least Dimbark is taking it all in and possibly learning from it. I think the other two, and you know who you are, just want to fight about everything.

I don't want to argue endlessly; my point is to bring some clarity to the 'source is unusable' debate. I've been working with the engine long enough (7 years?) so I feel like I have some ground to stand on considering I can actually tell you the ups and downs to the engine, it's strengths and weak points, instead of just calling it broken and useless because I don't know what I'm talking about.

The admins are probably sitting back having a hard belly laugh over all this dumb crap.

Yep

Certainly, but that's not what I was suggesting at all, my statement was not in response to people switching to the UDK over Source but simply that many people who experience problems with the toolset simply do not have computers capable of handling it, simple as. If you need evidence of that there's plenty on this very forum.

-_-

It's obvious you're not even willing to discuss this without turning this into a flamewar...

I've never said that the toolset was never broken or perfect. You seem to be under the impression that I'm arguing against that...

No, I've been modding for some time and have seen instances of the SDK being broken throughout the years. Most of these problems occured when they implemented major changes to the toolset (SDK base for mods, seperate engine selection in the SDK launcher etc).

Also going to stick to my previous point here.

Just because you can run something doesn't mean you meet spec for it.

Same goes for installs. Just because your computer will let you install something doesn't mean you can play it. I can install all manner of modern applications on old win98 machines but that doesn't mean they can run the programs with any degree of usefulness.

Just because you can run something doesn't mean you meet spec for it. You also seemed to miss half of my statement where I mentioned that those that do meet spec often have other problems with their computer which are independent of the software.

I'd like to think I know a little bit about computers, I have to work with them every day

Personal attacks really make your argument that much more valid. If you want to get into semantics, I wasn't implying that you said it was BAD either, but you did imply (and explicitly say, do I need to quote you?) that it was shit and you keep going on about how it's broken. Broken in the software development world usually implies 'bad'.

I also fail to see how I'm contradicting myself, my statements are pretty independent of themselves. A lot of people complaining about the SDK or other Source problems don't meet minspec and if they do then they're running outdated drivers or have other PC problems that aren't even related to the SDK. Just because a piece of software doesn't run on someone's machine doesn't mean the software is broken and if you actually did any work with computers or software for a living then you'd already know that. Hammer is notoriously buggy and if you've been working with the toolset for years then that's something you'll also know. It's common knowledge, you're not the first person to notice how bugged of a program it is. And lastly, it IS free, so people shouldn't be complaining at all.

Yes, at one point the SDK was so completely fucked that no mods would run, tools didn't work, and everyone's mods basically just shut down for a period of time. Even on the mods I worked on, with several people trying to map and mod looking for workarounds, nothing would work. We waited a few days and things got fixed while everyone was raging on SPUF forums about how terrible Valve is. When you have so many updates like Source and the SDK recieve it's inevitable to get some bugs thrown into the mix once in a while, making games is a buggy business.

The engine is certainly not unusable, that's just outlandish and it's obvious how little you know about the subject when you say things like that. Either learn more about the toolset, software, and the engine, or don't, I don't care, but if you're not going to do the former, than please, shut up. I'm tired of seeing source-bashing from you in almost every thread especially because by your own admission you don't even use it and clearly don't know anything about it.

Why is this about you? Because you're the one going on about how much the engine sucks. It's obvious that you don't work with the engine because of all the nonsense you keep bringing up. If you don't like it, and don't use it, then fine, but keep your mouth shut then.

Scalabality really isn't as big of deal anymore as it was when Source was first released in 2004. It's 2011 now and most companies making demanding computer games expect that gamers have a machine commensurate with the specifications of their games, and most serious (and even casual gamers) have machines in that range.

My point still stands. It's FREE. Are you so spoiled that you complain IRL when someone gives you a gift that's FREE just because it was shit or you didn't like the way it worked?

It's Valve's software so they can do whatever they want, whether that means supporting it, not supporting it, running it into the ground or making it the most comprehensive set of mod tools available.

Most of it is on the end user's machine. I updated my display drivers yesterday and immediately ceased to experience any graphical glitches in Hammer. Remember that Valve uses the same toolset to dev their games. If it was crashing every 2 seconds on their machines they'd probably fix it. If it's crashing every few seconds on a machine that's near minimum spec for Source they probably don't even care.

It's true that it's free, and sometimes it is well supported, but that doesn't stop the fact that there are problems with it that are steadily becoming more and more offputting to users. If you're lucky enough to have it problem free recently, then good for you, many other people have suffered from constant crashing, glitchy, unusable views, artifacts in the 3D view, etc.

Welcome to Hammer. You get used to the constant crashes, driver glitches, and artifacting. If you don't, well, I suppose you move onto another toolset. Nobody's forcing anyone to work with the SDK, but most will find that the positives outweigh the negatives/occasional bugginess. If it's too tedious for you or too frustrating then maybe you should work in another toolset or stop modding altogether. I think it has more to do with one's computer and specs, though, as mentioned. I run hammer at least 8 hours every day during the week and my computer still works fine and I still manage to make maps. Sure, it crashes sometimes, but there's an autosave feature to handle that (unlike other softwares...photoshop, anyone?)

Valve doesn't make money from supporting and releasing the SDK - quite the contrary, they are running at a loss when they pay their developers to update the SDK which is released as a free product. People may be getting fed up but it's entirely their own fault for expecting support for something that's unsupported. If I buy you a free ice cream cone, are you going to be thankful for having free ice cream, or will you be angry because it's vanilla and your favorite flavor is chocolate? The people getting outraged over how tedious Source is to work with are in the latter category

I'm sorry for dragging another thread OT but really, this is outrageous. Either map for Source or don't, but don't knock Valve for releasing some tools that are abit buggy. There are plenty of other people out there willing to brave the bugs in order to create maps and mods.

To be completely honest, most of the time the minor problems of Hammer can be solved by asking questions or trial-and-error instead of complaints (ie 'why does hammer crash when I do this', 'maybe changing the viewport rendering mode will stop my display driver crashes' instead of 'valve sucks they broke the tools')

Offtopic slightly but the mac updates did NOTHING to break the Source SDK. Why would an update to a game break a toolset which isn't even released on the Mac? hurr durr...

If the SDK was broken for you then it could have been for a plethora of reasons (many of such 'broken' instances are often problems on the user's end and have nothing to do with the software) but certainly not the Mac updates for any of the games. People who beg for support from Valve for a toolset which is already greatly supported (far more than any other SDK available) are wasting their time; it's stated many places that the SDK is provided unsupported which many people seem to ignore.

Also, Source09 code is available for modding (as well as newer code through aswarm)

You mean the demo version is okay?

Should work just fine.

First of all, you've told your normal map to also act as a specular map. That's what $normalmapalphaenvmapmask does, so just take that line out all together.

No, it tells the material that the specular mask is stored in the alpha channel of the normal map. In this event the specular mask generally has to be inverted because it's in the alpha channel. You can either use an external spec mask ($envmapmask), a spec mask in the alpha channel of the normal ($normalmapalphaenvmapmask) or a spec mask in the alpha channel of the diffuse texture ($basealphaenvmapmask). $envmap defines the particular reflection map to use; in most instances you want env_cubemap because it will use the nearest cubemap as a reflection source.

Rabid, CrazyBump costs money. VTFedit is an all-in-one, and it's free .

It's free, you don't have to buy a license.

The effect shown ingame is just what's being caused by your spec map. The white bricks are really white which means they're going to be very shiny.

Liking the weapon concepts, hoping for more ingame/map screenshots. The lighting in the background map looks pretty bland; you could really do a lot more with the sunlight there to really make it look great I think.

If there are no GIMP plugins you can always use CrazyBump

Furthermore, the reflection mask for textures utilizing normal maps is located in the alpha channel of the normal map. I'm not certain if that is ignored if no alpha channel is saved in the normal map, but you may want to try adding just a completely white alpha channel to the normal map, and adding "$normalmapalphaenvmapmask" to the VMT somewhere.

It's ignored if there is no alpha and you're not using the $normalmapalphaenvmapmask parameter. You can define an external specular mask with $envmapmask. The only caveat is that $envmapmask doesn't work on model materials that also use $bumpmap and so you have to put your spec mask in the alpha channel of the normal map to get them to work on models.

Where did I ever say it would work better? Sprites are sprites, they're relatively cheap and are inexpensive in vanilla goldsrc so the game can render several of them (yes even on an integrated chipset) without dropping to 12fps, so it's safe to assume that something derived from that engine should be able to render several sprites without dropping to an unplayable framerate. But it's certainly not going to perform BETTER than vanilla goldsrc, I could have told you that at the beginning of this discussion.

The reason I asked the question was to try and determine if the performance problems were a result of the engine or the computer, not arguing for one engine over the other.

I've never tried running it at my monitor's native resolution; I doubt an integrated card would even support my native resolution. But chances are that if you're running integrated graphics you're not going to be running a gigantic HD display or an equally huge monitor; you're probably running at 800x600 or 1024x768. I'm not talking about a mobile series card, I'm talking about an integrated chipset which meets the minimum spec.

Comparing particles to full-blown physics simulation, I'm just laughing here, haha. You can't even compare the two; four particle systems (which look abominable compared to what Source can do, btw) should not slow down a game to an unplayable framerate. Maybe if there were 3000 particles, but there's no more than two dozen onscreen (and not much else)

This is entirely irrelevant because the engine is still not better than Source...admittedly, the Source engine will not run on an integrated chipset, but who uses integrated cards for gaming anyway?

True, you cannot determine an engines possibilities from a few screenshots...

...but you can certainly get a good idea of them.

Thank you for posting this, I was going to post some hl2 screenshots to reiterate my point but this is a better example

If it was still the way it is, then bringing a chopper down, would bring basically your whole PC down.

Maybe it does? This is why I asked...
For all I know the game runs at 1fps when rendering the helicopter crash.

Give me a gameplay video of a intel integrated running half-life at even 1280x1024 (A very low end resolution) at at least 30 fps, if it can't even do that, how could it draw 'standard gameplay effects' at even 1024x768?

Minimum spec for HL1 is very low; even an integrated card provided it's not ancient should be able to play the game and draw some sprites without dropping to unplayable framerates considering how old the game is, as far as I know the minimum spec is simply a card with VGA... maybe it can't do it at at 1280x, but the screenshot is 1024x.

Then why show them? Show what it can really do.

qft

Your arugment that it's a superior engine to Source is completely invalid until you can prove it, showing us what we've seen so far is certainly not helping, if anything it's helping to reinforce the opposite.

Hence my question...

Even a sub-par computer should be able to run a goldsrc derivative at upwards of 12fps when standard gameplay effects are being drawn

http://i55.tinypic.com/n32k4g.jpg

looks at netgraph

is your computer that bad or is the engine that poorly optimized?

Source has no way of forcing your modem to reset either; there's no reason why the game is causing your modem to do anything. Did you google your particular model of modem and steam/source to see if anyone else is having the same problem?

That has nothing to do with the engine, it has to do with the artist.

Yes and no. Source is designed to handle high quality facial animations and integrate it into the pipeline (Faceposer) unlike other engines which would require animating it by hand. So, yes, in one regard it's artist-dependent, but the tools allow the artists to simplify the process and achieve better results...

Maybe I could have worded it abit better; the morphs themselves and the dialog are dependent on the people creating them of course. But I would say that an engine that simplifies the process to the extent Source does with Faceposer is 'superior' in that regard, it's much more efficient than hand-crafted animations for dialog in almost every way.

Sounds like more of a modem problem to me

^^ this

My intention wasn't to spark such a debate, especially in 'post your WIP' thread. With regards to brush-based editing; I'm not arguing against it's simplicity, it's much easier to iterate and develop levels using brushes than it is to work in a program that's designed for other 3D tasks, but the tradeoff is visual fidelity. Environment art development is being done increasingly more in 3D tool sets; don't be surprised in 10 years if the content creation pipeline for most games is done in a 3D program entirely.

"Source is state of the art!"

Oh ho ho.

It is in some regards...please show me an engine that does facial morphs and dialog better than Source

Besides my SDK is broken, and judging by what I have seen in the Source community, It's complete shit. Everyone seems to be a dickhead of extreme measures.

again,

@Ant; Well put...

TCs require much more work to be completed in any relatively modern game engine; but there's no limit to how creative people can be with stock game assets in Source games if you think outside the box abit. If you look, you can find plenty of custom Source maps that barely use any custom content (aside from the maps themselves)...anything completely different from the base game is going to require new content anyway; HL just had a much wider range of materials to work with than HL2 (which still has a lot; they're all just..purpose-built, basically)

As games look better the gap between environment art and level design is getting smaller as well; pretty soon there will barely be a distinction; many games' environment art and level design are simply done in 3D tools already. There are still options for level design using brushes and more...traditional tools, but it's becoming a very obsolete method of content creation despite it's simplicity.

Not arguing that the time required is drastically different to achieve quality results, but anything good takes time.

Feels pretty much like shit to me.

I'll admit it's an improvement on goldsrc, but it's certainly nowhere near as powerful as Source, I don't even know how that could be argued...I don't even see any last-gen features like bumpmapping or specularity...Some features like the 'HD textures' and particle systems were modded into the engine ages ago, and the radiosity in the indoor scenes is pretty muddy and you can tell it's HL1-quality at a glance.

Admittedly the art assets in the mod itself aren't exactly helping, but still...it's a good demonstration of the extendability of the goldsrc engine, but it's certainly not pretty.

I'm in doubt about how an engine that's that old is even capable of supporting such modern features. Does it do things like parallax mapping, specularity and realtime reflections? Can it support scenes on a grid larger than 4096x4096? (which is painfully tiny by modern standards, unless you want to build maps which are entirely vertical or have a million level changes?)

I'll believe it when I see it...the proof is in the pudding, as they say.

Edit: Source is indeed a modification of goldsrc in some regards, but you have to change a lot to get it to that point, and it has many new features which aren't simply a modification of the previous engine's code. I'm in doubt about how much a modder or even a team of modders could incorporate features like that; they're rather advanced and well beyond the scope of most people's skill sets.

heavily modified GoldSrc engine. New renderers (better than Source's),

You mean to tell me an engine that's over a decade old has been modified to display modern pixel shaders and is capable of rendering more detail than Source can handle in a single scene? (which is several thousand polys at minimum)

There is a keyvalue on the func_tracktrain to set smoothing between path_tracks, it's off by default, so try using one of the other options (ease in/out or linear blend). You can also force it to remain in it's default orientation instead of rotating between tracks to keep it 'upright'. The movement direction is irrelevant.

Rough movement between each track is best handled by adding more path_tracks, as mentioned, instead of trying to use one of the smoothing algorithms; you have more precise control over the train's movement by adding more path_tracks.

I believe you have to set the origin of the func_movelinear to get them to move into position; not their angles or any other keyvalue. Didn't have time to check out the map but it sounds like you're not doing this?

Is your ISP (or network administrator, depending on how/where you use the internet) blocking Steam?

Did you try contacting Steam support to see if they have any insight on the issue?

Welcome to the SDK. I heard Source SDK is chock full of problems (too many updates that screw it up or something).

Lies.

I'm aware of what the SDK is, I've actually used it before, but it just never felt right.

You're used to Hammer 3.5; it's not going to feel 'right' until you start using it It's really not as extreme of a technology leap as you're making it out to be; if you want to experience something like that then maybe you should try making a Doom3 or Unreal mod or something.

Really, it's easy to setup a configuration for HL:S. Open up Hammer in any configuration (HL2, HL2DM, whatever), go to options, game configurations. Click on 'edit' and then 'add' and type in HL:S or whatever you want your configuration to be called. Under 'game data files' you need to 'add' and browse to the location of the HL:S FGD file. You can leave the next several fields alone although you may want to change default texture to 1 (because HL:S textures are low-resolution compared to HL2/other source games and don't need to be scaled to 1/4). Then you need to find the correct game paths in your \steamapps directory and point Hammer to them - Game executable directory should point to the directory containing hl2.exe (so it's probably steamapps\yourusername\half-life source), Game directory needs to point to the directory that contains a gameinfo.txt for HL:S (it's probably in steamapps\yourusername\half-life source\valve or something). You can leave the default VMF directory alone, it's just where it will prompt you to save maps by default.

Really, you don't have to do any back-breaking work; the gameinfo will tell Hammer which .gcf files it needs to load content from, so you can work with all the HL:S assets.

If you receive an error while opening up Hammer with any config to create a new one (like with HL2DM as you mentioned) then you need to do a 'refresh game content' and 'reset game configurations' through the Source SDK first.

Ninja defuse, you really shouldn't hijack other people's threads, but there's no way to change UI elements like that without modifying hammer itself.

The steam client ones was an interest for me, and they all work expect the last one(listed on this page) : UDP 4380.

Do you have a router? Did you open UDP port 4380?

I don't think that would even make a difference but who knows.

Worse comes to worse, back up your steam game files and reinstall.

Glad to be of help. Sometimes remaking things is the best (if only) solution!

Aw, such a cute kitty :3

Sure, the maps might run fine, but maps with leaks can and will often have unpredictable behavior. Make sure it's sealed and try again so we can be 100% sure that the dome is the issue and not something else randomly choosing to be problematic.

The log is fine for 3; nothing seems out of the ordinary. When you did a full cordon compile, did it still crash?

If so, did you try remaking the displacement surfaces? I only had a cursory glance at the maps, but does the teleporter cause the crash when you've cordoned a portion of the map (sending the player to a nonexistent destination in the 'hidden' dome or something?)

I've also noticed some Dystopia paths in your logs. Have you tried running the maps in another mod/game to rule out the possibility of any game-specific crashes? Sometimes crashes can be a problem with a mod's game logic and not even a map itself.

Um, you're not trying to compile these maps exactly as they are in your .vmfs, right? Displacements aren't solid and won't seal holes in your level, so you need to fill in the space behind them with solid, world brushes so that your map doesn't leak.

Displacements are very versatile. Usually any errors you encounter with them specifically will be printed in your compile or console logs telling you that something went wrong with a displacement face; and if they're severe enough they should halt the BSP process of the compile itself.

I've watched several friends play it and it looks just the same as FO3 to me (worse in some places), right down to the characters, combat and environments - what makes it better? I'm not trying to troll here, just genuinely curious.

That's your problem; the error means that your scene has too much 'stuff' and some of it isn't being rendered as a result. That's why it happens only when you look at things at certain angles; because those particular views are causing the game to draw too much than it can handle.

You want to make sure you're not running vvis with the -fast parameter; as doing so will bypass the vis process and can result in this error happening (even if your level is lit correctly and compiles without error, if you ran with -fast it's not optimized visibility-wise).

If you did indeed perform a full compile, the only remedy is to optimize your map somehow and reduce the amount of things being drawn. Perhaps you have some areas with unnecessary or excessive brushwork that you could reduce? If you have a lot of complicated structures made from brushes, you could convert them to static or physics props with Propper, but this will mostly just free up brushes and not vertices, which doesn't help with your problem. Occluders and areaportals can help, depending on how your map is laid out. Setting/style permitting, you could also try using fog to obscure distant parts of your scene that are far away from the player.

Source should be able to handle outdoor maps just fine provided it's not rendering too much in a single scene. Most of the big-huge Valve maps (hl2 coast levels) utilize fog as a visibility control with the FarZ clip value; this just culls/hides anything beyond the FarZ clip value from the player, while the fog masks the fact that the distant objects are disappearing.

[m]EDIT[/m]: If you're using func_viscluster this could be contributing to the error, as well - if multiple func_visclusters with lots of models, brushes, etc can see each other, than the game will think they're all visible at once, even when they might not be, so use them sparingly, if at all!

Is there a skybox brush between the player's location and the disappearing geometry? Is it tied to an entity of any sort? Do you have any far-z clip settings set in your fog controller? And do you receive any console errors about 'too many vertex format changes' or anything similar which indicates too much geometry is being rendered?

They wanted you to look for yourself

http://minecraft.net/

It's a great time waster for a few hours, after that it feels more like work than play...

Yes, instances are only available in L4D/2 and Source2009 games; if you're working on a HL2 map they won't work.

This is great news both for developers and the games development industry. Fostering childrens' interest in games and challenging them to develop something is exactly what we need, not fear mongering and condemnation of the industry and games as a whole.

Yeah, 4 hours down the line it's a country war, religion war, and all out "george bush is a moron" debate.

With regards to the latter, there's little, if anything at all, to debate.

http://www.bleepingcomputer.com/virus-removal/remove-antimalware-doctor

No need to reformat, unless you were planning on doing so as routine computer maintenance anyway.