Commented 9 years ago2014-11-18 08:43:47 UTC
in vault item: Glass Doors TestingComment #20743
I'm not on my computer at the moment, so I can only guess what exactly the problem is from the comments, but it sounds like you have the window brush and the door brush at different widths. The way that the game engine figures out how far each door is supposed to travel is based on how wide the brush is. So for the window to line up with the door whether it's open or closed, you have to make the window entity the same width as the door entity. Since doing so by just making the brush wider could lead to ugly texture problems at the door edges, the way Captain Terror suggested is to extend the width with clip brushes, like in the picture.
The clip brushes should be tied to the same entity as the window brush, so in total you would still only have two door entities. This can be done by creating the clip brushes, selecting them and the glass, and clicking 'Tie to Entity'. This will open a little window saying that one of them is already tied to an entity, and do you want to just add the selection to it. Click yes, then it should work fine.
Commented 9 years ago2014-11-18 02:21:53 UTC
in journal: #8469Comment #61192
This year we're doing a 2.5D platformer loosely based on the world of Mary Norton's The Borrowers. By the time it's done it's supposed to have 5 enemy types appearing/reappearing in each level, a miniboss per level (neither of which was our decision - course requirements) and a climbing mechanic using player-placed thumbtacks. So far we have a graphics pipeline using modern OpenGL and the ability to move an object in 3D space with no collision or physics.
Commented 9 years ago2014-11-18 01:59:35 UTC
in journal: #8469Comment #61181
I wish I had the time to help you out with those tools! I know how hard it is for art people to work without tools. Major game engines have full suites of tools including material editors, scripting languages, and WYSIWYG map editors that allow for fast prototyping. Artists/designers can focus on making the game without direct programmer intervention for 80% of their needs. It really sucks to start from nothing in comparison! I had to write from-scratch tool stuff for my studio too.
Commented 9 years ago2014-11-17 18:42:41 UTC
in journal: #8465Comment #52803
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
Commented 9 years ago2014-11-17 18:29:03 UTC
in journal: #8467Comment #62644
If only I had $150. I'll still bear that in mind.
While we're at it, I've always wondered: WHAT does Cyanogen do, exactly? Because I pretty much only read "it's better" but I don't recall finding specific reasons for it. What does it do that I want?
Commented 9 years ago2014-11-17 13:23:46 UTC
in journal: #8468Comment #58461
Jamie and Adam from Mythbusters have a Youtube Channel called "Tested". There are some other guys on there who get together and talk about coming trends in technology and new gadgets. They also discuss "Making" - the art of crafting pretty much anything. They talk about anything from making movie prop knockoffs to cosplays to different tools they use and techniques. There's also some interesting 1-day builds that Adam does - those are my favorite.
It's an interesting channel to watch sometimes and they do mirror podcasts of their longer videos. They're usually between 20 minutes and 1 hour long.
And i feel your pain on the commute times. Though my original one was a short 15 minute drive, it's now double that and more stressful thanks to the idiots rushing to work in the mornings XD
Commented 9 years ago2014-11-17 01:09:34 UTC
in vault item: Glass Doors TestingComment #20739
Make them part of the window, i.e. select the CLIP(s) and func_door, Ctrl+t to attach them.
BTW use may want to use NULL instead of CLIP, else you may get a compile error; VHLT33 will allow you to use CLIP brushes as part of entities, ZHLT3.4 will not, so use CLIP with VHLT, and NODRAW with ZHLT
Commented 9 years ago2014-11-16 23:07:30 UTC
in vault item: Glass Doors TestingComment #20737
If what you were saying is the transparent glass window doesn't close at the same time as the other door, try attaching invisible clip brushes to the transparent door(so it's the same width as the actual door), and they will slide at exactly the same time.
If you're saiying you don't want that edge sticking out of the door jamb, try adding negative Lip, e.g., a value of -5.
Commented 9 years ago2014-11-16 23:06:11 UTC
in journal: #8467Comment #62642
If Android was instead an OS written in Assembly, I would probably be able to compute trajectories for satellites, control space ships, interpret telemeter data and possibly have a local AI that is sufficiently powerful to be able to run a small country - in 2 words, rocket science - on my S4.
But Android is a software developed by humans with the purpose of being useful and practical for as many people as possible.
Commented 9 years ago2014-11-16 22:44:17 UTC
in vault item: Glass Doors TestingComment #20735
I've always set up my glass doors with a trigger multiple and a multimanager, I think. I'mma have a look at this when I don't have an exam I have to get to.
Commented 9 years ago2014-11-16 21:44:21 UTC
in journal: #8467Comment #62639
^ I have definitely "mistreated" my phones before, they are pretty tough! Except for the screens cracking they seem almost indestructible, especially with any kind of case.
Commented 9 years ago2014-11-16 20:50:36 UTC
in vault item: 3 Door LogicComment #20734
Really, awesome work on this, it's something I would never have been able to figure out using relays/multisource. Thanks also for the nice explanation and diagram inclued with the download
Commented 9 years ago2014-11-16 20:40:15 UTC
in journal: #8465Comment #52815
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.
Commented 9 years ago2014-11-16 16:14:06 UTC
in journal: #8465Comment #52802
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.
Commented 9 years ago2014-11-14 16:51:35 UTC
in journal: #8465Comment #52801
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
This comment was made on an article that has been deleted.
Commented 9 years ago2014-11-13 00:12:50 UTC
in journal: #8465Comment #52804
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.
Commented 9 years ago2014-11-12 19:27:03 UTC
in journal: #8465Comment #52809
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
Commented 9 years ago2014-11-12 19:17:07 UTC
in journal: #8465Comment #52817
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.
Commented 9 years ago2014-11-12 15:37:31 UTC
in journal: #8465Comment #52819
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.
Commented 9 years ago2014-11-12 13:17:43 UTC
in journal: #8465Comment #52808
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.
By the time it's done it's supposed to have 5 enemy types appearing/reappearing in each level, a miniboss per level (neither of which was our decision - course requirements) and a climbing mechanic using player-placed thumbtacks. So far we have a graphics pipeline using modern OpenGL and the ability to move an object in 3D space with no collision or physics.
It's hard to be optimistic right now.
What kind of a game are you making?
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
While we're at it, I've always wondered: WHAT does Cyanogen do, exactly? Because I pretty much only read "it's better" but I don't recall finding specific reasons for it. What does it do that I want?
I already fixed it, but the problem remains there
You can probably grab a Used / Refurb for $100-$150(USD) since they're 2 gens old now.
It's an interesting channel to watch sometimes and they do mirror podcasts of their longer videos. They're usually between 20 minutes and 1 hour long.
And i feel your pain on the commute times. Though my original one was a short 15 minute drive, it's now double that and more stressful thanks to the idiots rushing to work in the mornings XD
You can also download youtube specials for offline viewing/listening on your phone. (many documentaries in general are great with audio only)
Tons of great audio books out there too... The Game of Thrones audiobooks alone would occupy you for months
Made Urby and Digi listen to one episode, now they're both utterly hooked. Too hilarious.
BTW use may want to use NULL instead of CLIP, else you may get a compile error; VHLT33 will allow you to use CLIP brushes as part of entities, ZHLT3.4 will not, so use CLIP with VHLT, and NODRAW with ZHLT
The problem is: what entity I'll give to the "clip" blocks (brushes)?
If you're saiying you don't want that edge sticking out of the door jamb, try adding negative Lip, e.g., a value of -5.
Anyhow, Welcome to TWHL! =P
But Android is a software developed by humans with the purpose of being useful and practical for as many people as possible.
Your old phone is just a small collateral victim.
Try Cyanogen instead.
I've used trigger_multiple on my glass doors too and they worked correctly, as I said above.
The only thing I should fix is this annoying glass bug on the door. Apart from that, this map is working flawlessly.
It's because I'm developing my debut Counter-Strike maps. I'll just do 5 maps, for the time being, due to my personal life issues and lack of time.
By the way, I'm planning around 30 maps, for Half-Life, Counter-Strike, GoldSrc engine and the Source engine.
Anyway, thanks for commenting here
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
Yoohoo! Mapper!
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
Is there any "NOT" gate in GoldSource? Because if yes, you could build a NAND. And NAND gates are a basis for everything.
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
Hosted By Jessie
Looked at the entity guides myself, l think I've got how do it. Will let y'all know.
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
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
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 sure there is some way of replicating gates, I've just never gotten round to figuring out if there is.