New Force of Gravity over the Prop_Weighted _Cube
Hey guys,
Has anyone noticed that in the new puzzles made since the PTI release the prop_weighted_cube bounces through floor portals without losing height?
This didn't happen (and still doesn't) in the levels created in hammer...
Where exactly is this difference stored in the entities (or in hammer/the new puzzle maker)? I mean, if it is the same entity, why behaves differently depending on what you used to build your map? Is there a new prop_weighted_cube entity?? Is it possible to set the force of gravity easily for it or atleast decide about which behaviour do we want to use of those two?
useful tools and stuff here on TWP 
[spoiler]
[/spoiler]
I haven't noticed, I wanted to use this for a test but as far as I could see this didn't happen...
It's kind of annoying: I've got 2 puzzles based in bouncing a cube throught floor portals, and for one of them, the most complex, I've set a complex trigger_push system that activates/deactivates as the cube goes up and down. It works great though but after I discovered this change in gravity on the cube, I would really like to know how to take advantage of such that change...
useful tools and stuff here on TWP [spoiler]
[/spoiler]
I've been creating a puzzle with the editor based on momentum through floor portals, and something weird was happening with the heights I could reach. I thought it was just my imagination, but now you mention it...
I think there definitely needs to be some tests on this. I also noticed that faith plates projecting upwards behave strangely when talking about speed once you drag the slider above the roof.
Hmmmm... but you mean you? the player? If so, I haven't noticed that though. Looks like in the new puzzle maker now the player and the cubes behave the same regarding gravity, what didn't happen before...
I've got some PTI maps decompiled, I'll give them a close look this evening. Could it be something inside the func_instance_parms of the cube_dropper instance? maybe a script setting the cubes velocity? I'll check.
EDIT: Wow, this is amazing. Look what's into the new dropper instances:
They have built a complex system in which there are 2 entities inside the instance in a first place: one is a prop_weighted_cube and the other is our friend the prop_monster_box!
I've tested it and we can conclude that the prop_monster_box do bounce through floor portals without losing height, while the weighted_cube doesn't.
Here it's the interesting part: this system inside the new droppers seems to be built so the final result is that the normal looking cube somehow takes the properties of the prop_monster_box after all that bunch of logic_relays, math_counters, logic_branches, listeners, triggers, etc.
The prop_monster_box has the property "allow silent dissolve" active. And indeed that entity is killed several times in this complex circuit. Hmm.. the regular cube also gets killed in the normal instances and is respawned by env_entity_maker and point_template inside the instance. But here there's no env_entity_maker, the point_template is spawned (ForceSpawn) by a trigger and by a logic auto only...
At the end of the dropper there's a trigger_multiple (only flag ticked is "physics objects") with this outputs:
OnTrigger > !activator > BecomeMonster
Where the hell has that output come from?? Incredible! could this output be the key?
I've tried to make a logic_auto that OnMapSpawn > cube_dropper_box > BecomeMonster, that ofc doesn't work 
I'm still trying to extract the logic behind this system in order to implement it easily... I'll post whatever I find...
useful tools and stuff here on TWP [spoiler]
[/spoiler]Aperture must have hired Frankenstein.
Why do you think they're called frankencubes anyways 
Wow, that's ridiculous! Although very Aperture-like.
Isn't there a separate instance for the Turret Cubes? If so, we could redesign the normal one to be MUCH simpler.
I don't understand what you mean by "bouncing": do you mean when you have two portals on the ground, and drop the cube into one from a height, and it flies back and forth? I thought that always kept the same height, and thus things like Portal (1)'s Test 18 would work without fast reflexes?
EDIT: Wow, this is amazing. Look what's into the new dropper instances:
[bunch of stuff]
WTF??? wow. what a fucking... roundabout way to solve a problem that didn't exist? this is so surreal.
I'm assuming from a design standpoint they wanted 'cube physics' to be as simple as possible for the PTI (so when you launch a cube through something in PTI you can predict exactly where it lands when you're building the puzzle?)
But man, what a complicated solution to that problem O_O
Exactly, that is what I meant. And I mean this discrepancy is only for cubes, not the player:
- Hamer maps = player doesn't lose height while getting out/in floor portals. Cube loses height little by little.
- PTI maps = nor player or cube lose height ever.
Isn't there a separate instance for the Turret Cubes? If so, we could redesign the normal one to be MUCH simpler.
Indeed. The new dropper instances distributed with the DLC2 (located into sdk_content/maps/instances/p2editor btw) are only 2: a monster_dropper and an item_dropper.
The item dropper can spawn different cube types you can choose by setting a number value in the func_instance_parms. Due to the fact that there is an independent monster_droopper, I guess you'll never be able to spawn a monster box by the item_dropper , so the cube types would be regular, companion. reflector, ...and maybe their rusty models? (don't really know if those exist in the PTI, I believe not, because of the clean style in the PTI maps).
Yesterday I was making some tests trying to turn the monster_box into a regular cube model by a script. Check out and LOL:
(It seems that even if you set the monster_box to be spawn in the map as a box, then change the material model, it still look like if the frankenturret were pulling its cube)
It's strange because if you simply spawn the monster_box as a box, its position is very similar to the regular cube (hermit_idle model) except for the noises and the sad eyes 
I guess it's possible to use some script to GetAngles(?) from a regular cube already placed into the map and SetAngles(?) of the monster box to be those? Could any scripter help me about that?
I'm assuming from a design standpoint they wanted 'cube physics' to be as simple as possible for the PTI (so when you launch a cube through something in PTI you can predict exactly where it lands when you're building the puzzle?)
But man, what a complicated solution to that problem O_O
Yeah! Kaleido, I thought the same! Ofc I think they wanted to simplify the cubes physics for being used in the PTI... but man, why didn't they just change the prop_weighted_cube entity?? THIS is what really intrigues me! Is it because they didn't want to change what had been that way "all our lifetime"? Is it in order to avoid messing up with the stock campaigns puzzles?
And finally, isn't there any simpler solution for this? I won't stop until I understand the system by which they turn a monster_box into a regular cube. I've tried the "BecomeBox" monster_box input to no avail. Maybe using (filtered) triggers like Valve does instead of logic_autos?
Will continue testing...
useful tools and stuff here on TWP [spoiler]
[/spoiler]
OnTrigger > !activator > BecomeMonster
Where the hell has that output come from?? Incredible! could this output be the key?
I've tried to make a logic_auto that OnMapSpawn > cube_dropper_box > BecomeMonster, that ofc doesn't work
I'm still trying to extract the logic behind this system in order to implement it easily... I'll post whatever I find...
This command sounds very intriguing... Have you tried using a different way to trigger the output (e.g. ent_fire) because the problem could be the logic_auto. (Used 'em all my life, never had a problem.) Worth a try anyway. Also, it's not just the physics they've changed for the PeTI, they've the changed the way some things move, and for me the gel looks de-graded. Could be just me :S