schleicher on 2/11/2015 at 00:48
ouch ! Thank you guys, for explaining that. I was totally on the wrong track ;-)
Now I understand, why I needed the inverter.
The problem is solved; without any inverter and without any black frame ;-)
ZylonBane on 2/11/2015 at 08:14
Quote Posted by LarryG
As to the black rectangle you are seeing, that's a special feature of doors which keeps AIs from seeing through them.
Quote Posted by john9818a
The black frame actually goes through the entire door and prevents the AI from being able to see through the door when it is closed.
Holy flawed mental models, Batman. The above is like saying that moonlight makes it dark outside.
How it
actually works is that doors have a property, Blocks Vision, that the engine uses for two different things. First, AIs use this property when doing visibility checks to see if it blocks their line of sight when closed. Second, the renderer uses this property to determine whether it needs to draw what's on the other side of the door when it's closed. That's what the black plane is that you see when a door isn't set up correctly. It's a disabled visibility portal.
Obviously AIs can't "see" the vis blocking plane like players can. That's just silly.
john9818a on 2/11/2015 at 12:38
Quote Posted by ZylonBane
Holy flawed mental models, Batman. The above is like saying that moonlight makes it dark outside.
How it
actually works is that doors have a property, Blocks Vision, that the engine uses for two different things. First, AIs use this property when doing visibility checks to see if it blocks their line of sight when closed. Second, the renderer uses this property to determine whether it needs to draw what's on the other side of the door when it's closed. That's what the black plane is that you see when a door isn't set up correctly. It's a disabled visibility portal.
Obviously AIs can't "see" the vis blocking plane like players can. That's just silly.
Ok ZB :laff: I was going to mention the closing of the portal but it wasn't relevant to fixing the problem. Both Larry and I said "see through" not "see" ans obviously the AI can't "see" anything.
PinkDot on 2/11/2015 at 14:02
ZB - are you a computer programmer? The precision and disambiguation you require from a human language is of the same level as compilers and interpreters require from a programmer's code. Larry and John said everything what schleicher needed to know about the black rectangle to understand where does his issue with the door acting up comes from - just using a natural language.
schleicher on 2/11/2015 at 19:29
I am sure, in the near future AI's will see and feel and understand everything. AI is not a question of possibility, its just a question of time. So this discussion is sort of obsolete :-)
PinkDot on 2/11/2015 at 20:24
Quote:
I am sure, in the near future AI's will see and feel and understand everything. AI is not a question of possibility, its just a question of time.
I wish you meant this in the context of the Dark Engine's AI...
ZylonBane on 3/11/2015 at 00:08
Quote Posted by PinkDot
Larry and John said everything what schleicher needed to know about the black rectangle to understand where does his issue with the door acting up comes from - just using a natural language.
I used natural language too, and explained it correctly. If X causes Y, and X causes Z, telling someone that Y causes Z is not doing them any favors. All it does in the long run is seed confusion.
LarryG on 3/11/2015 at 00:31
Well, without access to the code, neither of use can talk definitively about how it actually works. It could work as you say, that the AI code looks at the flag on the door and branches accordingly, or it could be that the flag causes the special blocking rectangle to be created at the time of portalization and the Door code takes care of inserting/deleting/showing/noshowing it at runtime causing whatever is behind the door to be drawn/not drawn, and the AI vision code merely processes whatever is drawn at the time (unlikely). But my point is that there are literally hundreds of different possible implementations of the same observed game behaviour from which the developers chose the specific one they implemented. And do you know what? I don't care which one they chose. That's right, I don't care about the specifics of the software implementation. What I care about are the practicalities of the in-game behaviour. How the software accomplishes that behaviour is not of interest to me. I am interested in what it does, not how it does it. And the in-game behaviour is what I described. Whether or not the blocking rectangle actually keeps the AIs from seeing through the door, or the fact that the door has a flag set that tells the AI code not to see through the door doesn't matter. What matters is the fact that a visible blocking rectangle is created when the door is closed and it disappears when the door opens (does the flag get changed on opening? Who knows? Who cares?) and reappears when the door is closed. So you had better have the closed door properly positioned in its doorframe if you don't want to see that black rectangle. What matters is that all doors are created closed no matter how you position them and they will make the opening door sounds and closing door sounds irrespective of their position, but only with regard to their internally tracked open/closed state. That is what matters!
This isn't a situation where we can talk definitively about causality or correlation between these events. You are guessing. You may be right. But it doesn't matter.
PinkDot on 3/11/2015 at 11:26
@ZB - this thread was about A, B and C - Y came in as a side effect of issues with the former ones. Therefore it's not relevant whether X is causing Y and Z or Y is causing Z. Once the topic's author fixes A, B and C then X, Y and Z become irrelevant for his problem.
But anyway - my observation on your precise language and logic was of a general nature and could have happened in almost any other thread.
ZylonBane on 3/11/2015 at 14:26
You people sure are putting a lot of energy into defending sloppy reasoning. Irony ahoy.
