Author Topic: New Portal Gun - Finally added pictures!  (Read 7508 times)

aside from the main model improvements here are some of my thoughts for a revamped portal gun:

  • 1. ramp compatibility: should be able to spawn on ramps.
  • 2. dts portals: you should use a dts for the portal aside from the emitter stuff, like qwertyuiopias' portal gun. i have put reasoning behind this.
  • 3. multiple layers of detection zones: you should have different stages of detection. more than one layer at least. there is one larger zone that teleports if the player is at a certain velocity or higher. if they're slower, a smaller zone teleports them, and this goes on until passing through things seems non-teleporting-in-mid-air-etc
  • 4. picked-up objects MOUNT to you: objects that get picked up shouldn't hover in front of you, i think there should be a system that somehow MOUNTS the object to you, so if you're going through a portal, it's coming with you

directional things: some of the far more difficult things that i'm not sure are possible at all but whatever:

  • 5. portals consider direction for exiting players: directional changing. if you're going through a portal, you're going to come out pointing in the direction the other portal is facing, not some universal constant direction. this applies for up and down and etc.
  • 6. projectiles consider direction: projectiles shooting into portals should consider the direction the projectile went when it flew into the portal, not just flying out of the portal in a straight line upon exit
1. Hard to decide how to position a portal. I dunno if this is even possible.
2. DTS portals, possible.. However i think there is a reason for it to be not used yet.
3. I see why, this prevents falling to your death.
4. Urgh, i am pretty sure there is a way around, like that, but it is not being pretty i guess.
5. A player cannot go upside down or on his side without using tumble.
6. Pretty sure this IS possible and do-able.

By the way, Darkstar made the model.
Credit where it's due :u
Clearing portals was always there, and the one button for 2 portals? forget no.

Off topic: hai bit :D

On topic : Love the model, but bugs just ruin it. (Portals in portals? O_o)



-seizuresnip-
Oh man. I've seen that picture before! I love it! It makes me even more insane than I already am O_o

Portaling to the center of the map What do you mean by that?
Portaling through objects like bricks?
Portals in portals Are you planning on creating the gun from scratch? I'm fairly certain I could find something in the old pgun that prevented this.
and Floating portals oh stuff.
Did you use a function that makes sure the receiving object is:
NOT a player/bot
NOT a vehicle

By the way, the code that you might use/reference is here:
(I'm tired right now, so I ripped it from the old pgun)
for portals being placed on areas that aren't bricks or the map itself:
Code: [Select]
%class = %col.getClassName();

if(%class !$= "InteriorInstance" && %class !$= "StaticShape" && %class !$= "TSStatic" && %col.getClassName() !$= "fxDTSBrick" && %class !$= "TerrainBlock")
 {
  portalError(%pos,%obj.originPoint);
  return;
 }
That's from the projectile's ::OnCollision feature.
It pretty much checks if what the projectile collided with was anything other than:
-The map itself
-A brick

and then the portals in portals thing:
Code: [Select]
for(%i=0;%i<PortalGunCtrl.getCount();%i++)
 {
  %portal = PortalGunCtrl.getObject(%i);
  if(vectorDist(%portal.position,%pos) < 5 && %portal != %obj.sourceObject.portalOrange)
  {
   portalError(%pos,%obj.originPoint);
   return;
  }
 }
This is from the orange portal projectile's ::OnCollision code.
It checks if a portal has hit less than 5 units in radius(most players call them studs, i guess. unit = 1x1 brick) away from another portal, and if so, checks if it is NOT an orange portal. If it is a blue portal (basically, a portal that isn't orange), it spawns a portalError at the position of the projectile's collision point. Otherwise, it moves the portal, as seen here:
Code: [Select]
if(isObject(%obj.sourceObject.portalOrange)){%obj.sourceObject.portalOrange.delete();}

 %rot = -(getWord(%normal,1)) SPC -(getWord(%normal,0)) SPC getWord(%normal,2) SPC "90";
 %p = new ParticleEmitterNode()
 {
  datablock = genericEmitterNode;
  emitter = PGunOrangePortalEmitter;
  scale = "0.1 0.1 0.1";
  rotation = %rot;
  velocity = "1";
  client = %obj.client;
  position = vectorAdd(%pos,vectorScale(%normal,0.4));
  normal = %normal;
  sourceObject = %obj.sourceObject;
  colObject = %col;
  portalType = "Orange";
 };
 %obj.sourceObject.portalOrange = %p;
This checks if there's already an orange portal open, and if so, deletes it so another can be created. then it creates an emitter node at the projectile's collision location, and needless to say, a portal.

I mostly explained this in case anybody else couldn't read it. Besides, you learn more from reading if you say it "out loud"(or in this case, type it in English), and that helps me to learn how BL-Torque works a bit more.

Probably, you'll need to look at the script more in order to find out what everything equals. This should make a good reference, though.

Hopefully that helps.

you should also see the view of the first portal through the second portal and vice versa. this is possible if i'm correct.


you should also see the view of the first portal through the second portal and vice versa. this is possible if i'm correct.
I dunno who said this buuut.
That's not gonna be fun.

No he didn't.
Yes he did, I know. Is Brian saying he made them?

No he didn't.
Yeah, actually. Brian asked me to make a new model for him when he heard that I was making the player types.

you should also see the view of the first portal through the second portal and vice versa. this is possible if i'm correct.
I dunno who said this buuut.
That's not gonna be fun.
lordician's right.
Also, I'm pretty sure that at the most, you'd be able to see cubes and yourself(bot version).
And even that would require a stuffton of work.

Also
1. Hard to decide how to position a portal. I dunno if this is even possible. I think portals can only be positioned on the axis. That is, the grid. Even that glitches at some times.
2. DTS portals, possible.. However i think there is a reason for it to be not used yet.
3. I see why, this prevents falling to your death.
I think this idea was just to prevent the thing where you hit the ground before the portal moves you, causing you to lose velocity.
4. Urgh, i am pretty sure there is a way around, like that, but it is not being pretty i guess.Yeah...I doubt it looks any good.
5. A player cannot go upside down or on his side without using tumble. Titanium meant if the player comes at the portal from the side, I think. The current one sends you out in the direction the portal faces. If Titanium meant that it changes which way you're facing when you come out, hell, I don't know if that's possible.
6. Pretty sure this IS possible and do-able.

Also, does the portal gun have a pickup thing yet? If so, you should just make the light button attempt a pickup/fire off an OnActivate event(instead of changing modes)

Code: [Select]
  if(%colType & $TypeMasks::fxBrickObjectType && getSimTime() - %col.lastLaserActivateTime > 200)
   {
     %col.lastLaserActivateTime = getSimTime();
     $InputTarget_["Self"]   = %col;
     $InputTarget_["Player"] = %obj;
     $InputTarget_["Client"] = %obj.client;
     if($Server::LAN)
     {
        $InputTarget_["MiniGame"] = getMiniGameFromObject(%obj.client);
     }
     else
     {
        $InputTarget_["MiniGame"] = getMiniGameFromObject(%col);
     }
     %col.processInputEvent("onActivate", %obj.client);
   }
I grabbed that from the Laser Pointer, it pretty much fires an OnActivate trigger.
« Last Edit: July 04, 2011, 07:18:29 PM by Wheatley »

also this gun is bullstuff, the other one does the same things except it has no bugs.

also this gun is bullstuff, the other one does the same things except it has no bugs.
Please get out, troll.
We don't want you here.