A hitbox is a hypothetical box around the player that detects when a player gets hit, or touches something, etc.
Ok, so for the psuedo-hitboxes, what would they have been useful for? (I said have been because @eiqcrmeliutgwhc said that the player coordinate system solved the problem).
To detect when a player gets by a projectile, gadget, etc. If the props around them break, they are “hit”.
That’s what I thought. So, does it go with the concept of psuedo-health (that’s still a thing, right?)?
It could be used with pseudo health or normal health. Pseudo health would probably be better as it would solve pseudo healths biggest flaw (incompatibility with gadgets like zapper).
Just wondering, as I recently got on again, I kind of forgot why psuedo-health was important or something. Can you remind me?
You can edit the health however you want and track how much health you have since it’s connected to a property.
Why would you need to track health through psuedo-health if there already a thing for health?
You can know exactly how much health you have.
Ok, I want to have a game that when you are at 50 health you go 2x faster.
Let’s say I have bob. Bob is at 10 health. But the only current way to figure out how much health someone has is by damaging them and seeing when they respawn.
Pseudo health solves all of that, since it’s a property that can be grabbed whenever you desire.
Ok. I could try to make this but I need a better explanation of everything in the diagram.
I could try to re-explain it, but just be warned: this is a year-old guide, so I’m rustier with GKC. What do you need explained?
Just kinda what it should do and how I should set it up. Is that okay?
The Grim Builder is currently working on a way to connect those (very close to a breakthrough!)
We could make a grid-pixel screen like Gim Jumper did to make them…
Of course it’s okay.
In the end, it’s up to you how you choose to go about it, whether you use some other kind of coordinate system or the one I’ve created, or how you want to create hit detection.
Whatever you think would work towards the idea I presented, do that.
If you need help getting started, Shdwy left a reply which could serve as good guidance:
Good luck!
But I don’t really understand the mechanics of this. The diagram isn’t (trying to be the least offensive as possible) very easy to understand
In cooperation with a coordinate system, a trigger would activate a set of 4 invisible props around it when the player steps on it(above the player, below, to the left, and to the right), creating a ‘box’ around them.
The coordinate system would let the computer know which triggers are around the center trigger, using xy values.
Does that make more sense?
This mechanism is a theoretical design for a projectile tracker, to allow psuedo-health tracking with the hardcoded weapons in Gimkit. Basically, the idea is that when you fire a weapon at someone, there are props loaded around them that get hit first. That way, you can send a signal to your devices telling them the player got hit without them actually getting hit. This is the only way of tracking projectiles (I believe).
How the mechanism actually works isn’t as complicated as it looks. All you need is:
a) a way to track the player’s location. This was done with triggers, but we now have a device to make it easier: the player coordinate device.
b) a logic handler that enables props around the player’s coordinates
c) a bunch of props coded with specific coordinates in their channels
Here’s a very specific example:
I’m at (2,0).
The mechanism triggers props at (1,0), (2,1), (3,0), and (2, -1).
The mechanism saves all of those coordinates as props surrounding me.
Someone fires at me from (0,0).
The bullet comes from the right towards me with a vector of <2,0>
The bullet hits the prop at (1,0).
The mechanism sees that, and sends a signal to the CPU that (1,0) has been hit.
The CPU knows that means I was hit, since that information was saved, and then doles out consequences accordingly.
Does that make more sense?
for the people who actually know what's going on
Hold on. Reading the replies, it looks like we didn’t mention the fact that props can’t respawn.
Still, theoretically, this is possible (easier, even, with the player coord device) but unless prop damage has changed over the past few months, it will always be limited.
Right?
This might only be for sentries, but I think if you deactivate and reactivate a destroyed prop it might respawn.
Like I said, unless it’s been changed recently, they really just don’t. It’s an odd decision on behalf of the devs, and likely not one made out of anything but convenience.