You need to log in to create posts and topics.

Puzzle Creator Tech Info, Hacks, and Laughs

The P2C format has changed at some point, now it's on Version 14.

EDIT: I'm working on a C++ library to read and write P2Cs, and it works with versions 12 and 14 now. Are there any others out there?

Falsi sumus crusto!

Version 14 changes how voxels are stored. Rather than a "Voxel" block for every voxel, there are now blocks "Solid", "Portal0", "Portal1", and "Portal2", within which are blocks Z0 to Zn (where N is the size of the map on the Z-axis--NOT N-1 for some reason). Within each of those are keys Y0 to Yn, and each of those maps to a string of the format "f000101110110100101101". A 1 indicates that that voxel has the property, a 0 indicates that it does not.

Falsi sumus crusto!
FelixGriffin wrote:
(where N is the size of the map on the Z-axis--NOT N-1 for some reason).

There's an extra row along each axis. I think this is because you only know the portalability of the -X, -Y, and -Z sides of each voxels, so you need one more voxel to tell you whether that last wall on the edge should be portalable or not. In other words, if you reach the right-side wall of the chamber, the only way to tell what color the wall should be is to check the left side of the next block (which doesn't actually exist in the map).

It's funny you should post this. I'm working on some code to read a p2c file and write a vmf. I want to get it to the point where I can clean up some of the sillier things the PTI editor puts in there. I have it to the point where it correctly writes the blocks at least, and I started working on the entities. I realized last night though that the antlines are not stored in the p2c, so I'd have to do some kind of path finding algorithm to generate them. :sad:

Bleah. I was sailing right along on my p2c --> vmf project until I hit the freakin' faith plates. Does anyone know (or even have any idea) how the physics/player speeds work for the puzzlemaker faith plates? The only thing stored in the .p2c file is the 'catapult speed', which gets used for the physicsSpeed value for the trigger. But there's nothing for the player speed, which means it must get computed internally before the .vmf gets written.

The player speed is almost always less than the physics speed, but after dumping a bunch of numbers into Excel I can't figure out the exact relationship. It's not linear. It's not even quadratic. Plus if the target of the faith plate is on a different level that the plate itself then the relationship changes.

There's got to be some kind of equation, but damned if I can figure it out. :notwant:

As far as I can tell it's using the kinematic equations to figure out the velocity. It uses the physics speed to find the time, then combines that with the distance and the player's mass to find the player speed.

Falsi sumus crusto!
FelixGriffin wrote:
As far as I can tell it's using the kinematic equations to figure out the velocity. It uses the physics speed to find the time, then combines that with the distance and the player's mass to find the player speed.

Hmm. Could you elaborate? All I've been able to figure out so far is that if the faith plate and the target are on the same level, the physics speed is 80 times the distance between the two, divided by the sqrt(2). But the same rule doesn't apply when the target is at a different height. I thought it might be doing something like using the point where a parabola would intersect a plane at the same height as the launcher, but no.

And this isn't even getting into what happens when the plate is on a wall.

The relevant vertical kinematics equations are thus:
Image
Image
Image

V sub zero is the initial velocity, aka the KeyValue on the faith plate.
V is the final velocity, the speed with which the player hits the ground at the end (with sign information).
Delta-X is the displacement, the distance travelled.
A is the acceleration, in this case due to gravity.
T is the time it takes.

To find how high the player will be launched from a faith plate, for example, you would set V to zero, V-zero to the player speed, and solve for delta-X.

I believe the PTI figures out the physics-object-speed value, uses it to solve for T, then uses that to figure out the player speed.

Falsi sumus crusto!
Cyberwurx Web Hosting

You're forcing me to dredge up those high school physics memories. :)

Thanks, I'll ponder it for a while. Working my way through the rest of the item palette right now.

FelixGriffin wrote:
I believe the PTI figures out the physics-object-speed value, uses it to solve for T, then uses that to figure out the player speed.

I'm finally getting back to this after getting most of the other PTI test elements working. I don't think the time has any bearing on the calculation. The speed given in the in the .p2c file is the X component of the launch velocity for physics objects. Since the player speed is a different value in the .vmf, the time can't be the same for both.

You can verify this by making a loop of 4 faith plates in a square. Put a cube dropper over one of them and walk onto another one. The cube will gradually catch up to you as you bounce around the loop.

I have an equation that's accurate to 2 or 3 decimal places, but it only works if the plate and the target are on the same Z level. This is incredibly frustrating because I've pretty much got everything else working apart from goo pits, and these wretched plates are the railroad tie across the highway of progress. :angrysquare: