#if you create the door with lua just
1 messages · Page 1 of 1 (latest)
Could you give me a little more information about this?
I'm seeing two options for adding outputs:
- ENTITY:AddOutputFromAcceptInput
- This is, as far as I can tell, supposed to be called exclusively from within ENTITY:AcceptInput which, when I add it to
prop_door_rotating, does not appear to get called.
- This is, as far as I can tell, supposed to be called exclusively from within ENTITY:AcceptInput which, when I add it to
- ENTITY:AddOutputFromKeyValue
- As far as I can tell, this is intended to be called exclusively from within ENTITY:KeyValue. I tried hooking into GM:EntityKeyValue to check what keys/values are set on
prop_door_rotatingand from what I can tell there's nothing in there that would be helpful here
- As far as I can tell, this is intended to be called exclusively from within ENTITY:KeyValue. I tried hooking into GM:EntityKeyValue to check what keys/values are set on
What, if anything, am I missing here?
@quartz geyser, in case creating a thread doesn't ping you
Interesting
thats how the engine internally creates entities for the maps
it just creates the ent and sets all keyvalues, outputs are just keyvalues too
there are couple ways to add outputs
ent:Fire("AddOutput", "OnOpen portal,Open,,0,-1") would work too
the format is
Looks like comma-delimited arguments
named_ent,Action,parameter,delay,repeats
valve developer wiki has all the info about this
you can also see it in hammer if im not mistaken if you disable the advanced view
I've gotta be missing something here
door:Fire( "AddOutput", "OnFullyOpen " .. portalName .. ":Open::0:-1" )
I've tried it with : and with , as delimeters based on https://developer.valvesoftware.com/wiki/AddOutput
whats the issue?
Oh
This won't work
I don't know why I didn't see that before
These outputs only fire when the door opens/closes
I'm not opening the door, I'm moving it in the same way that it would normally move when opening, via MoveAngular, but without actually firing the Open input
Because the Open input does other things that I don't want to do in my use case
So, that AddOutput thing did work in terms of adding the output, but did not work in terms of actually solving my problem
what is the problem?
The issue is that area portals don't know that the prop_door_rotating is open because I'm not firing the Open input, so I need to manage the area portals for a given door myself
When the door finishes moving, it automatically calls the C++ function MoveDone, which changes depending on the door's current state
In some cases, that MoveDone function turns off the attached area portals, which is bad
I'm trying to find a way to keep the area portal open
that sounds all very hacky to what you are doing
I wouldn't call it "hacky" per se
what is the point in bypassing the normal functionality of doors?
I'm adding "breaching" functionality to doors
In order for it to work properly, I need to be able to move the doors to angles other than their normal open/close angles
Doors don't support that, so I'm recreating the method doors use to move internally
why not recreate prop_door_rotating in lua then and keep the outputs working
sounds like you are almost there already
I'd like to do that at some point, but that's a larger scope than I have right now
you are kinda breaking maps with this
My goal here is to not do that
yeah but in order to not do that is to do what valve intended
What aspect of this breaks maps?
you are not firing any outputs
Not currently, but it's not done yet
you cant really force an entity to fire outputs, at least not as long its not implemented in lua
well I suppose you could capture all the registered outputs and do it manually
The door doesn't necessarily need to be the one to actually fire the output, it just needs to be blamed for firing the outputs
It also doesn't need to be perfect, it just needs to work in the majority of cases where someone might want it
But area portals breaking is a pretty big case
i mean this sounds rather simple to do, at some point you are forcing it open so just lookup the linked portal entity and open it
so where is the problem at 😄
if those doors no longer work remove the area portal from the door
One moment, let me grab that
SetMoveDone is the issue
It's a pointer to a function that will be called when the door arrives at the angles it's moving to
That gets set all over the class depending on what state the door is in
I have no control over it
I cannot suppress it
I also cannot detect it
So when the door moves, something will happen to it
One of the things that it can do is to tell its attached area portals that they should turn off
Which leads to the issue you can see in that video above where the area portal opens, then closes as soon as the door finishes moving
In this case the door is just moving slightly in-place to show that it's broken
I can do something like this, but there's always going to be a delay of some kind between the door finishing its movement and the timer firing, which leads to an unpleasant flicker
OpenAreaPortals( door )
timer.Simple( moveDuration + 1, function()
if not IsValid( door ) then return end
OpenAreaPortals( door )
end )
If I don't add to the moveDuration, it doesn't work. Presumably because the function call happens before the MoveDone function does