geegee

It seems like I'm at the finishing stages of my first WIP. I have to add an overriding caveat that in the end I might not think the mission should be released at all. It's a large mission - probably too large to be a first mission, regardless of how "done" it might appear on the surface. The reason: I discovered how, as missions grow in size, so also they grow in not only technical complexity, which at least can be handled by perseverance and a bit of luck haywiring parts together, but also in the need for developing depth, as in characterization, cohesion, etc., so that it becomes more interesting rather than less as the mission is played through. And that's where I'm hitting a wall. All the architecture, objectives, pathing, lighting etc. is done. I'm still working on ambient sound. There are no conversations. I'm unable to supply them. In lieu of conversations I've been using different light/sound effects etc. to enhance the moments of ai/player interaction where conversations are usually found. This works to a significant degree. The problem is that the AI, on whatever path it's at, is indifferent. I would like at least as much control of AI as required to get it to -->STFU<-- while the events are happening, then to resume its idle banter. I've tried using S/R to change spawnarg def_vocal_set from e.g. atdm:ai_vocal_set_jack_civilian_01 to atdm:ai_vocal_set_mute, then back again, but I can't get it to work. I don't know how to write a script that'll do such a thing - and can find no info on that particular. Changing def_vocal_set works on an AI if I set the spawnarg permanently at game start. But I can't figure out how to swap the spawnarg in game. I've tried calling a fake conversation with a atdm:conversation_info and the actors all told to WaitSeconds NN, hoping that would shut them up. That didn't work. So OK, enough complaining- I need help. Just pointers to any detailed info on how to do this. How to even begin to do this. Hopefully with none of the critical steps left out because "everyone should already know...". Because I confess: I'm too fucking stupid to know any such thing.

Put an empty .txt file in your darkmod root directory and rename it autocommands.cfg autocommands.cfg serves the same function as autoexec.cfg - console commands put in there will automatically execute on loading, e.g bind F1 toggle r_showportals 1 r_frobIgnoreDepth = "0" If it's suddenly missing, somehow the file got messed with since last good load map. Perhaps reinstall the game in case other things got messed with.

That appears to be models/mechanical/gears/gear_metal_fancy.ase which sandwiches the model between two square patches that have the spoke pattern texture. Also, in my WIP I struggle with framerates and I get much the same results as you, tho' I use the TDM frame rate counter which bounces around a lot and doesn't do decimals. There's virtually zero difference in fps between 1/0 on the showdepth hack, and I REALLY DO like the outline with r_frobIgnoreDepth = "0"

I use DR. I suppose some existing missions put buttons under desk tops, etc, to hide them. If not, then it wouldn't be a problem. I'm not going thru' them all for you. Also, you asked, specifically: "What are the steps for me to reproduce?"

put a "secret" switch under a desk.

No, the problem I have with the highlight at default (where r_frobIgnoreDepth = "0" isn't set) is that it can be seen through walls, desktops, etc. See my earlier post in this thread where I set up a simple situation with hidden note under a backgammon set on top of a desk, and a hidden button underneath the desktop. I posted a series of screenshots. In my wannabe FM I first noticed the problem when I had a secret door in a wall, a somewhat hidden switch in the room, and a switch beside the door in the secret room. The switch in the secret room didn't need to be hidden since the door was necessarily already opened. With the default frob highlight the switch in the other, secret, room was immediately visible as the player wandered around - and the immediate instinct of any player would be to frob it since, after all, that's exactly what the frob highlight is begging the player to do.

How about, if an object isn't visible at all to the player, then no frob outline at all is drawn. The old frob highlight works like that: there is no highlight on frobable objects that aren't visible to the player, so the player doesn't see highlights floating in some x-ray vision.

It isn't a bug, it's a feature. With the frob highlight on as currently set default in the 2.10 dev builds, you can see it thru' desks, walls, etc. So if this is implemented in the final build I'll have to go through my wannabe FM taking this new feature into account, relocating switches, loot, readables etc., or covering the entities with target_set_frobable, or whatever else that'll work to make it play right. The game is a THIEF homage, and there's stuff that's supposed to be hidden from thieves, not telegraphed through walls etc. That's the whole point of the game. I never made TDM - I'm late to the party - so I'll go with whatever and do so thankfully because I appreciate the work, the result, and it's great fun working with DR then checking it out in a great game engine. Going thru' my wannabe FM to redo things to account for this feature won't be much problem, the time spent a drop in the bucket compared to the time already spent learning tricks. But what about all the FM authors who're no longer here, who's going to fix up their FMs to put back the mystery.

Excellent! That worked. Thank you!

@stgatilov Here's a .pk4 with maps, materials, textures, and bug.txt copy/pasted from my description. .pk4 zipped with 7-zip then renamed. map last dmapped with 2.10 dev build 16269-9462 (where seed is working properly) Sorry, I have no idea how to start a bugtracker issue. seed.pk4

The seed entity populating my turnip patch stopped working with dev build 16325-9462 and doesn't work with subsequent builds. The seed entity works fine with dev build 16269-9407 and earlier. (is this the correct place to report these issues?) eta. my other seed entities are working, the difference being that the turnip patch has a .tga map (8-bit grayscale 512x1024) in textures/seed whereas the others don't use maps. I guess I could always have the turnips distributed randomly rather than set out in neat rows....

Yes, that's correct. By setting $sgt1.setAcuity("vis", 1); etc. the AI now acts as it should, so the range is 0->1 with 1 default, and I guess setting 100 makes the AI into a superhero. That is, the range is 0->1 in the scripting language. 0->100 when setting the spawnargs in DR.

Using tdm_ai_showalert and some testing I found that only one AI produced this problem. With black/near_black lightgem I switched between blackjack and waterarrow and there was no alert differences for any of the AI, except one named "sgt1" that I'd altered from Acuity_vis 0, _aud 0, _tact 0, via the script { $sgt1.setAcuity("aud", 50); $sgt1.setAcuity("vis", 40); $sgt1.setAcuity("tact", 50); } For sgt1, after acuity was reset by the script, changing from blackjack to waterarrow caused a change from alert 0 to full alert wherever sgt1 was in the large area. So there's something wrong with the script? Reverting to an earlier map where I'd simply teleported out the sgt1 with acuity 0 and teleported in a sgt2 with default acuity settings there was no problem. sgt2 didn't go on full alert, didn't notice the waterarrow and the scenario played out as it should.

Is the water arrow more visible than the blackjack? How much more visible? In my FM when hiding with the blackjack enabled and the lightgem black or almost black I'm invisible, I can move around freely in the darkness, but if I then switch to the waterarrow to shoot out a light I'm suddenly visible to an AI across the whole room, I can't seem to hide, as if I'd lit a torch. What are the default acuity_vis, _aud, _tact, settings for when I put in an atdm:ai_guard_elite? answers seem to point to 100. Trying to find a setting where I can hide I set. { $sgt1.setAcuity("aud", 50); $sgt1.setAcuity("vis", 40); $sgt1.setAcuity("tact", 50); } But the elite guard spots me instantly I bring out a waterarrow, like I'm suddenly fullbright although the lightgem remains black or near black. This can't be right. Are the defaults for an atdm:ai_guard_elite the same as for an atdm:ai_citywatch or atdm:ai_guard_thug? Where can I find a list of these settings? Sorry for so many questions.

Thanks for that. I hacked together something clutsy before, teleporting out/in the vegetable/normal ai. The above worked to reset the vegetable ai to normal and the result is smooth. Not clutsy! It also gives me an idea of the general form.

Oh yes! The prefab with openable doors works perfectly with the desk3_complete. Thanks! eta: now changed to the desk3 prefab. I think I know what assets are there but then find out I don't know half of it.

Yes, that works. Good!

Then ignore is too limited. I've just had it. I'm not going to name names. I'm fairly new here, and I guess my stay is more or less finished except maybe if I complete my FM or run into a totally intractable problem

I wouldn't normally do it, but I put a member on my ignore list because the posts were upsetting. Very upsetting. I enjoy TDM and DR and enjoy the forum, except for the one person. Usually I check the forum out as 'guest' but will auto sign-in so there's no trace of the ignored person's post, mentions, and all of it. But it doesn't work. And I'm outa here if I have to suffer any more of that.

I just went through my map with "r_frobIgnoreDepth 0" and found no problems anywhere. Although the outline is occluded by deepset doors etc., in no cases was it totally occluded and in those cases where it was occluded most the old frob highlight was still there, making the frobable at least as clear as it is in v209a. I got the impression that if the old highlight is kept, alone without an outline, the highlight code will be hardcoded so can be removed from material.mtr entries and this will speed up load times which is wanted by everyone. I also got the impression that if a frobable has to be frobed through a box or etc., even with total occlusion the frobable can still be frobed just as accords with the mapper's original intent and how it has gone before. The highlight and/or outline just can't be seen, which is also what's wanted. So Dragofer outlines a plan that doesn't break anything and seems best for all purposes, it seems to me.

I assume that in my posts. I'm addressing the issue of fps "costs" and etc. for hardcoding this vs MirceaKitsune's notion of making this a player menu choice vs. the impact not having it set has on gameplay and the impact on designing a good FM. What are the drawbacks to hardcoding this and also applying some auto-version of the old style frob effect, to cover those cases where the outline is obscured by frames or etc?

Having spotted the switch right through the backgammon board and desktop while standing upright from the front, the player might crouch to look.

Here's the same desk, the player approaching from the front.

The only factor the casual player will consider is aesthetics - which leaves it up to the more conscientious mapper to account for every choice. A mapper can't just assume the player will choose the option the player prefers for playtesting areas. Here I've put a backgammon set on top of a hidden note, and under the desk is a switch. The player is approaching from the back, scanning back and forth, up and down. Some secret. So how does the mapper account for that?

I reverted to v209a and played for a couple hours and still think the frob outline in the 2.10dev build is better in general, and by quite a bit. I wouldn't want to go back to the old style. So what is the performance cost of depth blocking? Wouldn't that cost only be paid out for the brief moments something is in frobbing distance, and at those times where the player is paused or almost paused isn't fps much less of an issue?