Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Galemp on April 10, 2006, 07:44:56 pm
-
(http://web.njit.edu/~pjo3/assignpilot.jpg)
We have the interface art, mostly. The main interface is that of the multiplayer loadout screen, we're dynamically rendering the model of the chosen ship already with -shipselection3d, pilot portraits are included in Root_fs2.vp and rank graphics are specified in rank.tbl.
We can add specific characters in AI.tbl with a little more information. The game reads the stats from the table and displays them graphically.
$Name: Snipes
+Title: XSTR("Christopher Snipes", )
+Rank: XSTR("Lieutenant Commander", )
+Portrait: Ter003
+Persona: Wingman 5
$accuracy: 0.6 0.65 0.7 0.75 0.8
$evasion: 25, 35, 45, 55, 65
$courage: 70, 80, 90, 95, 100
$patience: 30, 40, 50, 60, 70
It's essentially taking the multiplayer interface and experience and applying it to single-player, with specific AIs taking the place of other players. There's nothing to prevent you from keeping the generic 'Major' and 'Colonel' AIs specified in the table as ordinary enlisted pilots, but if you're creating a campaign with persistant characters this could inject so much more life and vitality and personality into the game, something that Freespace has been criticized for.
So. Code people. Is this at all possible?
-
This is an excellent idea, because until now, if there were any characters, they received a little blurb in the briefings and then had to do much of their development in a little blurry message window ingame. I like the ability of actually seeing the character's face and his AI stats; it feels RPG-ish in a good way.
-
That is a really good idea, I'm amazed, I never thought about it.
-
Neato. :) I highly approve. The WCSaga guys would probably love it too.
Now we just need a coder...
-
any chance we can mayke this dynamic as well? at the beginning of a campaign it will load the values set in the table. and then as the campaign progresses, it track the scores for the ais. if they are successull in combat, their skills will increment up, if they are shot down points are lost because the character had to recover and his skills got rusty. perhaps also give the charachters lives, so that if a player gets shot down too much, he is killed and can no longer be selected.
-
If that should work I would be happy and sad at the same time...because it would mean that I have to redo the interface again that I have just finished....but hell that is a good idea and I would like to have it.
-
Not only is this a good idea, it's relatively easy to implement, and adds quite a bit to the game.
-
Not only is this a good idea, it's relatively easy to implement, and adds quite a bit to the game.
Great to hear! Go ahead and implement it then. Let me know when you're done and I'll give you CVS access.
-
:lol:
This is actually somthing I'd want in SoR. If no one has looked it in a couple of months I'll probably add it myself. It would go well with the team loadout stuff I'm looking at now :)
-
:(
1.) I'm not a C++ Coder. I am a C# coder however.
2.) I'm not familiar with the Codebase at all.
3.) I don't have enough freetime to implement this feature regardless.
Now that's out of the way, let's look at the veracity of my statement. Relatively easy to implement ?
Well, it is if implementing support for the Ageia Physics Card and it's API to the game would be rated as 'hard'.
I don't see why I need to be patronized for making a statement like that, it doesn't mean that the statement is wrong, there is certainly no need to adopt that attitude. :p
I'm not pressuring anyone to implement it, just stating that it's not that hard to implement, comparitively speaking. Is it time that maybe none of us have to implement it ? Probably. But that's a different story.
-
Saying that somthing is easy is a HUGE mistake to make. While something make look easy on the surface once you get into the labyrinthine code that comprises FS2_open (or worse FRED2_Open) it may turn out to be much more difficult.
For that reason stating that something is easy tends to get you a sarcastic answer. If it is easy then learn C and do it yourself. If you don't know C and don't know the codebase how can you possibly be qualified to say it's easy?
-
Okay, since you know more than i do about this, am I wrong ? is this very hard to implement ? If so, I retract my first statement.
I won't make any more statements regarding the code on this board until I've become more familiar with it.
-
You need to remember that FS2_Open is a mess of global variables. Coming from a C# background you'll have never seen anything like the FS2 codebase. I know I was horrified when I first looked at it.
I know that I would find it time consuming to add this since I have no idea where else changes like this could have an effect. Someone like Goober who has been doing this for longer would be able to make the changes more quickly but even so it's certainly not as simple as making a few changes to one class.
-
I think the point the SCP crew is making is that you never know until you try.
I never said this would be easy or indeed possible; but looking at what's already possible in the multiplayer interface code, and given that we have the necessary resources all ready to draw on, it might be doable with less effort than, say, pixel shaders or other projects that necessitate rewriting huge swaths of code.
-
This is certainly possible, but by no means is it easy or simple. Interface code and graphics changes will be needed, modifications to AI code (which is never a safe thing), changes to the ai.tbl and relevant code to allow person specific AI, and if it's done right it will need pilot file changes to make it persistent. Unless you totally half-ass it, this is deffinitely not a weekend project.
-
Yep. I can see a lot of additional changes that would be needed to make it look like the picture. Adding it invisibly without the interface changes would be a lot easier but I agree 100% that this isn't a trivial change.
-
You'd probably want to start by making different AI classes drag-and-drop in the multiplayer interface.
Forget about the portrait, stats, and model rendering; just start from there and see what happens.
-
I've not looked at the code (and I don't intend to for a while) but I'd probably do this as somethng definable in FRED rather than at the player level. Although I do like the idea of the player being able to choose his wingman from a pool of those available. :)
-
This is a brilliant idea. Reminds me of X-wing where you had a choice of wingmen, leaving you to decide if a mission was worth risking the life of a pro you might need later, or you just needed some newbie cannon fodder to soak up missiles - Assuming you didn't cheat and just copy the top wingmen. Ahh those were the days :) The ability to add/remove wingmen over the course of a campaign would be needed for that too though, a static wingman pool would quickly look suspiciously, well, static, after the same guy has been killed 5 times...
If this gets in though, which I hope it eventually will, it would be really cool to take it a step further and also allow the wingman stats to be modified over the course of a campaign, perhaps through a sexp-modifiable campaign variable that dynamically adds to or replaces the values specified in the table. Actually given that we already have campaign persistant variables, I suppose what that would take is to specify a specific naming format they need to use and look for any that fit (ie. ai_snipes_accuracy, ai_snipes_rank, etc...).
Finally an interface nitpick: Names on the ships are good, but the number should still be displayed somewhere. Perhaps before the name (2: Snipes), on one of the sides of the ship, or as a kind of shadow under the ship... just something, so you know who's calling when Beta 3 starts chatting in mission.
-
This is certainly possible, but by no means is it easy or simple. Interface code and graphics changes will be needed, modifications to AI code (which is never a safe thing), changes to the ai.tbl and relevant code to allow person specific AI, and if it's done right it will need pilot file changes to make it persistent. Unless you totally half-ass it, this is deffinitely not a weekend project.
You could get away with doing it with scripting. If you specify a state but don't override it, the state will be drawn, and then the last thing done before the page is flipped will be to execute whatever is specified in the scripting hook for that state. So if you made a scripting hook for the ship selection state, you would just have to specify it to output the relevant data. Depending on what's being asked for.
You would need to code scripting functions to get at the data from ai.tbl; however that would not be all that hard and would be well within useful parameters for the system.