Jump to content

Loading Weapons


Loading Weapons  

28 members have voted

  1. 1. What would be the best way to load projectile weapons in DU

    • Mass Effect style
      6
    • Current ballistic style
      5
    • Conveyor system
      7
    • Perhaps a combination? (please specify below)
      10
    • Other (also specify below)
      0


Recommended Posts

"Hence the problem with autonomous A.I. drones. A good idea may be to instruct the drones to return to a reload station once their cache is empty. Another drone permanently/ temporarily stationed there would check the inventory of the returning drone and once contact is made/in range(as in the case of wirelessly charged laser weapons), the reload drone does its job. A function tells it to loop on the check or:

do 
{xxx;} 
while(condition);

When the statement, proves true, the reload drone stops and sends a signal to the autonomous one. A receiver function turns to true on reception of the signal/once there is no space to take anymore weapons and it goes on its way.

Pax Vobiscum.

"

Indeed, I would not trust drones, especially ones wired to a ship's mainframe DPU, given some uncertainties that may occur on the code, or quite frankly, their power consumption.

Link to comment
Share on other sites

Indeed, I would not trust drones, especially ones wired to a ship's mainframe DPU, given some uncertainties that may occur on the code, or quite frankly, their power consumption.

"Battle drones may not be for the weak of wallet...or of mind.

Pax Vobiscum.

"

Link to comment
Share on other sites

After trying to find the post, I fell short on it. The idea is that the projectiles act as visual referrence for "time to respond" on the receiving end. You see missile coming? Well, they are slow compared to lasers, so you have to time to power the shields. Laser? Good luck reacting to the speed of light.  That's my point. The post I've read had something about that the projectiles were not "physically intercepted" sicnce the game utilises alock-on mechanic, but it provides you a chance for counter-play if you have the experience to see a trick coming.. or the other side telegraphs it.

 

In my example. pyroblast is like a rocket while a shock is like a laser. Both are lock-on, but only on of them has a real "travelling time". If I find the post, I'll post the link here.

 

It appears that you are correct; here's a quote from the "Ask Us Anything" thread that was just posted on the 28th:

 

"As for missiles, they will most likely have no physical reality, beyond the visual FX that will be client-side only. The way combat will work will be through basic lock + fire mechanism, where the actual impact is probabilistically calculated based on various parameters (skills, distance, armor, etc)."

Link to comment
Share on other sites

It appears that you are correct; here's a quote from the "Ask Us Anything" thread that was just posted on the 28th:

 

"As for missiles, they will most likely have no physical reality, beyond the visual FX that will be client-side only. The way combat will work will be through basic lock + fire mechanism, where the actual impact is probabilistically calculated based on various parameters (skills, distance, armor, etc)."

Indeed, the post I had read must have been on Twitter or something about the non-physical projectiles. Still, it's a way better thing than EVE's laz0rs nonsense. At least with missiles, it's a "countdown" to your damage being registered. You have time to power the shields. That in my opinion will be the real power to lasers. They are instant, because lightspeed, even though the arguement if they shoudl be more powerful the closer you are to the source is a totally different topic altogether, but given the parenthesis including "distance", I can see it happening.

Link to comment
Share on other sites

Perhaps a combination !

 

Making a Conveyor element would be a bad idea in my opinion.

Especially on large capital ships and stations.

The conveyor system is a HUGE source of lag and netcode crap business in Space Engineers. so ... make it simpler perhaps ?

 

 

Proposition:

  • Magazines can be anywhere on the ship as a container
  • Turrets / Weapons systems can be anywhere on and into a ship.
  • Both are required to be anchored or connected to a voxel material of type "conveyor" in order to be online.
  • This voxel conveyor material can be used for transporting ammo, electricity as well as water or whatever "pipes" are required in the game.

The only stress I can see is the check whereas a turret is connected to a magazine and a power source via the voxel conveyor line.

This status could be put in cache and updated when the ship loose a part due to player editing or external damage.

Link to comment
Share on other sites

Perhaps a combination !

 

Making a Conveyor element would be a bad idea in my opinion.

Especially on large capital ships and stations.The conveyor system is a HUGE source of lag and netcode crap business in Space Engineers. so ... make it simpler perhaps ?

 

 

Proposition:

  • Magazines can be anywhere on the ship as a container
  • Turrets / Weapons systems can be anywhere on and into a ship.
  • Both are required to be anchored or connected to a voxel material of type "conveyor" in order to be online.
  • This voxel conveyor material can be used for transporting ammo, electricity as well as water or whatever "pipes" are required in the game
The only stress I can see is the check whereas a turret is connected to a magazine and a power source via the voxel conveyor line.This status could be put in cache and updated when the ship loose a part due to player editing or external damage.

thats mostly how SE's conveyors work for the most part, though.

At least to my knowledge.

 

It also doesnt really matter if the conveyors are voxel or mesh elements.

As the only thing that matters is the connectome, the net graph which describes how individual elements are connected.

If you call them voxels or not doesnt matter.

 

For the connection checks it could mostly be done iteratively.

The (passive) connector blocks dont run any code on their own.

When the first functional block (anything with an inventory or energy consumption/production or a network port, depending on which connector block we look at specifically) starts to build a "net" (using a flood fill algorithm or similar) through all the connector blocks it can reach.

connector blocks keep track which nets they are part of (this would condense down to 1 net or x nets if there are different power tiers, say when you have multiple independent high power weapon subnets connected by medium power interconnects for general system load).

Other attached functional elements ask any connector they connect to if they are already part of a net.

If theres no net they go through the process i outlined.

If theres already a net they join it and then can exchange materials/power/data with all other functionals in the same net.

When a connector gets damaged the whole process repeats to guarantee that broken connections dont continue working.

This would limit the heavy calculations to when changes are made and lets modules communicate "directly" without having to invoke all the connector elements for it.

 

 

 

With mesh elements which have an orientation and defined connection points the whole process can be made more efficient.

general connector elements would be two-terminal elements which can only connect to two other elements. (Straight piece of wire without intersections)

Then there would be crossing elements which have three or more terminals.

 

Using such a sheme would allow to build a more detailed connectome including crossings.

So you could calculate a detailed connectome with all "edge" connections between all "node" crossings and can tell quickly how many paths there are from A to B and if an individual connector is important for their connection and if its removal would reduce/remove transport capacity between A and B.

It would also greatly accelerate recalculation of connections in case of damage.

It would also enable easier calculation of throughput limitations (you cant supply two 2 megawatt lasers through one 2MW cable)

 

Image for clarification of second part.

 

https://upload.wikimedia.org/wikipedia/commons/thumb/5/5b/6n-graf.svg/2000px-6n-graf.svg.png

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...