Skaruts

About approaching from behind, it seems impossible to do it. The only way to effectively blackjack an AI is if they're stationary, which gives me plenty of eternities to creep behind them silently, or if you catch a moving one passing by you. I would defend that a stationary target forces you to be as silent as you can, but moving AIs seem to behave the same way, and there's some problems with this: The only way I see that allows you to catch up with them is by either sneak-running or normal walking (or running, obviously). But both options fail every time. They will always hear you. I'd hope there was a lesser chance to be heard when they're moving, as they would first confuse my steps for their own (awareness level 1, if you will), and then start wondering if they were hearing something else (awareness lvl 2), and then stop to listen but still not in alert mode (lvl 3), and then yes become alerted to your presence and turn around and search (lvl 4). Of course, this describes something that might happen in seconds, giving a fast player only the chance to run in and BAM. But this might solve my other problem: Most times where I quickly approach an AI and blackjack them, it doesn't work. There should be a slight delay to allow black jacking. Most of the time I'm quick enough to punch them as they're still saying "uh?" and they haven't even started unsheathing their swords, and it fails already. I know this system is to make the game harder, but it's frustrating instead. A slight delay to simulate a "confusion moment", or something like what described above might make it more forgiving and less immersion breaking. And such a delay would be controlled by the AI difficulty settings. I'm playing on "forgiving", and it is quite forgiving, but not in these cases. Another problem I noticed is that blackjacking AI with unsheathed swords from the back is likely to fail too. I'm not quite sure what's the problem, but at one time I had to reload the save quite a few times until I succeeded. And it seemed the problem was the angle at which I was attacking from. When I placed myself "strictly behind" (if you get what I mean, not even slightly sideways) then it worked. I did this twice with the same AI because I had to reload later on and hadn't saved afterward. I had the same problem again and had to adjust my position in relation to him. I think AI with weapons should be allowed to be blackjacked from any direction, just as long as it's outside of their field of view. Currently I find this mechanic very "gamey" and a tad frustrating. Don't get me wrong, I wouldn't want the game any easier. I just dislike when some mechanics are unfair or "gamey" or immersion breaking, etc.

This thread's been going for so long that it's kind of hard for me to get to know what has been suggested and accepted/rejected. So I'll just throw my few cents in here anyway. Forgive me if I'm just repeating anything. I've been a long time user of Source SDK, specifically for HL2dm, and some features I'll be suggesting may be easily researched in the Source SDK wiki. So, forgive me for suggesting that one thing or another ought to be similar to Source SDK. It's just that there's very good reasons why I consider Hammer the best editor I've ever used (and I did try a ton of them). In no order of importance: 1- Transparent "tool textures". Such as visportals, clip brushes, nodraw, etc. Certain solid materials or ones that can be used to seal the map, such as caulk or portal_sky should perhaps remain opaque, though. Here's a visual representation of how it looks in Valve's Hammer editor. (Orange ones are triggers, red ones are player clips, green ones I can't remember. But it should illustrate my suggestion well) 2- A more conventional way of selecting things. I'm not sure of the reasons behind this selection method, to be honest. I can't see any real advantages to it. And it introduces the danger of creating brushes accidentally, but it's due to the unavailability of a "create brush" tool that would need to be activated prior to creating brushes. If that existed - and was by default - any accidental clicks would result in selections being made, nothing else. An accidental click that might drag a selection might happen, but it very well may currently. The current selection method is cumbersome, and doesn't allow for a simple 1-click selection if one is already made, among other issues. I'm not fond of conventions, but when it comes to software controls, I'm all for them. 3- A modifier key to accelerate camera movement by an adjustable percentage. This would be useful for large maps, instead of having to go to the menus to change camera movement between surgical maneuvers and traveling to the other end of the map and simply flying around. A button for temporary precision movement (adjustable speed or percentage too) might be a good addition as well. 4- Color coding or textured 2D views. Not strictly necessary, but I had already times where it might have been quite useful. For example, when making a large city map, I layed out the roads, and then roughly blocked out the buildings around them. At some point the view became a confusing mess of white lines where I had to decipher what was what by selecting and looking at the 3D view. (Maybe color coding layers?) 5- A tool that might be similar to Cordon Bounds in Source SDK. This tool is very handy in many situations. Most noticeably you can use it to select a portion of a map, and then toggle whatever is outside the selection to be hidden or shown. This helps minimize clutter in the 2D views, for example. But no only that, it actually works as a map sealing boundary, meaning you can compile a map that is surrounded by the cordon and it won't ever leak because the cordon acts as a sky brush and effectively surrounds everything that's visible. This also makes it very handy for quick mock ups, quick test maps, etc. (EDIT: The make room button already kind of makes up for the inexistence of such a tool as this one, in regards to making quick tests and mock ups, but has the downside that you can't intersect the already existing geometry when using it to quickly enclose the map - see note below) (Note: Hammer doesn't compile whatever is hidden, which makes this tool pretty safe to use (you never get leaks). Dmap however, compiles hidden stuff, as well as hidden layers. This difference in behavior would have to be taken into consideration). 6- A way to exclude "stuff" from compiling. When running tests I often change things around and then it doesn't work and I have to revert everything back to how it was. And I repeat that process a lot... I can save several versions of the map, but untidy as I am, they'll stay there for the rest of eternity, cluttering my hard drive. I'd prefer to be able to build several versions of whatever I'm testing inside the editor, and exclude some of them in a way that dmap would ignore them. This would have other uses, this was just one example. Maybe mark layers as excluded? 7- Layer "folders". Might help organize them, but more importantly it might help reducing the size of the list. 8- A more flexible way of resizing views relative to each other when using Split Pane window layout. Currently, resizing horizontally works well, the left ones adjust as you drag it. But resizing vertically doesn't. The right side is independent from the left side. Which makes clicking on the center and dragging not resize all 4 views as I would've expected at first. For this reason I've been using the default layout, as this way I can have a large 2D view and it's easy to change the camera angle. But for those who like using 4 views, this might be handy. 9- A way to maximize views when using the Split Pane layout. Again for anyone who would prefer to use 4 views, pressing a key to toggle between 4 views and 1 maximized view would be handy. My preffered work flow would be 4 views for general usage, and a miximized view for detailed work. As well as a maximized 3D view for flying around when searching for mistakes, evaluating things, etc. 10- A way to group "stuff" for easy selections and easy adjustments. I haven't tried func_group, but the idea seems a bit dodgy, as I don't see an easy access to it (correct me if I'm missing something here). I'm currently using func_statics for this effect, whenever possible. Note: layered groups might be a good idea too. By that I mean, for example, grouping two groups would obviously create one group. But disolving that group would revert back to two groups (which would in turn have to be dissolved as well), not to loose objects straight away. Also, a useful adition, but not strictly necessary: a way to manipulate objects within groups. Maybe a toggle button next to vertex/edge/face selections, for group component manipulation. 11- A way to merge vertices, or snap selection to vertices, would be really handy for solving unforeseen problems with patches, or other problems of the same nature. 12- A way to make selections on 2D views behave in such a way that if you click on a line it selects the nearest brush to whom that line belongs to. Clicking on empty space would behave as it already does, just clicking on lines would behave differently. This would be handy so you wouldn't need to be hiding stuff to make simple corrections or adjustments, for example. Of course that if you had several brushes sharing that line, you'd run into the same problem, but for this I would suggest also adding a way to cycle through brushes that occupy the space the mouse is clicking on. Maybe a modifier key that could select the next brush at each click?

Not a bad idea at all.

Speaking of animated textures, my question isn't entirely related, but... Can textures be manipulated ingame to create the illusion of movement? The second level of an old game called Blood was in a moving train, and there's a which does the same thing. I'd love to do something of this type. Basically, they continuously offset the scenery textures, and that creates the illusion of constant movement. Could this be done? I'm assuming the same way you make analog clocks could be used for this as well.

Doubled portals alone seems to work reasonably well. I guess I can mix it with walls of buildings like you mentioned, depending on the situation and the performance demands. http://www.mediafire...27q6z/test3.map Diagonal portals in this case didn't work. They only gave me glitches.

Indeed, that's one of the options I was thinking of. That's also not a bad idea at all. I've been placing them 32-64 units in and away from the corner edges, so that you have to come closer to the corner to open them. But now that I think about it... diagonally might be a bit better. I think I can control the angles better that way.

Yea, all the roads and alleys do zigzag (originally the alleys were intended to create L shaped entrances to some houses). But the problem with visportals on open roads is that they don't get enclosed by anything on top, so they'll all be open when you're on the roof looking at the road (regardless of zigzags and horizontal visportals (which will also be always open when viewed from the roofs) - unless perhaps if I make double visportals horizontally.. hmm, gotta try that). I was thinking I may have to surround the road with higher floors and extend the visportals up to the sky brush. This would probably work, but it would also take away the chances of looking down the street from the roof. Unless I can manage to create openings for the player to get in there at certain places. Perhaps I should make a thread about this. Maybe someone else has found useful tricks that remain unshared.

I have a few ideas I'm testing. On both I'm "encapsulating" the city in sections, and one of my goals is that on the roofs you'll have "rooftop-roads" which work much like any other corridor, but between roofs and higher buildings. On one I'm trying to leave it open wide but with city walls separating the sections, so that on a worse case you never have more than that section rendered when on the roofs, on the other I'm still trying to do the same but with higher buildings instead of walls. I'm thinking a mix of both might be a pleasant sight, though. If that fails, I'll go with the roof-roads concept. The streets and the wide areas are the tricky part. Ideally I'd want to leave them open, but I'm not sure if that's a good idea. Currently I'm leaving the large road that traverses the city open to the sky, and the alleys covered by the top floors that bridge across. So basically the alleys are tunnels (and I'm leaving enough height to make several rafter-paths in the alleys) . Now... If any of this will work, I have no idea. But sounds feasible to me.

Thanks Desino. I've been doing some testing here and there to see how they work as situations come along. So far so good. Trying to make a large city with rooftops access is a tricky puzzle though.

Yea, I did look at the factions. That's where I noticed the absence of the Mechanists and the Keepers. Just the builders' similarities kind of got me wondering. Thanks.

So I suppose the Inventors Guild and the Mages are kind of a replacement. I noticed too that the builders are never referred to as the Hammerites, despite the resemblances. Is this anything to do with legal repercussions? There's still the Pagans...

Makes sense. I thought of coachmen too. I don't know what they occupy themselves with, but perhaps they just chat around and tend to the horses if needed. I guess that's more than enough for a party. I'm not planning on including the coachmen. Although that might be an interesting asset... although it would require a lot of voice acting and character models that probably aren't available. By the way, speaking of not available - and just out of curiosity - are there no Mechanists and Keepers in this thief world? Or they just haven't been included yet?

Would they take any servants to a party?

Banging your head on the door might be a bit frustrating. I mean, you managed to sneak past the thugs on the fire, either by climbing the vines or quicly reaching the stairs and wait for them to calm down from seeing you for a second, and then the house is not accessible... I'd be a little frustrated for that and for having to get past the thugs again with my hands empty. An (easier) alternative to my previous suggestion might be to have the patrolling thug just stand there in front of the door until you speak with Gridley. That would be a major "NO ENTRY!" sign right there, and the player wouldn't need to go through any trouble to "read it".

Yea, simple definitions would be fine. Well, I found this, and it seems I'll be taking a while with it. One thing came to my mind just now though, that I looked for a day or two ago and couldn't find anything about it: What places would be suitable for nobles to have parties in? Searching "medieval parties locations" only gives me a sumary of modern parties with medieval costumes... I know the royal castle is one place. Are there other places where they'd might throw parties at? This is relevant to my story, since, hopefully I'll have the player "attend" to one.

Thanks, Sotha, that's quite useful. But the term "nobles" still gets me wondering. I'm not familiar with game of thrones (though it was recommended to me a few times). I'm familiar with Brent Weeks' Night Angels Trilogy, which involves a crap ton of medieval politics and intrigues. But not having a basic understanding of it makes me remain a bit confused of how it works. For example, from what I understood from those books, a Duke seems to be second to none but the king himself. But then baronets and counts come along and I have no clue where they fit in the hierarchy. I'll see what I can get from wikipedia in the meanwhile. I'm trying to understand these things not to be overly picky in the story, just so I make something that makes sense from the player's perspective. Certainly the player won't get a summary of all the social stuff that's going on, but, using an analogy, I'm trying not to mistake onions for garlic, which might set a player off. EDIT: Found something useful.

Yea I noticed now that I'm reading other people's posts. One solution might be to bring all the thugs out of the hideout at the start, making it impossible to go in from there. At least the two thugs that are playing cards, they could be outside just chilling. Then after talking to Gridley they could go inside, so that the player has a choice to go in from either side.

Loved this FM. The map is just beautiful.

I'm not exactly sure what to ask, or how. I guess for a start I should ask what's the social structure within the thief world? I'm not very versed in this. But I like political (and non-political) intrigues and the good old thief world conspiracies, and I'm trying to include that in a "script" I'm writing. But then I'm confused about a lot of things. For example, who governs a city? A governor, a mayor, a lord (is lord an interchangeable term or a specific one?). Since I don't live in an english speaking country, we don't have mayors around here, so the term is a bit alien to me. Surely we have something equivalent, but I'm not sure what. To make matters worse, thief mixes medieval and victorian ages. So I'm not sure what to look for if I google it (wouldn't know what would be relevant from what I found).

Thanks Springheel. I already have a fairly good understanding of how to use them (not wanting to sound like an expert, which I'm definitely not), I just needed to know if there was anything else besides visportals in this engine. I had already watched that video too. But thanks anyway.

Nah, I don't really have that mindset. Controlling visleafs was relevant in Source, since the engine calculates visibility automatically, but not always the right way. If the leaves are all manually created that's not relevant anymore. I still like to know the details, so that I have a good idea of what's happening behind my work. Thanks for the links.

Thanks for the feedback. I just made a quick test and noticed the engine doesn't hide any geometry at all by itself, so it isn't taking visleafs in consideration without visportals. Visportals it is, then. I still would love to know how the engine handles visleafs, so that I could test how exactly to place the portals in certain situations, to not end up creating unnecessary leafs, but... I guess I'll have to rely on that not being a performance killer if the rest of the map is well organized. By the way, I don't suppose there is any way to make the "tool shaders" (such as nodraw, visportals, caulk, etc) transparent. Or is there a way? Stuff gets really confusing with this... (I know I can filter them, but I can't filter them while I'm working on them - and I'm very used to be working like this)

I made maps for the source engine for a few years (specifically for HL2dm), so I have a fairly good understanding of how BSP geometry works and most of its intricacies, but there are a number of differences from half-life to quake (EDIT: I meant Doom :S But I guess it doesn't matter much, they're all very similar). I don't think that's a problem, though, I think I just need to adapt. But I'm looking to understand the differences. I started playing around with Dark Radiant, and a few things came to my mind so far. To put it all in context, in Source there were Hints and Area Portals, and they had different uses. Hint brushes were used for manual control over visleafs, which suficed to get the engine to automatically determine what geometry to render and what not to (used in corridors, and doorless doorways, for example, like visportals are, except that they didn't turn on or off, they just manually controlled where visleafs started and ended), while Area portals were used to turn rendering of separate sections of the map on and off (mostly used in doors and windows, and the like, and they did turn on and off like visportals do). They were also recommended to be used sparingly (the APs, not the Hints), for performance reasons (although, I always wondered if that was a myth, to a certain extent). There were also Occluders, that were used to prevent rendering entities that might be hiden behind some geometry where hints and area portals might not work (for example, crates or NPCs behind a shattered wall from say, a ruin, which the player wouldn't see until he went around the wall and thus shouldn't be rendered until then - or stuff behind a hill, on top of a catwalk, etc) https://developer.va...ty_optimization So, I'd like to ask a few questions: 1- Are Visportals the only thing used to control visleafs and overal visibility in DR, and used for both purposes? Or did I overlook something? And is there such a thing as too many visportals and any related performance issues? 2- Is there an equivallent to occluders? (this isn't very important, just out of curiosity. I don't think I ever even used them) 3- Are there cvars to show visleafs ingame and for ingame fullbright? (I couldn't find any of them in the wiki) 4- Is there anyone here with experience in Source SDK that might point out other stuff I should be aware of? This is all I have for now. Any feedback would be greatly appreciated. Thanks in advance.

Yea, I was thinking there might not be a way. I gave a cursory look through the files and there doesn't seem to be a config file for controls. I can live with it, though. I just find it perhaps more encumbering than advantageous, to be completely honest. I'd say it's advantages might be highly debatable. But I may be biased since I've been mapping with Valve Hammer for years, which makes me totally loathe (with evil eyes, protruding teeth and drool and all that) pretty much every other editor in the world - with the only exceptions being quake-derived editors (because they work similar to it), which I don't necessarilly hate but I always find annoyances... Anyway, thanks anyway.

Sorry if this has been asked before, I couldn't find anything about it. But is there any way to change the select method to a simple click without the use of shift (and alt)? (and possibly use shift to build brushes instead, reversing things) I find it a bit annoying, especially since it differs from every single app I've been using for years.