Jump to content
The Dark Mod Forums

MirceaKitsune

Member
  • Posts

    1910
  • Joined

  • Last visited

  • Days Won

    22

Everything posted by MirceaKitsune

  1. Aha, thank you for this clarification! I see what's happening now: I was expecting that the building modules still cast shadows by default, which I was in fact hoping got disabled since their performance impact can be felt... in addition I thought texturing the walls with normal caulk would still work as they create closed rooms, but indeed caulk isn't a shadow caster so I shall replace them with shadowcaulk as suggested. There's another bug in latest dev I was waiting to report: I noticed I can place electrical lights in DarkRadiant where they show up just fine, but when opening the map in TDM they do not spawn any longer. The console provides a warning which suggests an invalid newline causing the engine not to load the def though DR doesn't mind it. I don't override the file in my FM nor had any errors while running the installer and updating so I'm presuming something got broken. WARNING:file def/tdm_lights_static_electric.def, line 612: newline inside string
  2. It's not that no: I didn't modify the properties of the default entity or its flame, in this case it's the standard atdm:lamp_oil_wall_lit entity... also I have player shadows enabled, the player as well as other architecture elements cast shadows fine. Walls are the building modules, eg: model models/darkmod/architecture/modules/interior_set01_corner.lwo with skin diamond_wallpaper as a test. This is the closest to the setup I still have: The origin of the light is well beyond the face of the module surface for shadow casting. Though this shouldn't even matter since the light is in the other room and the caulk brush should itself mark this. I think I noticed this on other maps too while playing, but only now saw it obviously enough to realize there's likely an issue somewhere. I remember seeing the glow of a light from another room shining on the floor / ceiling when it shouldn't, though I didn't document it at the time.
  3. I'm on dev16829-10455: With a new map I'm working on I keep noticing lights leaking through walls. The walls are thin caulk brushes (8 units thick) as I'm using the building modules. Sometimes a lamp on the other side will shine straight through the wall over the floor or ceiling. In one case I noticed this happen even if the room where that lamp is located was behind a closed door / portal, meaning the engine should know the light doesn't reach you and should be disabled entirely yet it still worked. I've reworked my map since so I no longer have it. But in this screenshot I took, the brightness you see on the ceiling in the middle is from a gas lamp mounted on the wall on the other side. In this case closing the door to the right while standing in the same spot makes the glow go away once the door is shut, but like I said there was another case where the light shined through a caulk room even when its door was closed and I was standing outside.
  4. The magic temple / monastery of a new FM concept I'm working on. The flames will be part of the gameplay and represent progress in some form, will address the details as I go.
  5. There's another trick I wanted to try but haven't seen done before and it may not be possible but still: Can you make it so when you die, the FM doesn't end but a script function executes or an entity is triggered, ideally only if the player is in a given area? Thus once you reach 0 health, you fall hearing the player grunt sound and the screen goes dark as usual, but instead of the "mission failed" screen you find yourself teleported in a particular room with your health fully restored. The script reference page mentions two functions called customDeath and deathMenu for idPlayer, however they aren't documented... does anyone know if that's what I need and how to use them?
  6. Okay now I actually think we need a tip system, since in 10 years I never had any idea you can use lockpicks to disarm mines
  7. If there's a kit there must be that one FM which implements it: I played nearly every mission and can't remember picking up a "mine disarming kit" item. Makes me think the tip system should be implemented as a script: Apart from keeping the C++ code clean and relevant to the deep stuff, it would allow FM's to add their own custom tips specific to map functionality.
  8. Thanks. That would be the method for going with a campaign: I was wondering if it's possible outside of that as well, I take it that means not. I'll either go with the campaign approach, or if I can find a way to do a partial reset in the map.
  9. Wait is that actually true? I'm with TDM for almost a full decade now, always thought you can just disarm any mines but recently discovered that never works, seems I had it wrong both ways and could use such tips myself
  10. Indeed, but I imagined it was removed with the other stuff... now I hope it won't be, and if need be can be fixed to be compatible with TDM. The question is if it knows to work with our AI and entities, if we haven't done anything too radical to break it maybe we're lucky and it does! I should finish the FM I'm currently on, then I'll reload a previous one and give it a quick try to at least ensure nothing crashes or goes crazy.
  11. I'm still curious about part of my question from last time so I can weigh in all options: Is it possible for the scripting system to generate a text file in the FM directory, which can be used to store and retreive information about previous runs independently of saves? I could have a use for that if yes, though I'm not seeing any obvious way in the documentation.
  12. Oh my, it's already there? I will definitely take a look at it at some point! If it works there should definitely be a menu component so it's accessible to everyone, I didn't even hope it was already implemented to some extent Will need to see how it handles saving and loading while a demo is being recorded. Also what camera modes are supported: The magic I had in mind would be the ability to fly around and see the player, as well as through AI's eyes to experience how they perceived the world and saw you during your run.
  13. Those would need to be recorded and made constant during playback of course. Physics aren't random though right... like if you pick up and throw a vase against a wall, it will always move and roll the same way based on initial velocity? If so I'd presume this could work by merely remembering and simulating identical player key-presses and mouse movements, while using constant values for randoms in AI decision making and other entity scripts to ensure they always do the same things.
  14. As usual this is mainly intended as a discussion and to hear opinions: It's not an expectation that the feature will happen soon or at all. Especially as this would be complicated to achieve, but if it could be done I think it may be a fun capability to consider. The idTech engine had several features that got removed since we aren't using them like multiplayer. One used to be the ability to record a demo of your matches, which makes sense in multiplayer DeathMatch games. Yet recently I started to wonder: How would it be like to have a demo capability designed for TDM? Imagine being able to record your playthroughs or share your recordings for others to watch, for when you'd like to relax watching a FM like a film instead of playing it like a game. You could fly as a detached camera, observing yourself wonder around the map and watching the things you did... or stay in 1st person and see the game play itself like in a Youtube video. The coolest thing would be the ability to see through the eyes of any NPC: Imagine being able to click on a guard in floating camera mode to embody them, seeing through their eyes as they patrol the area and at some point notice the player hiding in a corner through that guard's eyes (even if the AI didn't notice you). The biggest challenge would be a way to record store and reproduce every input from the player, with every AI decision and other entity actions just as they occurred, which includes preserving object physics to represent the exact movements of all entities: Parts of the demo system from Quake would likely need to be reimplemented, wonder how much it knows to handle on its own. Saves and loads would be another tricky one: Each demo should erase what you did after last loading to produce a seamless run... alternatively it could record that as an action and include reloading in the playback. There's probably other challenges but if it's within the realm of possibility, would anyone else use this and think it's worth thinking of?
  15. As long as it's a setting, absolutely! Don't see anything wrong with it and it might help many new players. The approach I find best is to only show each tip once: Give the menu two buttons called "clear tips" and "reset tips". The first disables all tips in case you're an experienced player on a fresh config and don't need them, the second resets them so next time you play all tips will show up again in their relevant circumstance.
  16. I actually thought about it briefly. Biggest problem is the campaign has a finite number of maps listed: I guess I could just list the same map 10 times or something, that would well cover all the options you can get... better off just use the maximum number of runs in which you can achieve every combination! I remember there was a way to remember choices (from special triggers executing) between different campaign levels, though I never used it before. Will look it up and likely use it with that, seems like the best option for what I'm thinking.
  17. A rather unique idea for a possible FM occurred, though doing it right would require something I don't think is possible, none the less I'd like to know what the closest way is. Is there a way to trigger a reset of the map that makes you start from the beginning from within the map itself, storing only information about particular choices you made during the previous run? I don't care if the loading screen shows up again or not, a seamless way where you just reappear at the beginning would be ideal, but I'd rather avoid the briefing screen and having to pick a difficult again as I don't want the restart to be that total. Example: During your first run, you're given an objective to kill an AI which you may or may not complete. Upon reaching the end, instead of the FM ending normally and showing your stats, the screen fades to black and you find yourself at the beginning: Everything is reset, all objectives the AI the loot any items you picked up and so on. Based on whether you completed that objective or not before the reset, certain targets are triggered changing a few things on the map during this run. I case a map reset isn't possible to trigger: Is it at least possible for the FM to store information independently of saves? So you complete the FM normally at first, but next time you choose to play it choices you made during a different playthrough are detected and triggers executed accordingly. I'd rather avoid this method since there's no way to reset it unless you'd manually delete whatever text file is generated in the FM's directory, granted there's a script function allowing this to begin with.
  18. Only now got around to finishing this one. Absolutely loved it: Starts out looking pretty average at first, you can tell it was rough around the edges in places and the first map of the author... then it does a lot of things you don't expect, I absolutely love a FM with surprises! There was just one thing that left me confused once I finished... I know that most likely this was all left open ended on purpose for us to speculate, thus I'm not expecting an answer but if there are probable ones let me know. Other than that... One other thing I wasn't sure about at first but ended up loving...
  19. You must have not played my first (and somehow still last) released FM, on which I spent most of my time making the FPS somewhat acceptable in the outdoor area
  20. Another marvelous FM, I enjoyed every bit of it! Very pleasant city design to explore around, intriguing and interactive story, everything else one would expect. Eager for part two and what else you plan on making
  21. Not that I'm aware of, but try the team spawnarg on the trigger_hurt just in case.
  22. I had a curiosity: Is it possible to define an item that is picked up and used by nearby AI occasionally, without necessarily having to link a path node to it or target it from the AI? For example a wine bottle on a table: The AI picks it up drinks from it and puts it down, while patrolling next to it then resuming their patrol after using it (playing an animation). Looking at the AI prefabs, an AI need to target things such as food items with the "pickup_bottle_pickup" or "eating_apple" spawnargs. Is there a way that's proximity based and doesn't require that?
  23. Interesting, didn't think about that. Yeah the compass uses that trick, I could just use a model of the helmet instead. If it looks good and is worth maybe I'll consider that, though it might be distracting and not make enough sense. The heads are modeled that way: Hoods and helmets are part of the head mesh as they aren't attachments. This is normally a good thing since performance isn't wasted rendering the head or hair under the helmet, but complicates things for my approach as the only way is changing the head models at runtime which may break precaching and stuff. Only a few hats are attached as a separate entities, like the little red hat some merchants wear or the straw hat... those aren't ideal for disguises though and I don't plan on supporting both approaches. Technically I could try attaching the independent helmet model to the player head, but that would surely look awful and clip through the hood and stuff... only right way is to give the player the Citywatch head once that error is fixed. For AI there is no other way apart from also changing the head model: Stealing the helmet from a guard implies taking it off them, which means they need to switch to a helmetless head which can only be done by setting a different head mesh upon frobbing... no idea if that triggers the same crash as the player head, if so I'm out of luck till a dev can take a look at my report. The base disguise system can be used that way too, it's just not the theme I went for by default as I wanted them to be physical wearables. You can define a magical disguise too that implies creating an illusion which tricks other AI into seeing you as one of them. In fact I thought of including one for undead using a magic skull that makes them think you're also dead, might add that in the next version if others think it makes sense and is worth it? Note that the spawnargs are documented via editor vars in case anyone wants to make their own: As long as you have a moveable model and inventory icon it's just a few tweaks to define any disguise. Simply inherit from the base "atdm:playertools_disguise" entity def and customize the team and other spawnargs... remember to use the proper mass / friction / impact sounds. Let me throw them here for anyone who wants a quick preview: atdm:playertools_disguise { "inherit" "atdm:playertool" "editor_usage" "Don't use. This is the base class for disguise inventory items." "editor_usage1" "Individual hats and helmets will derive from this." "scriptobject" "playertools_disguise" "gui" "guis/tdm_hud_disguise.gui" //"model" // to be defined in subclass //"clipmodel" // to be defined in subclass "inv_name" "Disguise" "inv_category" "Disguises" "inv_icon" "" "inv_droppable" "1" "inv_map_start" "0" // Disguise "team" "0" "rank" "0" "personGender" "PERSONGENDER_MALE" "personType" "PERSONTYPE_THIEF" "regen" "0.25" "rate" "0.5" "rate_alert" "0.1" "distance" "500" "speed_move" "1" "speed_turn" "1" "overlay" "" "snd_wear" "player_rustle_short" "snd_remove" "player_rustle_short" "model_head" "head_thief" "skin_head" "" // Disguise editor vars "editor_float team" "The team the player disguises into when the disguise is active." "editor_float rank" "Rank while the disguise is active." "editor_var personGender" "Person type while the disguise is active." "editor_var personType" "Person gender while the disguise is active." "editor_float regen" "The disguise regenerates over time at this rate." "editor_float rate" "The disguise degrades at this rate when the player is seen by a member or ally of the team." "editor_float rate_alert" "The disguise further degrades by this amount when an AI is alert, increases gradually with alert level." "editor_float distance" "Maximum distance at which being seen by the AI can degrade your disguise, offsets with AI visual acuity." "editor_float speed_move" "Movement hindrance while wearing the disguise." "editor_float speed_turn" "Turning hindrance while wearing the disguise." "editor_var overlay" "Overlay image while wearing the disguise." "editor_snd snd_wear" "Sound to play when putting on the disguise." "editor_snd snd_remove" "Sound to play when taking off the disguise." "editor_model model_head" "The player's head changes to this model while the item is worn, can be seen in mirrors." "editor_skin skin_head" "The player's head changes to this skin while the item is worn." }
  24. Biggest problem is a full outfit would require changing the player's body model including the 1st person hands, and I'm having trouble getting even the head to change for mirrors so likely never happening. Unless massive changes are done in the engine to make it possible... meaning never happening The disguise changes the player's team, so all AI on any team will treat you as the team you're disguised as... however only AI on that team or allies of it can make your disguise wear out and risk exposing you. Currently the only risk is AI is seeing you, the bar dropping faster the closer you get to them... that's gradually accelerated by the AI alert level, being seen by an alert AI can immediately break disguises: Technically I could add drawing a weapon or picking locks or stealing, but I'm not sure if the extra complexity is worth it. When putting the disguise on or after being exposed, you do need to wait for the bar to charge back up... if an AI isn't seeing you this takes about 5 seconds on the default helmets. As for the suspicion meter it's universal, making it per-AI would be confusing as the bar needs to switch to represent the closest one... it also didn't make sense because the player's team is universally modified so you can't trick one AI while being known to another, that would require doing it a different way. BTW: Don't be afraid to check out the script if anyone wants... it's surprisingly small, only 148 lines of code were needed! What I'm doing is actually pretty simple, it's mainly the AI sight that's crammed into a longer if statement. Also I commented the important parts to explain what they do. If anyone's curious you can check it out here: https://pastebin.com/7rU6DAAc
  25. Yes: It could then be distributed as a mod that works universally. I may propose it for the modpack! I already did a brief test and it worked: I managed to give the player a guard head while the guard helmet was being worn! But soon after TDM would crash to the main menu, and after a few tweaks to the script even that stopped working and there's only the crash now. Likely some obscure internal issue that can be hopefully tackled in the engine. Thank you, that I shall! And the biggest issue with getting mods to work is the need for a tdm_custom_scripts.script which has been the biggest thorn in the backs of modders: I'd say either execute all scripts automatically the way all files are loaded, or if that's unsafe just allow a script carrying the name of the pk4 to be auto-executed.
×
×
  • Create New...