 |
Just for completeness, let's also make mention of communication stims here; currently they are based on radius, not soundprop, as with the example above of a water arrow's water stim going through a wall to reach a torch. If the fix for these cases turns out not to be the same (perhaps occlusion for the water stim and soundprop for the communication stim?), we should split these into separate issues. However, it is assumed the solution is not known at this time. |
 |
To add to this, a water stim falling through a floor puts out flames on the floor below where it hits. Think of two fireplaces on two floors of a house, one over the other, connected to the same chimney flue. Douse the upper one and the falling water stim lives long enough to fall through the floor and douse the lower one. |
 |
@grayman, The simplest solution I can see, is to add a simple bool value(ie, bool TaskCompleted) to the base class that indicates whether a stim has done it's job or not. It could then be set on a per stim basis, so, once it extinguishes one flame, it could be disabled, to keep that from happening. (There may already be a mechanism that could be used to disable a stim, the bool was just to illustrate the point.) Not the most ideal solution, but, it could at least prevent the bug you mentioned until something better can be implemented. Anyways, just throwing it out there, feel free to ignore it. |
 |
I don't think it is as easy as a "let the stim only work once". Actually for water stims, we do want them to work on two flames if it hits these at the same time. What we don't want to have is it to work on things on the other side of the wall or another floor. Me thinks we need bool that decides wether the stim works across "areas" or not (an area here being a room being zoned of with visportals). Then we could f.i. set that bool to false on water stims, meaning a water arrow douses a torch in one area (and then stores the area num) and then ignores and receivers in other areas. (This check needs to be implemented in the receiver, I think). This way a water arrow can be shot through a door, but not douse a torch through the wall or across floors. Mappers need to portal of these ares so it properly works (f.i. not adding a visportal to a doorway would make both sides of the wall part of the same area, so the water arrow still fails), but adding these visportals is good praxis and should be done, anyway. Edit: Forgot to mention: the complexity here is that the stim area needs to be checked against the receiver area, where the stim stores the area it starts of (because it can move and expand into other areas later) and each receiver checks its own area against that area IF the stim is an "source area only" stim. |
|
|
You still have to solve the visual issues as well. (Disable particles that cross the "area" boundaries?) Gas arrows and glass surfaces are a prime example of the need to solve that problem. As for my original post, actually, that's generally what developers do, cheat, they rarely realistically solve problems, it only has to look proper, the "sky dome\box" is a good example of developers cheating. (Anyways, I was suggesting it more as "hack" until a proper solution could be implemented.) |
|
|
The visual issue is not as important. Plus much harder to solve, because the visual particle is completely sep. from the invisible stim/response, and there is actually no way to influence the particle generation/rendering unless we start to hack at this subsystem, too. (The particle system has other problems, too, esp. releated to areas and portals etc. But lets ignore that for now) Gas arrows would also be exempt from that fix, because a gas arrow near a open visportal should gas a guard on the other side of portal. Might be an exception for close portals (if there is a door and the door is closed, the gas should/should not leak through). And of course, if there is f.i. a trapdoor in the floor with a visportal in it, shooting an arrow at the side wall and the water falling down *should* douse a torch down there. The more I think about it the more complicated it sounds. We might first to draw up a list of all potential cases with the current and expected outcome and then we might think what we need to change. So instead of maybe an area-check we just need a visual check - is the first starting point of the stim (or the current?) visible from the current working point of the response? If no, there is something solid in between, so ignore it. But this also could break valid use cases (a metal grate should not stop a gas arrow or a water arrow, but a glaspane or a solid wall should, but the grate could fall the visible check due to a tiny metal bar being in the way). |
|
|
I agree, this requires careful planning, there are far too many special cases to contend with. Make a virtual method that can be implemented per stim, that way custom behavior can be mapped out, and have a bunch of switch cases handling each scenario? Maybe raycasting could help determine the path for water? I don't know, I'll have to think about it. :( --- Adding collision boxes to particles is another possibility, but, it comes with a long list of problems too. This definitely isn't a trivial issue. --- I think you're right, just map out each case, and then create individual solutions per scenario, I can't envision a "one size fits all" solution to this problem, each one is going to have to be tailor made. |
|
|
raycasting: The engine has a methods called "tracepoint" etc these take a point, or a box etc and "trace" it along a path and stop at the first hit against certain materials (like monster_clip, solid etc.) That way you can determine if there is something in the way. If we just want the stim to act when there is a line of sight, I think a boolean per stim, and a method to query wether this is false (if boolean is false, or boolean is true but have line of sight) or true (boolean is true and have NO line of sight) would be the most simplest way. Then each response would call this method and ignore the stim if the return is true. Anyway, maybe you want to pick an easier item as your first assignment? ;) |
|
|
I forgot to mention that a single traceline from point to point hitting a solid and thus giving a false positive occurs elsewhere, too. F.i. checks if the AI can see something, or the player is visible etc all suffer from the same problem. Usually this is/was solved by making multiple traces (spread out over multiple frames because traces are extensive) and then seeing if any of them hits. Sometimes even selecting multiple points (from both eyes of AI to shoulders/feet/eyes of player) just to minimize the chance that a stray item blocks the trace and thus the engine thinks there is some thing in the way. Stim/response could select a random point inside the stim source and a point randomly spread out X units around the response and do multiple traces every time the response would fire and only ignore the stim if all of them are blocked. Anyway, we probably should discuss such things on the forum, there is an awful lot about the engine you can't know yet and the bug tracker isn't really the best method for learning this. |
|
|
I was just trying to help get the thought process going, but, if I'm distracting you, I'll leave you to it. |
|
|
This is fixed for gas stims. (0001104) I will need to address falling water stims, however. They can probably use a variant of the gas stim solution. |
- Anonymous
