button and portal
Can somebody just tell me in this forum?
This is really a very simple concept, if you just learn how a button fires an output, and how to use the I/O system then there's really no need to ask.
Is it big deal to you to tell me how can I do that? I have tried many output settings example: name: on open, target: autoportal, via this input: set stage active etc., but I can't get it work no matter what I do.
And Farragar, u know what? "the one asking does not go astray from the road"
I can't understand why you pro's can't help beginner with mapping?
I understand that you mean "by experimenting, one learns", right? But I tried all thinks that I know and thinks that I don't know and even more
.
I think it's better that I give up with mapping...
Quote:
the one asking does not go astray from the road
But there's a difference between asking a few pointers; to use your own metaphor, a question or two is fine, but a constant barrage 'pisses off the seasoned hiker.'
The I/O system is fairly simple. when you want to add an output from your 'trigger_multiple' You have:
'My Output named:' This is the action that will fire the output. For example, OnStartTouch
**
'Target entities named:' **This is the name of the entity/brush/particle effect/whatever that the output will effect. So, if you named your portal 'room1_blue_portal' then that's what you would stick in here.
'Via this Input:' This is what's going to happen to your target entity. In your case: 'SetActivatedState'. For a func_door you might have 'open'
'With a parameter override of:' This depends on the target entity, for most entities it won't be needed. In your case, it represents a Boolean (0=false 1=true) value for the state of the portal. Therefore, 1 is an open portal, 0 is no portal.
For other entities like an env_texturetoggle it can change the texture applied to a brush, or with a math_counter it can change the value stored in the counter.
'After a Delay in Seconds of:' Self explanatory; this will delay the output by x seconds after the trigger is fired.
edit: Oh I get it to work now 
replace "prop_portal" with the actual name of your prop_portal.
To Open:
OnStartTouch -> prop_portal -> SetActivatedState -> 1 (put this in the parameter section)
To Close:
OnStartTouch -> prop_portal -> SetActivatedState -> 0 (again in the parameter section)
I have my first maps first room nearly finished. I only have to somehow fix one button that make bad drone when I jump to it, and make switch to destroy old cube and and give new cube from dropper. And of course lighting. Then it's ready. My first map
at first I want you to know that I did read alot tutorials and tried out alot before posting this, so please don't answer me like "just try out for yourself you noob
".
1.
I want to make GLaDOS speak immediately after beginning the map...and of course I know how to put the triggers and stuff...but for some reason there is a delay of about 10 seconds before GLaDOS actually begins to speak...what am I doing wrong?? I didn't put any delay or something like that -.-'
2.
I wanted to put a door and a button into my map (http://developer.valvesoftware.com/wiki ... n_and_door) so i could open the door using the button.
for some reason the button doesn't go down if i jump onto it (the sounds work fine) and the door just doesn't open...in fact, the triggers don't seem to be wrong...if I check "touch opens" under flag and then touch the door, it seems like the door tries to open, but ending up getting stuck somewhere -.-'
btw. i did everything EXACTLY like in the door and buttons tutorial (check the link above).
I'm assuming that I'm doing some sort of a typical beginner mistake, so i hope some advanced mappers know what I'm doing wrong ^^
for #2: you need to check that the button is targeted with I/O and that its a func_door set to move down. ALSO: check to make sure you have the button model parented to say func_door
rellikpd wrote:
on #1: if you didn't put delay, but there is one then that means its using some default. put a delay of 0, or 0.1for #2: you need to check that the button is targeted with I/O and that its a func_door set to move down. ALSO: check to make sure you have the button model parented to say func_door
well I have the button and the door FINALLY working...I simply parented the button wrong, that's why the button didn't go down...
and lol...the doors...why do you have to type 90 (and 270) degrees @ move direction?? that doesn't seem to make sense to me O.o ... you like have to think sideways?? anyway, at least it works now ^^
but the delay...I just can't figure out what I'm doing wrong...there certainly is a delay of about 0 seconds, though I didn't put a delay...and as you said, I put a delay of 0.1 but that doesn't change anything -.-'
for some reason only the first GLaDOS voice has this effect...the second one I put into my map just works how it should work...any idea?? O.o
Sephiroth wrote:*
1.
I want to make GLaDOS speak immediately after beginning the map...and of course I know how to put the triggers and stuff...but for some reason there is a delay of about 10 seconds before GLaDOS actually begins to speak...what am I doing wrong?? I didn't put any delay or something like that -.-'
Did you use logic_auto? That's its purpose.
If the answer is yes, then I am afraid the error is on GLaDOS's side, probably the sentence you are trying to play has the delay itself.
Sephiroth wrote:*
...why do you have to type 90 (and 270) degrees @ move direction?? that doesn't seem to make sense to me O.o ... you like have to think sideways??
because if you are looking at the top down view, thats the angle they would move at (as if drawn on paper) with 0 degrees being to the right, 90 would be pointing to the "top" of the paper, 180 to the left, and 270 points to the bottom of the paper.
just like in geometry class :-/
Farragar wrote:
...counter-intuitive....
'
its NOT counter-intuitive, because now you are thinking about directions on a globe or map, and yeah we call these things MAPS but they are made on computers, and computers are ran on math, made by guys who were math nerds. so its only follows that they would follow math rules.
and although we call them maps. we are really building geometric shapes (now (with steam) quite complex shapes, but still geometric shapes) and so it only goes that we would use math coordinates and math rules, PLUS: north/south/east/west gets really confusing on the Z axis, how can you have 2 different norths? you can't, but you can have two 90 degree coordinates based in different axis
Also, the only time I've ever had to measure angles in this way is when dealing with Argand diagrams and Imaginary numbers, and even then, these are taken in Radians; not degrees. (obviously radians are pretty much useless for Hammer - but you get the point.) Still, I would have thought most mappers would deal more naturally with a clockwise system. It's only a software edit - after all.
its even on the protractor, and compass.
its math baby.