Jump to content

Frost_Salamander

Member
  • Posts

    474
  • Joined

  • Last visited

  • Days Won

    9

Everything posted by Frost_Salamander

  1. Hmm I'm not sure what's causing that issue with the menu, but thanks for raising it
  2. I'd like to announce the release of my 2nd fan mission: In Plain Sight. "You are an intelligence officer tasked with revealing the source of a political uprising in the city of Watchgate" Mission Type: City Missions Credits: @Frost_Salamander: Author @Airship Ballet: All custom content, including signs, loading/menu screens, in-game map, menu music and creative input. Also sets the standard for beta testing. W10 (my son) and @Frost_Salamander: Mission briefing Beta Testers: @AluminumHaste @nbohr1more @Obsttorte @Mawerick @madtaffer @wesp5 @Airship Ballet @Acolytesix @Cambridge Spy @jaxa @prjames Notes: TDM 2.10 required This FM rewards stealth play, although it can be done without KO'ing anyone Read the readables! They trigger some mandatory objectives that aren't initially visible. Follow this and you shouldn't have a problem figuring out what to do next. There are multiple ways to access some parts of the city. Some are riskier than others! If you are finding it too hard, maybe there is an easier way The only differences between the difficulty levels are the (optional) loot objective, the availability of some player tools and the difficulty of the bank objective. There is an in-game map. It's found in a location near the start. This FM contains 5 secrets (hints below for anyone who's given up ) Secret hints: Secret spoilers (did you mean to look the hints above instead?): Download link until the mission database gets updated: https://github.com/FrostSalamander/tdm-fm-inplainsight/releases/download/v1.4/inplainsight_v1.4.pk4 Screenshots: https://www.flickr.com/photos/196169449@N05/albums/72177720301116716 NOTE: Some of the initial versions have bugs. Ensure you have the latest version (currently 1.4)
  3. Yeah some of the best ideas just kind of happen that way, don't they? I think I found that one because
  4. Just finished this, really enjoyed it. I found it pretty challenging, but fair. I thought the builder area/church was really well done. God knows where the secrets are - I only found one, and just barely got the loot goal on medium (I got 685). Good use of verticality too, and I like these small but packed maps. Good stuff Oh and I loved it when
  5. The frob box becoming solid doesn't seem to be limited to this prefab - I just added one to another model and the same thing happened. However, I think it's probably not really an issue, and is only a problem in this case because the frob box is way bigger than it should be. I'll raise a bug about the prefab frob box being too large and mention the solid thing in there. If someone thinks that's a bug as well they can look into it.
  6. I have some questions about frob boxes. In the screen shot below, you can see the frob box for the wall_lever01.pfb prefab. In my FM, I made the lever non-frobable while you were outside the room it was in because you could frob it through the wall, and I didn't want to reduce the frob_distance. However, when you make it non-frobable, the frob box becomes solid, and if the player passed by that wall outside the room, it would appear they were being blocked by an invisible entity. I didn't really understand the problem at first so I just moved the lever. Since then I've played around with the spawnargs and have realised you can just change the frob box size, or get rid of it altogether. So questions are: Is the frob box supposed to become solid when the entity is not frobable? If so, why? This prefab works fine without the frob box, is it really needed? If the frob box is needed, why is it so big?
  7. I raised a bug report which kind of covers this, although I found it more severe than what you describe here: https://bugs.thedarkmod.com/view.php?id=5988
  8. I didn't do anything weird I don't think. I just used the usual path nodes to make the AI sit and sleep. Only one person mentioned it, but I tested it myself and sure enough most times damage was dealt to the AI, and maybe 20-30% of the time it was enough to kill them. I might set up a little test map and share it if anyone's interested in looking into it. At the end of the day I'm not too bothered by it - it's just something that seems like it probably shouldn't happen though.
  9. I was looking forward to playing this since I realised it was a train mission. Just finished it - great stuff. Such a refreshing change from what I've been working on Got to about 2600 and change before I had to pull out the old tdm_show_loot (I'm a terrible loot hunter). I missed an obvious one in a drawer, but not sure I would have got some of the others as they were very close to AI. Made for the exit after that with a stealth score of 17. I liked how in some situations I pretty much had to use my tools (or if I didn't it made it a hell of a lot easier). I also got busted by the spotlight on top of the train. I have shadow maps enabled but didn't notice a volumetric effect - not sure why. Anyways - nice job and looking forward to whatever you cook up next!
  10. I have some AI in my FM that are sleeping. Some in a chair, some on a bed. Sometimes they die if you blackjack them. There are logs in the console saying they are taking 'landing damage'. In one case it was 252 damage at once. Other times it was several small amounts like 5, 7, etc. Does anyone known what causes this and how best to avoid it? I've heard things like use moveable chairs and making sure the AI isn't touching them, but I don't want the AI to be sitting on air if you move the chair, or see them floating above the chair/bed just to avoid this.
  11. Not off hand no. Say you have an abstract class or interface you need to implement and it has a method called 'doSomething()'. In the implementing class you have to implement the method, but say it doesn't make sense to have it do anything, so you just implement it and have it do nothing. There could be various reasons for this, like early in a project and it's just not implemented yet, or bad design, or using base classes from a totally different game...
  12. well I meant more like it's implemented but does nothing just to satisfy interface requirements, like you see in some OO code. Not sure if that's a thing here or not.
  13. Is this because the script events are just not implemented? I get this sometimes too and wonder if there is a way to tell? It's just a lot of trial and error it seems. If that is the case, something in the script reference for each event would be helpful.
  14. It's a bit of a guess and no I'm not 100% sure. I'll try to test it again to see.
  15. Well it can only probably happen if @Kerry000 ever resurfaces, as his contributions gave it the character it has. A good chunk of the map for part 2 is done as well.
  16. I couldn't get the commoner to open the door directly either - and I admit I didn't actually test that on this map. What I was trying to say was if the commoner didn't have a path to the controller he would try to open it directly. But he does have a path to it in this case which is why it works. What I missed was that even though the door was locked, technically the path is still there. So, I think in real (as in mapping) scenario you'd always have a path between the door and the controller because obviously whoever opened the door would need to be able to travel to it after they handled the controller. So basically my imagined scenario doesn't make any sense. So maybe it's OK? If so, a Wiki entry on the doors page warning of this behavior and how to solve it would do the trick I think. You said it worked for secret doors as well - what did you do there just put the door handling entity on both sides of the door? In my map I used the func_aas_obstacle and that worked for this. Not sure what the better solution is.
  17. For my scenarios, the answer is yes. But surely there might be others where you'd want to be able to do both, like in real life (e.g. my flimsy wooden door example). This is why the mapper needs total control of this ability. Maybe we should just treat is as a new feature request? You're right in that those other solutions have their reasons for existing, and I don't have a problem with them really because they are meant to solve different issues (although the bit with the AI not being able to go through the door after it's opened needs fixing).
  18. Hi everyone! I have a fan mission ready for beta test if anyone is interested in helping out. It's a standalone city mission unrelated to the Hare in the Snare (which is on hold indefinitely). I will start a beta testing thread once I get a few replies. Thanks!
  19. If you use a door handling position entity it stops the AI from using a controller as well. This makes sense in a way, as you are basically saying 'don't enter the door from that direction'. My requirement is different - I want to be able to say 'only open the door using the mechanism I want to be used'. If I have a gate that is 20 feet tall and weighs a ton, nobody is going to be opening it by touching it. I've attached a test map to illustrate. A guard sees you behind a gate that he should be able to open with a lever. However he can't because I've had to put a door handling position entity in front of it to stop the commoner AI from being able to open it. If you take away the door handling position, the guard will able to open the gate, but then you get the commoner able to open it with his magic hands. The other nuance here is that the commoner can't get to the controller because it's behind a locked door that only the guard can operate because it's his station and not open to the public. It's a perfectly reasonable setup. aidoors.map
  20. So I just tested this, and it stops the fleeing AI from opening the door, but he still won't walk through it after it's been opened. Other AI do though (for example a guard chasing me did go through it). Not the end of the world but still strange. Yes I remember and thanks. I wasn't too enthusiastic about it because I don't like the default behavior and these all seem like workarounds. I had made a mental note to try it if nothing else worked though. Maybe there is a good reason for not calling this a bug, or not changing it but I'm not sure what it is. Fear of breaking existing missions maybe? Anyways, I'll put something in the Wiki about it once I'm 100% sure about what's going on here. thanks @Obsttorte for looking into this.
  21. perhaps, but do we agree it probably should be up to the mapper though? In one of my scenarios, the 'door' is actually one of those large iron gates that slides upwards. The AI shouldn't be able to open it without some sort of mechanical assistance. But yeah, if we're talking about a flimsy wooden door then sure why not.
×
×
  • Create New...