Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Sesquipedalian on October 09, 2002, 08:20:32 pm
-
Just wondering, since no updated FRED2 version has been released (or if so, I missed it), what new SEXPs have been added, anyway?
-
no and none yet.
-
Actually, DTP released a new FRED soon after the intial source release, making the Run Freespace link on the file menu point to FS2.exe instead of FS.exe. Nothing new since then, AFAIK.
-
I have this bad habit of asking questions I later wish I had never asked...but since you brought up the topic of SEXP's...
What new SEXP's are wanted/needed?
Are there any mission features that are used repeatedly that require several SEXP's that might be worth creating a new SEXP(s) to do the same function(s)?
-
This has been mentioned before but I'm sure everyone would rather have an option to have the mission start out with every ship beam-free'd, or perhaps a 'beam-free' checkbox in the ship info button in FRED2, instead of having to type in SEXPs for everything.
-
we released a companion fred2, no new sexp's but stuff to support things liek the fighter beams and glow points.
I just realized that I never put a link on the warpcore site, bad me, I will fix that.
-
I don't think those two needed anything in fred, but some of the SSM things and texture tileing/translation for beams would give normal fred2 a tummy ache
-
how about a reset-sexp SEXP? basically it's if-, reset SEXP , so stuff like the Robotech TC could make a SEXP that changes ship form if you hit a key, and it wouldn't be single-use.
-
Bobboau: I actually forgot what WM added (ship trails and something else as it turned out), but i bumped the thread that he released it in.
http://www.hard-light.net/forums/index.php/topic,9581.0.html
-
Most important/popular requests (as best as I can remember) for sexps included:
Repairs to the following sexps (i.e. they don't actually work right now):- orders (meant to return true when a specific order has been given to wingmen)
- is-tagged (meant to return true whenever the ship in question is tagged. Different from has-been-tagged in that has-been-tagged returns true once, and stays that way ever afterwards, where is-tagged chages back and forth as the ship is tagged and the tag then wears off)
Addition of:- end-mission (Probably the most sought after new sexp. Automatically end the mission without red-alerting, so that one is taken to the debriefing even though one did not enter subspace)
- player-to-ai (Gives control of the player's ship to ai. This will need an opposite sexp as well. Proposed as a means of solving a number of issues)
-
Originally posted by Sesquipedalian
Addition of:- end-mission (Probably the most sought after new sexp. Automatically end the mission without red-alerting, so that one is taken to the debriefing even though one did not enter subspace)
[/B]
I have some crude but usable code for this one....although I haven;t been able to figure out how to get Borland to work to actually test the damn thing.... but the red_alert code already includes some commented out code that takes the player to a debrief if it's the last mission in a campaign...I think adapting this is piss easy, from the looks of it.
If someone gives me idiot-proof instrucitons on dling and installing a compiler, I'll try it out.
EDIT - here it is (midway down thread);
http://www.hard-light.net/forums/index.php/topic,8949.0.html
I intend to give the SC a bit of a try sometime - not sure when - but hopefully I could do this and maybe learn a bit of how the camera code works and utilise that.... i'm a major novice at C/C++, but i've got a decent amount of textbooks and stuff to help me, so fingers crossed ;)
-
Orders Sexp
Mmm, good reason this doesn't work...it doesn't do anything :o
Thinking cap is on to figure out how to make this one work.
is-tagged
looking at it.
end-mission
doesn't sound like it would be hard to do. The hooks all seem to be there, just a matter of stringing them together.
player-to-ai/ai-to-player
Can you give more details on how these should work? i.e. what are you wanting to do with them? Would this be sort of like a Cap ship taking control to dock the players ship to something then releasing control back to the player or something else? What parameters should the sexp take?
-
It wasn't mine. As far as I understood it, it was meant to simply give the player's fighter over to an ai (presumably to do things like force it along waypoints, or use it for ending the mission by returning to the capital ship, or other stuff, i dunno. I'm just remembering things i saw requested.)
Here's one that I personally requested a while ago:
toggle-shields
Basically, this would activate/deactivate the shields on a ship. It would work much like the "Has Shields" property checkbox in the ships editor, except as a sexp it could be triggered in the middle of a mission instead of being a permanent thing. I know I could use it when, say, a shielded capital ship's reactors are destroyed and the shields are thus dropped, and other uses can certainly be thought of, too. ;7
-
There was a sexp request thread a way back somewhere that had more stuff in it. A search should turn it up. :)
Edit: here is one such thread with several good suggetions in it. http://www.hard-light.net/forums/index.php/topic,8949.0.html. Pegasus' and karajorma's suggestions seemed especially good (although karajorma's might also involve some AI work as well as sexp creation).
Edit2: Oh hey, looks like EdrickV already figured out how to fix the is-tagged sexp. I guess it never got commited, perhaps? http://www.hard-light.net/forums/index.php/topic,7573.0.html
-
IIRC, the player-to-ai, etc, was for use in 'holding' the player in position for in-engine cutscenes, et al. Or if you need the player to be in a certain place at a certain time.
-
Originally posted by Fry_Day
how about a reset-sexp SEXP? basically it's if-, reset SEXP , so stuff like the Robotech TC could make a SEXP that changes ship form if you hit a key, and it wouldn't be single-use.
The RT mod is beyond using SEXPs for transforming Veritechs. :D We've been using source code changes that are configurable using the normal key binding stuff. It's just not quite ready for release yet. (Hopefully, if we can get it converted to using table info, we'd like to merge it with fs2_open, but we started off with a clean copy of the code and some of the changes used for the early ship transformation code would break backwards compatability.) Ronin's done most of the coding, since I couldn't compile his copy of the code and, as I've said, can't compile the fs2_open version now either.
-
Bump: Just wondering if anything further has been done with this.
-
It might be occasionally useful to have something that merges key-pressed and key-reset into one operator. At the moment it is only possible to toggle a key "pressed status" a finite number of times as far as I can tell, so this new one could work something like what was mentioned earlier about is-tagged. (a dynamic true/false switch)
The other thing I would like to see is an operator that tells AI fighters to move to a waypoint as if it was an enemy, or in other words, afterburn to a waypoint. Currently they simply cruise to waypoints, which can be annoying if the waypoint is really far away. They go very fast when moving in to attack something though, so perhaps this same code can be put in for the waypoint code.
Actually, there are a number of small mission file enhancements I had in mind, but those are not exactly sexps.
-
If I understand you correctly, CP, I get around such things by simply giving such an event a ridiculously high repeat count.
Event 1 (repeat count 999999999, repeat delay 3)
-when
--key-pressed
---
--
Event 2 (repeat count 999999999, repeat delay 3, chained, chain delay 2)
-when
--true
--key-reset
If I need something to happen after, say, the fourth pressing of the key, I use a variable to record the data, and reference it in the trigger of the event where the stuff is supposed to happen.
-
Does the repeat count just cause the event to fire over and over again based on the time delay or does it actually check for the truth of the conditional every time?
-
By chaining the key-reset to the key-pressed in the way outlined, the key-pressed will never re-evaluate until after the key-reset has occured.
-
Ah, so the chain is the critical part there; thanks, I need to try that out.
-
No problem. I became pretty adept at creative uses of chaining, repeat counts, and variables doing some of the missions for The Scroll of Atankharzim. Pretty crazy chaining, actually. It is a very powerful tool.
-
Originally posted by Fry_Day
how about a reset-sexp SEXP? basically it's if-, reset SEXP , so stuff like the Robotech TC could make a SEXP that changes ship form if you hit a key, and it wouldn't be single-use.
You mean a repeat function? Look next to the event tree window in the Events editor...
-
Bumping again.
I want my end-mission and toggle-shield sexps! :D
-
I just thought of a use for the end-mission sexp.
when
-and
--<
---distance
----Alpha 1
----docking bay (Waypoint)
---100
--facing
---GTD Aquitaine
---30
--end-mission
One way to get the player to exit via a docking bay; have a waypoint where the fighterbay would be, have the player fly towards the bay, and when he's close enough the mission would end.
-
You can do something similar without any source changes, except that instead of automatically ending the mission it would do "allow-warp" and tell the player to land using Alt+J. If you disable the warp effect for Alpha wing, the player won't see his ship warping out either. I did a more advanced system in a mission I made for use with the Robotech MOD where you will get "reassigned" to another ship if the ship you took off from gets destroyed. Two of the ships would even complain if you buzzed the tower/flight deck. (Ala Top Gun borrowing a sound from Flight Unlimited II.)
Not saying an end-mission SEXP wouldn't be useful, but I'm still not sure how to arbitrarily end a mission. (I did look a bit, but still am not sure where the code that executes when you do alt+j is. But then I didn't try tracing it from the functions that try to catch the keypress.)
-
Ok, I think I may have found the function call to use to make an end-mission SEXP. It doesn't have a delay associated with it, but someone else can probably put delay code in the SEXP. The function call:
gameseq_post_event(GS_EVENT_END_GAME);
seems to be what the game uses if you hit escape to bring up the abort mission dialog and choose yes. However, that won't work for multiplayer. Multiplayer should use the multi_quit_game() function in multi_endgame.cpp. I think. None of this is tested of course.
-
Correction: That function will quit the game and boot you back to the main hall without a debriefing, so it's not what we want. Need to look over the various GS_EVENTs to find out what one might work.
-
Ok, having managed to find the code that runs after the player's ship has managed to warp out, I think I may have found our end-mission code:
// we have a special debriefing screen for multiplayer furballs
if((Game_mode & GM_MULTIPLAYER) && (The_mission.game_type & MISSION_TYPE_MULTI_DOGFIGHT)){
gameseq_post_event( GS_EVENT_MULTI_DOGFIGHT_DEBRIEF);
}
// do the normal debriefing for all other situations
else {
gameseq_post_event(GS_EVENT_DEBRIEF);
}
-
Here's a wild and crazy idea for a sexp: defun
If you're not familiar w/ LISP (which the sexp "language" closely resembles), defun allows you to define a new function -- in essence, to extend the language.
I wonder how tough it would be to implement... I can see lots of potential applications.
-
Originally posted by EdrickV
Ok, having managed to find the code that runs after the player's ship has managed to warp out, I think I may have found our end-mission code:
// we have a special debriefing screen for multiplayer furballs
if((Game_mode & GM_MULTIPLAYER) && (The_mission.game_type & MISSION_TYPE_MULTI_DOGFIGHT)){
gameseq_post_event( GS_EVENT_MULTI_DOGFIGHT_DEBRIEF);
}
// do the normal debriefing for all other situations
else {
gameseq_post_event(GS_EVENT_DEBRIEF);
}
If you're after what i think, look at the red-alert code - it has (commented out) lines that dump the player into a standard debrief if the mission just finished is the end fo a campaign. Possibly they decided to go straight to the end movie after implementing this, or decided to allow the player to die and thus skip the debrief. Or something.
NB: From gameseqeunce.h
#define GS_EVENT_DEBRIEF 33// go to debriefing
There is a whole bunch of interesting looking stuff in this file that may be of use....such as for impelementing a jump to command briefing sexp or something. :)
BTW - Penguin - a scripting editor type thing would be really neat... i,e, as well as self defined sexps, being able to type in events in a text editor and then import that into a FRED mission.
-
Originally posted by penguin
Here's a wild and crazy idea for a sexp: defun
If you're not familiar w/ LISP (which the sexp "language" closely resembles), defun allows you to define a new function -- in essence, to extend the language.
I wonder how tough it would be to implement... I can see lots of potential applications.
Oh yes, oh yes, oh yes, oh yes, oh yes! If we could find a user friendly way to do that, that would be sweet beyond compare!
Having poked at sexps a little bit (see "Looking for this..." thread), I can say that if there were some sort of system that could provide some semblance of user-friendliness for adding new functions on the fly, it would be the Fredder's equivalent of a religious experience.
-
Originally posted by aldo_14
If you're after what i think, look at the red-alert code - it has (commented out) lines that dump the player into a standard debrief if the mission just finished is the end fo a campaign. Possibly they decided to go straight to the end movie after implementing this, or decided to allow the player to die and thus skip the debrief. Or something.
Actually, that code would dump the player to a debriefing if he was running the mission but not in a campaign. The campaign end code is in freespace.cpp.
case GS_EVENT_DEBRIEF:
// did we end the campaign in the main freespace 2 single player campaign?
if(Campaign_ended_in_mission && (Game_mode & GM_CAMPAIGN_MODE) && !stricmp(Campaign.filename, "freespace2")) {
gameseq_post_event(GS_EVENT_END_CAMPAIGN);
} else {
gameseq_set_state(GS_STATE_DEBRIEF);
}
Player_multi_died_check = -1;
break;
-
Originally posted by Sesquipedalian
Oh yes, oh yes, oh yes, oh yes, oh yes! If we could find a user friendly way to do that, that would be sweet beyond compare!
Having poked at sexps a little bit (see "Looking for this..." thread), I can say that if there were some sort of system that could provide some semblance of user-friendliness for adding new functions on the fly, it would be the Fredder's equivalent of a religious experience.
Not sure how user friendly it would be -- have you ever looked at LISP code? :confused: :mad: :confused: :mad: :D
One issue I see with this is persistence and code sharing -- it might be nice to define some functions that are more "global" in scale (not limited to just one mission). Hmmm...
-
Just so people know, the sexps shields-on and shields-off are now fully functional. They do just what they sound like: turn the shields of a particular ship or ships on or off in the middle of a mission.
Next up: change-ai-level
-
Originally posted by Sesquipedalian
change-ai-level
Yeah, okay, forget that, at least from me. :shaking: :confused: :nervous:
-
Originally posted by Sesquipedalian
Yeah, okay, forget that, at least from me. :shaking: :confused: :nervous:
Huh?
I think it is wonderful if you can change a ship's AI level on the fly. Fredders surely appreciates that.
-
Why would you need that?
-
For special events, I could make use of it in TBP missions.
Say, a command ship is destroyed and all surviving fighter pilots gets morale failure. Or when our boys and gals achieves a major victory over the enemy, they gets a boost to their morale.
Or if it is about Vorlons and Shadows. It is often speculated that their fighters are remote controlled, that usually means that without mothership those fighters are easy pickings. But on another view, their AI technology is surely capable of defending themselves fine even without remote control.
I can see a few occasions where changing AI levels on the fly will prove itself useful.
OK, perhaps it will not be used so often, but almost every event can prove to be useful sometimes. I have learned that lesson in several occasions when making missions, although original events are plenty, more can't hurt either.
Of course I and other TBP fredders have to wait until TBP officially uses SCP stuff... :shaking:
-
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.
-
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. :)
-
I think end-mission sexp has been already done.
-
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.
-
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. :)
-
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.
-
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.
-
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.)
-
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!"
-
My bet is on this one, from parse_object() in missionparse.cpp
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.