If you've worked with Javascript or other languages in the past, you may be familiar with event systems.

Star War Vehicles: Redux is designed to be an event driven framework. This means your code will be reactive instead of proactive. You do things based on an event that just happened. The base itself takes care of making sure you react to the correct event.


The current list of events are as follows:

• OnFire(group, seat) - Triggers whenever any of the ship's weapon groups are fired.
  
• OnOverheat(group, seat) - Triggers whenever any of the ship's weapon groups overheat.
  
• OnOverheatReset(group, seat) - Triggers whenever any of the ship's weapon groups reset.
  
• OnShieldsDown() - Triggers when the shields go down.
  
• OnCollision(damage) - Triggers when the ship makes a physics collision (and shields are down)
  
• OnCritical() - Triggers when the ship enters the critical threshhold.
  
• OnEnter(player) - Triggers when a player enters the ship (pilot or passenger).

Well an important thing to note is that these events get called on the server and the client! This is so you can be as flexible as possible with what you do with the events. Let's do an example.

Say you want to let the player know in chat when their shields go down. Chat functions are clientside so we need to add this event on the client.

So, when initializing your ship add the event:


This would print "[WARNING] SHIELDS OFFLINE" to all players inside the ship. If you wanted only the pilot to know then you could add further checks.

You can see it in action here: https://www.youtube.com/watch?v=lsvjaC7cjxk

This event system is already used internally for default events such as the overheating noises:


Here's how that looks: https://www.youtube.com/watch?v=WjSAp63O51M

If you want to add the default events to your ship, you can simply call self:SetupDefaults() or configure it as follows.


Setting an event to false stops the default from running (so you can override it with your own). You can add as many events as you want, even multiple of the same event and they will all be called automatically.

Originally posted by KingPommes:

Id like to propose the usage of npc_launcher as a weapon. its basically the rocket from the rpg but you can choose its model and sounds. dont know how that entity can be used in lua but its a great thing as you can set it to home in on targets. recently picked up a commission job for the hailfire droid. The rockets would work perfectly here.

Do you have any examples of such usage you've done? Would make it way easier to integrate if I don't have to do the thinking you've already done.

I've put up the current state of the code at Github here[github.com].

Feel free to contribute anything if you wish or report any issues there.

As of 7/19/2018 the addon still isn't finished but I wanted to show progress.

Updated post with information on HUD changes.

Originally posted by Syphadias:

I had an idea with the scaling system, is it possible to add an Admin only feature to change ship scale for all via the Q menu? Sort of like the admin panel for Atmos or StormFox? Would make it so the server can choose their ships scale? Just a thought since theyd have to physically edit the addon themselves to do that if they "knew" it was there... Or we could just have a preset "scaled" section with a pre-determined size that makes sense. With a pre-determined we could do SSD finally at the scale of other ships to show how massive it is!

A global scale could potentially work, however live scaling isn't implemented. Which means changing the global scale means you have to respawn every vehicle or issues may occur. I don't really have plans to implement live scaling as that can cause a whole load of other issues on its own.

Hey everyone,

Just wanted to give everyone a quick overview of the current new features and new way of doing certain things, as well as some of the planned features that were requested by some of you and the community.

You can assume everything from the old base is already there (and probably improved).


I want the base to be as configurable as possible. Because of this, most functions now accept a table in order to parse optional data. Anywhere a table is passed to a function as a paramter, you can assume all the table values are optional and will be set to defaults if you do not override them.

For example when adding a seat you might see something like this:


That last parameter is a table, the values inside of it are all the optional things you can set to configure the seat even more.

Because all the table values have defaults, you could in theory leave it out of the function call and it will still work:




Ever felt like your ship was too big or too small? Don't want to recompile your entire model just to change the size? Now you don't have to!

Due to the nice way I have setup positioning, I was able to add drop in support for model scaling. This means that you can call at the beginning of to set a scale for all positioning involving the ship.

This means that you can scale the ship, all weapons, engine effects, etc. just with one line. Currently there may be some issues with view scaling but that should get ironed out. It's kinda fun to fly your ship around at 0.05 scale and feel like an RC plane.


Probably one of my most requested features. Optional to use with ships. Haven't fully implemented recharging yet but it will be soon.

Here[my.mixtape.moe] is a quick video showing the effect. Currently using a generic shield sounding hit until I can get a better.


The HUD will now draw for each passenger inside of ship, not just the pilot. This means passengers will have a better idea of the status of the ship they are in.

Separate weapon cooldowns are also now supported for other seats. That means that firing weapons as a gunner will also display your own cooldown under the main reticle.

Here[my.mixtape.moe] is an example showing off the addition of the HUD to passengers and their own weapon cooldowns


Sometimes you only want the people in the ship to hear something, this is best accomplished by only playing the sounds on the clients that need to hear it. As a result of this need, ships support a new AddSound method client side.

If you want to do something such as adding background radio chatter, this can easily be accomplished with the new AddSound method:


But this is boring, you only have one sound file! Luckily AddSound supports tables to.


By passing a table instead of a string, a random path will automatically be chosen each time the sound is played.

Note: This method is best used for sounds you want to play on intervals or only once during the lifetime of the ship. If you need a more complex sound condition, please see the information about events.

WIP, will finish this post later.