Jump to content
The Dark Mod Forums

Leaderboard

Popular Content

Showing content with the highest reputation on 10/11/19 in all areas

  1. Yes No. All GL2 systems will need to stay on 2.07.
    1 point
  2. So after 2.07 the engine will REQUIRE OpenGL 3.x GPU to run? Will my Geforce 7900GTX (DX9, OpenGL 2.1) run it at all? Or there will be a CTD saying my hardware is incompatible?
    1 point
  3. It just occurred to me: did your test map use delta1_fog by any chance? It has alpha explicitly set to 0.5 (values of 1 or less are treated as an instruction to use a 'default' fog distance of 500 units), which might explain why the shaderparm wasn't working.
    1 point
  4. In case of the grill lamp, it is actually a light entity with a model, not a model with a def_attached light. It also has a colorme skin by default. Hence, my assumption that it has to be rerendered. Here is a snippet from the "Attach Props to AI" Wiki page, which def_attaches a key to a guard an then changes some properties: "def_attach6" "atdm:prop_silverkey" "pos_attach6" "belt_back_right" "name_attach6" "gate_key" "set inv_name on gate_key" "gate key" "set name on gate_key" "gate_key" This should also work for other def_attached entities.
    1 point
  5. @STRUNK the tile trap's mechanism is that the tile starts the map slightly above the ground with its physics disabled (nodrop is set to 1). As soon as anything touches the tile, its physics get enabled and it drops to the ground, where it comes close enough to an invisible entity to trigger a stim/response effect. Setting the colour on a lamp model should only affect the model, but not any lights that have been attached to it via def_attach. The model should only be affected if it has a colorme texture on it (recolourable), though IIRC the only actually working way to change the colour of a model is to use a colorFade script command (see Down by the Riverside for examples). Btw, I've always wondered how to target a def_attached entity in this game - anyone know the syntax for this? For the fire arrow effect you described you'd have to add a response to fire stims on the target that gets hit by the arrow, with an effect to turn the light off.
    1 point
  6. For the spawnarg I am not sure what the application was. I am sure I had one some time ago, but I cannot remember what it was ? The door scenario sounds like the door somehow got further frob stims right after the response. Did you also define a stim with frob besides the response frob? This would cause the door to emit a frob stim itself and consequently activate itself. This is the only thing that I could think of from the top of my head. Making stuff unfrobable is very handy for anything that you want to be triggered once and prevent the player from frobbing again. It may also work on the door, if it gets multiple frob stims: As the first response, make it unfrobable, in the second line, do what you want, and in the third line make it frobable again. Not sure what you meant by "reversed one", but it could be that there is troble with the origin. I am pretty sure the new model uses the same values for the origin, so if the new door has its origin on the right, while the first one had it on the left, the new door would appear in the wall, which would be why you cannot see it. you could test this by putting the door not inside a frame, but somewhere in the middle of a room. When you want to use the same model with a different skin, it would be better to use the Set Skin response. That's what it is there for. The grill light should be a light source that simply has a model defined, which lights you add with "Create Light..." do not. If the colour of the light changes, but not the colour of the model, I presume that the material of the light would have to be updated. I am not sure how often stuff like colour is checked, but I presume it is each time the model gets rendered, so apart from changing colour you would have TDM to update the material render. I think there is a console command, that lets you reload materials, but I could not find it right away. You could try to give the light the response Set Skin and use the skin it already has. This might cause TDM to reload the skin it has and update the colour, but I am not sure if this works. Regarding the traps, I will have to take a look at the video again; maybe I will get to it this weekend. For your last question, it should work by giving the entity that you want to be shot to turn off the light the response type "fire" (you can select it from the dropdown menu) and the response effect "Turn (extinguishable) Light Off" with the "Target Light" being the light you want to turn off. Now, as soon as anything with a fire stim (which fire arrows have, but as written before the slow match or candles, as well) gets near the entity with the response, the light should be turned off. The same works for the response type water and water arrows etc. You always have two pairs: one entity that gives you a response to a stim and an entity that emits the stim. With frob the player emits the frob stim, when you hit the frob key. For others you need to find an entity that emits the respective stim. A side note here: entities other than AI and the player do not receive damage. Thus, it is not possible to give a random entity the damage response and create an effect, when it is hit with the sword or an arrow. This is something I spent some time in trying to get it to work, until I was told that it is not possible.
    1 point
  7. Set spawnarg has the problem that it sets a spawnarg, i.e. an argument that is set, when the entity is spawned. After spawning this does not do anything anymore (with very few exceptions). In order to work better, you would need set keyVal (this is possible via script), but even that does not work for everything. Frob acting weird on doors may be, because doors use a frob action script on their own. It may be that there is some interference there (though I am not sure why; some people with more knowledge about the code would have to chime in here). For this to work better you could try to target a trigger with the door and let the trigger trigger a response. At least, I think that a trigger entity gets activated, when it is targeted by a door. For set model, I am not sure why it does not work for you. I am currently using it in my WIP and it works fine. Maybe you have the path of the model wrong, so it uses a nodraw model instead? In my case, I am replacing a filled quiver with an empty one and the path for the new model is "models/darkmod/wearables/quiver.lwo". Note that you have to include the whole "models/darkmod/[subfolders]" part, when you choose the model. I am not sure what the problem with the grill light is. Maybe you could elaborate, what you want to achieve and which response and response effects you have used. So to summarize, at least most (don't want to say all, because I don't know for sure) of the response effects work, but many have some restrictions that are not that evident or need a specific format in which the arguments have to be set (like the model case). As said before, with scripts you can do a lot more, but these are also harder to grasp.
    1 point
  8. One thing that took me a while to understand was that you only need to define a response in 90% of cases. The stim is the info the entity needs to activate the response. I.e. if you frob something, the player emits a frob stim and the frob response on the entity is activated. If you want an entity to react to fire, you need a fire response etc. The stim part is only needed if you want an entity to emit a stim. E.g. the short match (player tool) emits a fire stim at its glowing end, so anything that has a response to a fire stim will react to it, when the slow match gets close. Another example would be a damage stim on an entity. This will damage anything in a certain radius around the entity. That way you can create stuff like toxic fumes etc. The S/R system is quite versatile. Not quite as powerful as scripting (as it is restrivted to certain effects), but more user friendly. Yet, it may help if you think of it as a little script: The stim is the requirement "if Stim happens" and the effect is ... well ... the effect "do stuff". The downside is that you only have the stim as a requirement and cannot define more like "if Stim happens AND light is green, set light colour to red". If you want to do that you would need a script or a more complex setup like VanishedOne suggested.
    1 point
  9. In the simplest case: frobbing already is a stim, so give the switch a response to STIM_FROB (that is, the Frob stim type). The catch here is that S/R alone doesn't give you a way to do one thing when a switch is frobbed 'on' and another when it's frobbed 'off'. The dining room in ITB has switches that fade the lights but I just used two switches.
    1 point
  10. unity now has 3 engine versions, one free and two you pay a subscription for, but it now seems the different versions are based on what support you get from unity rather than there actually being a difference in the engine features.
    1 point
  11. This is something I used for a custom AI script in an early alternate version of Down by the Riverside (Tales of the Riverside), which you can find [url=http://forums.thedarkmod.com/index.php?/topic/18402-fan-mission-down-by-the-riverside-by-dragofer-20160925/&do=findComment&comment=407828]here[/url]. The script is able to make an AI stop patrolling upon reaching its next path node. If you want the AI to stop immediately it would involve teleporting the path_corner to an inaccessible location, as I recall it. (I was aware of the StopMove event but in my experience it only caused the AI to twitch while carrying on with its patrol. Might be good for a free-roaming AI like a zombie though?)
    1 point
×
×
  • Create New...