Data of prop_-entities
Since I couldn't find any trace of the according info I assume that it is somehow coded into the engine. Nonetheless I wonder how Hammer can access that info if it was so. And before I give up my search I wanted to confirm my assumption with someone who probably knows better than me ... i.e. with you guys on this forum!
innocentive wrote:
I would like to apply these features to prop_dynamics/func_brushes and rebuild the original props manually... and the best way to do that would be to see how Valve did it.
That's going to be really difficult without the code. For some things you'll probably have to line the walls and floors with a grid of triggers (gel and funnels, to name two).
On that note, has anyone an idea about how to make a cube slide into the cube button as gently as it happens with a prop_floor_cube_button?
innocentive wrote:
or the particle effect at the end of a light bridge.
You might be able to use HMW's sendificator script for this. You'll need to find the particles and apply them at the end.
As for the button; you could try using a trigger push?
And I will try the cliping method. I hadn't thought of elevating the clipping brushes from beneath/inside the button. Sounds very promising!
I'll let you know how my tests went...
innocentive wrote:
On that note, has anyone an idea about how to make a cube slide into the cube button as gently as it happens with a prop_floor_cube_button?
I built a thing like this a while ago, for aligning laser cubes. It's a tray shaped like a cube button, with a moving bottom that sort of jiggles the cube into position. It's attached to this post; you can add it to your map as an instance.
I hope it's the right file; I'm on Linux now so I can't load it up in Hammer to check.
It doesn't have the ability to trigger anything (yet), so if you want it to work as a button, you'll need to ad a separate trigger.
As for the light bridge endpoint effect, I'm fairly sure it is possible to create this with an info_particle_system. I'll see if I can look that one up tomorrow.
(Right now it's time for 
)
.
That's why I had more or less the same idea like HMW. A cube would have to be moved from it's bottom side. I looked at your contraption and it's a very clever design. It also works quite well. But I haven't given up yet on finding a smoother solution. If I get there, I'll let you know!
Ah ... and also: I had tested a particle system with the projected wall particles and there were some glitches pointing to the origin. I thought that's just because I don't zip about particle systems yet (haven't worked with them yet) but it might very well be a bug of the code.
innocentive wrote:
That's why I had more or less the same idea like HMW. A cube would have to be moved from it's bottom side. I looked at your contraption and it's a very clever design. It also works quite well. But I haven't given up yet on finding a smoother solution. If I get there, I'll let you know!
Cool, if you find anything better, I'm interested!
The light bridge particle system is called "projected_wall_impact". I see what you mean by "glitches pointing to the origin". That particular system seems to use extra control points for the effect. To set a control point, create an info_target with a unique name and enable its "always transmit to client" flag. Then set the "control point xx" attribute of the particle system to the name of that entity.
I messed around with it a bit, and it seems to use control points 2 and 3 as the endpoints, but when starting up it still emits some particles from the info_particle_system itself. You should be able to get a decent result by experimenting with the positions of the various entities.
HMW wrote:
innocentive wrote:That's why I had more or less the same idea like HMW. A cube would have to be moved from it's bottom side. I looked at your contraption and it's a very clever design. It also works quite well. But I haven't given up yet on finding a smoother solution. If I get there, I'll let you know!
Cool, if you find anything better, I'm interested!
The light bridge particle system is called "projected_wall_impact". I see what you mean by "glitches pointing to the origin". That particular system seems to use extra control points for the effect. To set a control point, create an info_target with a unique name and enable its "always transmit to client" flag. Then set the "control point xx" attribute of the particle system to the name of that entity.
I messed around with it a bit, and it seems to use control points 2 and 3 as the endpoints, but when starting up it still emits some particles from the info_particle_system itself. You should be able to get a decent result by experimenting with the positions of the various entities.
That's great to know! Thanks!
Lpfreaky90 wrote:
The origin problem is known also at valve; it is the reason why PTI maps are not near the origin (or at least weren't). It might be good mapping practice just to stay away from the origin.
I've heard that before... 
HMW wrote:
innocentive wrote:That's why I had more or less the same idea like HMW. A cube would have to be moved from it's bottom side. I looked at your contraption and it's a very clever design. It also works quite well. But I haven't given up yet on finding a smoother solution. If I get there, I'll let you know!
Cool, if you find anything better, I'm interested!
I've been experimenting with a couple of different setups the last two days. There is one way that should be very close to what the prop_floor_button does but I can't get one detail to work ... maybe you can help me:
Having tried all sorts of I/O-mechanics, I had the idea to write a simple script. There's a button with a trigger that upon touch by a cube calls a scripted function which
(1) positions a func_clip_vphysics plane just above the floor of the button,
(2) positions a func_door somewhere near (this step would indeed be optional),
(3) parents the func_clip_vphysics to the func_door, and
(4) opens the door into the approriate direction, thus kinda dragging the cube on the vphysics plane into position.
The problem is that I can't seem to change the Move Direction (key: movedir) of the func_door from inside the script. I tried the following line:
EntFire(EntityGroup[1].GetName(), "AddOutput", "movedir 0 180 0", 0)
where EntityGroup[1] is the func_door and "0 180 0" is just some direction other than the original 0 0 0 in the door porperties ... to no avail. I assume that the second space between 0 and 180 might mix the program up because the value for the key actually contains three values. How to inlude that in the script code properly?
PS: In dry testing with a fixed move direction the cube in fact jumped away from the button once ... it totally felt like the ingame button and suggests that Valve did something very similar.
It is irrelevant whether movedir is a vector or an angle. The main point is that the object to be changed is an combination of <key> and <value>. As such the parameters need to be <String> seperated by <Space> (as in the properties dialog with SmartEdit turned off). For instance, this line works properly:
EntFire ("door", "AddOutput", "origin 128 128 0", 0)
It is interesting to look at this example a little more. Changing the origin of a func_door (either through EntFire or through SetOrigin) leads to the following:
(1) The door is positioned at the new origin.
(2) When the 'Open' input is sent, it moves to the original opening position that was assigned on spawn.
(3) Upon 'Close' it moves back to its spawn position.
In conclusion, it appears that the opening position and the closing position of a func_door are stored seperately from the 'origin' and the 'movedir' keyvalues. However, I'm clueless as to how to address these two. Does anyone have an idea how those keys can be found out?
Have you tried parenting the door to another entity (say, an info_target) and moving that other entity?
You should also be able to change the movement direction this way, by rotating the parent entity with SetAngles.