Cornflakes

i'd like to point out that proper warp drives (aka alcubierre drives) dont impart any force on your ship.
viewed locally you dont accelerate at all.
you just take space and move it around, while you are incidentally on that "space plane" (harr harr) you are moving around.
there is no classical force or acceleration there.
 
(also an inertia /generator/ would be rather counter productive to add to a ship you want to accelerate :V an inertia dampener would be smarter)

Build a big spaceship, label it a city.
Done.
:shrug:

not in this thread.
 
 
 
and direct stat manipulation completely removes the interesting part of the design system
the interesting part in the whole system as i advocate is that you have to think and tinker around with the sliders to get the actual gameplay relevant stats you want.
 
to reuse my gauß cannon again: 
there is no single part that affects efficiency, muzzle velocity, damage, or most of the stats that actually matter.
 
a bigger barrel isnt just "moar damage".
its heavier projectile, higher ammo needs, more size, more mass, more recoil, larger, less efficient coiling (which subsequently causes the bullet to be even slower than it would be from the increased mass), lower refire rate if you are power limited, and (if its a turret) lower tracking speed due to the increased mass and size.
 
and that was /one/ tweakable of /at least/ 5 or 6 that a gauß cannon would have.
 
there is no "one slider per stat" thing as you claim.
 
your system is the shallow and boring one because you can directly chose what you want, instead of tweaking the whole device to do what you want.

It isn't about what YOU want, it isn't about what I want. its about what is needed to pay for upkeep. atm this game is funded solely out the JC's own pockets and a few investors. with the kickstarter now going that is changing to us helping pay for it. they give generous amounts of DACs for backing imo. the game isn't like WoW that charges you 60 dollars ever year on top of a $15usd sub. this game is free to download. free to try, if you like it you can either gain enough ingame cash to buy a DAC or pay the 10-13 usd/euro. as far as sub games go, this game is really cheap. If you don't want to pay because YOU don't think its worth it or cause you feel entitled, that's fine, but I kindly ask you to leave as its already been decided. no amount of complaining will change that.
 
 
edit: don't want to pay the sub? pay 400 to the kickstarter, get lifetime sub (thats paying 2 years of sub upfront plus you get lots of physical goodies that are probably worth atleast 150-200 usd)

The formula is for /restmass/ and speed independent.
It also has no effect on inertia on game relevant scales.
It also has no effect at all on local acceleration.
Regardless of how fast you are, you can accelerate with the same rate and thus experience the same "g-forces" as they are inertial pseudoforces that are caused by acceleration.
Its just that external observers dont agree with the velocity change you must have undergone from your point of view.
 
And relativistic mass increases dont matter a single bit with speeds that any game useful physics engine can handle.
Relativistic effects generally dont matter on a human percievable scale below 0.3c.
and when you include relativistic mass increase.
At 0.3c the mass increase is about 5%
At 0.4c 9%.
Any physics engine breaks way before that speeds.
 
And when you include relativistic mass effects you also have to include time and space dilation.
Cause you cant have one without the others

I vote no. Seems a bit too complex for far to little payoff. Most of the problems like, ships accelerating too fast and turn speed can be handled by the engine and thruster mechanics and fuel consumption. I do not think this problem will need an additional system of injuring the player or ship.
 
Not to mention with all the technologies that seem to be available in the game, nano compressing weight and items, artificial gravity and whatever other crazy technologies in the game this seems like a problem that could be easily solved.
 
If this was a flight sim style game. A game that was 99% about building a ship and flying it with an ultra realistic feel to it, I would be all for it. In dual universe with all the other things to do in the game and the combat not really about dog fighting or ultra realistic flight. I just don't see the pick up in spending time on a system like this.

Let me phrase it this way:
If it were that trivial to do dont you think EVE would have to do the Time dilation thing in large battles?
 
Network latency may doesnt matter for the actual calculations, but it matters massively for the player input.
If that Japanese guy who is fighting in his fighter against me euro guy is always exactly where i expect him with that /at least/ 1/8 of a second time delay hes not using his controls
 
Try playing any fast fps with a ping of 125+, lets see how fun it is.
Same problems apply for any online game.
and unless we find a way around the no communication theorem its not going to be solved by ignoring it and saying the physics are easy to compute locally.

coilguns function fundamentally different from railguns.
 
railguns have the projectile being part of the electrical circuit.
you have one rail as conductor "forwards", the projectile connecting them, and then the other rail transporting current back
with the whole assembly producing a magnetic field that expells the bullet from the assembly.
the projectile is locked to the rails and has to follow any form the rails have.
https://en.wikipedia.org/wiki/Railgun
https://de.wikipedia.org/wiki/Railgun (german wikipedia has a better work principle graph on the top)
 
a coilgun works differently.
a coilgun is basically a series of individually switched electromagnets that pull along a (ferro-)magnetic projectile.
the projectile does never touch the wires and isnt directly part of the electrical circuit
it can rotate more or less freely inside the barrel assembly
https://en.wikipedia.org/wiki/Coilgun
 
what you are describing would be a helically wound railgun, with the rails twisting around the lenght of the barrel working as rifling.
 
 
and railguns cant work in continous mode, because any conducting element in front of your projectile produces a magnetic field against your movement, removing all forward acceleration.
 
coilguns on the other hand would make better particle beam cannons as you could use them as high powered and focused MHD/MPD-like "engines" which expell the highly accelerated material in very rapid pulses.

coilguns have no rifling.
at least they dont need one, and from what i know the preferred variation of a coil gun is a contactless variant to eliminate friction and decrease wear that way.
 
and rifling also has nothing to do with armor penetration

afaik the plan is to make sold software (execute/move only) a black box that cant be changed by the buyer.
 
I'd think that direct code access can also be sold, though.

well next time some one tell me to "shove it up my @ss" the joke will be on them

Have to agree with Steve here - technically it is griefing- and I guarantee if you attempt it on the wrong person your going to piss off some of the larger corps on here - and I know for a fact they will zerg ya We do have zero tolerance toward griefers - no matter how you try to placate it. 

It's your *assumed* simple game mechanics. Unless you are a developer you have just as much knowledge of the mechanics as everyone else on this forum. Dual can be coded with shield boosting mechanics, shield draining mechanics, both, or neither.
 
"No magic healing buffs in dual." Really, show me the quote from the devs. It is one thing to argue for or against a mechanic or you like or dislike an idea, it is another to state something as fact when it is not.
 
The flavor of the mechanic can be whatever it needs to be -- sleeper tech, mana, nanites, etc.
 
One of my criticisms of Eve is that combat seems mostly decided when you launch from the hanger with the ships and loadouts brought. If a game is a "series of interesting decisions made by the player" then most of those decisions happen before the fight. Combat should be fun for everyone. Without support roles the only actionable items in the fight itself for multicrew ships is piloting and weapons.
 
Support gameplay is something I am more interested in as both a player avatar and even as a multi crew ship. I love being the mechanic in Guns of Icarus -- prioritizing repairs, the tool I use to repair, and the types of buffs added to the different elements. I would enjoy similar mechanics being an engineer on a multicrew ship.
 
If we want to go with the nanite flavor a support ship could be equipped with nanite bombs. Shoot them at a baddie to do some damage or debuffs, or shoot them at a friendly to do some repair or buffs.

Am I the only one who had images of random planets with mined out 'dick pics' on their surfaces that are visible from space, when I read the thread title? 

theres nothing about "gradually", just more frequent
 
your certain area doesnt get old data, it just gets more rarely the current data set.
 
when your shard gets the update "ship x at position y" you dont get the data from 20 minutes ago when it first arrived in the system.
you get its current position.
 
thats not how lightspeed works
thats not how anything works

directly painting bump maps could be a bit heavy storage and streaming wise for the game.
 
maybe a decal based system with some limited PCG for long stripes of something?
 
 
premade infinitely stacking stripes of rivets, indents, bumps, seams, etc
which you can apply to a grid 

directly painting bump maps could be a bit heavy storage and streaming wise for the game.
 
maybe a decal based system with some limited PCG for long stripes of something?
 
 
premade infinitely stacking stripes of rivets, indents, bumps, seams, etc
which you can apply to a grid 

Hi MrStarWars and welcome on our forum.
 
It was planned to contact you soon, but as you opened a thread on the forum, this will be much easier as it will clarify some points for all other members as well.
There are many fans of Starwars in the Dual Universe Community.
 
However, while we want to give as much freedom as possible to the players, Starwars material is copyrighted.
 
To copy openly the Starwars Universe as much as you do, we can't allow that for several reasons:
 
- The most important one is copyright infringement. As the community portal has a goal of promoting player-generated content, you can't use copyrighted material (not made by you) to promote your organization. In fact, to do the things well, you should ask permission to the author for each material not made by you (even if it's not copyrighted), to use it for your organization.
- Using Star Wars material can be extremely misleading for newcomers: We are NOT a Star Wars game. Dual Universe has its own story, and while we can understand you really love the Star Wars Universe, our game is not the right place to recreate it.
 
So in short, you can't use material with iconic characters or spaceships and the same applies for words like Palpatine, Darth Vader, and such.
You can reproduce in Dual Universe a social/political structure similar to the Empire in Starwars, but you can't say "Hey this is Starwars!"
 
Getting inspiration from the Starwars style for your spaceships can be tolerated, but you must keep in mind that at any moment, if we receive some complaints from Starwars copyright owners, we will have to remove it. This is the risk of copying something that already exists. 
 
We didn't delete anything until now, because we wanted to get in touch with you first.
We hope you'll understand our position as we ask you to remove obvious starwars content posted by you on the Community Portal.
In the case you wouldn't do it by yourself within a week, we will remove it without further notice.
 
Best regards,
Nyzaltar, Community Manager at Novaquark

To my shame i have to say that i got my numbers wrong, its 5.4 light hours and a factor 7000 xD

i'd personally limit the range of any repair tools to very short ranges, like a few meters.
 
combined with some system that remembers the undamaged state of a given construct (or just plain blueprint access) it would strongly encourage shipyards (with repair arms) and small repair vehicles that crawl surfaces.
 
neither variant would make it "too cheap" or particularily useful in combat.
 
and would make repair yards and fleet tenders an asset to be protected.
with all the repair equipment and production capacity at hand.

so, ignoring the physics talk getting back on topic:
 
to build on the basic premisse of individual shield projector nodes whichs defense ratio depends on the power they get.
 
shield projectors generate a defensive field whichs strenght is dependent on the power they are supplied.
(this could be a damge-per-server-tick value or a damage-per-impact value, it doesnt significantly change the rest of the mechanics)
 
when the incoming damage is higher than the defense value for a single point in time, the shield collapses and needs a certain amount of energy (not power) to reinitiate.
so to reinitiate the shield it has to be supplied with a certain amount of power x  time.
it can take long with low power input, it can go fast with a high power input.
 
 
so, now the interesting part comes when the power allocation to the shield generator gets /changed/.
the ratio of power input to hp generated changes with the rate of change of the power input.
the higher the rate of (upwards) change, the more hp you get out of the power you supply.
 
so a shield which gets 10 power supplied constantly can stand less damage than a shield which gets 0 constant supply but the 10 power for the moment of impact.
 
all we need now in addition is some way to supply large amounts of pulsed power. for example capacitor banks from which the shield generator nodes pull when they need to stop a large shot.
 
 
this creates a continuum of
always-fed-on-full-power shields with low-med ish per-hit stopping power but infinite HP as long as their treshhold isnt exceeded
to
"offline" shields which only activate when a shot arrives which can block very very high damage impacts but get depleted quickly as their capacitors drain with every hit.
depending on the build of the ship and its shield arrays, the energy distribution choices of the crew and the damage state of the ship (for example the buffer caps getting damaged or some power conduits that power the shield array)

i'd personally limit the range of any repair tools to very short ranges, like a few meters.
 
combined with some system that remembers the undamaged state of a given construct (or just plain blueprint access) it would strongly encourage shipyards (with repair arms) and small repair vehicles that crawl surfaces.
 
neither variant would make it "too cheap" or particularily useful in combat.
 
and would make repair yards and fleet tenders an asset to be protected.
with all the repair equipment and production capacity at hand.

Your version sounds mostly annoying imo.
When i keep my equipment in pristine condition all the time and put in replacement parts continously why should it get worse all the time anyway?
 
When a gun's barrel gets worn out and cleaning and rust removal doesnt cut it anymore i replace the barrel (maintainance! Magic!) and dont throw away the whole gun

Your version sounds mostly annoying imo.
When i keep my equipment in pristine condition all the time and put in replacement parts continously why should it get worse all the time anyway?
 
When a gun's barrel gets worn out and cleaning and rust removal doesnt cut it anymore i replace the barrel (maintainance! Magic!) and dont throw away the whole gun

i'd say that functional elements (generators, thrusters, weapons, etc) have a limited "maintainance" point count.
this point count goes down naturally over time (with or without use) with a slow rate.
the maintainance bar can be refilled by using some tools and resources.
 
maintainance needs go up with usage of the device (output power x runtime or discrete uses for devices where it applies).
so the older a device and the more it has been used the more its maintainance bar has been depleted.
 
a ship just being stored in a hangar would still need upkeep, albeit less than an actively used ship.
requiring regular attention and resource input.
 
as a bit of mitigation it would be possible to "mothball" individual functionals (or just the whole ship, but thats just mothballing all the functionals of the ship)
this would take some time and resources and reduce the maintainance decay strongly (or even to zero) but deactivate the component untill it gets taken out of mothballing again (again taking resouces and time).
 
this would discourage massive ship stockpiling as every ship thats in a flyable state is taking manpower and resources.
and the ships that arent taking a lot of resources are either not built yet or in a state where they arent readily flyable.
putting some strategy and thinking into what ships you build and keep flyable, not to speak active.