kingsal

Looping back on this, if the frob code gets booted we need to find something that works in a variety of lighting situations and material values (dark - light). I am against color coding anything simply because it could be a nightmare to manage what objects do what . I think keeping in line with classic thief is the way to go with some solution for darker materials (which dont show up very well in the current scheme). EDIT: The current prototype highlight looks nice IMO but is a bit too strong. We shouldn't go full white but maybe 25-50 percent. Another option would be to add a custom setting that allows players to pick how strong of a highlight they want.

I dig the idea of "mod-wide" tool tip pop ups in game. We don't want to do it with everything, as its fun when player's discover some things on their own, but we should cover the basics and a couple lesser-known useful hints ex: "Learn forward..." . The distinction there is a little muddy so we'll have to test the system out and get feedback. Visually, we should try to make these as elegant and unobtrusive as possible and the beginner/ intermediate/ off is a great idea. (dig that SS solution, totally forgot about that!) My suggestion would be to try this out in the tutorial mission and take it from there. If dynamic tooltips work well enough, we might not necessarily need message pop ups in the tutorial. We'll just have to see. We need to be very careful about changing conventions as they can have downstream effects, but we can take a look at this stuff on per case basis. @Obsttorte Springheel and I discussed the idea of actually showing the key bound to that specific impulse in the tutorial pop ups. For example: " Press RMB to frob" Is there a way to grab the current bound key and display it?

For what its worth, Springheel and I discussed building a new training mission that covers the basics in a more structured way. Im glad this got brought up, I'll add extinguishable light sources to the list of features. We don't have any concrete plans yet, but the idea is to make a shorter, more linear section that introduces the core mechanics followed a practice area for more complex stuff, shooting arrows, lockpicking, stealth, ect. This will lead right to A New Job where you put these things into practice. Stay tuned.

These are great! I'll have a look through them and see which ones would be nice additions to the core mod. Some more variety is always welcomed. Thanks for putting these together!

@greebo Very excited about this.! If I can get it set up I can start playing with it as soon as its ready and hit you with some feedback. Very cool.

@stgatilov Well that's discouraging. I think you are making assumptions on the part of mappers. Yes its their responsibility to teach players if they deviate from the standard camera, but we have tons and tons of things in the mod they can already do this with. That's the point of being a mod and we've seen some awesome things in missions because of it. Im pretty confident we can get this camera to mimic the ones in thief 2. Plain and simple. If an author wants to get creative and make whacky design choices. That's their choice. Edit: Also I should note that we haven't really started testing this thing out. A lot of these questions will be answered once we start testing and playing with it. Pretty standard process. So we can debate up front all day about this and that, but in the end we just need to test them to see whats working and what isn't.

@DragoferThat sounds like a good plan. We wont know really until we do some testing to see what works and whats fun. It might prove extremely difficult or super easy to cheese them with flashbombs- we'll just need to test out these assumptions.

@VanishedOne Thats a good point. I think on balance the most interesting part about the cameras is avoiding them and then trying to find a switch in the level to turn them off (at least in the case of my own experiments). Outright destroying them or even disabling them should require the use of a valuable item. Maybe water arrows are too common for that and we should just stick with firearrows as the players way of immediately dealing with them if they choose to. We do run into this problem where different maps will use different conventions so maybe turning the water arrow disable thing off be default, but leaving it available to mappers is the way to go. EDIT: I also had the thought that temporarily disabling them with a flash bomb is interesting. It would be more difficult to do and usually flashbombs are more rare. Anyways- a good bit of that can be handled by the mapper and stim-responses. Maybe we just leave the code in for a "temporarily disabled" state incase a mapper finds use for it. Keep in mind the idea is to make these somewhat modular so it can turn into eyeball plants and floating skulls or whatever where a disabled state might make sense.

Sorry one more bit: I think some concept of damage threshold would be the way to go if we wanted them to be immune to everything but firearrows. Dragofer already has some concept of this in his code. So any amount of damage underneath the threshold of the firearrow gets thrown out. (assuming a direct shot from a fire arrow does a good deal more damage than anything else)

The current set-up Dragofer has is configurable for all kinds of things. The idea is to keep it as flexible as possible, while still manageable. I think we're talking about an entirely new camera definition, so these won't interfere with old maps. In the case that they do, I believe its only a small number of maps that use security cameras and we can reach out to those authors to let them know. Im not sure if clipmasks have types associated with them and some things might even use the same ones, but that sounds like a potential avenue. EDIT: Looks like there is some idea of a melee weapon in collision information, not sure about arrows. I guess those would be in the projectile code like @VanishedOne mentioned. MeleeWeapon.cpp: #include "Game_local.h" #include "Grabber.h" #include "DarkModGlobals.h" #include "MeleeWeapon.h" CLASS_DECLARATION( idMoveable, CMeleeWeapon ) END_CLASS const int CONTENTS_MELEE_WORLDCOLLIDE = MASK_SHOT_RENDERMODEL | CONTENTS_MELEEWEAP | CONTENTS_CORPSE; const int CONTENTS_MELEE_ACTCOLLIDE = CONTENTS_MELEEWEAP | CONTENTS_BODY; // parries/held items, AI

Also with regards to how they are damaged/ disabled: While playing around with them in my own mission (which has a bunch of these guys). I find its more interesting to use high value arrows to destroy/ temporarily disable OR find a switch to power them down. A couple proposals: - Water arrows to temporarily short circuit them. Maybe 10 seconds or so by default? Could be handled with a water stim - Fire arrows to blow them up. This is a bit more tricky as fire stims wont work. Maybe a damage threshold? Or simply give them a good amount of health and make their texture immune to broadheads? Im not entirely sure how to do that. We do have a concept of "armor" on AI materials which might help.

Definitely. I think in all cases its proper etiquette to ask the artist/ creator for permission to use their work. I also think its also our responsibility as creators to use our best judgment when we put our work on the internet, because inevitable not everyone is going to ask, unfortunately. Assets that come packaged with the mod (part of the core) are up for grabs for editing, modifying, ect without permission. Just not using commercially of course.

I get the sentiment here, I really do. However, if someone wants to take models (my own included) and change them for better or for worse - I consider that their problem and not mine. Thats just the nature of contributing to a free mod. We're not going to boot model exporting.

Yep there is a map in this mission:

Nope, there is no attitude of "can't be done, lets throw it away". The team is doing its best to make TDM a stable experience for everyone. Some of that yes includes changing the way stuff works and in very rare cases removing features. The best approach is to say "Hey guys, I really get a lot of use of (so and so feature) what's the reason for removing it" State your case and the team will do its best to help. Your last comment is bogus. Stgatilov, Cabalistic, Orbweaver and Greebo are doing a fantastic job of supporting mappers. Yes Grayman is awesome, but the current team is staying the course and trying to support mappers as much as possible.

Hmm the extra page on that readable is just a bug, but I am able to pick it up and read it. No reports of not being able to be pick readables in this mission, so that's weird.

I have a situation in my current FM where AI on the same team are more likely to accidently hit each other and then start a duel. Does anyone know of a work around for this? I'd like to stop the AI from turning on one another in this particular situation. Thanks!

That would be helpful! Im not sure where the entity should be placed on double click. Maybe at the origin of the current or previously selected object? Also its worth mentioning that various different entities have s_shaders, lights for example will also take a s_shader arg.

@greeboVery excited to check these features out! Thanks for all the work you've been putting into the editor these days. EDIT: From the favorites menu how do I actually create an entity or change a speaker s_shader? Double clicking on a texture will change the selected surface, but double clicking entities or sounds doesn't seem to do anything for me.

Very nice! Excited to use this model in one of my missions. Thanks guys.

@stgatilov EDIT : Looking into this further, I think this is a problem specific to these models. I can't seem to reproduce with other models. Might be an issue with the mesh or something weird? This is what I did to get the duplicates (video below): Selected a group of func_statics. Reduced the current hide_distance and hit enter to apply to all: Hit respawn selected entities There are now duplicates spawned in the game. Video here: https://www.dropbox.com/s/722cns51h3wbedp/The Dark Mod 2.09_64 2021-01-06 10-55-39_Trim.mp4?dl=0

This for sure happened. I'll capture a video or screenshots next time I'm in the game.

@greebo Awesome, will give this a try soon. Not sure how the behavior should be but apply to selected / selected surface for materials sounds good. Maybe models and s_shaders for entities with the respective spawnargs. Drag and drop to create speakers and func_statics would be very cool. I wonder if we can use that convention for other elements in DR and gradually introduce it where it makes sense?

@greebo I think this is looking pretty rad! Would be curious to hear what other people think, but I would definitely get use out of this.

For example : something like this would act sort of like the unreal collections convention. Just a pop up list thats alphabetical and filters by type? Im just kind of spit balling ideas, no idea how feasible this would be.