Journal #8465

If there is some way of replicating logic gates using entities, then you could probably try and figure it out in Minecraft with Redstone, or rather ask someone on the Minecraft forums while pretending that you're going to make an adventure map.

I'm sure there is some way of replicating gates, I've just never gotten round to figuring out if there is.

I could imagine a logic_math (or whatever it is) could be used?

Perhaps the doors will set themselves as +1 on the counter whenever they're closed, and +0 when open? So that means that you can have the door be unlocked or enabled whenever the counter is set to +2.

I'm quite sure it can be done. Then again I know very little about source mapping and I have entity problems of my own. I'd totally try this as soon as I have some time. I get the feeling it's a relatively easy problem.

If triggers can be activated by func_doors, maybe you could use the doors themselves as switches?

The door positions(A open, B closed) would activate trigger multiples, which could open thin, invisible forcefields walls in front of door C? You could use func_doors, func_wall_toggles, etc.

If this was for Source, it'd be VERY easy to accomplish what you need with the input/output system, but again, I'm not sure exatly how offhand

I guess I should have mentioned this was a goldsource problem =P

Soon as i noticed "multisources", i knew it was GS ;P

I don't know much (anything) about triggers/targets in GS, but going by the limited information in the entity guides...

Multisource acts as an AND gate, but I don't know if a door evaluates to 1 when open and 0 when closed. If it does, you might be able to toggle a hidden toggle button to invert the value of door B, and then use a multisource as the master of door C. You could set door C to toggle the enabled status of doors A and B, which would disable them when C opens and re-enable them when it closes. As CapT said, if you can't toggle enabled/disabled status, you might be able to use a clip brush instead.

In Source it would be super easy

I kinda just assumed that if people saw ME talking about mapping, they'd know it was gldsrc ;P

Looked at the entity guides myself, l think I've got how do it. Will let y'all know.

Entity minicompo reboot #1: [i]Three doors[/i]
Hosted By Jessie

I don't think we're quite that desperate yet ;P

I miss the entity compos ;PP

func_doors have 2 fields that fire triggers
1) trigger: activates the target when opened or closed
2) fire on close: activates the target when closed only

So you can probably use the target field to trigger an event, but use the 'fire on close' field to reset a trigger relay to a wanted state.

Door A: Trigger: Trigger Relay > ON > Door_C_Multisource
Door A: Fire on Close: Trigger Relay > OFF > Door_C_Multisource

Door B: Trigger: Trigger Relay > OFF > Door_C_Multisource
Door B: Fire on Close: Trigger Relay > ON > Door_C_Multisource

Door C: Trigger: Trigger Relay > OFF > Multimanager > Doors A+B multisource
Door C: Fire on Close: Trigger Relay > ON > Multimanager > Doors A+B Multisource

So by my best guess without actually trying it, here's what's going on:
Door A, when opened, is enabling 1/2 of door c's multisource.
Door A, when closed, is disabling door c's multisource.
Door B, when opened, is disabling door c's multisource.
Door B, when closed, is enabling the other half of door c's multisource

You'll need a trigger_auto in there to set your initial values. For example: doors A and B both have masters which you would need to enable by default.. there's probably more but i can't test ATM.

Once door C opens, it targets a multimanager that will fire 'off' state relays to disable door a and door b masters.

Once door C closes, it does the opposite.

Seeing as how the 'target' field fires in both open and close states, fire that first (delay of 0). I would put a 0.5s delay onto the "Fire on close" field so that will override any triggering done by the target field.

Let me know if it works

^ Impressive explantion Tet, I want to try this now!

Haven't mapped for quite some time but this journal made me think about a thing:

Is there any "NOT" gate in GoldSource? Because if yes, you could build a NAND. And NAND gates are a basis for everything.

So my general idea will not work. I've been trying different variations over the last hour and my main hurdle is this: Two trigger relays cannot target a multisource.

It seems multisource is reading active states from the things that trigger it. Instead of activating or deactivating itself. (if that makes sense)
So if you have two trigger_relays targeting a multisource, one with an ON state and one with an OFF state, it will never fire because the relay with the OFF state will always negate the multisource.

The plot thickens....

---

EDIT!

I figured it out. It's actually much simpler.
I'll upload an example map and a write-up on the logic

All in all, i'm using a trigger_relay inbetween the door and the master that acts like a not.
So when the map loads, it triggers the 'inverter' relay to be normally 1.
When you open a door, it toggles that relay so it's now in a zero state.
So door A triggers door c's master normally, but there's an inverter relay between door b and door c's master.

SOLUTION

Well done, you are the HL entity MASTER!

Since func_doors WILL NOT activate trigger_multiple, func_button, NOR func_breakables for my backward solution, I'm gonna try using Stojke's method of employing env_beam and a shootable button to detect the position of the doors.

So much fun.. =P

ALL HAIL TETSUO.

Haha thanks Capt and Stu
PB is right in his speculation. Func_doors evaluate to a 1 when open and a 0 when closed. At least when they're triggering multisources.
All we needed was a way to invert the door values. Put a trigger relay in the way that's initialized to 1 and BAM. 1 becomes 0