Jump to content
The Dark Mod Forums

Obsttorte

Active Developer
  • Content Count

    5894
  • Joined

  • Last visited

  • Days Won

    93

Obsttorte last won the day on November 15 2018

Obsttorte had the most liked content!

Community Reputation

1487 Deity

6 Followers

About Obsttorte

  • Rank
    Scripting guru, Mapper

Profile Information

  • Gender
    Male

Recent Profile Visitors

2786 profile views
  1. The function expects the entity as argument. Entities are referenced via $ in combination with their name. So if the entity is called atdm_key_simple_iron_dark_1 the reference is $atdm_key_simple_iron_dark_1 (so the name with a $ in front). Don't use "", those are for strings.
  2. Yes. You have to extent the ai's base script. I think Springheel already utilized this as an aberation of my trigger_look script. Probably for "A New Job".
  3. Patches are intented for round surfaces, so edges shared by two tris of the same patch will always have the same Vertex normal and therefore look smooth and round. If you want something edgy-looking, use Brushes.
  4. @MirceaKitsuneLike @Dragofersaid. If lights can have models (can't remember right now as it has been a while) and you use the particle as model, you may even be able to skip the "set _color on flame" part (note that there is a space after set).
  5. You can make the particles use the light color. This way you wouldn't need to have specific entities for each color. Btw.: You may want to start a mapping thread to bundle your ideas instead of creating a new one for everything?!
  6. @wesp5: The general opinion back in the day was that for many players searching the inventory for the correct key was part of the immersion and automizing this process is no good idea, so it will not make it to the core mod unless those opinions have changed. In regards to the files: The video is 6 1/2 years old, I haven't found anything in my mapping thread or the newbie thread. I'll see whether I can find it on my harddrive, but can't promise anything.
  7. That's possible. The only issue is the lack of a proper animation and bark for the ai. You could use the "blinded" animation and letting the ai say "ugh", but it may appear a bit silly. Seems to be doable.
  8. In regards to how implement custom arrows: It's old and lengthy but may still be useful. Regarding the useful/lessness of flash bombs and mines: I don't think that those items are useless per se, but that those, similar to many other items the player has at his disposal, aren't as useful as they could be due to the way most missions are designed. Almost all of them are ghostable, or relatively close to that. There is rarely a situation, where using an item really gives you an advantage, especially for advanced players who are familiar with stealth games. Flash arrows, emp a
  9. As mappers have to add it on purpose and existing maps as well as future map design aren't affected, as you correctly point out, I don't see a reason for you to not create it and upload the requiered files here. Mappers can than choose on whether they want to use it or not. My experience is, though, that it will most likely be forgotten. So it probably makes more sense to either implement it in an own mission or, if you ain't going to do this, simple do nothing until someday someone may stepup to you and say: "Hey Mircy, didn't you had that proposal with the emp back in the day, would be cool
  10. @Strunk: The script looks ok so far. However, having to let the poltergeist entities to target each moveable that should be moved by it seems like a tiresome procedure. How long did it take you, as there are over houndret of entities in question? It would also be a good idea to specify the editor appearence in the def [code] "editor_color" "0 .5 .8" "editor_mins" "-8 -8 -8" "editor_maxs" "8 8 8" [/code] Ths way you can see and select the entity in the editor. Change the color so you can differentiate it fro
  11. You can change the name via the function setName(string newName). getName() returns the name of the entity. So if the trigger entity is the spawning entity the code would look like this [code] entity myEntity = sys.spawn(entityToSpawn); //pass the proper entity def as argument myEntity.setName(getName()); [/code] If the trigger is not the spawning entity but only initiates the spawn (via a global script call or a custom entity) you have to pass the trigger entity (or at least its name) to the function where the spawn is handled.
  12. As VanishedOne already pointed out I think the issue is that your response function "OnOff" does not have any arguments. My interpretation, as the script gets performed anyway, is that the script compiler considers the function to be of "global" scale (in a sense as independent as to what entity it is called on) and ignores the value of the member variable clicks. Note that this variable is defined for all entities of type poltergeist_script, but the compiler can't know that it also has the same value for all of those entities. I can't say, though, why the code behaves like that.
  13. Possible that duzenko changed some stuff, the way I described it was as it worked back in the day. I haven't looked at the code for a while, though. If I am not mistaken the skybox is something that was implemented for TDM and not part of the original Doom 3 code. If that is the case, then it was implemented when the team haven't had full access to the complete code, what may cause it to behave a bit different from what other engines do. Either way, the way it is described by AH is how it has worked in the past, and if this isn't the case anymore, it would definetely be a drawback.
  14. Muahaha!!! :D

    1. SeriousToni

      SeriousToni

      Oh nein - dein berühmtes Bild vom Maniac ist weg! 

    2. Obsttorte

      Obsttorte

      War mal Zeit für ne Veränderung ;)

      Das neue Bild ist aber aus der gleichen Serie und bezieht sich auf den selben Charakter.

      10559832.jpg.0fc20f4694249fa92b653c7aca36cb5d.jpg

  15. The skybox texture was pretty much handled like caulk in the past (pre-duzenko era ). On parts of the screen were a caulk or skybox material on worldspawn is closest to the player, it basically leaves a hole there. The difference is that if there was at least on surface with the skybox material on it in the current view, the skybox got rendered first and the current scene than on top of it, and where the holes were the player could see the skybox shine through. Another difference is that caulk does not effect the depth buffer, whereas the skybox material does. That's why it is useful to combi
×
×
  • Create New...