Data of prop_-entities
I have been trying a lot configurations for the two aforementioned methods yesterday evening: (a series of) point_pushes and a func_door raising a func_clip_vphysics positioning device. Unfortunately I couldn't get the desired result with either of those methods. I think the main problem is that a cube that's already touching the bottom of the cube recepticle will rather fall over (i.e. rotate around x and y axis) then slide in (move along x and y axis) when a force is executed on it.
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.
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.
Other Portal 2 maps: Medusa Glare
Portal 1 maps: Try Anything Twice | Manic Mechanic
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.
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!
I've heard that before... 
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:
- Code: Select all
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 <movedir> 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.
I think vectors are sent in params as x,y,z rather than x y z, but don't quote me on that.
I think I had tried that too ... will try again. But we are dealing with an angle which strictly speaking is not a vector. If I'm not mistaken it's stored as a vector though.
"Vector" in the Source engine just means three numbers together. They don't always represent mathematical vectors, and to do standard vector math on them (as in Sendificate) you need to write your own functions.
Did a couple of more tests. Here's the results:
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:
- Code: Select all
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?
It may be that those attributes are not accessible via a script.
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.
Other Portal 2 maps: Medusa Glare
Portal 1 maps: Try Anything Twice | Manic Mechanic