Reply With QuoteLook into the Editor's menu "Veiw" - "Conversations". It's Conversation browser with all the conversations and objectives...Originally Posted by all
If you go up a few posts, jtr7 (and some others?) are working on a Thief Encyclopedia. They may have all the text documents and it sounds like they are going through all the audio files also. Not sure if they are converting them to text or just grabbing certain words from them.
It would kick it to a new page, wouldn't it. On the previous page, up a few posts from yours...
Look into the Editor's menu "Veiw" - "Conversations". It's Conversation browser with all the conversations and objectives...
Last edited by Tiens; 18th Jul 2007 at 04:49.
None such exists... yet. Although there are fine contributions out there and you can see all 20000+ of them if you use SoundDrone.
We're working on the complete texts and transcriptions for posterity's sake. It's gonna take years, but we've never stopped working at it (except for those Real Life interruptions and neurological meltdowns from dwelling too long on it).
Blood Dragon, 242, and others I can't think of right now to credit (SORRY!) have contributed in other threads.
Have you tried running them all through a speech to text program? Might not be perfect, but it should get the main points.
Hey, Bardic. I didn't see your previous post, but I, along with spix's circlet, are two of the primaries working on the Thief Encyclopaedia. I was hoping I could copy and paste the texts right off the SoundDrone screen, but I'm gonna have to go through the *.sch's one at a time. Heh, all 15000 of those.
And Tiens, what's with the? This is a N00b Questions forum?
Stumped here . . . how do you get torchguards to work properly? I've tried looking at how they were done in the game levels, and I've had everything set up the same - proper torch attachment, AI movement model, scripts . . . but in-game the torch won't go out if you shoot the guard with a water arrow, nor will it go out if you kill the guard. What am I missing?
This should help.
I see now the one thing I was missing . . . never would've thought of that! Thanks!
So, more questions. The reasons for the questions will be made clear in time.
Is there an EFFICIENT way to use T3Ed for the following:
To determine when, where, and how all the Deadly Shadows characters "speak" in the game, especially in conversations or other instances where the player's proximity alone triggers the voice-files?
In other words (which escape me)--can I, say, open a window to see all such instances? Grouped in a tree, or something?
My colleague and I would like to avoid playing through the game over and over JUST to map out the conversations. We would like to know when (which DAY), where (which district, which street or building, what floor, etc.), how (caused by player proximity, or previous action, especially if the action happened a previous DAY).
If there are any OTHER ways to do this, I'm all eyes...(I am only reading, after all). Otherwise, we may just have to play through a hundred times. We would have to play different utilizing different styles, difficulty settings, and make different approaches to meet the objectives. And we would have to avoid immersion, 'cause we'd forget our real mission: to find the hows, whys, and whens of the conversations.
Last edited by jtr7; 21st May 2007 at 22:19.
As far as i remember, the answer to your question is: hmmmm... You can see the how the conversations were triggered in the game by browsing through the triggerscripts (I'm not sure exactly where it is, but it must be there). If you want your some game conversations in your fm, you're limited to one of the maps - you must choose conversation package name in your level properties (for more details see the tutorial included in editor package).
I believe that some of us tried to make their own conversations based on this system, but failed in their effort. It's "easier" to make and import your own sounds, and then make your characters play proper animations at certain points, as they're talking. I said "easier", because it requires many custom scripts, which is "a bit" time-consuming...
But it works!
Will help with modeling, texturing and T1-style cutscenes | Photoblog
wondering if anyone could provide some more tips on zoning and trying to keep FPS generally low; I read through the section in K's tutorial, but still thought maybe there might be some other tips not expressed there . . . mostly, working with large areas, for example - a 3 story building with fairly large space all around it - is it better to have smaller zone portals only tween the doorways, or . . . ? As for lighting, smaller strategically placed omni's are better than larger one's with brightness pulled down, correct? At least, to me, it seems to work that way.
Oh, and what FPS stand as being decent rates? Lowest I'm currently pulling is about 15-17 on my system (so I figure rates will be much higher on better systems), and I feel these rates are alright.
Oh, and how does one go about getting spots to work properly? For example, I was trying to add in the SteamWallLight actor, but couldn't set up the properties for the spot light to work at all. I tried adjusting the length of the light cone, brightness, etc, but can't get it to build at all. Saw nothing in the wiki on spots . . .
With zones it's all about the angles, I think. When you can find an angle, where you can see through two of your zones or more, then it's useless. As for the performance, you can have fairly large areas (at least bigger than in OM's), but try to keep omni lights to minimum, no more than 3-4 per scene.
Generally, if you want to achieve the best performance, you should fill your level only with static meshes and subtractive brushes
If you need a spotlight, simply add a normal light, and add property: FleshLightType: FL_Spot. By the way, if you have "show non-local props" option unchecked, check it immediately. It will save your time, you won't have to search and add so many properties manually. And then, if you see some property grayed-out but the value is set as you need it, then leave it as it is. It just means that this value is inherited from upper actor class from the actor tree, and it's active.
It's also useful for learning. This way you'll see what set of properties you need to create a certain class of objects e.g. elevators. After that you'll be able to turn any static mesh or light, or any other actor into elevator (flying candles, boxes etc.)
Last edited by Judith; 27th May 2007 at 06:06.
Will help with modeling, texturing and T1-style cutscenes | Photoblog
Hehe, my kind of questions.
Zones are bit of a pain.
The general rules are:
- Have as few zones as possible
- Try not to have the engine looking through multiple portals (at least, not too many)
- Try and keep them small
- Keep them rectangular: don't fit them to spaces, that just makes them take longer to process, so make them neat and just take the "hit" of extending them through walls/floors/whatever a little
- Try and keep them vertical. For some reason, the engine doesn't like portals at angles, and that includes lying flat. You can do it, but it hurts performance more than you'd expect.
- Do not double-portal anything. As a simple rule of thumb, don't have any zones contained with less than about 192UU between the entrance and exit portals: those 14 extra polygons or whatever are cheaper to render than the portal test to remove them, so portals on both "sides" of a door frame or window is just not worth it.
- And have portals as close to the problem as possible: doors leading outside when you spend more time inside should be on the "outside" of the door frame. It doesn't really make a huge difference, but sometimes you really are arguing over 1-2fps.
As for large buildings, well, that really is a pain to work around. The answers largely depends on what's around the building, if you can get on the roof, where the place is accessible (doors/windows/whatever), and as ever, how many lights there are.
Trying to put large portals all around the building is probably a bad thing in general, but if the grounds aren't that complicated, or only have a few lights, it might be cheaper just to leave the entrances and exits portalled and sort of ignore outside (it'll be big enough most of the visibility should get nixed by the view-cone rather than anything else anyway).
-----------------------------
FPS, depends a bit of the test system. Ballpark by what the OMs runlike for you: on my system the OMs run like a concussed dog, at a measly 6-8 FPS, so for FMs I tend to say 10 is the goal, and 8 the lowest acceptable (apart from in really bizarre places to be standing/looking). But that's based on performance on my system.
-----------------------------
And spotlights, well I don't know about the SteamWallLight actor, since I tend to just place smeshes and build my lights from the *Light actor, but you need to add the LightShape properties, so that you can give it the right dimensions: *and then you need to move the light* That's right, just wiggle it up and down (back into position) or whatever and it'll update: for some reason they tend not to visibly change the results without being waggled.
(Hint: you can use the Actor>Show Radii option if you right click in the orthogonal views to see the light shape - select the actor and it'll be the red shape around it: a ball for normal lights, a tube for Directionals, and I think it's cone for Spotlights, but could also be a tube)
And yes: small radius lights are better than large damped ones - the fewer things any given light hits, the better. Non-Shadowcasting are cheaper than those that do cast shadows, and Vertex lights are even cheaper still but don't catch normal maps and so tend to be a bit bright/ugly. And try not to overlap the effects of lighte either, since that can hurt really bad - especially if both cast shadows (I know it can be cool - just be careful with it)
------------------------------
Long speil later, I hope that helps a bit.
Yeah, OMs are a bit confusing, I have bigger spaces and more static meshes in my mission and still have better performance
If you want to have zoning and better performance in large open air areas, try to keep the "ceiling" relatively low and try a trick with skybox and transparent textures:
Oh, and one more thing about performance - while building, select all your surfaces from time to time and check "do not cast shadows" flag, uncheck it only if you know it's necessary for particular scene.
Last edited by Judith; 27th May 2007 at 06:15.
Will help with modeling, texturing and T1-style cutscenes | Photoblog
Thanks y'all - helps a lot, really! There's not much on zoning in the wiki, and K's tutorial is just basic stuff, I think. Y'know - maybe someone'd be willing to post some of that info in the wiki?
Completely forgot about doing that! I've been ignoring the surface selection after setting up a basic area because I'm running an ATI, and T3Ed has a chance of crashing out when you start selecting surfaces (it's really irritating, too). I've got to save, save before I edit surfaces and textures . . .Oh, and one more thing about performance - while building, select all your surfaces from time to time and check "do not cast shadows" flag, uncheck it only if you know it's necessary for particular scene.
Speaking of texture selection . . . I'm guessing that having wall textures scaled in also takes a hit on FPS with this engine because it has to draw that texture a higher number of times? I know some older game engines were like that (DukeNukem, Quake), but wasn't quite too sure here (although, I haven't noticed much of a difference). At least having some prior experience with other gaming editors I think really helps me out, I'm picking things up with this engine very quickly.
The question about the spot lights is because I haven't been able to get the to function properly at all - I've also tried just adding the mesh and positioning an omni with the FleshLightType>Spot property, but it doesn't build at all. Directional lights also don't work, either - I was almost wondering if it's a problem with the engine and ATI drivers, but not sure . . .
Anyways, asides, I appreciate the info, y'all; it's been a major help clearing up some confusion! My first attempt (those pictures I originally posted) just feel through, things were too big - 2nd attempt was smaller, but stressed the engine too much and I was getting very odd geometrical anomalies (holes in ceilings, etc.) - currently working on a 3rd attempt, and coming along much better (3rd times a charm, eh?). I'll try to post a few screenshots later on today.
Can't help if it's an ATI thing, but the spotlights:
Place light.
Add property Lighting>FleshLightType=FL_Spot
Move the light actor (otherwise it doesn't show as having changed)
Adjust the Lighting>LightShape>LightCone and ..>LightRadius properties as desired.
Change colours and things as normal, and/or give it Lighting>FLLightTexture>Name=(the name of some texture you want to project), which can also be tinted with the colour settings, but tends to look weird.
Directional lights are much the same, except they don't don't taper/distort, and can run rampant through buildings (I think there's settings for FLDirectional you can add, which let you control the radius and cut-off tube: again using the Actors>Show Radii is a good way to see how far things are going)
You don't actually have to rebuild anything so long as you've built the BSP and FleshBSP for the light to affect: You don't need to rebuild lights in this.
funny . . . nothing different than last time I messed with one, and it worked for the time being . . . I wonder if it's just an issue running an editor that was designed around different hardware;
anyways, thanx again!
Should I patch my Thief 3 installation with 1.1 before or after I install the 2005 editor release, and after it is run?
Also can a no CD patch be run with T3edit installed?
1.1 patch fixes the bug with resetting difficulty settings, so it probably should be installed before the editor. You won't need any no-CD patch, as the exe files shipped with the editor don't require CD to run and check your maps in the game.
Will help with modeling, texturing and T1-style cutscenes | Photoblog
If you have the editor, you don't need to install the patch. Just rename the t3mainrelease executable from the editor and overwrite the original...also overwrite the T3.exe file with the one from the editor.
Thanks NH, I have version 1.1 DVD, so i couldn't actually check it.
Will help with modeling, texturing and T1-style cutscenes | Photoblog
I have only got the editor to work from making a shortcut path to the T3.exe and writing in the target window "T3.exe editor" and then use that shortcut directly (I could probably use the shortcut elsewhere as well) in my Thief3Edit folder.
If I try to use ThiefLauncher it does not do anything if I want to use the editor (Thief3Edit), but it will work for the the game (Thief3) even with the paths set at Thief3Edit for the Editor, and Thief3 for the game in ThiefLauncher.
If I use GarretLoader 1.41, it wants to overwrite my application files with newer versions so I cancel the configuration of T3 in GarretLoader for fear of what it might do.
Is there anything I can do do to make T3Ed work in ThiefLauncher and GarretLoader where it will show up and work in both programs?
Two meager questions right quick:
1. Just for future reference, a meshes/actor's TriggerScripts; are they executed sequentially in order, or all they all executed simultaneously?
2. Is there any way to "lock/unlock" a switch, until another switch is thrown (like using a switch to lock/unlock a door)? I've tried various properties and scripts, from using the toggle lock script, to attempting to change the highlight distance (doesn't seem to work, I can set highlight to 0, but not back to 128 with a script) and suchforth. Just a bit stumped on it . . .
Two meagre answers:
1. You mean if both scripts are being triggered by the same event? In that case then I'd guess that they would be executed simultaneously (to all intents and purposes anyway). Are you leading somewhere with that?
2. bIsFrobbable?
OldMeat: I followed Komag's tutorial and didn't encounter any issues with either the launcher or GL.
Naw, it was something I was wonderin yesterday working with some actors and their scripts; I just wasn't sure if they would be executed like lines of programming code, one after the other; or if the engine executes them all together. Like . . . a door controlled by a switch that has the scripts: OpenDoor, CloseDoor, ToggleLocked - does the engine excute OpenDoor, then CloseDoor then ToggleLocked; or does it execute OpenDoor, CloseDoor, ToggleLocked together . . . I guess what I mean in that same example, if they were executed sequentially, then theorheticlly, ToggleLocked script would have to be at the top of the tree, before OpenDoor, CloseDoor - am I making any sense?1. You mean if both scripts are being triggered by the same event? In that case then I'd guess that they would be executed simultaneously (to all intents and purposes anyway). Are you leading somewhere with that?
Negative, tried that one too; it would do the same as setting HighlightDist=0, it stayed that way and I couldn't get a second script to reset it to it's original value of 128 (or so it appeared in-game).2. bIsFrobbable?
Posting Permissions
