Beam fusion

New Member
✔️ HL Verified
Joined
Jun 19, 2009
Messages
124
Best answers
0
Is it possible? Like when standing next to your partner and you both shoot a beam at roughly the same time, can the two energy beams fuse into a more potent one? Say two weaker fighters are on a team going 2v1 against a stronger opponent, let's say goten and trunks vs super buu, buu blasts a huge energy beam at them, but they counter it with two beams that fuse before the clash making the initial beam larger and allowing goten and trunks to continue pumping energy into the beam.

Is it AT ALL possible? I'm thinking not, probably has something to do with having to swap out the two beams with a new model in its place etc, therefore making it a waste of time to make in the long run.

I also searched the forum and found nothing on this, but I'm not 100% sure i'm the first poster on this topic xP

Anyways tell me what you think? :D

Also another quick idea, going super saiyan in a beam clash? not possible right? bummer D:
 
Freelance Mappzor
✔️ HL Verified
🚂 Steam Linked
💻 Oldtimer
Joined
Nov 21, 2003
Messages
17,065
Best answers
0
Is it possible? Yes

Is it probable? No

Adding a whole new system that reworks the beam system itself for nothing more than a visual gain would be a waste of time ATM. So youll have to be happy with a 3 way PS.
 
Only go forward sideways
✔️ HL Verified
🚂 Steam Linked
🎈 Advanced
Joined
Apr 24, 2010
Messages
482
Best answers
0
But the Super Sayian transformation during a PS is definitely possible I should think since it is possible in the current versions of esf as far as I've seen in the tutorial posted on esf-world, I havent actually tried it yet :p
 
New Member
✔️ HL Verified
Joined
Jun 19, 2009
Messages
124
Best answers
0
Oh wow didn't think it would be possible :p

Yeah I'm happy with the current way PS are, just a thought ^^

More looking forward to playing around a bit with the new melee system more than anything..
 
Freelance Mappzor
✔️ HL Verified
🚂 Steam Linked
💻 Oldtimer
Joined
Nov 21, 2003
Messages
17,065
Best answers
0
Oh wow didn't think it would be possible :p

Yeah I'm happy with the current way PS are, just a thought ^^

More looking forward to playing around a bit with the new melee system more than anything..
From a coding sense of view it would be something like this

Code:
If(client1.shootbeam() && client2.shootbeam() && distance(client1, client2) <= 100 && delay(client1, client2) <= 0.2)
{
removebeam(client1, client2);
beamfuse(client1, client2);
{
Pretty much saying if client 1 and 2 fire a beam in close proximity within 0.2 seconds of one another, their beams get removed and replaced by a fused beam. The question would only be who to give control for the fused beam.

And thats where the main issue lies.

Though adding all those extra checks and stuff so that 1 player can sit back and watch while the other takes control of his beam and tries to shoot someone with it is both a waste of coding and FX time not to mention bad for gameplay to strand a player unable to do anything while someone else aims his beam.
 
Resting in H.E.L.L
Banned
💻 Oldtimer
Joined
Jun 9, 2009
Messages
1,328
Best answers
0
They both aim it.

Make it like a PS, but between the two people, while aiming.

:p
 
Freelance Mappzor
✔️ HL Verified
🚂 Steam Linked
💻 Oldtimer
Joined
Nov 21, 2003
Messages
17,065
Best answers
0
They both aim it.

Make it like a PS, but between the two people, while aiming.

:p
One looks left and the other to the right. One used beam lock on, the other doesnt. What then?
 
Resting in H.E.L.L
Banned
💻 Oldtimer
Joined
Jun 9, 2009
Messages
1,328
Best answers
0
It jitters back in forth, kinda like Special beam cannon. Forces people to work in tandem.
 
Member
🚂 Steam Linked
🎈 Advanced
Joined
Dec 22, 2007
Messages
259
Best answers
0
Why not give the control to the first player who shot the beam? i think its the logic way to go, since the other player would be like just adding more power to the first beam.
 
New Member
Joined
Nov 24, 2001
Messages
692
Best answers
0
From a coding sense of view it would be something like this

Code:
If(client1.shootbeam() && client2.shootbeam() && distance(client1, client2) <= 100 && delay(client1, client2) <= 0.2)
{
removebeam(client1, client2);
beamfuse(client1, client2);
{
Pretty much saying if client 1 and 2 fire a beam in close proximity within 0.2 seconds of one another, their beams get removed and replaced by a fused beam. The question would only be who to give control for the fused beam.

And thats where the main issue lies.

Though adding all those extra checks and stuff so that 1 player can sit back and watch while the other takes control of his beam and tries to shoot someone with it is both a waste of coding and FX time not to mention bad for gameplay to strand a player unable to do anything while someone else aims his beam.
Yes, except that that's wrong and that there is another gazillion extra issues:
- You probably only want to fuse beams that are actually going into a similar direction
- You probably only want to fuse with beams from team mates
- Distance between 'clients' is not very informative, you'd like to know the distance between their beams instead, similar argument for 'delay'
- You need to keep track of the 'delay so far' somewhere
- What about balls/detached beams?
- What should the fused beam and all of its fx look like?
- What happens if one of the players detonates?
- Removing a beam from a player and replacing it with a fused beam is not some trivial matter
- etc etc
 
Freelance Mappzor
✔️ HL Verified
🚂 Steam Linked
💻 Oldtimer
Joined
Nov 21, 2003
Messages
17,065
Best answers
0
Yes, except that that's wrong and that there is another gazillion extra issues:
- You probably only want to fuse beams that are actually going into a similar direction
- You probably only want to fuse with beams from team mates
- Distance between 'clients' is not very informative, you'd like to know the distance between their beams instead, similar argument for 'delay'
- You need to keep track of the 'delay so far' somewhere
- What about balls/detached beams?
- What should the fused beam and all of its fx look like?
- What happens if one of the players detonates?
- Removing a beam from a player and replacing it with a fused beam is not some trivial matter
- etc etc
Hars i know that. What i posted was an overly simplified implementation example.

And i also wrote this remember

Though adding all those extra checks and stuff so that 1 player can sit back and watch while the other takes control of his beam and tries to shoot someone with it is both a waste of coding and FX time not to mention bad for gameplay to strand a player unable to do anything while someone else aims his beam.
 
New Member
Joined
Nov 24, 2001
Messages
692
Best answers
0
Hars i know that. What i posted was an overly simplified implementation example.

And i also wrote this remember
Yes, I'm just saying that you shouldn't post code examples that are conceptually iffy and oversimplified in some aspects and over specified in other (why only expand the collision detection algorithm between the beams, but not the actual fusion??). It suggests that we can implement beam fusion in three lines of code, but that we're just too lazy to do so.
 
NOT IN THE MANGA™
★ Black Lounger ★
✔️ HL Verified
🚂 Steam Linked
💻 Oldtimer
Joined
Jan 5, 2008
Messages
3,276
Best answers
0
Well,

on PowerStruggleStart
check BeamType
check ClientTeam
check BeamDirection
FuseBeamHeads
disable BeamDetonation

on PlayerDamage
check InFusedBeam
DefuseBeamHeads
 
Last edited:
Freelance Mappzor
✔️ HL Verified
🚂 Steam Linked
💻 Oldtimer
Joined
Nov 21, 2003
Messages
17,065
Best answers
0
Yes, I'm just saying that you shouldn't post code examples that are conceptually iffy and oversimplified in some aspects and over specified in other (why only expand the collision detection algorithm between the beams, but not the actual fusion??). It suggests that we can implement beam fusion in three lines of code, but that we're just too lazy to do so.
If thats all the beef you have with it then im glad XD

And yes i know its oversimplified, thats why i did it. Do you REALLY think id post a code example going it out of my head on the forum and do all the 1000 lines that would be needed otherwhise?
 
New Member
Joined
Nov 24, 2001
Messages
692
Best answers
0
No, I'm suggesting that we should first resolve all design issues and lay out a proper design before throwing around pseudo code that either has implicit design decisions (in hlev's case) or is so simple that is uninformative at best and misleading at worst (in Grega's case).
 
Freelance Mappzor
✔️ HL Verified
🚂 Steam Linked
💻 Oldtimer
Joined
Nov 21, 2003
Messages
17,065
Best answers
0
No, I'm suggesting that we should first resolve all design issues and lay out a proper design before throwing around pseudo code that either has implicit design decisions (in hlev's case) or is so simple that is uninformative at best and misleading at worst (in Grega's case).
Fine ^^;

Sorry for posting iffy code examples.
 
Last edited:

Users who are viewing this thread

Top