Information from Mission to Outro

[h-]

The variable thing, it turns out, only works in the Mission Editor if you play the mission before the outro - if you go straight to the outro on loadup ofp it doesn't work.

You mean you played the mission in the editor and then 'played' only the outro in SP trying to use the variables saved while playing in the editor? And it wouldn't work?
It's probably because the editor mission very likely has a different entry in the object.sav (where the saveVar saves the variables) than the SP mission...

It should work also in SP and not just in the editor...
After all, a campaign is just a series of SP missions tied together with a descriprion.ext...

[macguba]

Not quite:  I created a little mission with a mission and an outro.     In the Mission editor the saveVar command worked for the outro providing I had already played the mission.   I suspect this was because the variable had to be initialised in some curious way.

However, when I exported the whole thing to single missions and played the mission followed by the outro, the variable did not work.

The important thing for me is that the savestatus thing did work, and that's what I need.   (The player's squad, or rather what's left of it, has a chopper extraction in the outro and I just wanted the numbers and weapons to be right.)     However, having come across the savevar thing, I'd like to get it sussed.     Use in savestatus to transfer varible-like information from the mission to outro is of course possible, but very inelegant.

The good news is that this of course allows you to have different outros for different numbered endings End#1, End#2, etc..

[Fishion]

Okay I made a mission to test this.
It seems it is possible via the saveVar thing to save Variables from
the Intro to the Mission, but not from the Mission to the Outro, which is strange.
I guess we have to use a GameLogic with a saveStatus to do that
*grummel*  

-Fishion

[Calamity]

My interest in this thread was the ability of passing info into a loose outro. And cripes I think I've got it!

I have a mission that I wanted to make several loosing outros, depending on what objectives were failed. It's an SP mission, so I've got some limits, as I've discovered here. Thanks to Fishion, Messiah, and most of all Macguba, I got an idea that works for me. Thank you Gentlemen, I stand on the shoulders of Giants!

My solution:
I used the health of a Game Logic to store information from the mission to the outro. Theoretically there are 10 or more bits of information each game logic can store!

It's a Hack I know, but I'll work with it until something better comes along.

I'm including a POC (Proof Of Concept) demo mission. It's not polished or anything. But I got the important stuff; I documented the Exit and TestCamer scripts. I know most of you guys have already answered this to your satisfaction and moved on. So, this is really for the next guy like me, so he won't have to go through my learning curve.

Thanks again guys!

Calamity out

[macguba]

I've already thought of this.   Well, actually, not of using a gamelogic, but of doing something like that.    

saveStatus does not appear to record whether a unit is alive or dead, only weapons & ammo, rating I think and probably other stuff like that.     I don't think it does setIdentity. ... but I had a LOT of comings and goings to make it work and I can't quite remember what works and what doesn't.   At one stage I even thought it did pass whether the unit was alive or dead, but in the end it wouldn't.     Anyway the point is that I need to pass whether the unit was alive or dead to the Outro.   I also need to pass the value of a couple of booleans from one to the other.

At the end of my mission a script (transfer.sqs) checks if the unit is alive or dead.   If it's dead, it gets a specific (and bizarre) ammo loadout.    The script also checks the booleans:  they check whether the loon in question should be in the outro at all so the process is just the same:  not in mission, he gets the bizarre ammo loadout.

At the start of the Outro another script (outroStart.sqs) checks the ammo loadout and deleteVehicles the loon if appropriate.    One little twist is that some of the other loons appeared dead in the Outro for no reason that I could figure out:  the Outro script had to have a setDammage 0 command to make sure that the ones that were supposed to be alive, really were alive.

I thought about writing a tute but I don't think we're quite there yet:  we need to understand this a bit better so I'm delighted somebody is picking up on it.

To communicate large numbers you could use several GLs with one as the units column, one as tens, one as hundreds, etc..   It is a bit cumbersome - well more so than using saveVar  ;D - but it works and once we figure out the best way of doing everthing and write it up it will be a nice little contribution to the community.      I've always hated getting onto that extraction chopper with the wrong number of loons and the wrong weapons.

I've attached a zip which has 3 files.     exit.sqs which is called automatically at the end of the mission:  transfer.sqs which is called manually at the end of the mission (the stuff in here should probably go in exit.sqs, it's only in a seperate file because that was more convenient at the time):  and outroStart.sqs which does the relevant stuff in the outro.    The whole mission is too big to attach, but you can grab it from here.

I'm off for some breakfast now but I'll look at your demo later.

[macguba]

Well I've just tested your demo and it clearly works.    And is more elegant that the method I used.   ;D   (But I'd have needed 10 GLs and in a mission that's already laggy, I don't want another 10 groups.   Well that's my story and I'm sticking to it.)

I forgot to add that I had problems with some magazines - some of them caused stupid problems.    Kozlice was one, there were others, can't remember exactly what went wrong but it stopped things from working.    The point is that this whoe thing is not just an easy fix:  in true "fickle Flashpoint" fashion it's all very temperamental.     Which is just what you expect from this game when you succeed in doing something it was designed not to do.