[EdrickV]

If a ship has an actual working fighter bay (for instance an Orion class destroyer) you can set that ship's fighterbay as a jump out point for a ship/wing of ships. It won't really affect player ships though. Don't recall how well it works, but in game I think you can have two ships docked to a third. You have to have a ship with two dock points and two two other ships. One ship docks with the big ship (either in game or setup in FRED2) and then in game the other one has to dock to the big ship's other dock point. Player ships can't dock with other player controlled ships because there isn't any controls to tell the game to dock them and players can't see the docking point paths that AI ships use to dock. One thing that might work for multiple displays would be to fake them with some sort of special program or even just a static screen saver image. (You might have to have the players manipulate the displays, if possible, to keep them synced with the game's data.) That way you could have displays that don't actually look like a hud. If you're going to be using the game over a LAN, then that may limit what you can do with other stuff network wise. There's only so much space within the network packets, and changing them would probably require redoing the whole network code. (Which might take too long.)

With the FS2 source code available, just about anything is possible. Whether anyone can make something work, and work well, is an entirely different thing.

PS Multiple people should be able to control the same ship by using multiple keyboards attached to one computer. The trick would be getting multiple, different, displays. Multiple displays that are the same wouldn't be hard. (You could split the cables to multiple monitors.)

[athropy]

Thanks for the reply and tips EdrickV. The docking seems to be something the game engine really is not suited for (tryed different things yesterday, and none worked). The AI can although pretty limitedly dock with ships, but this way all these events would need to be pre-planned, which is always really difficult (usually impossible) in live roleplaying.

The hard realities are these, and they cant be sacrifised to gain other possibilities.

¤ We need to have our carrier ship flyable (or at least very freely controlled)
¤ We need to have our escort ships flyable

Only after these things are established (and they already are, thanks to helpful tips) we can try accomplish other things that would boost the atmosphere even further, and these things are.

¤ All sorts of docking
¤ Multiple control, and displays
¤ More flexible mission parameters (realtime changes), which could be possible, if WMCoolMons suggestion (command prompt SEXP) would be possible.

Your multiple keyboard idea is great and its something we'll probably use. If, after all, our carrier ship is essentially *one* ship .. we only have one PS2 and Joystick input. We just have to experiment with different hardware solutions. One possibility to do the multiple displays would be to use kind of invisible observation pods, which would be player crafts that would be modified to show only the radar, target and map information. At least this way we could have a few more tactical views. Is there a way to autopilot player-flyable ships?

About the LAN and networking ideas. The only thing I would actually need is for example the game-engine to occasionally save its state into a text file. We could then read these files with java-applets and use htmlpages for the extra displays. And this way we could easily add a few spices to the boring gameplay statistic ("hull breached, containment field collapsed, power reles burned"). It wouldnt mind if the tactical information lagged a few seconds, this is an old-fashioned pirate ship after all.

[athropy]

We accomplished the multiple keyboard solution. We first thought to make a hardware PS/2 splitter, but then thought of using USB keyboards. There are really cheap PS/2 -> USB adapters. This way we can use as many keyboards as we like. At least the engineering and tactical should have their own keyboards (or parts of them).

Has someone tryed creating the command prompt sexps?
Or a sexp that would change a player ship into an AI-controlled ship.

[athropy]

I decided to put some news about the progress of our little project.

Things are looking pretty good. The live roleplay named 'Vapaa Avaruus' (finnish for Free Space) takes place July 11th. We were fortunate enough to have a chance co-operate with Oulu University which provided us with some resources to program a little bit more sophisticated interface than originally planned. It is not finished yet, but is coming along nicely. Its nothing fancy, but every little bit helps. And its fun work when you even get credits for doing it.

The plan is to divide control to five different clients that connect directly or indirectly to Freespace 2 engine. Basically the Freespace 2 acts like a socket server and responds to clients requests. The socket server is started with a sexpression that indicates which ship provides this functionality. The exact solution is kept open as the project is not finished yet.

These clients are according to their function.

ENGINE ROOM
¤ Naturally has access to the ships power controls (shields, weapons, engine)
¤ Some added tasks (fix the fuse or the ship will shut down)

TACTICAL
¤ Has tactical information (radar, local maps, ship/object information)
¤ Controls the weaponry (turrets on / off)

NAVIGATION
¤ Has the jumpgate navigation information and bigger maps (isnt directly connected to the Freespace 2, but rather pre-planned with mission editors)
¤ Locations, details about different systems

CREW
¤ Receives messages from command (brace for impact, intruder alert, docking complete) possibly with a sexpressions passing the information in certain points of the mission.

GAME MASTERS
¤ Issue pre-planned events (like engine shutdown, shields down, unvulnerability, arrival of the destroyer)
¤ Monitor the situations

All of this is pretty much unfinished, so every bit of help is appreciated. If something useful is finished, of course we'll pass it here if someone wants to make use of it.

WISHLIST
¤ The previously suggested player-flyable --> ai-controlled switch would be useful, especially autopiloting and docking would be a great help for us.
¤ External views, anything from duplicating the 1st person view to another machine or simply copying the radar information would be helpful. I've been tinkering with an idea to use the Fred's view as an overall map (like in X-wing), but have no idea how to implement this.
¤ Suggestions, pointers, tips, help, slaves, inspiration, direction.

[Unknown Target]

Will you be releasing this code to the public after you are finished with the role-playing?

[athropy]

That'd be a long wait.

[Towani]

athropy said:
>WISHLIST
>¤ The previously suggested player-flyable --> ai-controlled switch
>would be useful,

I have thought of a possible solution but there are limitations. First I will explain my method.

First you will need to create a variable:
"autopilotStatus" "0" "number"

And a suitable, invisible, custom made, ship to dock with the player ship. Here I named it 'AutopilotShip1'.

You will also need an invisible trigger ship, because FRED2 won't allow for values of variables to be a condition for ship arrival. I named mine 'AutopilotTrigger'.

The arrival and departure cues to the autopilot ship would be:

$Arrival Location: Hyperspace
$Arrival Cue: ( is-iff "Unknown" "AutopilotTrigger" )
$Departure Location: Hyperspace
$Departure Cue: ( has-undocked-delay
   "AutopilotShip1"
   "Player Spaceship"
   1
   2

With no warp effect set.

Below is an event to activate the autopilot:
$Formula: ( when
   ( key-pressed "Z" )
   ( modify-variable
      @autopilotStatus[0]
      1
   )
   ( key-reset "Z" )
   ( change-iff
      "Unknown"
      "AutopilotTrigger"
   )
)
+Name: AutopilotSwitchOn
+Repeat Count: 1
+Interval: 1
+Team: 0

Below is an event for switching the autopilot off again:
$Formula: ( when
   ( key-pressed "V" )
   ( modify-variable
      @autopilotStatus[0]
      0
   )
   ( key-reset "V" )
   ( change-iff
      "Neutral"
      "AutopilotTrigger"
   )
)
+Name: AutopilotSwitchOff
+Repeat Count: 1
+Interval: 1
+Team: 0

There will also need to be an event to get the autopilot ship to dock:

$Formula: ( when
   ( has-arrived-delay
      2
      "AutopilotShip1"
   )
   ( add-goal
      "AutopilotShip1"
      ( ai-dock
         "RPG Spaceship"
         "lower ring"
         "rearming dock"
         80
      )
   )
)
+Name: AutoPilotShip1Dock
+Repeat Count: 1
+Interval: 1
+Team: 0

And, of course, an undock event:

$Formula: ( when
   ( and
      ( has-arrived-delay
         2
         "AutopilotShip1"
      )
      ( = @autopilotStatus[0] 0 )
   )
   ( add-goal
      "AutopilotShip1"
      ( ai-undock 81 )
   )
)
+Name: AutoPilotShip1UnDock
+Repeat Count: 1
+Interval: 1
+Team: 0

You could include messages to go with the keypresses like:
$Team: -1
$MessageNew:  XSTR("Engaging Autopilot system...", -1)
$end_multi_text

$Name: Disengaging Autopilot system..

$Team: -1
$MessageNew:  XSTR("Disengaging Autopilot system...", -1)
$end_multi_text

When the autopilot ship is docked with the player ship add a goal to make it follow a waypoint path. Waypoint paths, as far as I know, have to be pre-set in the mission file.

This would result in an autopilot system that:
Requires the player ship to stop moving to allow the autopilot to engage.
There would be a delay of a minute or more while the autopilot ship docks, even if it arrives out of the player ship's docking bay and is custom made to be very fast moving.
It's possible accelerating to full speed might force the autopilot ship to undock.
Once the autopilot is disengaged it won't work again, unless there are more autopilot ships added to the mission with an arrival condition that the previous autopilot ship must have warped out. Perhaps there is some way to make use of the event repeat option in FRED to deal with this? Reusing the same ship would be possible if it was also switched to escort orders while the autopilot is off to keep it near to the player ship.

You could do some kind of fake 'player docks with ship' using this method by setting two more keys to 'DockOn' and 'DockOff'. 'DockOn' causing an autopilot ship to enter, dock and waypoint its way real close to the ship the player ship is fake docking with. Also by using waypoint speed capping and timer events some unstable, player fake docked, flying could probably be implemented.


athropy said:
>¤ External views, anything from duplicating the 1st person view to
>another machine

Using the standard camera controls on the numpad you can view the first person view of other ships, but you get no hud which unfortunately means no radar data.

[Stryke 9]

Something about roleplaying... and a furry...

Hmm. As to the shared-control thing, you couldn't have it on the same ship, but what you might be able to do is have a modular ship in multiplayer and some FRED commands. Hence, when, say, the engineering "section" (really an independent ship, permanently docked to the other components from the beginning in FRED) gets a bunkerbuster in the tail or loses power due to a pre-scripted event, you can have the dude playing engineer use a walkie-talkie to inform the guy playing captain, hit a button setting off an alert, whatever. It'd take about a thou in hardware to set up, but you roleplayers seem to be rolling in it anyway so there you go. Or you could even automate it- set up the play-captain's room with multiple monitors giving displays from the different computers (a lot of wiring and probably even more money, as well as some tech savvy), and throw in some FRED codes so that the appropriate people at the appropriate times.

I think it goes without saying that turrets are another story altogether, though you could potentially knock together a few ball turrets if you don't plan on having the ship, say, move. THAT could ge ugly REAL fast.


As for docking, set a special explosion. Kill those suckers when they get to the dock bay and press a button, be sure to disable comms first. Then all you've got to worry about is getting them back in the game.


And the, ah, "commander" can change mission parameters the same sort of way. Set up the game with some sexps so that certain keypresses can change certain objectives or send certain messages- or set up options, with y/n responses. Simple enough, same sort of **** I did as a newbie working on LB.

As for external, again, easy. Have an invisible, invincible ship with no weapons and maybe no engine control. Set it about 20k out, and tracking the freighter.

[athropy]

Towani, have you tryed this yourself? I dont have that much experience with Freespace mission design, but I had the impression that you couldn't dock with player-flyable ships. But nevertheless, its worth trying. It could get a bit messy with multiple ships..

I guess I could use the 1st person view as you described, but that would only be useful for spectators (like the crew or something). I think I could add a few of those if I have extra computers available. Passive displays or sorts.

And Stryke 9, funny you should mention it. Its exactly engine room and turrets we have been able to "share-control". The functions were easy to locate and once the socket server is up and running inside Freespace, it has access to these functions which fire up whenever the clients wants to.

So we already can do this

1) A sexpression starts a socket server inside Freespace and starts accepting calls from clients
2) A client connects to the Freespace socket server and sends a message "INCREASE_SHIELD"
3) The socket server does function

if(at_self)
control_used(INCREASE_WEAPON);
increase_recharge_rate(objp, WEAPONS);

if((Game_mode & GM_MULTIPLAYER) && (Net_player->flags & NETINFO_FLAG_AM_MASTER))
   {
   Assert(npl != NULL);
   multi_server_update_player_weapons(npl,&Ships[objp->instance]);
   }

4) The server replies to the client that it has been done.

So basically we can easily add all the simple elements of Freespace to our clients (like sexpressions and commands). Next we are trying to tackle the tactical officer's client, which ought to have access to some tactical information, like maps, radar, ship information, mission telemetry, you know. This is a bit trickier, naturally, 'cause we need to receive real-time Freespace data and not just activate commands.

[EdrickV]

For ship information such as subsystem status, shield status, speed, etc. it sounds like you need code to send out the ship structure for the player ship and maybe the ship_info structure for it too. Those store just about all the info you'd need I think: hitpoints, weapon inventory, shield status, subsystem info, etc. You'd also need a custom client to catch that data and show it on a screen with a UI to let the operator change stuff. (Or at least give them a USB keyboard/keyboard equivalent with bindings for the functions they're allowed to control.) FS2 doesn't have maps as such, and I don't have any idea what you could do about radar other then hiding a monitor showing cockpit view behind something so only the radar screen part shows.

[Flaser]

I haven't managed - or dared, it's exame time after all - to look into the code, but I assume FS has to store all the locations if the ships. The same goes for IFF and stealth.
If the server could send that data to a client a radar can be created pretty fast. Even a non-FS program could handle the data.
It's up to the interface to visualise the data.
If you need a radar corresponding with the main ship's radar then the position and orientation of the main ship should also be transfered.
For a targeting mechanism - or detailed radar - the orientation of the other ships should be sent as well.
If it's just a radar it can run on a separete screen without FS using only the data.

[Towani]

Ok I have run some tests and created an example mission file, which I have uploaded here:

http://www.angelfire.com/falcon/danproject/autopilot.htm

The mission is set as a multiplayer co-op and red alert. An Elysium will jump in at the start and dock with your ship. It will then proceed to take you on a waypoint run. Once docked you have no movement control of your ship.

I couldn't quite get the keypress triggers to work so I made them unnecessary in the example. The triggers themselves activate the events but the Elysium would not gain the dock order due to some kind of problem with the event conditions. In the example the 'X' key should set the trigger ship to Unknown IFF and the 'J' key to Hostile IFF. The fighter in the mission is just an extra to show you are actually travelling around somewhere. You may notice that your ship gets rotated at the rate the docked transport can turn, which may seem a bit unrealistic.