Template Space Combat Kit (VSXGames) [RELEASED]

Glad to hear that's fixed! I held off replying until I'd had a look and (without having a Rift or Vive) tried to figure out what could be causing it.

Regarding the issue with the camera positioning, would it be preferable to have the HUD anchor and the Camera anchor separated?

-----

Grab the Space Combat Kit now at HALF PRICE on the Asset Store Holiday Sale!

 

Here's a rough draft of the next version of the user guide. It's aimed to be much more procedural rather than explanatory, and get right to the point to be more useful as a quick reference guide. Topics still to be added:

- More HUD information (creating widgets for 3D radar and target tracking)
- Vehicle Camera
- Gimbal Controllers
- AI
- Input scripts
- Object Pooling
- Floating Origin
- Game State Manager
- UVC Event Manager

Feedback much appreciated!

-----

Grab the Space Combat Kit now at HALF PRICE on the Asset Store Holiday Sale!

 

I'll need to do some more testing, but so far I think all that is needed is to separate the two objects so the head camera can move freely, while the HUD cam stays fixed at the reference point. My recommendation is to simply provide an optional secondary reference point, and if that isn't filled, the HUD cam uses the same anchor as the head.

 

Billy,

I believe that people would very much appreciate a 'basics' section for programmers that contains many useful short snippets of code to do basic stuff from script - and I'm sure that many of us will be happy to contribute.

For example, how do you get access to the player?

Code (CSharp):

1.  // get the currently active agent that is acting for the player
2.         GameAgent theCurrentAgent = GameAgentManager.Instance.FocusedGameAgent;
3.  

How do you access the vehicle that the player is inright now?

Code (CSharp):

1.  
2.         GameAgent theCurrentAgent = GameAgentManager.Instance.FocusedGameAgent;
3.         // get the vehicle the player is in
4.         Vehicle currentVehicle = theCurrentAgent.Vehicle;
5.  

How do you make the player to switch the current vehicle to vehicle B - or exit their vehicle (if vehicleB is null)?

Code (CSharp):

1. public void switchToVehicle(Vehicle newVehicle){
2.  
3.         // get the currently active agent that is acting for the player
4.         GameAgent theCurrentAgent = GameAgentManager.Instance.FocusedGameAgent;
5.         // get the vehicle the player is in
6.         Vehicle currentVehicle = theCurrentAgent.Vehicle;
7.  
8.         if (currentVehicle == newVehicle) {
9.            return; // already in vehicle
10.         }
11.  
12.         theCurrentAgent.EnterVehicle(newVehicle);
13. }
14.  

And so forth. All the tiny things that are every-day stuff, but not entirely obvious. There are a lot of small things that we currently must hunt through the various scripts to put our own hooks into. I believe that most people people are looking for the following basic things:

- How to access the player's vehice and change it (see above)
- How steer the ship or provide additional force inputs, e.g. when the ship collides with something. Perhaps explain the different methods you already provide andwhat to use them for (SetBoostInput vs. SetTranslationInputs). Perhaps also highlight the sublte differences of accessing the Engines, and the VehicleController

Code (CSharp):

1. // Give ship a bump to the right
2. // Step 1:
3. // read current translation FROM VEHICLE CONTROLLER,
4. // then add directional thrusters
5.   Vector3 nextTranslationInputs = agent.Vehicle.Engines.VehicleController.CurrentTranslationInputs;
6.  
7. // Step 2: add force at max lateral thrust
8.   nextTranslationInputs.x = lateralThrust;
9.  
10. // Step 3: tell ENGINES to output this
11.   agent.Vehicle.Engines.SetTranslationInputs(nextTranslationInputs);
12.  

- How to access the items on the radar and switch to different targets
- How to get notified if the ship gets hit (other ships, obstacles, weapons fire, explosion splash damage)
- How to impement an auto pilot and control waypoints (I know you already provide everything for that, including a PID controller and obstacle avoidance - it's not obvious, however, how to access these great features from code)

I'm sure many people will be happy to pitch in with their snippets as well.

Cheers,
-ch

 

Hi everyone, the documentation is coming along well. Take a look at this second draft.

I still need to add more information about the HUD, as well as adding inspector screenshots and property descriptions.

-----

Grab the Space Combat Kit now at HALF PRICE on the Asset Store Holiday Sale!

 

I'm not sure I understand. If the HUD camera is fixed, and the main camera can move, then there will be two different perspectives pasted into the same view. It seems to me that the HUD camera should always be in exactly the same place as the main camera.

Are you saying that the HUD camera and the main camera become separated due to some aspect of the VR setup at runtime?

Also, since the HUD transform is parented to the vehicle itself, the cockpit HUD should be in the correct spot regardless of where you are looking from (pilot or copilot seat, or anywhere else).

Let me know what I'm missing here.

 

Great idea, that's definitely going to be very useful.

 

This is one of the strange things that hppen with some of the VR implementations. You are of yourse correct when you say that both HUD and Head cams must look at the same point, and I verified that. However, when you parent the HMD (Head) to the HUD cam, the following happens: the HMD cam is moved from the origin (anchor point) by the amount that the HMD is above the ground (let's say I'm sitting, so 1.3 m), and then turned to the point I'm looking at. So far, so good. Unfortuntaley, then the *same* transformation is added to the HUD camera, moving it in the local up-direction by another 1.3 m and turning it towards where I'm looking (this is the double turn velocity I observed). Not parenting the HUD cam to the Head makes them equal twins, turned and moved identically. I need to experiment further to see if this is particular to the VR integration I'm using (Vive Input Utility / OpenVR) and if there are differences to other (SteamVR, VRTK).

I also still was unable to make the Target Tracking work in VR, so there's still some way to cover.

 

The problem with HUDTargetTracking is that it's written for ScreenSpace, which does not work in VR; all canvases in VR must be Word Space, or they will not be drawn in the HUD (they do appear in Game View, which can be very misleading).

 

Hi, the HUD is fully VR compatible and you can switch between world space and screen space canvases quite easily. Here's a user guide that was made for the Vehicle Combat Radar package (which is almost exactly the same as the HUD in the Space Combat Kit) which has details about the HUD and how to set it up for VR.

Sorry about the confusion, that guide should have already been integrated into the SCK documentation.

 

That really helped a lot - thanks! The last remaining issue was setting scale to 1,1,1 for the world space canvas.

Now that I got it to work - there are two minor issues I noticed.

1. The canvas is 1000 units removed from the camera. Objects that are further away (easily done in my space level) currently do not get a tracking symbol any more (it warps in at exactly 1000 units)
2. The off-screen arrow when a target falls off the visor isn't visible.

Cheers,
-ch

 

Billy,

I think it would be advantageous to make the central methods of your subsystems "virtual". For example, I want to extend your SpaceVehicleEngines to add an engine startup and engine shutdown sequence. For this I changed Awake, Update and FixedUpdate to virtual, and added Start. If possible, you declare the central methods as virtual in the Subsystem base class class level, and include Awake, Start, Update, FixedUpdate, OnEnable, OnDisable and OnDestroy so the whole class tree is covered for these functions. This makes the excellent systems you provide much easier to re-ues and extend.

 

Hi!

1. I'm not sure I understand this problem. The canvas may be a long distance away, but the target boxes are close to the camera (the exact distance can be set with the World Space Target Tracking Distance in the inspector of the HUDTargetTracking script). As far as I can tell, with a world space canvas it doesn't matter where the canvas is, as long as the individual UI elements are within the camera view range. Let me know if there's something I'm missing here.

2. Reduce the UI Viewports Coefficients settings in the inspector of the HUDTargetTracking to bring the off-screen arrows closer to the middle. I added this due to the edges of the screen being out of sight in VR.

Thanks for the suggestion! However the specific vehicle controller script for a vehicle is already completely separated from the core of the kit via interface (IVehicleController). This means that you're free to add any vehicle controller script to your vehicle as long as it implements that interface. The SpaceVehicleEngines script is just one example - it's not necessary to extend it and you can simply duplicate it (name the class something else), modify it and whack the new script on the root transform of your vehicle and you are good to go.

 

Thanks Billy! I'll investigate further, but there seems to be a clipping issue. Here's a screenshot where the target base is at 1000 units distance, and I have slightly inclined my HUD downwards. Left is scene view, right is game view. The upper left part of the green tracking box, and part of the label aren't drawn, but clipped (and I think it is because of distance, but it could be anything). When I close in further (to 950 units), the issue resolves itself and everything is drawn. If I move away further (say, 1010 unitx) the entire box and label disappear and nothing gets drawn. Radar range is set to 5000.



I'll see if I can get more info about this issue.

 

Well, that wasn't difficult to solve a all. The HUD cam has the Far clipping plane set to 1000.

 

Ah yes, if you select the 'Use Target World Positions' in the HUDTargetTracking inspector, it places the target box at the world position of the target and scales it up until it appears at the correct size in the camera. So the camera clipping plane matters here.

If you unselect it, the target boxes are placed at the distance from the camera that you set with the 'World Space Target Tracking Distance' value in the inspector, along the axis that points toward the target.

This is simply to offer two different ways of achieving the same thing, with the second option being more 'realistic' like a helmet visor.

Hope this is clear.

 

This is brilliant! Setting the HUD distance to 0.5 will make you fly cross-eyed (the target box is really close ) so for VR 3.0 is a much better setting. I then also turned on 'center offscreen arrows' with a radius of 0.65 (instead of 30), and now I also have the direction indicators working perfectly, with the coefficients remaining at 1 for x and y. Belatedly, I see that you describe these in the docs for the vehicle combar radar, but I (blush) didn't read that part because I didn't realize that the mentioned HUD View script is the same as HUD Target Tracking script. My bad.

Thanks for the assistance!

 

Glad to hear it works! Really this is my fault for not having proper documentation on that part of the kit. It's what I'm working on at the moment.

 

Incidentally, while digging through the HUDTargetTracking code, I made a small adjustment to Awake(). This is because for VR, the HUD and UI cams are separate siblings, and even though it's not a big thing, the script currently picks the chase cam as UI cam, not the HUD cam. For the script to work, the HUD cam must have the substring 'HUD' as part of its name:

Code (CSharp):

1.             // Check the camera
2.             if (UICamera == null)
3.             {
4.                 // Find a cam labelled HUD
5.                 Camera[] allCameras = Camera.allCameras;
6.                 foreach (Camera aCam in allCameras) {
7.                     if (aCam.name.ToUpper().Contains("HUD")) {
8.                         UICamera = aCam;
9.                         Debug.Log("Using " + UICamera.name + " as UI cam");
10.                         break;
11.                     }
12.                 }
13.  
14.                 // fallback
15.                 if (UICamera == null)
16.                     UICamera = Camera.main;
17.             }

 

The kit have support for mobile, there are controls or something like that, or need to bem work with third party controller for mobile?

 

Not yet, although this is only a question of creating the ui and control script for mobile.

 

Hey, what would be the best way to get xbox + flightstick + VR compatibility running so me and my programmer can start modifying and expanding this kit? I wanna try it with a toon-shader and VRTK. Any advice? I know it's been ages but my programmer is also grabbing a copy of this module + any that will be needed for interaction + input.

 

Billy,

I'm trying to use SCK's PID to use for an auto-pilot, but seem to be doing something wrong: while the ship does turn towards the target, it starts oscillating strongly when almost facing the target. This is usually a matter of getting PI and D correct, but using the values you recommend do not seem to work.

Here's the auto pilot code that overrides the control input

Code (CSharp):

1.     public void otto() {
2.         GameObject theTarget = currentWaypoint;
3.         Vector3 newSteeringValues = Vector3.zero;
4.         // use the static 'TurnToward' method of the maneuvering class to generate input for the steering controls
5.         // inited coeffs: steeringPIDCoeffs = new Vector3(0.1f, 0.1f, 0.01f);
6.         // intgralSteeringValues is inited to Vector3.zero
7.         // maxrotationvalues limit the rotation. I use maxRotationAngles = new Vector3(360, 360, 45);
8.         //
9.         Maneuvring.TurnToward(theControlledShip.transform, theTarget.transform.position, steeringPIDCoeffs,
10.                 maxRotationAngles, out newSteeringValues, ref integralSteeringVals);
11.  
12.         // we then use the newSteeringValues to change the ship's direction for this frame
13.         theControlledVehicle.Engines.SetRotationInputs(newSteeringValues);
14.  
15.     }
16.  

What am I doing wrong?

 

Hmmm... Looking at maneuvering.cs (without claiming to fully understanding your PID implementation - normal PIDs calculate the Integral error attenuated by deltaTime - yours seems to not require time to weigh the error) I think that any value for Ki other than 0 will introduce oscillation. So the correct coefficient vector (assuming Ki is y) initialization should be

Code (CSharp):

1. steeringPIDCoeffs = new Vector3(0.1f, 0f, 0.01f);

This works, but I still see some (subdued) oscillation during initial alignment. Is it possible that how you apply Ki is perhaps incorrect?

 

Hi,

1. The kit is VR compatible - if there are any problems with VRTK I'll be happy to help sort them out.
2. There is Rewired integration for controllers supported by the HOTAS template (and the gamepad template).

I have never attempted to port to XBox, but I don't see why there would be any specific issues porting to other platforms. A customer developing for PS3 had an issue with ambiguous references in one of the shaders, that was quickly fixed, but other than that as far as I know it was smooth sailing.

 

Hi, first of all, yes the integral coefficient should be multiplied by time, thanks for pointing that out. However I don't think it's the only thing responsible for the oscillation.

The physics-based control is indeed a bit of a black box and it's a difficult part of the kit to make user friendly. Part of this is that there is no reliable analytical way to determine the best coefficients for a PID controller. Trying to do so is an attempt to fit a single equation into a system that can experience all kinds of disturbances, which is bound to be a limited approach. The values are all affected by mass, angular drag and so on.

That said, the PID controller is fairly simple to understand conceptually.

PROPORTIONAL

First, the P is for Proportional, which makes the ship turn toward a target point with a rotational force that is proportional to the angle to the target - the larger the angle the harder it turns.

DERIVATIVE

The problem with simply having a Proportional force is momentum - simply reducing the force doesn't decelerate the ship immediately, and the nose of the ship can swing past the intended orientation, causing oscillation. This is what D (Differential) is for. It is an opposing force (a braking force) that increases the closer the nose of the ship is toward the target orientation.

INTEGRAL

The I (Integral) part is the trickiest to deal with. The idea is that sometimes the target that the ship is steering toward is moving fast laterally across the nose of the ship. Depending on how fast this is, the proportional coefficient is not enough to make the nose of the ship 'catch up' to the target and it will always lag behind. The integral part of the controller adds a small fraction of the proportional force over time to a stored value, so that the longer the ship spends not oriented to the target, the faster this value increases, accelerating the turning of the ship toward the target.

Because the integral value is stored, how does it ever get reduced? Well, it gets reduced when the nose of the ship swings past the target and then the force becomes negative (in the opposite direction) which begins to reduce the stored value until it becomes negative.

This means that with an integral coefficient > 0, there will likely be some oscillation all the time. But that's not necessarily a bad thing - a human pilot oscillates across the target with the cross-hair when aiming, so it's not un-realistic as long as the oscillation is fairly small and slow. The last thing you want in a game is an enemy that is 100% dead accurate.

TUNING A PID CONTROLLER

The best way to tune a PID controller (and debug excessive oscillation) is the following:

1. Set I and D to be zero, and tune P until the turning of the ship is decent but there is a small oscillation.
2. Now tune D until the oscillation disappears.
3. Now tune I until the ship catches up with the target and there is a small amount of acceptable oscillation.

I will try to come up with a better way to do this in future, but right now it can take a bit of time to find the right balance when you change the physical characteristics of the ship's rigidbody.

 

Sorry to post again, we've been following this project for a long time now. We bought two development machines and a third for testings and we intend to use this module the way I described. What would be the best way to get the most up to date version with multiplayer compatibility with the hooks ready for VR and flightstick + xbox controller support so we can begin modification? I'd like to update my review now that I'm in a position to actually use your module the way it is intended, please. My programmer will also have to purchase the module, so they too will be leaving a review, synchronized with mine to give you the maximum score we can without breaking the rules. I may also pay you extra if you help integrate features or assist with integration of features, I'm 100 percent serious.

I'm an amatuer modder with experience with TES, Duke Nukem 3D and System Shock 2, being trained in Maya and Unity + game design at university, my programmer has a CS degree and has 20 years experience with general programming as a hobby + experience with Unity.

Contact me if you want to know more. Max I can spend for now is about 250 USD but anything I can use to build a vertical slice will be able to help me secure grants, funding and no + low interest loans from the government I can funnel here to help support development.

Edit: Clarification: Xbox controller support is for max user install base, need everyone to be able to try it with just VR and a xbox controller. I intend to use twin stick + pedals as premium/intended play method using a Windows PC running SteamVR with Unity.

We have 3x 1070ti, a 2080ti on the way and a 1080 for testing. 3 machines. i7 with 64gb, 1700x with 16gb and a third that will be fitted with a i7700k and up to 64gb. Got a Vive Pro and buying my programmer a Vive Pro or Vive if he lets me.

 

The Rewired integration includes Xbox controller support, so if you have Rewired and install the integration you should be able to plug and play.

I am not currently developing the multiplayer part of this kit, it is available free as-is in a functional but very incomplete state. It's on the backburner and I'm not sure if or when I will continue working on it. If you have any questions as you develop your multiplayer game I will try to give as much direction as I can but I cannot guarantee support for multiplayer.

Thanks for the offer but I'm not looking for freelance work right now, I'm very busy with supporting and developing this kit as well as my game.

 

That's fine, I can just use what you provide later down the track for multiplayer and focus on single player experience for now. Thanks for the help.

 

Is it possible to disable weapons during runtime?

 

Not specifically, but the player input can be disabled on the player's Game Agent component with the ControlsDisabled toggle (which can be set via code).

If you just want to disable weapons, what circumstances would that be? If it's during a cutscene or something like that, I recommend adding a new state to the GameStateManager and disabling weapon firing in the input script when in that state.

 

Thanks, Billy - it's not a high priority; now that I understand how maneuvering.cs works, I believe I can proceed further with your great asset.

Oh, and merry xmas to you all!

 

Thank you for your prompt reply. Your asset is really great!
I would like to implement alert levels, as in star trek.

 

Merry christmas!

Glad to hear you like the kit!

If your alert level is something that is fundamentally part of the vehicle (i.e. when the radar detects an enemy) I would recommend adding a boolean to the Weapons component that is checked before the weapons can be fired.

But if it is a game-context situation (something outside of the vehicle systems), I recommend checking for the alert level in the input script, and managing the alert level state in a scene-level component.

Does that make sense?

 

First, some answers that may help you:
We have SCK running with Vive using OpenVR / Vive Input Utility). Since you mention that you are supporting Vive - using VRTK means that you will be using single cam/multi-pass (which is very good, but breaks compatibility with some shaders, for example CTAA, most sceen-based AO and reflectios).

Support for input hardware in Unity itself is rather basic, but an Asset called 'Rewired' exists that is superior in all relevant parts, provides abstraction, supports controller re-connects, and is supported by SCK.

Multiplayer support isn't built into SCK, but adaptation to a P2P or C/S structure seems straightforward. Some elements will need adaptation (all scene-level managers probably need some adaptation, and the floating origin manager needs a hard look because that can be a problem when players are far away from each other). The bigger problem here is that Unity's networking has been discontinued, which is a problem for us with a published game thatrelies on UNet. You will need to pick a third-party networking tool, and then adapt SCK to that. I hear good things about PUN (Photon), but we haven't yet started analysis for a successor for UNet.

But here is what really bugged me about your post
I really don't want to get ino this discussion, but personally, someone promising good reviews 'without breaking the rules' as compensation makes me want to puke. Here's why:

- You assume that Billy is corrupt and just by the offerring it you are tarnishing any review you may leave. Worse, since his asset is at 5 Stars already, you may imply that you would post bad reviews if he doesn't play along.
- You seem to believe that Billy is so cheap that he would want to do this
- You overlook the plainly evident fact that Billy is providing ample support here (he's helped my company tremendoulsy) for free, and you seem to think that your blatantly open offer of bribery wouldn't be noticed. This is an open Unity forum, for crying out loud!
- Your post also reeks of self-importance: that you seem to believe that your two reviews wouldbe able to move the needle on an established five-star asset - you do realize that it cant go up further, right?
- Yet you are so cheap that all you offer are some lousy 250 bucks (the equivalece of a half day's work for an expert here in Switzerland) while you enumerate a hardware park that alone costs thousands. Get your funding first, then - when you have secured the funds - talk to the pros about committing. Don't promise what you can't keep, and remember that if all you can offer are peanuts, all you will attract are monkeys. I'm sure your idea is great (all our ideas are great), but don't rely on the work of others unless you are prepared to compensate accordingly.

OK, I'm getting off the soap box now.

 

Glad to hear you have it up and running on your Vive! I also recommend Photon although I haven't got any real experience with other multiplayer frameworks.

Just for everyone's information, there is a very basic implementation of Photon multiplayer available free to anyone who has bought the kit. It is in a playable but incomplete state (with version 1.1 of the kit I believe), but I am not actively developing it. It might serve as a good starting point for anyone making a multiplayer game.

 

That could work. The alert level is part of the vehicle.
Now I try to make modules without energy or functionality and mount this when changing the alert level.
Thanks for your help!

 

Do you mean adding modules that represent different alert levels? This doesn't seem like an efficient approach to me.

What I would do is to add a separate component on the vehicle for managing the alert level, e.g. AlertLevel.cs, that has a function or variable that can be read to get the alert level.

Then in the input script (e.g. PlayerSpaceFighterControl) you can store a reference to this script when the game agent enters a new vehicle, and check the alert level before checking/implementing the weapon inputs.

Let me know if you need more explanation on this.

The reason I would do it this way is that although the alert level is part of the vehicle, the relationship between the alert level and the specific vehicle functionality to be enabled/disabled seems to be more a question of gameplay design than systemic vehicle design - it's not a completely logical part of the vehicle itself.

 

Hi everyone, sick of reverse-engineering the Space Combat Kit? Take a look at this draft of the Space Combat Kit User Guide and let me know what you think!

40 pages of to-the-point information (with inspector snaps) that should cover pretty much anything you need to know.

There's still a few odds and ends missing, and I'm very much open to feedback and suggestions.

 

This is a giant leap forward and will be very helpful, Billy! Congrats!

Since you want feedback, please let me point out first that even though I suggest stuff to improve, this in no way means any criticism of what's already there. "Docs are never done." So below are things I'd like to see in the furure:

First would be a 'Big Picture' of the full kit in action, similar to Unity's "Execution Order" description, which would show how SCK calls what, and when which callbacks are initiated. This, I believe, will not only boost understanding of how the kit fits together, but also enables us to correctly identify the ideal script to modify for our purpose.

Additionally, I'd like to see more short setup and code samples that (icing on the cake) would (if they are demo setups) be available in a tutorial folder as prefabs:

- how would someone set up their script to be notified if the ship has collided with an asteroid.
- how do you set up a power plant that powers the engines (example setup)
- how do you set up a recharging shield (example setup)
- how would a script turn an auto-pilot on/off, how would you enable object avoidance as an override to input (how do you mix AI and real input, how to use Tick())
- how your script actually connects to a health component and how to 'repair' damage from script
- how do you actually fire a selected weapon
- how do you change targets from script
- how do you change manage (add, remove, change) patrol waypoints from script
- how to create a hologram from an existing mesh (I know that this is not a SCK issue per se, but I'm not sure everyone realizes that they already have everything to do it). Note also that currently, the auto-generated hologram only reproduces the first mesh; if the targeted object contains multiple mesh objects, they are ignored.

Cheers,
-ch

 

All right - I can also walk the talk - here's what I mean when by "short samples" - and I now realize that this is anything but short, but I think it would help understanding tremendously.

How to set up an AI pilot in SCK that flies a ship

Step 1: Creating the ship flown by the AI Pilot
- create an empty game object in the scene and name it "AI Flown Ship"
- add the Vehicle Script, and set Label to "AI Test", the control class to spaceship fighter
- Add the Engines Script, no changes
- add Space Vehicle Engines (Vehicle Engine controller) script and leave all the defaults.
- add a Rigidbody and set amss to 1, drag to 3, Angular drag to 4, turn off gravity and turn off IsKinematic
- add a mesh object as child that represents the vehicle. Use a capsule for testing, or add a cool looking mesh if you have it
You now have a vehicle that can be flown by anybody in the game. Now create the AI player

Step 2: Create the AI behaviours
The SCK-provided AI uses up to three behaviours that you need to set up first, and then save as a prefab. They are all created the same way: create an empty game object in the scene, name it accordingly drag the relevant behaviour script into it, set up the fields in the script, and then drag that object into your prefabs folder to create a prefab. Finally, delete the (now blue-tinted) object from the scene.

(WARNING: SCK's demos have the tendendcy to give identical names to scripts and the objects that contain the script. There are ObstacleAvoidanceBehaviour scripts and Prefabs in the kit, which may become confusing initially. Make sure you are using the correct items)

We do this twice:
- create one Obstace Avoicance Behaviour (we'll call it "AI Obstacle Avoid") Prefab, using all default values
- create one Fighter Patrol Behaviour (well call it "AI Patrol") Prefab, again using default values (i.e. don't change any)

NOTE:
Once you become more experienced, you'll probably want to bundle the various behaviour scripts into a single AI Behaviour.
We now have the behaviours the AI needs to patrol and to avoid obstacles during flight. Let's build the AI

Step 3: create an AI Player
An AI player is a player object that creates all control inputs for the ship by script. SCK comes with a built-in AI system that you can access though behaviours.
- create an empty game object in the scene and name it "AI Player"
- add the GameAgent script and choose a team, then drag the previously created "AI Flown Ship" into the Starting Vehicle slot
- add a Group Member script (this will later hold the patrol route)
- create an empty game object as child and name it "AI"
- add the AISpaceFighterControl script to the AI object. This will provide all input for the vehicle engine controller that this AI is flying. Leave the combat hehaviour slot empty, but drag the previously created AI Behaviour prefabs (Obstacle Avoid and Patrol) into the lower two slots (obstacle avoid in the middle slot, and patrol in the last slot)
NOTE: the documentation doesn't say so, but you *can* leave behaviour slots empty in the AI.

Step 4: Create a patrol route
- Create an empty object in the scene and name it "AI Patrol"
- add four empty children to the patrol route, and move these children object to different locations in your scene. These will be the waypoints the AI is flying to, so call them WP1 through WP4, respectively.
- add a 'PatrolRoute' script to the Patrol Route object
- in the 'Patrol targets' change the 'Size' to 4. You'll receive four empty slots. Now drag the waypoint objects "WP1" though "WP4" that you just created into the slots in the order that they should be visited.
- drag the "AI Patrol" object into "Patrol Route" slot of the Group Member component in our AI.
Note that even though the patrol route is fed to the AI via the 'Group Member' script, you do not need a Group Manager object to manage the waypoints.

You now can run the scene and the AI pilot should fly a loop throigh all waypoints, endlessly.

NOTE:
You must have set up all scene-level scripts (Managers) before this will work.


Hope this helps.

 

Good

Very nice guide .. but ... we have a space COMBAT kit, we need a "COMBAT" guide ;-)

I tried and now it seems to work:
Open the demo scene and follow the steps of the guide by "csofranz".

Then:
A) Add following scripts to "AI Flown Ship"
1) Add Health script
2) Add Radar script and one "selectable types" (ships); Set audioclips and add an audiosource.
3) Add Weapons script
4) Add ExampleWeaponsComputer script and set "default turret targeting mode" to "automatic"

B) Copy from "Space Fighter 2 Friendly" gameobject and paste as child of "AI Flown Ship":
1) HealthFixtures
2) Meshes
3) ModuleMounts and assign all reference of child "WeaponMounts" and child "Other Mounts"

C) Add Combat AI
1) Create an empty gameobject. Rename it "AI Combat Behaviour" and add the "Combat Behaviour" script. Save it as a prefab.
2) Add reference to it (dragging it) in AI Player->AI->AI Space Fighter Control script. In the field "Combat Behaviour prefab"

 

Are you nuts????

You now have armed my perfectly harmles target practive drone!



This is exactly what I hope this will become - a step by step guide to have yourself killed in space.

 

Now I have to recode my game !!!

http://www.afc82.com/XXVCenturyRedBaron/Pre_Teaser_01.mp4

 

Ah, that's a much better idea. Many Thanks!

 

Can you add features to health.cs like this ?

i wrote this damagemanager long time ago. If you like i can send code to you.


UPDATE: I can add this feautures to health.cs linking the health values of the two modules calling at start GetStartingHealthValue and polling GetCurrentHealthValue
I'll try modifing the demo scene. Stay tuned.

UPDATE 2: WOW !!! It works !!!
If you like it, I can share the module.

 

How can I show healthbars only on selected targets?

Thanks.

 

WOW ! I replaced old Vehicle Combat Radar with SCK and scene fps improved by 10 fps !!!

 

when will the captical ship control arrive? and how will it be different form the fighter controls?

 

Solved it.
I modified the TargettrackingWidget Script.