[RandomTiger]

Cool I see your point. It usually helps if a change idea is backed up by a reason, means we know that it might get used it we do it.

I would have thought TBP would move to fs2_open fairly soon given the features that Bob is putting in it.

[EdrickV]

Is anyone working on an end-mission SEXP? I would if I could but I can't so I won't.

But I do think the code I posted above (the one that starts: // we have a special debriefing screen for multiplayer furballs) will do the trick if you can code a SEXP to put that code into. And it should be compatable with single player and multi-player.

[Fury]

I think end-mission sexp has been already done.

[Sesquipedalian]

Originally posted by Mr. Fury


Huh?
I think it is wonderful if you can change a ship's AI level on the fly. Fredders surely appreciates that.

I meant that it had proven to be beyond my abilities.  Making the shields-on and shields-off sexps was more or less just a matter of copying the code that ship-invulnerable and ship-vulnerable use, and changing the flag that is referenced.  Pretty simple once I found my way around (it was my first time going into the code).  

Making a change-ai-level sexp is a whole other ballgame, in that the assignment of an ai class to a ship is not a simple and straightforward process like putting a flag on a ship is.  First, I found a bunch of different snippets of code that looked promising, but not knowing much (read: anything) about C itself, I can only partially understand what exactly is going on in each one and how they differ, and thus cannot figure out which one I should use.  Secondly, since there is no similar sexp to base it off of, I would have to invent the function code myself, and that is a task for which I am woefully unsuited.

Originally posted by RandomTiger
Why would you need that?

Play-balancing would become much, much more exact.  There have been numerous times when I have been making a mission and found that the AI class I want on a wing of fighters at one point in time to keep things balanced is not what I want at another point.  

Say Aries wing is attacking Alpha.  If I want to give Alpha 1 a challenge, Aries better have a high level AI class.  But then if the rest of Alpha wing is to have a hope in hell of surviving, they also need a high AI class.  Now imagine that later in the mission Alpha needs to pick off some bombers.  Even if the AI class of the bombers is also set to General, it is entirely likely that Alpha will have too easy a time doing this, and either more bombers or better escorts, or both, or who knows what will be necessary to keep up the challenge.  But this process can be very finicky; it doesn't take a lot to overcompensate when your only solution is to throw more bad guys into the pot.  An alteration of AI class would give a precision to all this that is currently lacking.

[EdrickV]

I can see why you found that task daunting. There are at least 2 ints and 1 struct all called ai_class. (How the struct and ints manage not to conflict is beyond me.) And then there's the weapon ai stuff, which you can set in FRED2 but which may not be actually used and which I haven't looked at today. (Though I thought I saw some code setting the weapon ai stuff from the ship ai stuff.) The problem isn't figuring out how to change it, it's figuring out what needs changing.

[IceFire]

Originally posted by RandomTiger
I would have thought TBP would move to fs2_open fairly soon given the features that Bob is putting in it.

We will.  I'm not sure if current releases feature all that Bobboau has put in there yet...but stuff like the warp POF and the sliding will be of major use to us.  The other thing is that it sounds like current releases aren't stable yet.  ATM I'm still using FS2's retail EXE with a FS2 Open test EXE in another DIR for use every once in a while.

When releases are stable, and I've fixed up TBP's tables a bit...AND when Release 2 is finished, TBP will start fully supporting FS2 Source releases.

[Fury]

But there is a slight negative effect for fans as well...

They need to periodically check for new versions of fs2_open, for bug fixes or feature additions.

To make this as easy as possible, it would be kind of you to make an updater program. It could be seperate, it reads the version number of currently installed fs2_open and then checks if there's new version available.

If I am not mistaken, all mods should use one and same modified exe. At least in my opinion they should, it makes things a bit simpler. And if the modding team does have an experienced coder that could make specialized exe for certain team, why this coder can't work for SCP? This would benefit everyone and not just single team/mod.

Oh, I am just ranting here again. Probably you have this covered in theory at least.

[EdrickV]

Only seperate exe's I can think of are various test versions, (usually featuring things for people to bug test that aren't in the latest release) and the Robotech MOD's exe, which hasn't been released and we want to get our changes merged into (or rather rebuilt within) fs2_open. (Ronin started the RT MOD one from the freespace2_public source.)

[Sesquipedalian]

Originally posted by EdrickV
I can see why you found that task daunting. There are at least 2 ints and 1 struct all called ai_class. (How the struct and ints manage not to conflict is beyond me.) And then there's the weapon ai stuff, which you can set in FRED2 but which may not be actually used and which I haven't looked at today. (Though I thought I saw some code setting the weapon ai stuff from the ship ai stuff.) The problem isn't figuring out how to change it, it's figuring out what needs changing.

Exactly.  "Do I want this one, or that one, or that one?!" I said to myself, "Yargh!!!  Run away, run away!"

[Sesquipedalian]

My bet is on this one, from parse_object() in missionparse.cpp

Code: [Select]

if ( optional_string("+AI Class:")) {
objp->ai_class = match_and_stuff(F_NAME, Ai_class_names, Num_ai_classes, "AI class");
Assert(objp->ai_class > -1 );
} else {
objp->ai_class = Ship_info[objp->ship_class].ai_class;
}


Of all the options, objp->ai_class = match_and_stuff(F_NAME, Ai_class_names, Num_ai_classes, "AI class"); seems the one most directly relevant to taking some external data and hooking it into the ship.  But how to implement it is another question, at least for know-nothings like me.  

Assuming this one works, we need to set up some code that will first reference the ai.tbl and retrieve the valid options in it(Coward, Captain, General, etc.), then compare them with the value actually entered as an argument of the sexp to ensure it is valid (returning an Int3() or whatever otherwise).  Then I'm going to guess the (F_NAME, Ai_class_names, Num_ai_classes, "AI class") bits of objp->ai_class = match_and_stuff(F_NAME, Ai_class_names, Num_ai_classes, "AI class"); will have to be modified somewhat.  Also, somewhere along the way Fred will have to know to retrieve the info from ai.tbl just so that the Fredder will only be given the valid options to begin with.

The one thing about this bit of code is that parse_object() ultimately ends with creating an object, not modifying it, so I don't know what difference that might make, if any.