[Inquisitor]

Nuke: This is a good example of why some structure to idea submissions is a good idea

You had to reply 3 times before everyone finally understood where you were going

Just a friendly chide

[Nuke]

to all of those who whant to keep reverse compatability:

i can only die in a supernova (or do the greedy thing and escape) so many times. next time i do it i will go insane. we need a new engine for a new story.

[Sesquipedalian]

Originally posted by Nuke
to all of those who whant to keep reverse compatability:

i can only die in a supernova (or do the greedy thing and escape) so many times. next time i do it i will go insane. we need a new engine for a new story.

Umm, not to be rude, but is there a train of thought here, or just some disconnected cars randomly ranging along the tracks?

[LAW ENFORCER]

I belive it started as a good point but his rage and near insanity at replaying the same FS2 plot over and over and over...(while (1) ) again.

Anyway, I think you should make a 'gloabl mission attributes editor' and include that and a load of other stuff in there to make mission wide chages in a button click...

edit - lost my train of though on first para, episode contiues***
made him write jibberish.

[Nuke]

near insanity my (_|_)!

[Bobboau]

we shouldn't break backwards compatability if we don't have to

[Nuke]

we dont have too, but many panicky people think we cant increase the table limit without breaking backwords compatability.

a couple more things i need, a bigger explosion limit, and a bigger thruster flame limit.

[DTP]

the reason why some ppl cant use rasied Tbl limits for example are that they have very little Swap file storage place.

mine is set to 200 MB no mather what. unless i have to do some Big building of some memory hungry prog.

i took out ram so I only had 64 mb of sd-ram and my raised limits still ran like a charm.

so, im sure this has to do with poor memory management.

[Bobboau]

raising table limet wouldn't break bakward compatability unless you made some change that was needed in the table that isn't there now

[vadar_1]

Beams should be locked by default. If they are not, a ship would fire them out of nowhere when it is emerging from subspace. IE: any point of the ship that is still "in subspace" would fire its beams behind the subspace node, seemingly from nowhere. I can't beleave people are so lazy that they cant beam-free-all everyship that emerges from subspace. If you have stupid "frenzy" missions, then you deserve to be shot. You don't need of beam-capable warships. Learn how to design missions before you babble ideas like this.

[LAW ENFORCER]

Thats the stupiest post I have ever seen! I [will] use fighter beams (turret not primary) bomber beams and beams on nearly all of my craft - and with 20 plus fighters/bobmers and 10 plus caps per mission (not a frenzy - good computer and balanced play (not my Alpha and Beta tests!)) it takes hours to get every thing beam wise working the way I want most of it is in testing weather beams hae been enabled properly. (and large changes mean hours of debuging and retesting) I want an editor that can do all this in one click - on or off, exceptions by sexps.

Also disabling turrets and all weapons inside subspace is on my wanted code list.

[Bobboau]

well makeing fighters/bombers beam freed by defalt wouldn't have and backward compatability issues, but I still think it would be best for beam free to be an inital status thing, it would take less effort to set this than would selecting wich beam you wanted to be on a turret, and it would be caried along with waves, and it wouldn't give everyone who makes missions now go nuts by haveing to lock beams on all ships they don't want them to be free on (wich would be most of them).

how does this sound, we make it be an inital status for all ships type thing, but we add a button in, say, the mission property box that will set the inital status so that all beams will be free for all  ships

[DTP]

i think initial status is better, if it can be done,.

just add a check in the code and no need for it in SEXP so that no ship can fire if its "event" of leaving subspace is not over.

[EdrickV]

I think there are two things that could be used to make it easier to turn a ship's beams on:

1. On a per ship basis you would select a checkbox labled something like "ship beams free" that would result in that ship's beams being turned on after it entered just like the SEXP would.

2. On a per mission basis you could turn beams on for all ships in that mission that carry them. Each ship's beams would get turned on once they entered, just as if you'd used the SEXP.

Both methods IMHO are possible and could be useful. You could even put both of them in and just have 2 take precedence over 1. And, if those check boxes were not checked by default, it would not break backwards compatability. Method 1 and the existing SEXP both have one limitation that I have seen in other SEXPs: They would only work on the first wave of ships. That isn't usually a big thing for cap ships since they usually aren't in wings with multiple waves, but when you have a wing with 3 waves of beam carrying fighters/bombers then it makes a difference. Only the first wave would have their beams turned on.

[JudgeMental]

OK, I'm having a REALLY hard time seeing how making beams free by default would break backward compatability.

I thought that it was FRED that had the beams locked by default, NOT the game.  In other words, I don't think that the FS2 exe has anything to do with beamfree, but that the FRED exe has everything to do with it.

For example, a mission has its beams locked by default (because nobody freed them in FRED 2.0, the beamlocked version).  You change to FRED 2.1 (beams FREED version), but the missions themselves don't change.  Thus, the game reads them the same way, and the beams that were locked before, stay locked, and vice versa.

I hope I'm making sense...

But I think the best way to go about it would be to have a "beam enabled" toggle box next to each beam cannon in the initial status display.  If you want to enable or disable any of them later, use SEXPS.

It's like the sabotage SEXP.  You don't use it when you want a ship to start out damaged, you use the initial status display.

Wait, I just had a brain wave.  In addition to (or instead of) a check box for the beamfrees, have an entry box to enter a time delay, just in case you want this ship to me emerging from subspace sometime in the game.

Just a few thought by lil ol' me:-P

[Fury]

For example, FS2 main campaign first mission, where GVD Psamtik destroys the NTF Deimos corvette.

The original beam default value is disabled.
If we change this to enabled, then GVD Psamtik will immadiately open fire, it won't wait till conversation is over.

This breaks backwards compatibility. So instead we will have a mission specific and ship specific initial status checkbox.

Mission specific will automatically free every beam once the ship has arrived. Ship specific checkbox will enable this particular ship's beams once this ship has arrived.

This won't break backwards compatibility, as the FS2 main campaign first mission now reads the mission and ship specific checboxes unchecked and behaves as intended by events.

[JudgeMental]

Oh, I understand how having ALL the beams in the game freed would screw it up, but I was refering to something slightly different.

I thought that the mission files controlled whether the beams were locked or not.  That means that changing the default status to beams freed would only affect missions made in the "enhanced" version of FRED (I think I'll refer to the beamfree version of FRED as FRED 2.1 from now on).  The original missions would still be the same.

In other words, I don't think that the game engine decides whether the beams are freed or not, so I doubt you'd even find that setting in the engine source.  However, I would think that, because it writes the missions, you would find the beamlock-default setting in the FRED source.  Changing that would only effect new missions, NOT the old ones where the tags already indicate the beams as locked.

Grrrr, I don't think I'm making sense...

The only thing I could think of might be in reading the FRED 2.1 missions in the original FRED install.  I can think of some ways around it though.