Attempting the Impossible

[SuperLlama]

LOL, it suddenly decided to work! Apparently, RenderView ignores beams completely-- they're drawn in the right place. Same with bullets! The only problem now (and it's minor) is sounds-- you hear sounds from the ghost ship's point of view instead of the real one's. There's no sound in space anyway so who cares-- but it would be nice if it worked properly for aesthetic reasons. If you guys know any way to change where the player hears sounds from, please let me know!!!

All that remains now is to get interior props working. Right now, the player is the only thing that can be on the interior, and it doesn't transition automatically (you have to use a console command). When I'm done, you'll be able to enter a ship's local physics system simply by walking through the door. Bullets won't be transmitted though, unfortunately-- but grenades and combine balls can (since they're entities).

EDIT:
Major progress! Props and players can be "eaten" by the real ship, and are moved to the ghost ship.
Here's what I have left to do:
1) Make it so objects can leave the ship
2) Make the player's view draw correctly when looking through an external camera (it gets really wacky right now)
3) Make it so players in the ghost ship can't see out of it, and see out of the real ship instead
4) Make entities under the player's crosshair be dual-state so you can interact with external things

[sk8erjosh]

I like where this is going.I'm glad to hear of your success please once you have a working beta form of this please let me test it an ill give some feed back

[feha]

About slicing, there is a way to ignore collission on one side of a prop.

Basicly, on collission, find the nearest point (or whatever giving the best vector), and check if it is on the slized part of the prop.
If it is, get its velocity, and add it to its pos (same for angles), basicly making the collision never happened.
Another way is to nocollide the props in the case, so source physics can work on its own, and when it enters the non sliced area of the prop, it gets stuck (unnocollide but still inside the sliced away part of prop).

I must however say that your idea seems better, just wanted to mention other ways of doing it.


The spacebuild thing seems nice, but it does also cause alot of problems. For example it sounds like it is going to be laggy (something most spacebuild servers already are), especially for bigger ships.

It might also collide with other addons, such as, how will it work for the resized players, or those sliced props you have been thinking of?


I like your ideas tho, and I must say it sounds like a challenging project. If you can, I would love to see a fix for joincrashes, thats an attempt of the impossible XD. Very usefull if it works tho. Very.

[SuperLlama]

About slicing, there is a way to ignore collission on one side of a prop.

Basicly, on collission, find the nearest point (or whatever giving the best vector), and check if it is on the slized part of the prop.
If it is, get its velocity, and add it to its pos (same for angles), basicly making the collision never happened.

I've tried this before-- it's kinda ugly. It still makes the impact sound, and bullets still hit the invisible part, etc.

Another way is to nocollide the props in the case, so source physics can work on its own, and when it enters the non sliced area of the prop, it gets stuck (unnocollide but still inside the sliced away part of prop).

Like you said, it can get stuck-- and source nocollides take a few seconds to take effect.

The spacebuild thing seems nice, but it does also cause alot of problems. For example it sounds like it is going to be laggy (something most spacebuild servers already are), especially for bigger ships.

Surprisingly, it's not laggy yet. The only thing that lags is re-rendering, and that's clientside. It's not a redo of physics, it's just a relocation of them. I'm anticipating some lag with the "inside detection," but I'm planning to lower its frequency (process a different ship every 0.1 seconds, that stops the "It's getting stuck every second because it's processing all the ships at once" and makes it more uniform, and is definitely better than every ship every tick.)

It might also collide with other addons, such as, how will it work for the resized players, or those sliced props you have been thinking of?

Both would work normally. Like I said, it's not an override for source physics, it's a hack to make them think they're somewhere else.

[Divran]

Yes you definitely have to think about making it as lagless as possible for spacebuild.

[SuperLlama]

Technically, by giving the objects an internal state, it's actually REDUCING lag by allowing you to have, say, sixteen watermelons in your ship and not have them bouncing around when you fly. You can even freeze them inside your ship, and they'll still move along with it. The only laggy part is the door calculation stuff, which I'm trying to optimize as much as possible.
Currently, every ship think (which is once a second),

1) it calculates the collective AABB and Center of all hull props, and does a FindInBox. This will most likely be replaced by a one-time time calculation to find the radius, then a FindInSphere-- less accurate, but less expensive.

2) for each object found, it does a trace from the center of the object AWAY from the center of the ship. If the trace hits a hull prop, it "eats" the object, considering it inside, and since it's a ghost now, it's ignored from further checks.

3) [in progress] for each object inside, it does a similar trace from the center of the object away from the center of the GHOST ship. If the trace hits a ghost, it "spits" the object out, considering it outside.

4) [in progress] when players are inside, a trace is done from the external player's eye (the place others see him from) to check for potential interactions. If something is found, a copy of that object is created in the internal world, and the two props are linked so that the external one obeys the internal one's velocity, but the internal one obeys the external one's position, etc. Hard to understand, I'm sure, but it should work in theory.

5) There will also be some sort of checker inside the ghost so that the player's actions (spawning props, using the toolgun) will work properly. The prop spawning part is easy- just make spawned props' interior equal to their spawners'. As for the toolgun, I'm not so sure.

For optimization, there are various modifications that can be made:

*Ships will not check for potential exits if there's nothing inside them (durr!)

*No more AABB merging, that was a bad idea, I'm going to replace it with a one-time radial calculation that can be reused with findinsphere.

*Things welded to a ghost will be ignored in exit checks.

*Rather than setting external objects to nodraw, the player's view distance will simply be decreased to the radius of the ship. Special cases like people walking by the ghost's location will have to be set to nodraw, though.

EDIT:
If I were to spawn a ship right this second and run my temporary console command "shipdef" on it, here's what it would be able to do:
*If you walk into the ship, you would be seamlessly moved to its invisible physics environment. Your view would be anti-moved, so you wouldn't be able to tell the difference.
*If you were to thrust the ship forward, you would stay on the floor, not moving at all from the acceleration.
*If the ship were to flip upside down, you would STILL be on the floor-- able to walk around and even jump "down" and fall back "up" again. It's really fun, and weird in a good way. You'd have to see it :P
*If you were to walk outside of the ship while it was resting on the ground, you'd fall through the floor, because exiting isn't written yet. :/
*If you respawned and threw a bunch of watermelons into the ship, they would also be seamlessly moved to its invisible physics environment. They would still appear to be in the same place, though you can't shoot them anymore (bullets aren't entities and can't be moved between environments). You could accelerate the ship, or even smash it around with your physgun, and the melons would stay nicely on the floor, not moving an inch, not exploding and not falling out.
*If you threw a grenade at the watermelons, they would all blow up, because grenades are entities and can be "eaten." The debris would be invisible from the outside, however.
*If you spawned an object while inside the ship, it would fall right through the floor because it thinks its part of the external world and shouldn't collide with the ghost ship. This will be fixed.
*If you threw a barrel into the ship from the outside, then followed it in, you would be able to physgun it from the inside.
*If you froze the barrel, then accelerated the ship, the barrel would still stay in its relative position to the floor, in spite of it being frozen.

EDIT2:
Almost done with my homework, I'll be able to get back to work after that

[feha]

Wait what? Why would the players view distance need to be limited?

Also, what happens when 2 of those ships go close to (or into) eachothers? Any conflicts?

[SuperLlama]

Wait what? Why would the players view distance need to be limited?

Only their view of the internal world. The external world has no limit on its distance-- the problem is that the player can look out the window and see himself seeing himself seeing himself-- because he's in two places at once. One for physics, one for looks. The physics world needs a distance limit. If you know anything about Oblivion modding, you can compare what I'm trying to do to an "internal cell." Oblivion's interiors are separate worlds--- but source only allows for one world. The way I accomplish this is by making the "second" world only visible and solid to those inside it, but I have no way of doing the opposite. Heh, it's too hard to explain really-- but as far as the player will be able to see, there's no difference in view limit. It's a hack thing to fix a bug, that's all, and it will be totally un-noticable.

Also, what happens when 2 of those ships go close to (or into) eachothers? Any conflicts?

Props/Hulls can only be claimed by one ship at a time, so they'll just ignore each other. They'll collide, but they won't be sucked into each others' worlds. However, if you shoot a grenade out of one ship into another one, it will work as expected- the first ship will unclaim the grenade, the second one will reclaim it, and the poor guy inside the second one will be blown to pieces.

I might try to make some sort of nesting system where you can fly a shuttle into a larger ship's hangar and have it be "eaten" but still its own ship, but that's not really necessary at this time and will be rather difficult.

[Divran]

I might try to make some sort of nesting system where you can fly a shuttle into a larger ship's hangar and have it be "eaten" but still its own ship, but that's not really necessary at this time and will be rather difficult.

Just remove the shuttle's other world, so that if a player goes from the hangar to the shuttle, he's still inside the hangar and not inside the shuttle. What I'm saying is there is no need for a different world inside a different world. There's no need to go over the top with this thing.
This means that if the shuttle accelerates inside the hangar, the players inside the shuttle will be thrown around.

EDIT:
When you get this working completely, you should get in touch with the creators of SBEP and ask them for SVN access so you can upload it there Either that or ask SnakeSVX to put it in the Spacebuild SVN.

[SuperLlama]

This means that if the shuttle accelerates inside the hangar, the players inside the shuttle will be thrown around.

That's the problem here. In fact, it's more expensive to delete/recreate an other world than it is to nest it. Nesting is a little harder to code, but it's not too big of a problem.
Currently, the location for the other world is found by a function called FindNowhere. It generates random vectors until one of them meets the requirements: a 256x256x256 cube of empty space. I'm going to modify it later so that it picks larger locations for huge ships, and tries to find locations without gravity for spacebuild maps (users will probably want to use the gravity tool, rather than having the whole ship constantly affected)

I'm surprised at how not-laggy it is. I'm sure that LS3's beam system is far more expensive than this is.

EDIT:
Nesting actually makes more sense given the code I already have. The "other world" is really just a table of entities with some data about which ship they're in. The shuttle's hull could easily exist inside the other world of the hangar, and simultaneously be hosting its own other world elsewhere. The problem comes when you try to pull things from the hangar into the shuttle from the inside, since those objects aren't really going to exist.