Space Combat Kit (VSXGames) [RELEASED]

A little request: i need to have all friendly gameobjects visible on radars so i set the "ignore tracking distance" checkbox in vehicle.cs.
It's possible to have a checkbox to set them "not selectable" ?
In the old Vehicle Combat radar it was possible.

 

When new release will be available ? TNX !

 

Probably next weekend. Replaced my laptop today as the old one blew up (literally, some component inside started smoking) and I might have lost a day or two of work unless I can coax it into working long enough to copy it out.

I think everyone is going to be really happy with how much easier and more intuitive it will be to build things with this kit, and I'll have more to announce tomorrow about the changes the kit is going through.

Yes, teams will definitely be able to be excluded from selection.

 

Allright! Here's some info on what this next update is going to give you, and what problems I am tackling.

The purpose of the update

My goal is to go through all of the kit one piece at a time with a view to whether the code fulfills the following golden rules:

• A user should be able to set up a scene, using a small part of the kit or a large part of it, with a minimum of unnecessary overhead.
• A user should be able to control as much as possible in the inspector, rather than having to rely on black-box, magic scripts that try to cover all eventualities.
  
• Inheritance, rather than interfaces, should be the basis of extending the kit.
• The scope of each script should be reduced as much as possible.

Why Inheritance Over Interfaces

The reasons for inheritance over interfaces are a) more people are familiar with inheritance b) interfaces are difficult to update without breaking people's projects (overwriting their customizations of the interfaces, requiring code changes in all classes that implement it, etc) and c) interfaces require a lot of redundant code to be written in all the implementing classes.

Note that probably some interfaces will stay, but they will not be in areas where users will be wanting to make significant and frequent modifications.

Why Scope Reduction of Scripts

The reasons for scope reduction in scripts are very simple: a) it should be very clear to a user working in the editor what each component does and b) components should be able to be used as building blocks as much as possible, increasing the possibilities of what can be done inside the editor.

So with this in mind, I made a fresh project and started importing the kit one piece at a time. Here are some examples of issues I found and what I am doing about them.

Reducing Unnecessary Baggage - Au Revoir GameAgentManager

The first thing that became clear was that class dependency on the GameAgentManager was very high. It's a singleton that is used as a way to cache a global reference to the 'focused game agent' (usually the player). It seemed like a good way to organize things, but it was problematic for the following reasons:

• Many classes throughout the kit became totally coupled to it, meaning not just that it was required in every scene but that any changes to it would cause problems for a lot of other classes.

• Other classes often only needed a reference to the player's vehicle, not the player itself. But instead of having a nice locally cached vehicle reference, these classes would burrow down several dependencies into a global reference to something they didn't actually need to get what they wanted - making for some very ugly code.

• The architecture of GameAgentManager was badly implemented in the sense that it was high up in the architectural hierarchy and yet was very passive, not taking an active role in structuring the scene at the beginning of the game (or anything else really). This fragmented this responsibility into many different classes lower down in the hierarchy and obscured the architecture of the kit.

• Let's say users wanted to create a split screen game - suddenly they would be faced with ripping out code everywhere to create two 'focused game agents'.

The solution to these problems was:

• Each class that relies on having a reference to the player or player vehicle has its own locally stored reference to the exact class it requires.

• These references are exposed in the inspector, making it easy to 'drag and drop' references to set up small portions of the kit in a scene without unnecessary baggage.

• Something similar to the GameAgentManager will be available (so the game can easily focus on different players or AI during runtime), but instead of having everything else depend on it, it will take the responsibility of updating references in different classes as required. This means it is no longer required in every scene and has a clear responsibility.

 

A simple question: how can i set enemy missle weapon to fire more frequently ? TNX !

 

The minMaxSecondaryFiringInterval (Vector2) in the CombatBehavior.cs script controls this functionality. The pause between missile firing is a random value between those two values.

 

Removing Interfaces and Improving Editor Usability - Module.cs

The idea of a module in this kit is something that can be added or removed to a vehicle at runtime to modify or add functionality. Therefore it is in an area where users will want to add a lot of their own content.

Previously, a module was implemented with the IModule interface, meaning that every new component that a user made to add functionality to a vehicle not just had to implement it, but created another thing that could break when the kit was updated. Since modules are the primary entry point for extending the kit, this means a lot of potential pain.

To solve this, a module is now implemented as a MonoBehaviour class (Module.cs) that other scripts can either inherit, or (especially in cases where the functionality of the module will be broken into different building-block components, such as weapons) link themselves to the module via Unity Events. This means that all the scripts can respond to events such as the module being loaded/unloaded, deactivated, and reset. Also, because Unity Events, users can add functions to be called for different events in the inspector.

 

Yep ! Sorry, I mean the probability to be "locked" by the enemy, not the fire rate.

 

In the ExampleWeaponComputer prefab is the "Default turret targeting mode" set to "Camera Vanishing Point", it's a good setting for Enemy planes ?

 

What do you mean by the 'probability'?

Not at all, the camera vanishing point setting is for the player, so that the turrets follow where the camera is 'looking'.

 

1) Enemy planes shoot missiles very rarely. Even when i fly in front of them.
PS: SOLVED reducing locking time from 2 to 1.
2) Which setting i have to use for enemy planes ? The enemy plane prefab has the "camera vanishing point" value.

 

I'm getting two errors when I use version 1.21 of the kit, and they are as follows:
Assets/SpaceCombatKit/Scripts/SpaceCombat/AI/Behaviours/BehaviourState.cs(9,17): error CS0101: The namespace `VSX.UniversalVehicleCombat' already contains a definition for `BehaviourState'
As well as:
Assets/SpaceCombatKit/Scripts/SpaceCombat/AI/Behaviours/BehaviourState.cs(19,17): error CS0101: The namespace `VSX.UniversalVehicleCombat' already contains a definition for `CombatState'
I don't know if anyone else has experienced this issue, or if I was just lucky. What could be causing this? It's from a clean import with no modifications made by me. Any help would be appreciated!

 

The setting you're referring to in ExampleWeaponsComputer.cs is for turrets (gimballed weapons). 'Automatic' means they track the selected target and fire at it, while 'Camera Vanishing Point' is for the player.

For AI, you would use 'Automatic'. However, the CombatBehaviour script is not written with turrets in mind, it was written for fixed weapons. So if your AI's weapons are gimballed turrets, you might have to modify that script a little to get the behaviour you want.

 

I just imported the kit from the asset store into a fresh project, and got no errors. You must have already had BehaviourState and CombatState scripts in your project in a different place from where the new installation expected them to be, so now you have duplicates.

The paths shown in the error message are correct, so (unless you have modified the duplicates) you can find and delete them by searching in the Project tab for the name of the script. If you have modified them, you'll have to merge the duplicates together.

 

Ah! That fixed it. I appreciate your help, turns out I was using an old import, not a clean one. There are no errors popping up now. That said, when I access the controls in the menu during the demo gameplay, I can’t leave the controls section. The “back” button lights up when clicked but nothing happens. It sits there until there until I exit the demo and hit play again. Is this a known issue, or did I do something again? Thanks!

 

Billy,


when I use HUD target tracking in VR, I can see the HUD symbology overlaid on my HUD. For some reason, though, it looks as if these symbols are not updated as often as the rest of the sceney, making them look jittery when I use a VR headset: being merely human, I constantly move the head slightly; most objects update their positions correctly, but the HUD symbols (target brackets) tend to briefly stick to their positions, only to jump to their updated (correct) positions after about 1/5 of a second, where again they'll stick for a short period of time. This becomes more pronounced the faster/further i turn my head and the closer the objects are - in combat it is quite pronounced.

DO you have an idea what the culprit could be? Is updating the HUD on a different timer than the rest? Is there a trigger value when the widgets are updated/recached that may cause this issue?

Thanks,
-ch

 

How can I simulate wingman planes (Friedly planes flying left and right of my plane and following me) ?

 

The Back button OnClick event was not set properly. If you go to the button

• Add an onClick event
• Drag the GameStateManager component onto the component field.
• Select the 'EnterGameState' function
• Set the string to PauseMenu

everything should work fine. See image below:

Spoiler: screenshot

 

Interesting..

• What is your VR device?

• Is it just part of the target tracking widget, or the whole lot (including text, lead target box, locking box etc)?

• Does this only happen in VR? What about world space without VR?

All the target tracking widgets are updated every frame. I'm not sure what your setup is but the first thing that comes to mind is that somehow the HUD camera is not updated as often as the main camera, but I have no idea why this might be.

I don't have access to a VR device right now unfortunately. I can ensure everything works well in world space though, and if you can pinpoint any issue that causes an upset in VR I will do my best to fix it.

 

Did you take a look at the GameplayDemo scene? At the start you have two wingmen. Let me know if any part of how this works needs explanation.

 

I'm using a Vive (and Vive PRO), connected through a AMD Vega 64, with plenty of performance headroom for the Scene. I'll check if this is something that only happen inside Editor (as there are some strange hacks Unity employes), if it's reflected on the Monitor Screen, and will try to shoot a short demo Video if possible.

I'll take note of what is is actually affected, and will try to shoot some diagnostic Video.

It's good to hear that the HUD is updated every Frame, so there are no tedious race conditions to hunt down. This may well be a rounding issue or variable being truncated (or using fixed Point arithmetic versus floats). I'll investigate further.

Cheers,
-ch

 

Thank you, unfortunately it appears the GameStateManager isnt exposing the EnterGameState function. When I add the GameStateManager.cs component to the On Click field, I get only two options to choose from: no function or Monoscript string name. Sorry to be a bother, I'm just trying to figure out the kit.

 

I'm doing this in a fresh project in Unity 2017.4.18f1. When you add the GameStateManager gameobject to the OnClick field, the popup on the right of the OnClick area in the inspector should show every component on that object, including Transform, GameObject and GameStateManager.

Can you post a screenshot of what you're seeing?

 

When googling I've come across a few issues about UI being laggy, but it seems to be only something that happens in the editor. I suggest trying out a build first.

 

Hello again, the problem might be that the kit isn't completely compatible with Unity 2018.3 yet? It works fine in Unity's 2017 variant. In the newest Unity available, it appears to throw up some errors that don't appear in older versions of the engine. I'll include a screen shot of the problem I'm having with the back button. While it doesn't show the the options for in the drop down menu drop down menu in the screen shot for some reason, only two options appear in the 2018.3 version of Unity. They are: "no function" and "monoscript." The 2017 version of Unity has the full drop down list when the GameStateManager is appended to the back button function. There are also a few other hiccups that occur as well, as you can see in the screenshot it's throwing up errors that don't exist in the 2017 version. My guess is Unity's changes might be disagreeable with the kit, but I'm not sure. By the way, awesome kit. I'm a huge fan, you deserve way more recognition for this.

 

When following your tutorial videos about setting up a fighter, I get this when I try to play what I have after video 4 in your series. (About Engines) I'm including the screenshot. I'm not sure why it doesn't work, I'm assuming user error but hope you might be able to point me in the right direction.

 

If you get rid of those errors, you should be able to assign the button onclick function as normal.

These errors are conflicts between Unity's post processing stack and the Unity 2018 API. You can fix them by opening the offending script (by double clicking on the error message) and replacing every 'MinAttribute' with 'UnityEngine.PostProcessing.MinAttribute'.

 

The tutorial is a little out of date. In short, you need a game object somewhere in your scene that has the GameStateManager script on it.

One thing that I'm doing with this renovation of the kit that I'm working on is cutting down a LOT (maybe completely) on the dependency of scripts on a lot of singleton managers and scene level components.

 

Litte problem:
After being hit by my missiles, planes are rotated and translated. This is a good looking effect. But they continue flying having nose not forward oriented. A rotation lerp to restore the correct facing is necessary ?
This code is ok ?
transform.rotation = Quaternion.LookRotation(rigid.velocity);

 

Thank you! I've got a better handle on the kit now. It really is something to behold, you should charge more. The radar alone is worth the price of admission. Keep up the good work!

 

How can I pass the target selected by Radar to GimBall ?
My code is not working !

Code (CSharp):

1. using UnityEngine;
2. using VSX.UniversalVehicleCombat;
3.  
4. public class RadarToGimballBehaviourScript : MonoBehaviour
5. {
6.     public Radar MyRadar;
7.     public GimbalController MyGimbalController;
8.  
9.     private MonoBehaviour theTrackable;
10.     float AngleToTarget;
11.  
12.     // Update is called once per frame
13.     void Update()
14.     {
15.         if (!MyRadar.HasSelectedTarget) return;
16.  
17.         theTrackable = MyRadar.SelectedTarget as MonoBehaviour;
18.         if (theTrackable == null) return;
19.  
20.         MyGimbalController.TrackPosition(theTrackable.gameObject.transform.position, out AngleToTarget, true);
21.         //Debug.Log(theTrackable.gameObject.name);
22.     }
23. }

 

Is this something that you have implemented? Missiles don't physically interact with targets in the vanilla kit.

I can't really say how to restore orientation without seeing exactly what has happened. However if the orientation was changed with physics, then the maneuvring code should easily be able to level out the vehicle. Unless you have removed drag from the rigidbody.

If the kit is still using physics for maneuvring the ships, then directly setting the transform is not a good idea as it messes with the momentum and angular velocity of the rigidbody.

 

Glad to hear you like it! The next version of the kit will blow you away

 

That should work.

• Have you checked if the code is making it past those two null checks - does the debug line show up in the console?
  
• What does the gimbal controller do when you run this code?

 

Hi Billy. I need to access the current target vector of the AI from the obstacleAvoidanceBehaviour.cs so I can blend it with my escape direction. Through steeringvalues maybe?

 

What exactly do you mean by 'target vector'? The blackboard contains a value 'obstacleAvoidanceDirection' with the obstacle avoidance vector (i.e. the direction to go to avoid obstacles). Is this what you're looking for?

 

This is the code from the ObstacleAvoidanceBehaviour script I'm using to update the obstacleAvoidanceDirection and obstacleAvoidanceStrength values. The drawray at the end shows the obstacleAvoidanceDirection pointing at the ground occasionally, causing them to crash. I'm testing it with a formation that I lead. Something's overriding it somehow?

for (int i = 0; i < obstacleDataList.Count; ++i)
{

totalRiskFactor += obstacleDataList.currentRiskFactor;

if (obstacleDataList.currentRiskFactor > blackboard.obstacleAvoidanceStrength)
blackboard.obstacleAvoidanceStrength = obstacleDataList.currentRiskFactor;

if (altitude < 100f && altitude != 0)
{
float alt = altitude / 100;
blackboard.obstacleAvoidanceStrength += 1f - alt;
totalRiskFactor += 0.01f;
}
}

if (totalRiskFactor > 0.0001f)
{
// Update the obstacle avoidance direction
for (int i = 0; i < obstacleDataList.Count; ++i)
{
//blackboard.obstacleAvoidanceDirection += (obstacleDataList.currentRiskFactor / totalRiskFactor) * obstacleDataList.currentAvoidanceDirection;
blackboard.obstacleMovingAwaySpeed += (obstacleDataList.currentRiskFactor / totalRiskFactor) * obstacleDataList.movingAwaySpeed;

if (altitude < 100f && altitude != 0)
{
blackboard.obstacleAvoidanceDirection += -PlanetDirection();
}

Debug.DrawRay(blackboard.Vehicle.CachedTransform.position, blackboard.obstacleAvoidanceDirection.normalized * 25, Color.white);

}
}

 

Without seeing this in action, it's hard to diagnose a problem. However my suggestion for blending terrain avoidance would be to replace these lines:

Code (CSharp):

1. if (altitude < 100f && altitude != 0)
2.                     {                    
3.                         blackboard.obstacleAvoidanceDirection += -PlanetDirection();
4.                     }

with this code:

Code (CSharp):

1. float altitudeFactor = Mathf.Clamp(1 - altitude / 100, 0, 1);
2. blackboard.obstacleAvoidanceDirection = altitudeFactor * -planetDirection + (1 - altitudeFactor) * blackboard.obstacleAvoidanceDirection;

This way, the low-altitude-avoidance kicks in from 0 - 1 as you approach the ground, rather than being added to the current direction (which for all you know might be straight down, for some reason).

 

hi there.. just saying hello and waiting for the next big release and looking how the capital ship stuff is going to work

 

Would you like to play a little with the game I'm developing using SCK? I would like to make it an open project !!!
The alpha technical demo will have 3 scenes. 2 are ready. The third is nearing completion.

EDIT: Availble here

 

Hi there! I'm looking at early next week for the update, but I can't be certain. There's a lot to do.

I've really gone back to the drawing board with this one and rebuilt a lot of things with usability in mind, and I'm building parts all the time in new scenes to see how easily and intuitive things are (which is something I didn't do anywhere near enough of before the first release).

Small building block scripts

There are many more scripts now because bigger scripts have been broken down into logical (and often reusable) parts. This is very good from the perspective of building stuff in the editor, as the scripts are small and clear in scope and it's easy to tell what they do.

There are also a lot of Unity events that let you hook stuff up in the editor.

Very reduced dependency

I've taken component and isolated its dependencies and exposed them in the inspector so that you can 'short-circuit' a lot of unnecessary overhead when building stuff. But you also have the option of controlling these dependencies dynamically in the code.

For example, previously, to make a vehicle move around you had to create a game agent (for the player), create child components for the input scripts, make the game agent enter the vehicle, and then the game agent would load up the appropriate input script. This is fine but what about just getting something moving around in the scene real quick? Now you just plop the input script in the scene and drag the vehicle onto the inspector and off she goes!

Another example: before to add a gun to a vehicle, you had to go through creating a module mount first and then loading up the module through the module mount. Now, you can just add the gun as a child of the vehicle and it's done. But you can use a module mount if you want to have weapon switching or something like that.

The idea is that now it's very easy to test, prototype and isolate small parts of the kit from everything else because now everything is encapsulated a lot better as a self-sufficient piece of functionality.

Like I said before, almost all of the huge stack of singleton scripts that were necessary in every scene before will now be simply optional. GameAgentManager is useful, but threading it through almost every part of the kit's functionality as an anchor for everything else was a mistake.

Better input scripts

First of all there will be the possibility of creating multiple input scripts per vehicle - the scripts are run now based on the VehicleControlClass not just a numeric index, so as long as the VehicleControlClass enum values match on the vehicle and input script you can have as many as you want.

Secondly there will be scripts for testing module components (such as the Triggerable component) so you can create new weapons etc and then make sure they work without having to load it on a vehicle and all the rest.

Thirdly there will be some means of modifying input in the inspector:



It's not going to replace a good input manager like Rewired, but will make it easier to get started. And since it's a serializable class using property drawers, you can easily add custom input in your own scripts.

There's a lot more to show. Probably this weekend I will make a video to show just how fun it is to create a new module, test it, and add it to a ship!

 

I think I've found the issue with the terrain avoidance I've been working on. I've moved the raycast to the steeringTarget in the combat and patrol behaviours. Now I can keep the height of the steeringTarget variable above a certain amount. The route they take to the steeringTarget can still be through the terrain but I fixed that with the raycast in the obstacle avoidance behaviour (for below twenty metres). No more crashing and no more slowing down to avoid the terrain they decided to aim at!
Thanks for your help my friend.

 

Hi Billy, a new question: can I disable impact damages behaviour ?
I prefer to have only damages by weapons.

 

https://github.com/Unity-Technologi...q6cpiflm4BTX-3GL5-Uatv2tKEkmZo03gg_EEqsDJG7K8

• AR Radar : Lines and Dots that form a Radar Grid with multiple Targets

 

Hi, you can disable collision damage by setting the collisionVelocityToDamageFactor variable to zero on the inspector of the HealthGenerator script on the health generators that are being loaded on the vehicle.

 

TNX !!!

 

I'm trying to use RumbleManager calling AddRumble function. But the code don't work ! Where can I find more infos ? TNX !

 

What do you mean by the code not working? What is your code?

 

Code (CSharp):

1. GameObject.FindObjectOfType<RumbleManager>().AddRumble(0.7f, 0.05f, 1.0f, 1.0f);

 

What happens when you run it?

Note that RumbleManager just holds a float value from 0-1 for the current rumble level based on all the concurrent rumbles going on. What other scripts (such as the camera) do with it is up to them.

Did you make sure you added the RumbleManager reference to the VehicleCamera inspector?