Stargate Event Horizon - Developers

[QUOTE=Deco Da Man;13233171]I see your problem... According to the show, whatever is dematerialised within the event horizon does not physically move. (Although, this may not be true, as Lieutenant Ford's hand was sticking out of the horizon in 38 Minutes, one of the first episodes of StarGate Atlantis, yet it wasn't affected by lack of blood. And if things aren't physically active while dematerialised, do people actually see their journey through the StarGate?) Maybe, let's say, if their shoot position is within the horizon, it counts as if they are entirely materialised. If it is out, they can get out of the vehicle. You'll probably have problems with them getting out on the wrong side of the vehicle, but those problems should be easily fixed with a few hacky fixes. Also, with contraptions, it should be easy to not teleport the contraption until all props have been fully materialised.[/QUOTE] People don't actually see the journey, it lasts like a split second... and they are dematerialized so they don't have eyes to see it with, or a brain to think about it with. Yay! Just got constraint protection to work! It's being a bit overprotective though... it won't get rid of the props at all, even when they are all in the gate... oh well, must do some more coding then. The event horizon checks to see what side of the gate things are on and what their original entrance direction was. So the checking of what side the vehicle is on would work, but I am defenitely worried about that leaving the vehicle part, source seems to just plop you anywhere. Yeah, but nothing could be honestly true to the show anyways. I'll just go with (If I even get that far) whatever works the best... or if they are tied in functionality then just whatever looks best. EDIT: Muahaha fixed the overprotection, they now work as they should.

[QUOTE=ZeikJT;13222844]Oh no, it's not integrated into your code. This a new SENT written completely from scratch(...)[/quote] Sounds good. Easier for me to implement your code to my gate. [QUOTE=ZeikJT;13222844] There are currently some problems with the way it works and you might not want to add it for those reasons: 1.) If there is a static object on the ground and the horizon comes down on it it won't be detected to hit at all! I don't know why yet. [/quote] Have you set SetTrigger(true) on the EH? [QUOTE=ZeikJT;13222844] 2.) Once the entity hits the horizon it goes into the collision group world and can then escape the gate boundaries because it no longer collides with anything. [/quote] Might be a problem, yes. But probably, there are ways to avoid it. [QUOTE=ZeikJT;13222844] 3.) It doesn't handle constrained props yet, so it would just take the whole mess apart! [/quote] Should be easily fixable by using a "GetConstrainedEntities"-method and then sucking in all constrained stuff too [QUOTE=ZeikJT;13222844] 5.) When I was trying it out in singleplayer I used a camera to see myself but the gate wouldn't clip me, any ideas why? Is the model a separate entity? [/quote] Seems to be an issue with single-player. I know cases, where I couldn't do any drawing on myself in SP (like SetMaterial or SetColor), but in MultiPlayer. Maybe related. [QUOTE=ZeikJT;13222844]If you'd like to see the code I can drop you a PM[/QUOTE] Yeah, go on. But I can't promise when to test it since I'm busy with exams :(

[QUOTE=ZeikJT;13222844] 3.) It doesn't handle constrained props yet, so it would just take the whole mess apart![/QUOTE] [lua] function ENT:StartTouch *touching_entity*.ConstrainedEntities = constraint.GetAllConstrainedEntities( *touching_entity* ) for _, ents in pairs( self.ConstrainedEntities ) do if (ents:IsValid()) then ents:GetPhysicsObject():EnableGravity(true) ents:SetVelocity(ents.GetPos()-self.GetPos()) --self = eventhorizon end end end end [/lua] sumthin laik dis

Better use the function in my stargate-pack (originally by TAD2020), which isn't that CPU intensive. What I also noticed: You said, the prop getting "sucked in", strips apart from the contraption. Do you use ent:SetPos? If so, try to apply force instead of altering the position. If you do so, the rest of the contraption would follow too (if not that heavy) or atleast the first prop isn't stripped off.

Don't suck the prop, that doesn't happen in StarGate. Simply make the prop(s and the whole contraption) move in and out of the StarGate freely. When all of the prop(s) is(/are) in the horizon, teleport them to the other StarGate and [b]then[/b] force them out.

Actually, you are wrong. The Stargates do suck things in... Gently. because in one episode, they place something in mid-air halfway into the eventhorizon and let go.. the thing stayed in mid air and was slowly consumed by the stargate. But hey, it doesn't matter, it does not do this in ALL cases

What has science done

[QUOTE=aVoN;13235242]Better use the function in my stargate-pack (originally by TAD2020), which isn't that CPU intensive. What I also noticed: You said, the prop getting "sucked in", strips apart from the contraption. Do you use ent:SetPos? If so, try to apply force instead of altering the position. If you do so, the rest of the contraption would follow too (if not that heavy) or atleast the first prop isn't stripped off.[/QUOTE] Oh no, that was just before it had constraint detection so as soon as one of the props was in it would react. That's fixed now, but I'll look into any function that takes less cpu power, mine just does a for loop for all entities found with constraints on the entity that has entered the gate. If it finds any that are still on the other side of the gate then it waits. If it finds that it is the last prop constrained to enter or that it has no constraints it reacts. If you pull all of them out then they regain their original properties, one by one of course. Don't worry, I'm already using applyForce, it is the best way. I used to have setVelocity for human players before but I took it out when I was testing the event horizon clipping properties on player models. Also, I noticed in single player that a camera creates a new entity, a "calculated player view" model but I haven't been able to get that to clip either (though it is possible, I had a test entity using findInSphere and when I got close I got clipped, I also have the entity table dump from it). Also, I do have the setTrigger(true). Maybe it was just the way I was testing the moving horizon (was forcing it to change position) I'll try it again.

[QUOTE=GenXCypher;13235871]Actually, you are wrong. The Stargates do suck things in... Gently. because in one episode, they place something in mid-air halfway into the eventhorizon and let go.. the thing stayed in mid air and was slowly consumed by the stargate. But hey, it doesn't matter, it does not do this in ALL cases[/QUOTE] What episode?

[QUOTE=DieHardDeus;13240573]What episode?[/QUOTE] I think when the doc died and they placed a flower thingy in the gate (Sorry dunno how it is called).

[QUOTE=kevkev;13246087]I think when the doc died and they placed a flower thingy in the gate (Sorry dunno how it is called).[/QUOTE] Yeah the wreath. There was also an episode in Sg-1 (I think when Apophis dies?) and they the body like half-way in the gate and it gets sucked in the rest of the way. So either the gate nullifies friction and/or gravity or it was some discontinuity and the gate sucks objects in. Contradiction to the pulling of objects would be from the atlantis episode(38 minutes) when the puddlejumper gets stuck in the gate and when they finally retract the engine pods it just sits there, not pulling. If the gate just nullifies friction and/or gravity then it still makes sense. I mean hell, the gate can even distinguish a body of water or atmosphere from an object that wants to go through the gate... nifty stuff.

If you we going through in some kind of contraption, and (for example) the thrusters that power it go through the event horizon first, would they still function? If not, then the pulling effect would be a good thing to have, avoids you getting stuck.

Well, according to the show, no they shouldnt work... But in the case of this, why dont you make it "nullify" the gravity and maintain velocities through the gates, hense you can thrust towards the gate and when you touch the eventhorizon your contraption will carry on flying in that direction at the same speed, but also add the pulling effect, so if your hoverballs go into the EH first, then your contraption will not suddenly fall out of the air (like the wreath not falling to the floor)

[QUOTE=GenXCypher;13248995]Well, according to the show, no they shouldnt work... But in the case of this, why dont you make it "nullify" the gravity and maintain velocities through the gates, hense you can thrust towards the gate and when you touch the eventhorizon your contraption will carry on flying in that direction at the same speed, but also add the pulling effect, so if your hoverballs go into the EH first, then your contraption will not suddenly fall out of the air (like the wreath not falling to the floor)[/QUOTE] Actually it would make sense that anything that is inside but yet dematerialized could exert forces and help get the object inside, if someone puts their arm in they can still move it inside, it doesn't suddenly lose strength or movement. Thats why they can still feel it and what not. Then in other episodes this is contradicted (38 minutes) where the people who are fully submerged can't do jack squat. In this case going into the gate doesn't do much to the props, they just lose gravity and the pulling takes effect (they don't really enter some time/space dematerialization bay), so yes the speed of the object is maintained. Speedy thing goes in and the speedy object comes out, hopefully. I might have to tweak the way it comes out of the other gate, to account for unexplained possibilities in stargate.

[QUOTE=GenXCypher;13235871]Actually, you are wrong. The Stargates do suck things in... Gently. because in one episode, they place something in mid-air halfway into the eventhorizon and let go.. the thing stayed in mid air and was slowly consumed by the stargate. But hey, it doesn't matter, it does not do this in ALL cases[/QUOTE] Don't forget the submarine episode ;)

Also, it might be necessary to put props in a different collision group once touching/through the event horizon, so they can't collide with the world (for example, if the gate is up against a wall).

[QUOTE=Hysteria100;13254796]Also, it might be necessary to put props in a different collision group once touching/through the event horizon, so they can't collide with the world (for example, if the gate is up against a wall).[/QUOTE] Yep, they can always go into collision group none if the need arises. Still trying to prevent gate clipping though.

In Season 2 or something, when SG1 goes to a planet and [sp] Apophis gets "killed" later in the episode. Teal'c then gets his "dead" body and puts his legs through the gate, his body gets slowly sucked in.[/sp] [quote=ZeikJT]Yeah the wreath. There was also an episode in Sg-1 (I think when Apophis dies?) and they the body like half-way in the gate and it gets sucked in the rest of the way. So either the gate nullifies friction and/or gravity or it was some discontinuity and the gate sucks objects in. Contradiction to the pulling of objects would be from the atlantis episode(38 minutes) when the puddlejumper gets stuck in the gate and when they finally retract the engine pods it just sits there, not pulling. If the gate just nullifies friction and/or gravity then it still makes sense. I mean hell, the gate can even distinguish a body of water or atmosphere from an object that wants to go through the gate... nifty stuff.[/quote] I was a little late.

Any updates?

Looking pretty damn good!

[QUOTE=DieHardDeus;13304575]Any updates?[/QUOTE] Progress is going slowly. I've yet to implement some kind of nocollide detection, right now if it has a constraint of any kind if won't react unless the whole contraption has gone past the event horizon. I have to add a player check to see if the player is attached to anything, such as a chair, and make it wait before transporting. Maybe add some effects for the player to see. Then the problem I've been trying to deal with since I first posted this. How to stop entities from clipping through the gate. Could I add an entity event hook to detect if the entity touching the gate is supposed to collide somehow? Then again, I'd have to reconfigure this SENT and merge it with the current stargate before I could even fathom attempting this. I'm basically just waiting to see what aVoN makes of it. If he wants to incorporate it then it shouldn't be too hard (he doesn't sound like he would appreciate it if I did it for him, and it is his code so I will respect that). That and the fact that school is starting is really cramping my time for any dev work. If there are any developments I'll be sure you guys know.

will it be a part of the stargate pack? when do you release it?

As soon as there is some way to correctly disable the collision only between specific props.

any chance that this will be compatible with the supergate? just asking because i want to send big ships through with the same effect :V: i like the idea and where it is going, its much better than the cheezy, 1 prop slightly touches the horizon and the entire thing dissapears and reapears at destination, as well as the fact that you can currently simply take any size of prop or contraption, sling it directly at an open gate and it will go through...

i'm prety sure that most props have to at least be half way in to be teleported, because no matter how i lok a this, whenever i try to put a sbmp prop through a gate, it doesnt go anywhere (except out the back of the gate xD) Any joy with the EH Zeik???? or are you still stuck on the slight no-clip-with-gate snag???

@GenXCypher: try picking it up with physgun (the prop) and then literally throwing something bigger than the stargate at the stargate... if all goes well, it will go through...

Is this project dead?

I'd like to hope it's not dead. It's just the same snag I've hit over and over. I can't get props to collide with what I want, and nocollide with what I want. They either collide or not. Methods I've tried: 1.) Changing the collision group --Problems: It won't collide with other things, including the gates and I have no control really 2.) Dynamically replacing the entity's touch functions --Problems: As soon as two objects touch it's too late to do a nocollide (the engine remembers the hit surface) 3.) Not nocolliding entities at all. --Problems: An object behind the gate can stop the entering entity from going through If I released the code do you guys think you could help?

Probably not, but you should release it anyway... :P To tell you the truth, I have no idea. Will it add on to the current gates? Or will it be a separate entity...?

It is currently a completely separate SENT. It is just one entity and doesn't 'link' up to any others. You put stuff in it, and when they go all the way 'through' then it gets deleted. The code is actually relatively simple. Oh and I remembered another problem, the method for clipping I'm using (with Jinto's module) only allows one clip plane so if you put an object between two gates weird shit can happen. I think I know how to fix this, but it won't be too neat code-wise. I'll look into some quick and dirty fixes for the collision problem even though I've tried pretty much everything I could think of (except maybe the gm_guardian module; I would hate to have TWO dll dependencies in one addon). If I still can't find any good solutions then I'll just throw what I do have done out there for people to play with.