Jump to content

Archer

Alpha Tester
  • Posts

    50
  • Joined

  • Last visited

Reputation Activity

  1. Like
    Archer got a reaction from Sir_Rat in Walking Inside of Moving Ships?   
    It could also be interesting to use the ship's acceleration as a form of gravity if artificial gravity is disabled/not installed.  In this case the direction of "down" will be the direction of the engine exhaust.  If the main engines, gyros or maneuvering rockets are able to compensate for the center of mass shifting slightly (or if the game ignores the current position of people in a ship when calculating its CM) then you should be able to walk around normally as long as your ship is designed with the floor in this direction with the exact gravity strength dependent on the ship's acceleration.  Cut thrust and you're back to artificial gravity, mag boots or floating even if the ship still has some speed.  For a good example of how this arrangement would work watch any episode of The Expanse.  Yes, I'm really hoping gravity generators will be optional.
     
    As far as the programming side is concerned Star Citizen had a way of pulling this off.  From what I understand each ship generates its own coordinate system which governs the position of all players in, and possibly near, a given space ship.  In this way the player's position is referenced relative to the ship, not the world.  This way the movement of the ship is irrelevant with regards to the movement of people inside the ship... at least until you crash into something.  DU could do something similar, using that base block as a reference for any players in, on or near a given space ship.  With the game treating the ship as a stationary world it should be relatively simple to apply a gravity vector in the mini-coordinate system.  Overall the arrangement would basically be what Fitorion said; the game first treats the ship as a stationary world then determines the visuals of the universe moving around it based on the ship's movement in the global coordinate system.
  2. Like
    Archer got a reaction from Skcos in Rod of God/Kinetic bombardment   
    This isn't really how it works.  Large objects are indeed subject to greater stresses than small objects when in orbit, but the effects are backwards.
     
    Any object in orbit around a larger object experiences a certain amount of tidal stress.  Essentially this is the difference in the force of gravity on the near side of the object relative to the force on the far side of the object.  Given a fixed diameter object, such as a moon, the difference between the near and far sides is much greater in a low orbit than it is in a high orbit.  If we increase the diameter of this moon then we also increase this difference.  Earth's moon, for example, experiences enough tidal stress at a relatively high orbit to keep one side facing our planet at all times and create a bulge on the near side.If the Moon were brought closer to Earth then the tidal forces would increase, the bulge would be exaggerated and we could start seeing seismic activity on the Moon (as well as Earth).  If it were brought too close then those tidal forces would rip it apart and, instead of a single moon, we would have rings.  The distance at which this happens is called the Roche limit.  The stress isn't related to "entering" the gravitational field or how high the object is when it "starts," what matters is the object's distance relative to the Roche limit at any given time.
     
    On the opposite end we have small objects, such as spacecraft, satellites, most asteroids, meteors, etc.  These objects are so small that the tidal forces they experience are negligible even at extremely low orbits.  If someone were to try to launch a huge object at us, such as Ceres, then it might break up during its approach (though the effects would still be devastating, intact or otherwise).  If, on the other hand, someone picked one of the small asteroids then it would likely remain intact right up until it hit the atmosphere.  Actually redirecting the object towards the planet is the real challenge; in addition to the high energy requirements this kind of attack would probably result in a tug of war between attackers and defenders trying to redirect a specific asteroid months or years in advance of the actual impact.
     
    As for game purposes things get a bit more difficult.  I highly doubt this game will have anything resembling orbital mechanics and it sounds like we won't normally have collision damage.  It is possible that the devs could code a special exemption to have objects which fall from space and hit the ground at sufficient velocity to explode, though it would be a lot of extra work on their end to code both this system and a method to push asteroids around.  On the other hand bombarding a planet with conventional weapons could be made as simple as pointing your guns directly at the target and firing.  This wouldn't work with orbital mechanics (unless you use lasers or particle beams) but it might work in DU's physics with the main concern being game balance.
     
    EDIT:  One thing I should also mention, if someone does manage to throw an object at a planet that is large enough for the Roche limit to actually be a factor then it probably doesn't matter whether it breaks up before impact or not.  Either way you can pretty reliably count on wiping out all life on the surface.
  3. Like
    Archer got a reaction from ForlornFoe in Your characters looks and styles :D   
    Here are a few details that I would like to see as options but seem to be rare in scifi games:
     
    Transparent visors.  Too many games make facial customization irrelevant as soon as you put on a helmet.
     
    Pockets.  Whether you're an engineer, a soldier, an explorer or a miner you're going to need a place to store some gear to keep at the ready but this is something I very rarely see in scifi armor/outfit designs.  The nanoformer backpack is nice for bulk storage but I would still want to keep some duct tape, a leatherman and some spare ammo where I can get to them real quick without using my backpack.
     
    Safety tether harness.  Even if safety tethers aren't actually used in the game it would be nice to at least imply their existence in the universe with a line attach point and leg harness.  It would also come in handy for grappling hooks, rock climbing and re-creating that tether trick Holden pulled with Naomi in The Expanse.
     
    Emergency O2 hose and attachment point.  It could be interesting as a functional piece, just in case you or your buddy has a problem with an O2 supply.  (You did bring a buddy on that EVA... right?)  If not functional it would still be nice to see as a cosmetic detail.
     
    Custom decals.  Ideally I would like to display two of them, one to represent my organization and one for me.  Of course I would also slap both logos on my constructs.
     
    Name tag.  Any organization that has lots of people working in space will probably want to put fairly large name tags on their suits.
  4. Like
    Archer got a reaction from Vyz Ejstu in Low-Profile Turrets   
    The main tradeoff for a low profile model would be elevation.  Positive elevation can be helped if the rear portion of the gun is allowed to drop in to a recess in the hull when aiming high.  Negative elevation can't really be helped without having a higher profile.  Tanks have to deal with this tradeoff; a higher profile design gives better negative elevation so they are better able to fire while hiding the hull behind a shallow hill while a lower profile design presents a smaller target while mobile.  In either case the turret can have full 360 degree horizontal rotation* regardless of height as long as there aren't any other structures on the ship that block a firing direction.
     
    *Sometimes internal mechanisms have trouble dealing with full 360 degree rotation, such as cables or ammo conveyors, but these issues aren't related to turret profile and probably won't show up ingame.
  5. Like
    Archer got a reaction from Leonis in Jetpacks!   
    Let's have this thing as one of the jetpack options.  Good for vertical takeoff, hovering and precise movements, basically what you want when working on the outside of a tall construct.
  6. Like
    Archer got a reaction from Seraph in Jetpacks!   
    Let's have this thing as one of the jetpack options.  Good for vertical takeoff, hovering and precise movements, basically what you want when working on the outside of a tall construct.
  7. Like
    Archer got a reaction from TannhainRP in [Showcase] Show your Skills! Ship/Base/Building Designs & Concept-Arts (2D/3D/*D)   
    Obviously not a voxel build but here's a spaceplane concept I came up with not too long ago, my latest attempt to combine a bunch of different functions into a single, streamlined propulsion system:
     

     
    One of these days I'll have to add some details and learn to texture.
  8. Like
    Archer got a reaction from Hampius in [Showcase] Show your Skills! Ship/Base/Building Designs & Concept-Arts (2D/3D/*D)   
    Obviously not a voxel build but here's a spaceplane concept I came up with not too long ago, my latest attempt to combine a bunch of different functions into a single, streamlined propulsion system:
     

     
    One of these days I'll have to add some details and learn to texture.
  9. Like
    Archer got a reaction from Mortis in Build Mechanics: Hacks and Overpowered weapons? Curse in disguise?   
    Now I'm imagining a Jaeger armed with an appropriately scaled up Lancer assault rifle.  I don't care how impractical it is, someone has to build this.
     
    Anyway I think player-created codes are already kept in check by limitations of the specific elements.  Space Engineers has a similar mechanic in place, allowing players to run scripts in C# from the programmable block.  However, scripts can only be used to instruct elements to do things that they are normally capable of doing and, as far as I know, functional elements are all pre-made, not player-made.  To extend the Space Engineers example I can build a small craft which contains a missile launcher.  I have at least three ways to instruct that missile launcher to fire.  Method 1:  Attach a cockpit, take a seat, set the launcher as my active weapon and click my fire button.  Method 2:  Attach a button somewhere on the ship, set that button's command to fire a missile and push the button.  Method 3:  Attach a programmable block, write an instruction in the script which commands the launcher to fire under some circumstances, maybe in response to a hostile walking in range of a sensor.  With the right scripts and sensors I can set up a fully automated attack drone.  However, the missile launcher recognizes a specific command to fire; it does not recognize any instruction to bypass its normal functionality, such as "immediately refill ammo" or "fire 200 missiles at once in every direction."  If I tried to write a script in that programmable block to do this the game wouldn't understand what my block is trying to tell it and the launcher will take no action.  Presumably DU's player scripts will work the same way, only able to reference sensors that the player has access to and only able to instruct elements to perform actions that they could otherwise.
  10. Like
    Archer got a reaction from Mortis in Rod of God/Kinetic bombardment   
    This isn't really how it works.  Large objects are indeed subject to greater stresses than small objects when in orbit, but the effects are backwards.
     
    Any object in orbit around a larger object experiences a certain amount of tidal stress.  Essentially this is the difference in the force of gravity on the near side of the object relative to the force on the far side of the object.  Given a fixed diameter object, such as a moon, the difference between the near and far sides is much greater in a low orbit than it is in a high orbit.  If we increase the diameter of this moon then we also increase this difference.  Earth's moon, for example, experiences enough tidal stress at a relatively high orbit to keep one side facing our planet at all times and create a bulge on the near side.If the Moon were brought closer to Earth then the tidal forces would increase, the bulge would be exaggerated and we could start seeing seismic activity on the Moon (as well as Earth).  If it were brought too close then those tidal forces would rip it apart and, instead of a single moon, we would have rings.  The distance at which this happens is called the Roche limit.  The stress isn't related to "entering" the gravitational field or how high the object is when it "starts," what matters is the object's distance relative to the Roche limit at any given time.
     
    On the opposite end we have small objects, such as spacecraft, satellites, most asteroids, meteors, etc.  These objects are so small that the tidal forces they experience are negligible even at extremely low orbits.  If someone were to try to launch a huge object at us, such as Ceres, then it might break up during its approach (though the effects would still be devastating, intact or otherwise).  If, on the other hand, someone picked one of the small asteroids then it would likely remain intact right up until it hit the atmosphere.  Actually redirecting the object towards the planet is the real challenge; in addition to the high energy requirements this kind of attack would probably result in a tug of war between attackers and defenders trying to redirect a specific asteroid months or years in advance of the actual impact.
     
    As for game purposes things get a bit more difficult.  I highly doubt this game will have anything resembling orbital mechanics and it sounds like we won't normally have collision damage.  It is possible that the devs could code a special exemption to have objects which fall from space and hit the ground at sufficient velocity to explode, though it would be a lot of extra work on their end to code both this system and a method to push asteroids around.  On the other hand bombarding a planet with conventional weapons could be made as simple as pointing your guns directly at the target and firing.  This wouldn't work with orbital mechanics (unless you use lasers or particle beams) but it might work in DU's physics with the main concern being game balance.
     
    EDIT:  One thing I should also mention, if someone does manage to throw an object at a planet that is large enough for the Roche limit to actually be a factor then it probably doesn't matter whether it breaks up before impact or not.  Either way you can pretty reliably count on wiping out all life on the surface.
  11. Like
    Archer got a reaction from Mortis in Energy   
    That's not necessarily true.  A plasma-core antimatter rocket functions by injecting small amounts of antimatter fuel into a stream of matter propellant.  Only a small portion of the propellant is annihilated; this reaction heats up the remaining propellant.  If you have a way to store antimatter long-term and you can route it through some sort of pipe relatively safely (likely with lots and lots of electromagnets) then there's no reason you couldn't regulate or shut off the antimatter flow at any time by manipulating those magnets.  A pure antimatter system doesn't have to operate in short bursts.  If you can't store and route antimatter then you probably can't build a working antimatter drive in the first place.
     
    You are right about using antimatter in a fusion rocket.  There is one concept generally known as an antiproton-catalyzed fusion rocket where a few antiprotons are used to kick start a fusion reaction.  The name is slightly misleading since a catalyst, by definition, can cause a reaction by its presence but is not consumed in the process, but oh well.  This could make the reactor assembly cheaper than a pure-fusion design since you don't need quite so much compression or startup energy to get the reaction running.  This could be a sort of entry-level use of antimatter, allowing an organization with small scale antimatter production capabilities to build their fusion drives cheaper at the expense of requiring a little bit of antimatter in addition to the fusion fuel.
     
    On a more general note there is a lot of wiggle room in these propulsion systems for the sake of ingame balance while still keeping the system itself relatively plausible.  Sure, you can talk about predicted performance values of these things, but all we have to go on without a working model are theoretical upper limits.  Without a working model we can make whatever assumptions we want about the efficiency of a given propulsion system, antimatter storage capabilities, production efficiency, etc. and tune these values with respect to game balance.  If a theoretical max antimatter drive is overpowered then set it to 50% efficient, assume that this is the best efficiency the engineers in DU were able to come up with and check the balance again.
  12. Like
    Archer got a reaction from Mortis in Energy   
    Orbital elevator combined with the galaxy's longest extension cord.  What could possibly go wrong?
     
    That would make a nice hybrid station though, giving people the ability to reach space for what is basically a train ticket.  Solar panels can be used both to power the elevator and to send power to the ground base along the tether.  Of course without orbital mechanics in play the physics of a space elevator are a little different, though if we don't have to worry about the tower crushing itself if we build it too tall it would probably be easier than in reality anyway.  On the other hand severing a proper orbital tether would result in everything above the break point going into an eccentric orbit or flying off on an escape trajectory depending on the design while everything below the break point probably burns up in the atmosphere; severing a non-orbital space tower would probably bring the entire assembly crashing down on to the ground station.
     
     
     
    That could be interesting, placing a solar power satellite closer to the sun and using microwave beams to transmit power to ships, stations, colonies, etc throughout the system.  Alternately a carrier spacecraft could hold the power plant and remotely charge up the batteries on its fighters, lightening their load and improving their maneuverability (assuming you can actually transmit enough power through a microwave beam to pull that off).  Of course if the carrier is taken out of commission the fighters are basically dead immediately without a backup power plant, though if you lose the carrier you're in a bad place either way.
  13. Like
    Archer got a reaction from Mortis in Loading Weapons   
    I would use a hybrid system for ship weapons.  Basically each weapon may or may not have a magazine depending on the nature of the weapon; a giant cannon might only load a single round at a time but a point defense gun might load a drum holding 1,000 rounds.  On top of that you can build a conveyor system which will automatically pull ammo from a storage unit and load it into the gun as needed or you can omit the conveyor system and have players load it manually.  In the case of the big gun this would mean either the conveyor or the players have to be active full time while the gun is firing and the limiting factor on rate of fire is how long it takes to load each round.  In the case of the point defense gun the entire magazine is swapped out to reload in blocks of 1,000, though whether this is done by a player or a machine this takes time and forces a pause to reload.  The choice between a conveyor and player is the classic auto-loader dilemma.  If you spend the mass to have a conveyor system then you can generally reload more quickly but that mass is good for reloading and nothing else.  If you spend the mass on another player (including the character's mass plus whatever additional life support or interior space might be required) then your load times might be slower and less consistent but that player can also fend off boarders, repair battle damage and serve as an extra set of eyes when they're not loading the gun.  If you use neither then you can use that gun on a smaller ship but your gunner will have to leave the gun controls to reload the weapon.  It should make an interesting design tradeoff.
  14. Like
    Archer got a reaction from Vyz Ejstu in Rod of God/Kinetic bombardment   
    This isn't really how it works.  Large objects are indeed subject to greater stresses than small objects when in orbit, but the effects are backwards.
     
    Any object in orbit around a larger object experiences a certain amount of tidal stress.  Essentially this is the difference in the force of gravity on the near side of the object relative to the force on the far side of the object.  Given a fixed diameter object, such as a moon, the difference between the near and far sides is much greater in a low orbit than it is in a high orbit.  If we increase the diameter of this moon then we also increase this difference.  Earth's moon, for example, experiences enough tidal stress at a relatively high orbit to keep one side facing our planet at all times and create a bulge on the near side.If the Moon were brought closer to Earth then the tidal forces would increase, the bulge would be exaggerated and we could start seeing seismic activity on the Moon (as well as Earth).  If it were brought too close then those tidal forces would rip it apart and, instead of a single moon, we would have rings.  The distance at which this happens is called the Roche limit.  The stress isn't related to "entering" the gravitational field or how high the object is when it "starts," what matters is the object's distance relative to the Roche limit at any given time.
     
    On the opposite end we have small objects, such as spacecraft, satellites, most asteroids, meteors, etc.  These objects are so small that the tidal forces they experience are negligible even at extremely low orbits.  If someone were to try to launch a huge object at us, such as Ceres, then it might break up during its approach (though the effects would still be devastating, intact or otherwise).  If, on the other hand, someone picked one of the small asteroids then it would likely remain intact right up until it hit the atmosphere.  Actually redirecting the object towards the planet is the real challenge; in addition to the high energy requirements this kind of attack would probably result in a tug of war between attackers and defenders trying to redirect a specific asteroid months or years in advance of the actual impact.
     
    As for game purposes things get a bit more difficult.  I highly doubt this game will have anything resembling orbital mechanics and it sounds like we won't normally have collision damage.  It is possible that the devs could code a special exemption to have objects which fall from space and hit the ground at sufficient velocity to explode, though it would be a lot of extra work on their end to code both this system and a method to push asteroids around.  On the other hand bombarding a planet with conventional weapons could be made as simple as pointing your guns directly at the target and firing.  This wouldn't work with orbital mechanics (unless you use lasers or particle beams) but it might work in DU's physics with the main concern being game balance.
     
    EDIT:  One thing I should also mention, if someone does manage to throw an object at a planet that is large enough for the Roche limit to actually be a factor then it probably doesn't matter whether it breaks up before impact or not.  Either way you can pretty reliably count on wiping out all life on the surface.
  15. Like
    Archer got a reaction from Cornflakes in Rod of God/Kinetic bombardment   
    This isn't really how it works.  Large objects are indeed subject to greater stresses than small objects when in orbit, but the effects are backwards.
     
    Any object in orbit around a larger object experiences a certain amount of tidal stress.  Essentially this is the difference in the force of gravity on the near side of the object relative to the force on the far side of the object.  Given a fixed diameter object, such as a moon, the difference between the near and far sides is much greater in a low orbit than it is in a high orbit.  If we increase the diameter of this moon then we also increase this difference.  Earth's moon, for example, experiences enough tidal stress at a relatively high orbit to keep one side facing our planet at all times and create a bulge on the near side.If the Moon were brought closer to Earth then the tidal forces would increase, the bulge would be exaggerated and we could start seeing seismic activity on the Moon (as well as Earth).  If it were brought too close then those tidal forces would rip it apart and, instead of a single moon, we would have rings.  The distance at which this happens is called the Roche limit.  The stress isn't related to "entering" the gravitational field or how high the object is when it "starts," what matters is the object's distance relative to the Roche limit at any given time.
     
    On the opposite end we have small objects, such as spacecraft, satellites, most asteroids, meteors, etc.  These objects are so small that the tidal forces they experience are negligible even at extremely low orbits.  If someone were to try to launch a huge object at us, such as Ceres, then it might break up during its approach (though the effects would still be devastating, intact or otherwise).  If, on the other hand, someone picked one of the small asteroids then it would likely remain intact right up until it hit the atmosphere.  Actually redirecting the object towards the planet is the real challenge; in addition to the high energy requirements this kind of attack would probably result in a tug of war between attackers and defenders trying to redirect a specific asteroid months or years in advance of the actual impact.
     
    As for game purposes things get a bit more difficult.  I highly doubt this game will have anything resembling orbital mechanics and it sounds like we won't normally have collision damage.  It is possible that the devs could code a special exemption to have objects which fall from space and hit the ground at sufficient velocity to explode, though it would be a lot of extra work on their end to code both this system and a method to push asteroids around.  On the other hand bombarding a planet with conventional weapons could be made as simple as pointing your guns directly at the target and firing.  This wouldn't work with orbital mechanics (unless you use lasers or particle beams) but it might work in DU's physics with the main concern being game balance.
     
    EDIT:  One thing I should also mention, if someone does manage to throw an object at a planet that is large enough for the Roche limit to actually be a factor then it probably doesn't matter whether it breaks up before impact or not.  Either way you can pretty reliably count on wiping out all life on the surface.
  16. Like
    Archer got a reaction from ttcraft0 in New gameplay footage!   
    Since I can't build a proper hype train with DU's system yet we'll have to settle for one built by SWDennis:
     

     
    All aboard!
  17. Like
    Archer got a reaction from Vyz Ejstu in Build Mechanics: Hacks and Overpowered weapons? Curse in disguise?   
    Now I'm imagining a Jaeger armed with an appropriately scaled up Lancer assault rifle.  I don't care how impractical it is, someone has to build this.
     
    Anyway I think player-created codes are already kept in check by limitations of the specific elements.  Space Engineers has a similar mechanic in place, allowing players to run scripts in C# from the programmable block.  However, scripts can only be used to instruct elements to do things that they are normally capable of doing and, as far as I know, functional elements are all pre-made, not player-made.  To extend the Space Engineers example I can build a small craft which contains a missile launcher.  I have at least three ways to instruct that missile launcher to fire.  Method 1:  Attach a cockpit, take a seat, set the launcher as my active weapon and click my fire button.  Method 2:  Attach a button somewhere on the ship, set that button's command to fire a missile and push the button.  Method 3:  Attach a programmable block, write an instruction in the script which commands the launcher to fire under some circumstances, maybe in response to a hostile walking in range of a sensor.  With the right scripts and sensors I can set up a fully automated attack drone.  However, the missile launcher recognizes a specific command to fire; it does not recognize any instruction to bypass its normal functionality, such as "immediately refill ammo" or "fire 200 missiles at once in every direction."  If I tried to write a script in that programmable block to do this the game wouldn't understand what my block is trying to tell it and the launcher will take no action.  Presumably DU's player scripts will work the same way, only able to reference sensors that the player has access to and only able to instruct elements to perform actions that they could otherwise.
  18. Like
    Archer got a reaction from OzenRay in Shields   
    On the realism front there really isn't any known method that will give us something like scifi shields, at least as far as acting like a barrier generated in empty space outside your vehicle (or whatever you're trying to protect).  There simply is no real-world process which will replicate the effects.  A magnetic field might offer some protection against particle radiation (potentially including particle beam weapons) but that's about it; they would be useless against projectile weapons and lasers.  It might interfere with missile guidance but then missiles will be designed with that in mind anyway and launch a dumb projectile from a greater distance or just follow the magnets.  But hey, DU has some weird space/time geometry compression going on, artificial gravity and FTL travel.
     
    As far as the DU version is concerned I figure a shield's "hit points" could be explained as a charge in a capacitor bank.  The shield isn't on all the time, it flickers on only when it sees an incoming projectile, stays on long enough to block it and shuts off the rest of the time, waiting to intercept the next bullet.  This both explains why the shield demands more power when under fire and why it does not stop outgoing weapons.  The shield draws power faster than most power plants can supply it so if you hit it enough times in a row the capacitor gets depleted and the shield won't have enough energy available to stop the next shot.  Give it a chance to recharge and it's back to full strength.  This way the shield is really three different components: The power supply, the shield generator and the capacitor bank.  The type and placement of generator affects the shield geometry, how strong of an attack it can actually prevent, whether it is more efficient against strong or weak attacks and how much of your construct is actually protected.  The capacitor bank affects how many hit points that shield has.  The power plant determines how quickly the capacitor bank can be recharged.
     
    The capacitors open up another element of design strategy in general since railguns, coilguns, pulse lasers and particle beams will also need capacitors to supply power.  You might have one big capacitor bank that can run everything, giving you more flexibility, but then firing your railguns eats your shield HP.  Alternately you might compartmentalize, giving dedicated weapon and shield banks so one won't interfere with the other.  Crafty designers might install a switch between the two banks so they are normally isolated but you can occasionally tap your shield reserves for several rapid shots or shut off weapons to extend your shield's HP.
  19. Like
    Archer got a reaction from Halo381 in Build Mechanics: Hacks and Overpowered weapons? Curse in disguise?   
    Now I'm imagining a Jaeger armed with an appropriately scaled up Lancer assault rifle.  I don't care how impractical it is, someone has to build this.
     
    Anyway I think player-created codes are already kept in check by limitations of the specific elements.  Space Engineers has a similar mechanic in place, allowing players to run scripts in C# from the programmable block.  However, scripts can only be used to instruct elements to do things that they are normally capable of doing and, as far as I know, functional elements are all pre-made, not player-made.  To extend the Space Engineers example I can build a small craft which contains a missile launcher.  I have at least three ways to instruct that missile launcher to fire.  Method 1:  Attach a cockpit, take a seat, set the launcher as my active weapon and click my fire button.  Method 2:  Attach a button somewhere on the ship, set that button's command to fire a missile and push the button.  Method 3:  Attach a programmable block, write an instruction in the script which commands the launcher to fire under some circumstances, maybe in response to a hostile walking in range of a sensor.  With the right scripts and sensors I can set up a fully automated attack drone.  However, the missile launcher recognizes a specific command to fire; it does not recognize any instruction to bypass its normal functionality, such as "immediately refill ammo" or "fire 200 missiles at once in every direction."  If I tried to write a script in that programmable block to do this the game wouldn't understand what my block is trying to tell it and the launcher will take no action.  Presumably DU's player scripts will work the same way, only able to reference sensors that the player has access to and only able to instruct elements to perform actions that they could otherwise.
  20. Like
    Archer got a reaction from Anaximander in Build Mechanics: Hacks and Overpowered weapons? Curse in disguise?   
    Now I'm imagining a Jaeger armed with an appropriately scaled up Lancer assault rifle.  I don't care how impractical it is, someone has to build this.
     
    Anyway I think player-created codes are already kept in check by limitations of the specific elements.  Space Engineers has a similar mechanic in place, allowing players to run scripts in C# from the programmable block.  However, scripts can only be used to instruct elements to do things that they are normally capable of doing and, as far as I know, functional elements are all pre-made, not player-made.  To extend the Space Engineers example I can build a small craft which contains a missile launcher.  I have at least three ways to instruct that missile launcher to fire.  Method 1:  Attach a cockpit, take a seat, set the launcher as my active weapon and click my fire button.  Method 2:  Attach a button somewhere on the ship, set that button's command to fire a missile and push the button.  Method 3:  Attach a programmable block, write an instruction in the script which commands the launcher to fire under some circumstances, maybe in response to a hostile walking in range of a sensor.  With the right scripts and sensors I can set up a fully automated attack drone.  However, the missile launcher recognizes a specific command to fire; it does not recognize any instruction to bypass its normal functionality, such as "immediately refill ammo" or "fire 200 missiles at once in every direction."  If I tried to write a script in that programmable block to do this the game wouldn't understand what my block is trying to tell it and the launcher will take no action.  Presumably DU's player scripts will work the same way, only able to reference sensors that the player has access to and only able to instruct elements to perform actions that they could otherwise.
  21. Like
    Archer got a reaction from rmhenn in Shields   
    For that I was thinking a weaker version of the shield with a longer range than the proper shield boundary.  My thinking was that any impact on the shield would be transmitted to the generator.  This weaker shield wouldn't be powerful enough to actually stop a projectile but it would still generate enough force feedback for the projector to detect a projectile crossing it.  When that happens it determines where and when it will strike the main shield and triggers the appropriate section just long enough to stop that projectile.  It might be interesting to have to weigh the consequences of various detection shield ranges, with a short range not giving the main shield enough time to react after detection and a long range susceptible to projectiles fired from inside its perimeter, but it would probably be easier to just use this in the lore and assume the detection field is built into the same shield generator assembly.
     
    As for lasers force feedback doesn't help much here but the entire hull can be lined with temperature sensors.  When a laser strikes the hull the temperature at the point of impact will increase rapidly.  The shield will be programmed to trigger accordingly.  Depending on how quickly the shield reacts the laser might get anywhere from a few nanoseconds to a few milliseconds on target before the shield triggers and blocks the rest of the burst.  For most practical purposes this probably isn't enough time for a laser to do any real damage.  Of course if we're talking Star Wars style blasters all bets are off; the perimeter feedback field would probably work just fine.
  22. Like
    Archer got a reaction from rmhenn in Shields   
    On the realism front there really isn't any known method that will give us something like scifi shields, at least as far as acting like a barrier generated in empty space outside your vehicle (or whatever you're trying to protect).  There simply is no real-world process which will replicate the effects.  A magnetic field might offer some protection against particle radiation (potentially including particle beam weapons) but that's about it; they would be useless against projectile weapons and lasers.  It might interfere with missile guidance but then missiles will be designed with that in mind anyway and launch a dumb projectile from a greater distance or just follow the magnets.  But hey, DU has some weird space/time geometry compression going on, artificial gravity and FTL travel.
     
    As far as the DU version is concerned I figure a shield's "hit points" could be explained as a charge in a capacitor bank.  The shield isn't on all the time, it flickers on only when it sees an incoming projectile, stays on long enough to block it and shuts off the rest of the time, waiting to intercept the next bullet.  This both explains why the shield demands more power when under fire and why it does not stop outgoing weapons.  The shield draws power faster than most power plants can supply it so if you hit it enough times in a row the capacitor gets depleted and the shield won't have enough energy available to stop the next shot.  Give it a chance to recharge and it's back to full strength.  This way the shield is really three different components: The power supply, the shield generator and the capacitor bank.  The type and placement of generator affects the shield geometry, how strong of an attack it can actually prevent, whether it is more efficient against strong or weak attacks and how much of your construct is actually protected.  The capacitor bank affects how many hit points that shield has.  The power plant determines how quickly the capacitor bank can be recharged.
     
    The capacitors open up another element of design strategy in general since railguns, coilguns, pulse lasers and particle beams will also need capacitors to supply power.  You might have one big capacitor bank that can run everything, giving you more flexibility, but then firing your railguns eats your shield HP.  Alternately you might compartmentalize, giving dedicated weapon and shield banks so one won't interfere with the other.  Crafty designers might install a switch between the two banks so they are normally isolated but you can occasionally tap your shield reserves for several rapid shots or shut off weapons to extend your shield's HP.
  23. Like
    Archer got a reaction from Velenka in Shields   
    On the realism front there really isn't any known method that will give us something like scifi shields, at least as far as acting like a barrier generated in empty space outside your vehicle (or whatever you're trying to protect).  There simply is no real-world process which will replicate the effects.  A magnetic field might offer some protection against particle radiation (potentially including particle beam weapons) but that's about it; they would be useless against projectile weapons and lasers.  It might interfere with missile guidance but then missiles will be designed with that in mind anyway and launch a dumb projectile from a greater distance or just follow the magnets.  But hey, DU has some weird space/time geometry compression going on, artificial gravity and FTL travel.
     
    As far as the DU version is concerned I figure a shield's "hit points" could be explained as a charge in a capacitor bank.  The shield isn't on all the time, it flickers on only when it sees an incoming projectile, stays on long enough to block it and shuts off the rest of the time, waiting to intercept the next bullet.  This both explains why the shield demands more power when under fire and why it does not stop outgoing weapons.  The shield draws power faster than most power plants can supply it so if you hit it enough times in a row the capacitor gets depleted and the shield won't have enough energy available to stop the next shot.  Give it a chance to recharge and it's back to full strength.  This way the shield is really three different components: The power supply, the shield generator and the capacitor bank.  The type and placement of generator affects the shield geometry, how strong of an attack it can actually prevent, whether it is more efficient against strong or weak attacks and how much of your construct is actually protected.  The capacitor bank affects how many hit points that shield has.  The power plant determines how quickly the capacitor bank can be recharged.
     
    The capacitors open up another element of design strategy in general since railguns, coilguns, pulse lasers and particle beams will also need capacitors to supply power.  You might have one big capacitor bank that can run everything, giving you more flexibility, but then firing your railguns eats your shield HP.  Alternately you might compartmentalize, giving dedicated weapon and shield banks so one won't interfere with the other.  Crafty designers might install a switch between the two banks so they are normally isolated but you can occasionally tap your shield reserves for several rapid shots or shut off weapons to extend your shield's HP.
  24. Like
    Archer got a reaction from Khaymann in Shields   
    On the realism front there really isn't any known method that will give us something like scifi shields, at least as far as acting like a barrier generated in empty space outside your vehicle (or whatever you're trying to protect).  There simply is no real-world process which will replicate the effects.  A magnetic field might offer some protection against particle radiation (potentially including particle beam weapons) but that's about it; they would be useless against projectile weapons and lasers.  It might interfere with missile guidance but then missiles will be designed with that in mind anyway and launch a dumb projectile from a greater distance or just follow the magnets.  But hey, DU has some weird space/time geometry compression going on, artificial gravity and FTL travel.
     
    As far as the DU version is concerned I figure a shield's "hit points" could be explained as a charge in a capacitor bank.  The shield isn't on all the time, it flickers on only when it sees an incoming projectile, stays on long enough to block it and shuts off the rest of the time, waiting to intercept the next bullet.  This both explains why the shield demands more power when under fire and why it does not stop outgoing weapons.  The shield draws power faster than most power plants can supply it so if you hit it enough times in a row the capacitor gets depleted and the shield won't have enough energy available to stop the next shot.  Give it a chance to recharge and it's back to full strength.  This way the shield is really three different components: The power supply, the shield generator and the capacitor bank.  The type and placement of generator affects the shield geometry, how strong of an attack it can actually prevent, whether it is more efficient against strong or weak attacks and how much of your construct is actually protected.  The capacitor bank affects how many hit points that shield has.  The power plant determines how quickly the capacitor bank can be recharged.
     
    The capacitors open up another element of design strategy in general since railguns, coilguns, pulse lasers and particle beams will also need capacitors to supply power.  You might have one big capacitor bank that can run everything, giving you more flexibility, but then firing your railguns eats your shield HP.  Alternately you might compartmentalize, giving dedicated weapon and shield banks so one won't interfere with the other.  Crafty designers might install a switch between the two banks so they are normally isolated but you can occasionally tap your shield reserves for several rapid shots or shut off weapons to extend your shield's HP.
  25. Like
    Archer got a reaction from Antioch in Shields   
    On the realism front there really isn't any known method that will give us something like scifi shields, at least as far as acting like a barrier generated in empty space outside your vehicle (or whatever you're trying to protect).  There simply is no real-world process which will replicate the effects.  A magnetic field might offer some protection against particle radiation (potentially including particle beam weapons) but that's about it; they would be useless against projectile weapons and lasers.  It might interfere with missile guidance but then missiles will be designed with that in mind anyway and launch a dumb projectile from a greater distance or just follow the magnets.  But hey, DU has some weird space/time geometry compression going on, artificial gravity and FTL travel.
     
    As far as the DU version is concerned I figure a shield's "hit points" could be explained as a charge in a capacitor bank.  The shield isn't on all the time, it flickers on only when it sees an incoming projectile, stays on long enough to block it and shuts off the rest of the time, waiting to intercept the next bullet.  This both explains why the shield demands more power when under fire and why it does not stop outgoing weapons.  The shield draws power faster than most power plants can supply it so if you hit it enough times in a row the capacitor gets depleted and the shield won't have enough energy available to stop the next shot.  Give it a chance to recharge and it's back to full strength.  This way the shield is really three different components: The power supply, the shield generator and the capacitor bank.  The type and placement of generator affects the shield geometry, how strong of an attack it can actually prevent, whether it is more efficient against strong or weak attacks and how much of your construct is actually protected.  The capacitor bank affects how many hit points that shield has.  The power plant determines how quickly the capacitor bank can be recharged.
     
    The capacitors open up another element of design strategy in general since railguns, coilguns, pulse lasers and particle beams will also need capacitors to supply power.  You might have one big capacitor bank that can run everything, giving you more flexibility, but then firing your railguns eats your shield HP.  Alternately you might compartmentalize, giving dedicated weapon and shield banks so one won't interfere with the other.  Crafty designers might install a switch between the two banks so they are normally isolated but you can occasionally tap your shield reserves for several rapid shots or shut off weapons to extend your shield's HP.
×
×
  • Create New...