Jump to content
The Dark Mod Forums

Tels

Member
  • Content Count

    14982
  • Joined

  • Last visited

  • Days Won

    21

Tels last won the day on August 15 2014

Tels had the most liked content!

Community Reputation

266 Legendary

About Tels

  • Rank
    Mod hero
  • Birthday January 1

Contact Methods

  • Website URL
    http://bloodgate.com/
  • ICQ
    0

Profile Information

  • Gender
    Male
  • Location
    Antarctica
  • Interests
    Coffee, chocolate, and cookies.

Recent Profile Visitors

11610 profile views
  1. Tels

    Batch FM downloads?

    You can also download the FMs outside TDM from my mirror: http://swift-mazes.com/fms/
  2. @grayman: The entity does work - it is the trigger_multiple that does not work - it doesn't call the script function repeatedly as it should.
  3. If you are refering to "def_attach5", the 5 in this is just an arbitrary number, and not related to the attach position. The wiki also says to not use 1..5, but start with 6, so it contradicts itself there. The position where to attach is defined with "pos_attachX" where X is the same number as used in "def_attachX", f.i. "6".
  4. No, this is a bit of missing on DR. The spawnargs are actually only the ones the entity inherits, but wether the code really supports this spawnarg (and wether it reads it once when loading the map, or everytime the spawnarg is used) is not encoded and thus DR cannot show it to you. The list, however, weeds out a few spawnargs that definitely are not supported on that entity so it's a first step.
  5. The "effect" you mention is toggling (which can be solved with two scripts) or "see emitter even when not in zone"? That would need a more complicated setup, which is indeed cumbersome. And yes, the manual listing of entities in the script is very error prone. Anyway, I think it would still make sense to add support for "max_view_distance" spawnarg on emitters - then they could toggle themselves off with little resources. There is still the problem that a lot of emitters could be near the player, but not visible (think "one floor above the player"), or they could be far away, but need still to be visible (otherwise there is popping when the emitter comes into the distance). So its probably not safe to set default values, but instead use "-1" as "inifite view distance". In any event, are we sure that turning off emitters actually improve performance in a visible way? Edit: Oh, yeah it was for emitters that should not be visibe from outside - in that case a distance base check would not work, anyway (outside/inside of house is the same distance, but in one case the emitter is behind the wall and should be off). So, yeah, I guess location zones + scripts to toggle the emitters is the one method which must be used here. Still, I could provide a script that toggles all emitters in a certain zone - that way you would not have to list all the emitters in the script manually.
  6. Interestingly enough, I always liked to have to pick up candles to snub them out - that makes it more a challange and adds a bit of suspension. My fear is the game will get way to easy if you can do anything with a simple click of a button and no longer need to have a "skill" in manipulation objects in 3D space.
  7. Springheel, the solutions posted above use only one function, that calls "trigger" on the entities. Which means, they are toggled. You could also use two different functions, and one calls $entity.On(); while the other one calls: $entity.Off(); It would be even safer if you have a function that runs through all emitters, and only disabled the ones in the old_zone, and enables all in the current zone. Then you would not need to adjust the scripts everytime you add/delete or rename an entity. (The last one is a potential source of errors!)
  8. No need to make it this compliated, running a script function when the player leaves/exits a zone is much safer - it even works with noclip Edit: Although I like your idea of distance-based emitters, this should really be built into emitters and turned into a C++-supported spawnarg. Running a script function on each emittier will use a lot of resources if you have lots of emitters, plus it adds quite some memory overhead for the script objects that need to be bound to each emitter.
  9. Looking to this thread, wow, that sounds er looks all nice. Seems 2.04 will get a boost in quality, love especially the idea of higher resolutions - some of our original textures have become quite outdated in that department over the years due to progressing of technology. Can't wait to play some old missions with these new shiny textures!
  10. Yes, definitely. The location system supports running a script when the player enters one location, and one when he leaves the location -no matter how the player actually enters or leaves the location. Use one or two of these on the info_location separator entity: "editor_var call_on_exit" "Name of global script function to be called when the player exits this zone." "editor_var call_on_entry" "Name of global script function to be called when the player enters this zone." "editor_var call_once_on_exit" "Name of global script function to be called exactly once when the player exits this zone." "editor_var call_once_on_entry" "Name of global script function to be called exactly once when the player enters this zone." Inside the script you can do whatever you want, activate triggers, dim lights or teleport entities etc. If you need help with that, I'm happy to provide script snippets.
  11. Today 9V cells are actually a rectangular housing containing 6 x 1.5 volt round cells - so not only does it waste a lot of space, it often basically amounts to a stack Li-On cell, anyway Capitalism gets you the cheapest product that passes as the one you'd actually wanted instead...
  12. I've tried to detangle the thread and what I gather is the entities (already existing) will be used and the new script object (with the "use less entities") will not be added. So there is nothing for me to do, right? The only thing that would need to be looked at is the "why does the multiple trigger in my testmap fire only once". Is this a mistake in my testmap? Or a bug? Grayman, could you have a look please?
  13. In case you don't own the originals, GoG is your friend: https://www.gog.com/game/descent_1_descent_2
  14. Exactly. The different sliders are different for "It was a dark and stormy night in copperlane district" (important info by narratori: we are in copperlane district) and "I'm afraid of heights" (unimportant info spoken by the player to himself).
  15. I don't think soundshaders make it possible to tell which voice they appear on, but I might be wrong. On the other hand, the already existing solution (atdm:voice) and the new one (atdm:trigger_speak) already work... The difference is in importance for the map/story/gameplay. Player grunts or witty comments are entirely optional, narrator voices might contain important story bits they player does not want to miss. Plus they play on different sound channels, which might make a difference in some sound settings (multiple speakers f.i.). And if there are two sliders, not having to spawnargs to make use of them would be a bit silly.
×
×
  • Create New...