[General Battuta]

Beam fade breaks missions. Nobody else has a problem with this?

I know that Fury doesn't believe the MVPs should support mods, but changing a weapon's effective range is huge. The MVPs could not get away with that on something like the Harpoon or Treb. Why can they do it with beams?

[mjn.mixael]

Yeah.. I'm not a fan of breaking missions.. nor the effect...

[blowfish]

Beam fade breaks missions. Nobody else has a problem with this?

This is actually my main problem with it.  It didn't matter in the context of Blue Planet, but now that this is in mediavp territory, it's a serious issue.

The MVPs could not get away with that on something like the Harpoon or Treb. Why can they do it with beams?

Supposedly because beams have a targeting range that is much lower than 30km.  It still breaks a lot of fire-beam sexps and tag scenarios though.

If a solution can be implemented (obviously via code changes) which can cause the beams to fade without breaking balance, then maybe this is acceptable (though then you'd have the problem of beams damaging things beyond where they disappear).  But for now, these types of things should probably stay how they are in retail.

[Spoon]

I'm with the General on this one.

[Fury]

MVP's have not changed beams targeting range at all. Hence it doesn't affect retail missions. If some mod missions have just so happened to use fire-beam-sexp to use a beam past its targeting range, is something I don't really think should be of any concern to MVP's. How much FSU is willing to bother themselves over trivial concerns like that, is up to them. But I think it's silly.

Mods on the other hand can easily get around it by extending beam range across the board if they want to, create custom beam weapon entry for the occasion or just keep using .10's.

Not gonna bother with this further though, what FSU does with beams is their business.

[Polpolion]

what FSU does with beams is their business.

why the FSU is under the community projects category, again?

EDIT: Maybe I'm just an absolute moron, but I'd hope that FSU would kind of... not disregard users.

[NGTM-1R]

To summarize: Fury says **** you community!

[pecenipicek]

what disturbs me more than the beams is the flashy deaths on almost everything that blows up with a blast warning.


and i find it utterly unneccesary in the MVP's. BP is okay, but keep fun mod stuff out of MVP's.



(no offense to anyone...)

[Solatar]

So mods that make creative use of RETAIL data (fire-beam sexps and tag scenarios) get pushed to the side because they don't use that data in the way that V did?  Making every MOD compatible with mediavps could get tough, but a mission made with retail data should be compatible.  Why should I have to distribute a campaign as a mod folder when it SHOULD work with just normal, upgraded Freespace 2?

I wouldn't have bothered posting, but I feel like I'm seeing the beginnings of a very insular FSU Project in some comments here.  I know for purely logistics reasons - so there aren't too many chiefs and no Indians - much of it has to be done behind closed doors, but completely disregarding community content goes against everything that has made this community last for so long.

[Cyker]

30K beams looks a bit silly, but the beam fade looks much worse.

Most of the time I don't normally notice the beam fade (Usually because I'm trying not to die ), but when I do it just looks horrible

I do hate the bomb flash, but I hate all the white-out effects (e.g. looking at a tiny distant sun and *BLINDED*)

[NGTM-1R]

I have to agree with Solatar. Anything in MVPs that would break a mission that is completely constructed from retail components does not belong.

[The E]

I fully agree with Solatar and NGTM-1R on this issue.

[MatthTheGeek]

Now that the potential mission-breaking behavior has been pointed out, I have to agree that having those fading beams without a better control of the fade is a bad idea, at least in the MVPs. Not letting ourselves get stopped by constant backward compatibility is good, but that feature seems to have too much of mission breaking potential to be left as-is.

But I still stand on my point that beams MUST fade, and I have yet to read a single argument strong enough to even begin of convincing me of the contrary. SCP guys just have to find a way to have this feature working alongside an out-of-range fire-beam sexp... somehow.

[pecenipicek]

simple. fire-beam fires a beam at a target. add an option to the sexp to determine fade length. backwards compatible and works.




now, this is a really nice thing to have in the engine, but we need an entry for beam weapons in the weapons.tbl like such:

Beam targeting range = range at which a beam can acquire a target and fire at it
Beam dissipation range = range at which the beam starts to dissipate
Dissipation length = determines how long the dissipation continues after the beam crosses the dissipation range

the distance of the first two is measured from the firing point of the turret till the end of the beam, the dissipation length is measured from the point where dissipation range ends and continues for how many meters the modder decides to put in.

[Qent]

simple. fire-beam fires a beam at a target. add an option to the sexp to determine fade length. backwards compatible and works.

I don't feel good about this for some reason.

now, this is a really nice thing to have in the engine, but we need an entry for beam weapons in the weapons.tbl like such:

Beam targeting range = range at which a beam can acquire a target and fire at it
Beam dissipation range = range at which the beam starts to dissipate
Dissipation length = determines how long the dissipation continues after the beam crosses the dissipation range

the distance of the first two is measured from the firing point of the turret till the end of the beam, the dissipation length is measured from the point where dissipation range ends and continues for how many meters the modder decides to put in.

That first one is already in as +Weapon Range. For the last two I think it would be better to mirror the current +Range and +Attenuation values in $BeamInfo: let +Visible Range be the distance in meters from the firing point at which the beam is completely invisible, and +Visible Attenuation be the fraction of the visible range at which dissipation starts.

Still, I like the visual effect of beams extending infinitely into space, except maybe under very special circumstances.

EDIT: I forgot some way to make the visible beam actually extend into infinity. Maybe if the visible range is negative?

[sigtau]

Beam fading is really a weird looking effect, and anyone who says 50k long beams look even stranger is sadly mistaken, because it looks like they're going off into deep space that way and not up close (which, again, looks extremely strange).

My two cents.

[Syder]

Will somebody please post a pic of this effect, cause I've never seen it/heard about it before.

I think that a beam should dissipate while extending infinitely - well that is a beam after all, thing that consists of tiny little thingies, that use to travel 300 000 klicks per second.

[Mongoose]

I fully agree with Solatar and NGTM-1R on this issue.

As do I.  Any individual mission designed to run on retail data should work exactly the same way using the MediaVPs.  No exceptions.  I find this whole philosophy Fury has been espousing of the MVPs needing to be compatible with retail missions and nothing else to be rather absurd and potentially dangerous, and we're already seeing the latter concern be justified here.

What I really can't understand is why a decision like this was implemented unilaterally.  The FSU project isn't some sort of benevolent dictatorship.  I can distinctly remember moments in the past where the community as a whole was asked to vote on which version of an effect to include in the MediaVPs, or on different options for an individual model.  Where was that process this time?

[The E]

There's a fine line here. In some cases, MediaVP assets will break with retail traditions. For example, mapping schemes for some models may change when they are HTLed (See Lilith, Cain and Hatshepsut for recent examples). Those are changes that, I think, everyone can accept.

However, when it comes to changes that alter significant aspects of the FS2 gameplay, we as the FSU have a responsibility to maintain retail compatibility.

It's simple, really. As Mongoose said, a mission or campaign made for retail should work, without alterations, when using the mediavps. This extends to stuff like the beam fading under discussion here; the endless beams are a significant aspect of FS2's gameplay (whether the retail campaign uses it or not), and as such should not be altered.

[swashmebuckle]

The end has come.  Before the final jump, there was still a hope that it was only our ships or our nodes or our resources that they wanted, not our people, but now that hope is gone.  It slides out of subspace, enormous, engorged with a horrible power pulsating beneath its shining alien skin.  The Lucifer.

It glides lightly towards us.  It is not like a Terran vessel, bound by treaty and ideology and humanity.  It will not hesitate to take everything that we have, everything that we are.  There is nothing we can do but watch as it draws from its bottomless reserves, preparing to end us without thought or meaning.  Blasts of incomparable destruction stream forth from the the vessel's potent prongs, expending the energy of a thousand fusion weapons in a second.  The Emperor, watching from afar, intones the sacred royal funerary chant for his race's lost home. 

Then a miracle happens.  The impossible columns of death peter out a pathetic six kilometers from their points of origin, the energy dissipated long before reaching the furthest reaches of the atmosphere.  Vasuda Prime is saved by free space!  Elated sand eating bookies collect a surprising windfall of cash from gullible Terran gamblers, while the younger generation exchanges high-threes and fist-bups!

The destroyer hangs silently in the void, its glow maps turning a shade of green.  It broadcasts a short signal before slinking back into subspace, never to call again.  Years later a team of Terran and Vasudan cryptographers translate the Shivans' message as "Sorry, we've had a rough week.  You know, this happens to a lot of guys..."