geegee

nvidia GTX 1060 6GB on desktop nvidia MX150 on laptop In both cases I have to disable the new backend as per duzenko's advice, above. ps. jeez, I paid way less for that 1060 way back when I got it than they're asking now!

Is the major drawback that the outline will then be obscured by doorframes etc? Can the outline be changed to have a subtle "inline", so the "inline" would then be visible? An option to ignore depth wouldn't be quite right since the casual player wouldn't know why or how to choose it - and really the only fix would be to hardcode it so the player can't in effect break the game for what seems to me to be a lot of FMs.

That you can see it right through geometry is anti-immersive and I've never seen such a thing in a game. Aside from the issues I mentioned above, consider the player sneaking through a room with stuff hidden under papers, vases etc, none of which is now hidden. Desks aren't mysterious, perhaps containing drawers with loot or notes. Instead, with the whole drawer brightly x-ray highlighted it becomes center of the scene - the desk becomes this semi-transparent afterthought. This seems totally alien to TDM - which has a deep and beautiful game world.

Yes. But since a player doesn't frob randomly at everything (like wall-strafe-frobbing in wolf-3d) throughout the game a mapper doesn't have to worry much about that except at obvious places like chests etc. where putting a atdm:target_set_frobable entity is the fix - there's nothing to frob 'till the player opens the lid. But with the frob highlight shining bright through a bare wall there's no guessing - the player is attracted right to it and clicks it. Thus the need to use a atdm:target_set_frobable entity there, too - and that isn't always so straightforward.

A fix that requires the player choosing the right options on something as basic as this isn't good. In v209a switches aren't seen through walls and with a bit of care in placement can't be seen in places like under the skull, either. But with the shining frob outline, they're seen like with a spotlight - inescapable. As a mapper, my solution just in case the shining frob outline is included either as default or as a choice (once a player chooses to enable something like that they're not going to change it according as which FM they're playing at the time - such choices tend to be permanent), is to cover the switches with a clip textured atdm:target_set_frobable entity and give the skull a spawnarg immune_to_target_setfrobable = 1. And to put items in boxes with lids or etc. so something has to be targeted - opened or switched on or etc - before the player can reach it. Anyhow, I'm glad I'm an end user and not a dev.

Although I like the frob outline and in the vast majority of cases it's only helpful, there are a few cases where I find it annoying, as a mapper. For example, I have one of those secret wall-doors, not frobable but opened by switches on each side. On one side the switch is hidden behind a moveable skull on the other side of the room, this being the side the player first enters the area. On the other side I put the switch on the wall near the wall-door. Now when I enter the room the hidden switch pops out as one of the first things visible, just when the player is first wandering around. There's no longer a mystery, the switch is no longer hidden by the skull. Also, the switch on the other side of the wall-door is clearly visible right through the wall as I wander around. So as a mapper I have to figure a way to hide the frob outlines - else the area is spoiled. No doubt I can do this, and go through my map to find other instances of the kind. Less bothersome cases are where e.g. I put loot in a box and where I've put a water arrow or something down in a more easily visible area nearby, the water arrow serving the dual purpose of being a decoy - the impatient player grabbing it and thinking they've cleared the area out quickly moving on. But lo and behold, when creeping in to grab the arrow, the frob highlight of the loot pops out right through the box. So, I put the box further away or whatever. However, what about the 150 already built missions? This issue is going to impact them, too.

Ok, got it! Changed arrow damage. One shot, one kill. Thank you.

I got it to work with my model, icon, names. Everything good to go except, IMO it's unusable as it takes 4 hits to kill a revenant, 2 to kill a skeleton - which strikes me as being so wrong that it kills immersion. Too bad. The problems with builder_ghost and revenant_spirit must be a rendering bug.

Thank you! And so simple, too. Being an unsophisticated type, I'll opt for the easy way. eta. - or perhaps not. I need a new icon and inv_name etc. - i.e. not "holy". So back to the problem: where do I put the new entitydef? Is myFM/def the right place? Is my copy/paste -> change names procedure on track? eta2. After creating a holy water potion then changing the model to my own, it works exactly like the original holy water -- so my model inc. collision mesh is OK. The icon and inv_name are dead wrong, tho'. Also, about the way holy water arrows work is very odd and I don't like it. I tested on various undead AI with these results. atdm:ai_undead_revenant 4 x hw_arrow to kill it. 1 x fire_arrow to kill. atdm:ai_undead_skeleton_armed atdm:ai_undead_skeleton 2 x hw_arrow to kill. 1 x fire_arrow to kill. atdm:ai_undead_zombie 2 x hw_arrow to kill. 1 x fire_arrow to kill. atdm:ai_builder_guard_ghost invisible to player, it still attacks and kills player atdm:ai_revenant_spirit flat black skin. nonsolid for hw_arrow and fire_arrow How can a player know it takes 4 shots with holy water arrows to kill the (no doubt closely) attacking revenant? What's the point of an invisible unkillable attacker (builder ghost)? Or an unkillable revenant spirit?

I want a potion with holywater properties, but applied to a DR made model that looks more appropriate for my FM (with no crucifix). I've made several objects to grab, put in inventory, then drop at a location to complete objectives before, so that's not a problem. But how do I apply the properties of entityDef atdm:playertools_holywater to a model? One required property is that it can be applied to a waterarrow. I copy/pasted the holywater entitydef to myfm/def subfolder with appropriate name changes, but that didn't work at all... Does anyone know of an FM that has done this, or something similar enough with playertools, so I can copy that procedure?

I've been optimizing my map to boost fps from in a lot of cases 25-30 to 45-65, doing this systematically. I have a newbie perspective, this being my first FM - so .... be kind. First off, when building the .map I began by dropping in shadow/no_shadow lights with zero care - just looking to light the areas being worked on. Same for entities, dropping them in with little care except for aesthetics and creating shadows for the player to hide in. That procedure made for a very unoptimized map. So, what's been the optimizing plan? First, clean up the geometry. Second, go thru' the map section by section, setting shadow/no_shadow on entities. There's a tradeoff: complexity of geometry multiplied by shadows gets out of hand, so a lot of care needed here. With a first pass on that done, redo the lighting. I eliminated all the small ambients I'd put in, whether shadowcasting or not, leaving just those lights attached to fixtures of some kind, which I wanted to be in general shadowcasting. I reset these shadowcasters to not overlap so far as viable. I was amazed to find that this made for a much much better looking map coupled with much more acceptable frame rates. I use hide_distance on entities sparingly as I don't like the pop-outs. Not at all! My map has a lot of transparent windows/doors. I use func_portals with hide_distance set on every one of these. Controlling pop-outs caused by func_portals is fairly simple. The func_portal pop-outs tend to be marked by abrupt lighting changes. These are very ugly and getting rid of them or making them unobtrusive is a priority. I cant see using any kind of light pop-out/pop-in spawnarg. Rather, I could see using a shadow/no_shadow hide_distance setting, which could be used more universally and quite unobtrusively. If that's possible now, please tell me how! Also, I could see using a fade-to-black hide_distance on lights, so there'd be no lights a popping.

Thanks for the info OrbWeaver. Altho' I'd noticed the 'connection' menu item I hadn't bothered to enable it - to find the forum thread that explains how etc. was too much hassle what with all the other mapping things overloading my frazzled mind. Anyhow I put 'seta com_automation 1' in autocommands.cfg and started using the feature yesterday. If changes can include menu items it might be helpful having something like 'connections' item highlighting (unobtrusively) green when connected, unhighlighted when not, but clicking it when not connected might have pop up an info-box with a message "unconnected: to enable connection to TDM, type 'com_automation 1' in TDM console". I like the feature! It's perfect for my current task optimizing fps and tweaking lights/shadows/hide_distance etc. and so far I'm already hooked on using "move camera to current game position" - it puts me right there: saves time and helps me focus. Also I like "update entities now" (saves .map) and the hot reload "tell game to reload .map file now". I like the term "hot reload" as the feature is much better than going to console and typing "map myFM" and restarting at player start. Hot reload resumes with edited entities plus the player is in the same game position and, it appears, at the same game state. Lights shot out are still out, etc. I suppose this makes the "respawn selected entities" option handy but have yet to try it. Haven't checked if it resumes with the same objectives completed/not_completed, visible/not_visible, etc.

I've never ghosted a Thief or TDM mission. One thing that I enjoyed most about Thief was sneaking up and bonking the guards with the blackjack, hauling the bodies away to a corner where they piled up. One of my goals is always to KO as many as I can without getting caught - clear out the area so I can waltz thru' it coming back. For alerts, I just reload when I trigger a full alert. Otherwise I sit and fume while I wait for the search to finish, hoping not to get caught. So that's my playstyle and in considering how to set up my WIP (my wannabe FM - there's a LOT more work to finish one of these than advertised in the "hey kids! Now you can create your own FM!" jingle.) That's how I've been setting up the first tentative AI pathing networks. But it's fairly obvious why players who're a bit more adept than me would want to ghost a mission. I've seen a couple of V-man's videos. Anyhow, my question: does bonking an unaware AI, not setting off an alert, carting off the body so it doesn't cause an alert later on, count against ghosting? If it does count against ghosting that seems to set hard limits on what the FM maker can do to make a fun game for ghosters and non-ghosters alike, esp. since ghosters want to crank all alert levels and etc to max.

No, a skybox isn't always rendered, which is why when I swapped portal_sky with caulk in my now problem free WIP, the fps problem vanished. Because the area is sealed - closed by visportals - and if there are no portal_sky textures in a sealed area the caulk will display as what looks like flat black. Put one portal_sky texture in the sealed area and the caulk will display as sky.

@duzenko I found the problem. In my layer map there is no skybox. I drop a skybox in and it has that radical effect on fps. The sky is only seen thru' windows on the ceiling of the only area where there's a big drop in fps. The skybox is the one with full moon overhead, stars and wispy clouds. I'll take the sky out of the scene and do something different. I know, the geometry is complex - not up to the standards of my personal critical critic. But ~50 fps in a couple spots is now the lowest of the area so my optimizations have worked and the game seems to play fine.

r_showSmp 1 - FFFFFFFFF........... both maps r_fboresolution 0.5 - 50fps ->100fps - 35fps ->80fps

@peter_spy No mirrors in my WIP and no cubemaps in the area. Though I don't understand how that could impact on the issue since as I said, the areas with 34 vs 50 fps are IDENTICAL. As I said, separated by a closed visportal (red), and the anomaly persists even when I put in a worldspawn blocking brush. The area's where I do have cubemaps aren't problematic. The counts may be "superhigh", but they're IDENTICAL in both pics. The geometry is quite complex and what you see on screen isn't the whole picture.

r_showSmp = 0 in both maps r_fboresolution = 1 in both maps I worked on abstracting a small test map (leak...leak...leak... ahhh, finally) and it shows the no difference in fps at the place where above it's 50 vs 34, and the identical fps moving forward, but taking a few paces back to where the player is touching the door there's a 10fps difference. If proximity is causing it, in the WIP there's a busy (but totally isolated) area to the left as the player moves forward. I think I'll try moving the entire layer area to a more isolate position with 2 or 3 switchback visportals to further isolate it. Thank you muchly for all your kind replies.

These two images should have near identical fps. Working with layers, I exported a layer to a new map. The layer had only one door opening to the rest of the larger map, so the exported map only needed one blocking brush to seal leaks. This door is directly behind the player in the pics. th_1.jpg is from the exported map, lucy_1.jpg is taken after I remerged the maps. The visportal works, is outlined red, and I get the identical result when I put a blocking brush over it just to check. There's still a 16fps drop. I've been working on optimizing the area and had increased fps from 10-15 to 45-50 in one problem area with little or no hit to the aesthetics, by turning off shadows and making a fake ambient occlusion of sorts with stretched "dirt" decals (I do all my work in DR and don't have a modeling program with the texturing tools). That area is on the opposite side from the player (in the pic) and the fps in that area is identical in both abstract and merged maps. As it should be! It's only in the area of the pics where there's the discouraging fps drop problem. And discouraging it is! Does anyone know what's going on here, and how I can fix it? (pics of showtris and showshadows seem identical)

It doesn't work at all, v2.09a and the latest dev build. If I input eg. "r_showShadows 2" nothing happens, then when I input "r_showShadows" it gives the info that the value is currently set at "2", that default is "0", along with info on how it should work.

@duzenko It's fixed - by updating the intel gfx with the intel drivers at the Asus site. I had thought, since it was using the nvidia chip, that updating the nvidia drivers would be enough. But I guess that "GPU 1 -copy" also addresses the intel chip. Thanks, and I apologize for wasting your time!

@duzenko 1. opening TDM, prior to mission loading: GPU 1 - copy (nvidia) after mission loaded: GPU 1 - 3D (nvidia) 2. laptop: 1920x1080 desktop: 3840x2160 (a cheap LG TV - good for my failing eyesight, esp. when mapping, but looks like washed out crap compared to the crisp clear color of the laptop) nvidia control panel can allow me to choose "preferred graphics processor" but ignores that when loading games.

In the meantime a solution is to just delete the particle value before moving the group, then once moved open entity inspector and the key/value is already correctly entered so you just have to click the check mark. It's just a rare few particles that give any trouble. I haven't seen any use for showing particles in non-lighting mode either and every time I try something new I have to see how the effect works in game. There's a lot of subtlety in the TDM particle system and I just wish I was a quicker study...

Asus i5 zenbook with MX150. Opened my WIP in the laptop to check and compare framerates against my i5 desktop with geforce 1060. Since I'm using the dev build 16269-9407 on the desktop, used the same build on the laptop and got "Unable to initialize OpenGL" screen. Backtracked thru' the dev builds and found the last working version was dev16225-9284, which loads the game fine. Problem starts with dev16238-9330 and the two newer versions. No similar problem on the desktop. (and.... WIP framerates on the laptop will give some people heart attacks. Tho' I find it still playable - TDM isn't deathmatch - and it looks very good on that little machine.)

The pic shows a grouped emitter+light+fixture. In this case the particle is lantern_glare_simple which, when selected, obscures the fixture making it harder to accurately place. Some other particles like al2_lamphaze are similar, tho' thankfully most don't create any mess and the selection is confined to the emitter box. Is there any way to turn off or hide this -- I guess it's a cluster of textures?