[Weapons system rework proposal]

Hello girls and guys,

It's been a while I didn't post anything and wasn't much active into the game, but sometimes I do come back

 

So today, and as I thought of it often, I wanted to propose you a detailled mechanic of a advanced weapon system, based on existant of course. It comes in two new components, the reload system and the weapon orienting system (mount) and a topic about weapon's power consumption.

But first, please notice that I consider the power system to be availible and fonctionnal.

 

Weapon's reload system:

All weapons should come along a reload system being a physical component that you must put next to the weapon. The reload system depends on the size and the type of weapon. Once you place a weapon, you automatically get the reload system in hand and it must placed to validate the weapon placement. This reload system must be feed with power and ammo. We can imagine building additional reload system if it seems necessary.
The goal of this additional component is to limit the use of weapon capabilities without limiting on where (on which core) the weapon can be attached, but also offering a way of customization and optimisation (including LUA).

  -On missille: Missille are big compared to other weapon's ammunitions, so is the reload system, While we can imagine having XL missile on an XS ship, the need of having a huge power consuption in plus of the size should drastically reduce the usage of such a design. Not that the reload system on missille only draw power (and ammos) whenever it has to reload.

  -On laser: Laser's reload system is small compared to other's reload system as are the ammunitions, it doesn't consume much but the reload process being very complicated it is very slow.

  -On cannons: cannons fires continiously ammos, and for this reasons the reload system must feed the gun continuously and draining power in the mean time, while not being a very big consumption, packing multiple cannon could be a challenge on smaller ship.

  -On railgun: Railgun use magazine that must be reloaded once empty, the power consuption only happens when so.

 

Weapon's power consumption:

All weapons consume power, but quitte differently. If there isn't enough power availible the weapon will works slowler if possible (adjusted to what is availible).

  -On missille: Missille pods only consume power when firing but in a spike. If there isn't enough power availible the weapon won't fire.

  -On laser: Lasers consume a huge ammount of power continuously while firing, it can't fire if there isn't enough power.

  -On cannons: cannons consume tiny ammount of power but continously, adding to the reload-system consumption, both can work significantly slower if needed.

  -On railgun: In order to shot, railgun must stack a lot of power and release it. It can works with a reduced fire rate if not enough power is availible. Once the power stacked, the weapon desn't consume power until next shot.

 

Weapon's orienting system (and aiming):

Any weapon can be mounted on a weapon's orienting system, they allow the weapon to rotate an align with the target, envetually tracking it. There is three different kinds of weapon's mount:

  -Static mount: The weapon doesn't move at all, while the missille can change trajectory after being fired (at the cost of travel time), the other weapons cannot. This mount well protect the weapon, is very basic and efficient. It can be usefull on small ship that can fire straight to big target (fighters) or on gunship that can align the whole ship, think of litterally a gun with adjustors and engines programmed with LUA to track a target.

  -Tracking assisted mount: The mount can move in any direction to a small angle, helping tracking and target adjustment, it consume a bit of energy and is more fragile than the static mount due to the use of alignement system. But it is very handy on almost any ship that face is target.

  -Fully roating mount: Able to rotate in any direction and therefore track any on sight target, it's a must have on big and slow ship that cannot turn quikcly to keep tracking. It uses a lot of power and are very fragile while taking a lot of space. Smaller version can track faster due to less inertia involved.

 

Others thoughs:

-Missille with integrated lock system to replace the big radar that couldn't fit on a XS score, but with limit of not being able to lock S and XS score at long range. It an advanded class ammos.

-Counter mesure: Small laser being able to destroy incomming missile when they're close enough.

-Damage propagation: on laser spreading much more than other weapons through the target due to heat transfer; on cannon almost none, therefore concentrating power; on missile almost only on the surface, on railgun mix between canon and laser hard punch on concentrated point and smaller damage through the target.

 

I know it isn't perfect, those are just though (some very close to what planned or existing) that I wanted to share with the community. Have a good day.

[[Lua][Script] HTML handler]

1 minute ago, Sambo726 said:

File Unavailable

i removed the file and put a pastebin

[[Lua][Script] HTML handler]

I have been working on a script to construct HTML for those who want a simple tool yet quite powerfull I hope.
The Idea is to have the script as a file in your Lua environement and just use the require() function, then start building your HTML.

There is a demo at the end of the script (put the commented lines in your unit.start then uncomment them)

HTMLhandler = require(HTMLhandler)
HUD = HTMLhandler:Create(system)

Features:

The tool accept multiple monitors at once, like several screens or HUD (system).

myHTMLhandler:Create(system,screen1)

 

Simple usage:

To get a simple window inside a left grid in your cockpit you can do:

local myHTMLhandler = require("HTMLhandler")
normalScreen = myHTMLhandler:Create(system)
local baseGrid = myHTMLhandler:addDiv("", "left grid")
local myWindow, myWindowContent = myHTMLhandler:addWindow(baseGrid, "MyWindow", "Inside the window")
---- change the content inside the window ----
local changeInside = "change the inside of the window"
myHTMLhandler:updateContent(myWindowContent, changeInside)
	

 

 

You can create a div with a string or a variable like that myHTMLhandler:createDiv(myVar) and it will display on the selected screen as long as the variable accept the tostring() conversion. You can pass in parameter custom style or/and class.

There is also function to create a window and a table. At any time you can change the content as the "addx" functions returns a contentId. For the table, when created you get a table of contentId to modify the column's header and when adding a line you get a table of contentId to modify what's in the line. You can also delete a line or push a new line at the top of the table.

indexSimpleDiv = myHTMLhandler:addDiv("simpleDiv")
myHTMLhandler:addDiv(indexSimpleDiv, "anotherDiv in SimpleDiv")
myHTMLhandler:deleteElement(indexSimpleDiv)
-- the anotherDiv will be anchor into the simple Div, but once you delete the simpleDiv it will also delete its child, being "anotherDiv"

mainDiv, contentIdMainDiv = myHTMLhandler:addDiv("MainDiv", "left grid") -- this will create a div with the content "MainDiv" and class "left" and "grid"
local tableDiv = myHTMLhandler:addDiv(mainDiv, "", "window") -- create a div with the class window as NQ style (works only with HUD)
local columnHeaders = {"Name", "Quantity", "Container", "Container size"} --define the title of the column's header for the table
local simpleTable = myHTMLhandler:addSimpleTable(tableDiv, columnHeaders) -- create a table with headers
local firstLine = {"Gold", "153kL", "Treasure", "L"}
local firstLineId, firstLineContentId = myHTMLhandler:addSimpleLine(simpleTable, firstLine) -- add a first line
local secondLine = {"Silver", "20kL", "Chest"}
local secondLineId = myHTMLhandler:addSimpleLine(simpleTable, secondLine) --add a second line but without data in the last column
local pushToFirstLine = {"Plastic", "FULL", "line pushed #1", "M"}
myHTMLhandler:addSimpleLine(simpleTable, pushToFirstLine, 2) -- add a third line but at the top position in the table (1 being the headers)
myHTMLhandler:updateContent(firstLineContentId[2], "20kL") -- change the amount of gold of "firstLine"

 

 

Advanced usage:
You can change the position of element, attach it to any other element, pass the class and the style in parameters, you can delete it and you can update the content.
But it is also possible to do more advanced stuff like creating any HTML element template and use them by referencing them.
It should also be possible to do svg tags like that :

myHTMLhandler:defineElement("svg", '<svg height="100%" width="100%">', '</svg>')

then use

myHTMLhandler:addElement("svg",myContentInsideTheTag)

The defineElement and the addElement accept variadic parameters so there is in theory no limit

 

Another example, to make this '<line x1="939" y1="537" x2="957" y2="519" style="stroke:rgb(1, 165, 177);opacity:0.7;stroke-width:3"/>' being encapsulated as an element you can do:

myHTMLhandler:defineElement("svgLine", '<line ', '" style="stroke:rgb(1, 165, 177);opacity:', ';stroke-width:', '"/> ')
local content = 'x1="939" y1="537" x2="957" y2="519"'
local svgLineId, svgLineContent = myHTMLhandler:addElement("svgLine", content, 0, '0.7', '3')

0 being a default postion value, if you want to change the position in a list of element (see above for the table). '0.7' the opacity and '3' the strokewidth.
now you can change the content by using (by default it will rebuild the HTML and display it as soon as the function ends) :

myHTMLhandler:updateContent(svgLineContent, 'x1="0" y1="12" x2="37" y2="24"')

Note that multi-content is only availible for table for the moment.

 

others functions:

addWindow(Anchor, Title, Content, TitleClass, TitleStyle, ContentClass, ContentStyle, Pos) -- to build a window with the NQ style
setAutoDisplay(boolean)
setAutoCompute(boolean) -- for big HTML structure you might want to turn them off as every time you add element or edit content the HTML is rebuild and displayed
compute() --build the HTML
display() --display HTML on all the "monitors"
computeAndDisplay() --straightforward
getElementHTML(Index) -- to get just a chunk of HTML could be used to display just a part of the structure somewhere else

I am aware that there is other tool to build HTML.
If you find a bug please report it.
If you need help, ask me (same name on discord and IGN) or in the #lua-scripting discord channel
If you make your own design using the tool, consider sharing

 

Special thanks to @hdparm

 

 

ps: I'll put images when the server works

 

pastebin instead of file:

https://pastebin.com/KuMRGFFp

create a file "HTMLhandler.lua" and save it at the root of lua folder as below

 

 

[[FAQ] Anti-cheats and choosing EQU8]

On 8/27/2020 at 5:10 PM, WildChild85 said:

The problem is, that they don't deliver required features!

While i'm very glad that coders are making insane things here, its also normal to play the game with the same rules as anyone else. Indeed their is still needed features for the game, but its BETA and their is a lot of more needed features for the majority of people. Coders are not second hand, they're just not on top of other players.

I can really understand the frustration of seing lot of things you made and invested yourself in being not allowed anymore.

[Automated object movement]

On 1/12/2019 at 11:05 PM, CoreVamore said:

You answered your own question there, anything that can move requires its own core and cores must stress the DU servers. So having mini-cores fixed  inside another moving core sounds like a potential can of worms.

Now, yes, later hopefully not.

 

On 1/12/2019 at 11:05 PM, CoreVamore said:

I dont think it would greatly improve the game experience. Sure it would be nice, but there is way more to DU than player made moving parts. (note i am still hopeful that it will happen a few years down the track    )

I agree, it is not a priority for sure, but when I see what people does already in the game I'm pretty sure adding the possibilities of moving part of ship from other like that would be a huge things. But yeah, don't expect it before 2 or 3 years x)

[Automated object movement]

On 12/22/2018 at 8:03 AM, CoreVamore said:

I think you are forgetting one very important fact, that DU is voxel based. A swinging, rotating, arching, moving voxel could well be enough to crash the server. So what may seem very simple could in fact be the most complex thing to handle.

That's something I don't get, there is already moving voxel in any direction with dynamic core, what is the difference between 2 ships and 2 blocs of voxel moving from each other in one ship ?
It may indeed cause performance issue if everyone has a couple of moving voxels inside their ship, but that would be great to find a solution as having this functionality would greatly improve the game experience.

[Camera elements that can link to screens]

I am hopping for a camera as well, would be nice to have a window-less fighter ingame

[Good job on the test today!]

Well this is not much breaking NDA. Just a bit x)

[Attach a ship to another]

1 hour ago, Miamato said:

1 hour ago, NanoDot said:

To me, "attaching" and "docking" mean different things.

Agree. So in previous post I was talking only about docking.

You're both right indeed
 

 

1 hour ago, Miamato said:

As for attaching constructs together - this may be cool, but would be hard to balance and maintain. But probably this may be easier if we have some special module that marks one ship as primary construct (this module contains information about initial vessel borders and design), also it should have kind of 'consumer attaching' spots/modules. The other ships design to be attached have 'attaching provider' spots/modules and special module that marks it as secondary construct (again this module contains information about initial vessel borders and design),. In this case control over all the system always is granted to primary ship, secondary ships lose control over systems, except turrets or some modules that can be operated by direct interaction (not from cockpit), that means primary ship just becomes bigger and have more modules. In other words, even if this vehicles can be operated separately, you should design them together or at least considering properties of each other. In attached state you cannot modify any of the vehicles, when you want to separate them - constructs are split according to information stored in primary/secondary determining modules 

That's exactly what I tried to explain earlier, I guess i explain it wrong

[Attach a ship to another]

33 minutes ago, NanoDot said:

Attaching one ship to another would have implications for the flight physics. Which pilot seat will be the one that controls this new unit ? Which CU will govern the attributes of the construct ?

 

If you "attach" 10 fighters to each other, should the resulting mega-fighter still fly and maneuver like a fighter, or should it now perform like a battleship ?

 

On 05/10/2017 at 4:24 PM, Aesir said:

In anyway, your "main" ship should actually have as many configuration as you can dock things to it, meaning that a chain ship wouldn't be possible unless someone planed every configuration.

You have a main ship, you can dock things to it, it must be pre-defined -> 1 attach = 1 exact construct design to be docked on.
You want to dock 10 ships ? fair enough, you can, but you have to pre-define the behavior of your main ship for any combinaisons.

 

EDIT:

8 minutes ago, Miamato said:

But there should be size/class/mass limits for it.

also this, because one attach must have a limit of weight.

 

EDIT2: It wouldn't be very convenient if you want to do a mother ship or something like "automatic fuel swap" or any "small" module swap. It may have some rules like : if the attached DCU is 3/4 times smaller than the main ship then just set the attach to weight a certain amount, wether or not something is docked to it, in the scenario it wouldn't be very realistic as a mother ship would have the same weight with or without its drones, but that simplify the process a lot.

[Rails system]

Actually I thought about this kind of things also, rails would be nice but before I wish to have 3d movement with : translation, rotation and ... patella ? not sure of this one in english, in french it's "rotule" this is just the basic Linkage : https://en.wikipedia.org/wiki/Linkage_(mechanical)

this is what you want for doing such a thing:
 

On 05/10/2017 at 5:58 PM, Vellnn said:

 

but they probably already planned it as in the E3 demo they featured a cargo door opening from the giant aircraft.

[Poll: Space Narcotics]

On 01/10/2017 at 6:41 PM, Asmodeus said:

The idea of narcotics might seem like a cool idea initially but it would have a negative impact on the games publicity and player accessibility. I feel that their should be alcohol and other items that mess with the camera perspective and such but that these items should not have any feature that is not purely cosmetic. I don't think it would be good for dual universe to appear that it is promoting some kind of illegal drug.

 

I know it seems like a fun idea but I would rather DU didn't give the media any kind of big weapon to use against it.

this, plus i hate temporary effect by nature in every games
I just hate when someone basically have less skills than you, have the same character/ship than you, but took hundread of pills and go to god mode. I also hate when games start to rely on this kind of consommable.

And i'm not a big fan of narcos, side undiserable effects are not worth :x

 

But, if it doesn't provide huge boost and is not called "heroin", i can certainly deal with it.  

[Raming ship]

1 minute ago, wizardoftrash said:

Play Space Engineers, its built for that. DU isn't

Hooo but hasn't DU the right to be cool as well ? It still adds another gameplay mechanic, whatever if the other games has it or not, I think it should be cool in DU

 

Anyway, i'm pretty sure a simple (technically speaking) ram weapon would be nice, not sure how to make it works, their is plenty of options, it could also be activated only when you reach a certain speed and therefore get rid of the dash mechanic, etc ...
 

[Raming ship]

I do agree

 

We can get rid of the dynamic damage and just do it as other weapons does.

 

But wouldn't be so cool to ram into a ship and split it in two pieces

[Raming ship]

1 minute ago, wizardoftrash said:

local point of impact.

you do not have a local point of impact when considering the weapon, either you hit or not.
you may have a local point of impact when doing the physics of bouncing, but this is not related to the weapon itself, its about collision in general.
 

 

5 minutes ago, wizardoftrash said:

My concern is that a ramming implement would be challenging to balance against other weapons, it wouldn't tie into character skill trees well, and it would be hard to use. The payoff would be that a person could intentionally build a ramming ship, but that wouldn't satesfy the "ram stuff with garbage to grief" players, and it might not even satesfy the players that would use the implement.

 

It would be a risky thing to burn dev time and energy developing, when instead they could make melee weapons that behave exactly like other weapons, which would take less time and energy and be effectively similar to ramming implements. They would be effective at the same range

Hum, i don't see the point, maybe i was not clear, but this is basically a "normal" melee weapon with instant damage which have also the effect of dashing forward on a little range.
I don't think their is anything different from a normal melee weapon despite the dash part.

 

In another hand, melee weapons are always a nightmare to balance properly, so I don't expect them too soon.

[Raming ship]

1 minute ago, wizardoftrash said:

At that point, wouldn't we just call it a "melee weapon" for a ship, rather than a ramming weapon? Because if the damage is based on mass/speed/point of impact, then it will end up using a totally different set of calculations from any other ship-mounted weapon. As soon as ramming "requires" a ramming "weapon" to be effective, you might as well just have a class of melee weapons for ships (like beam cutters, pile drivers, drills, etc).

yes sure, but we can still have the collision physics added to this I guess. You don't have the assiocated "collision damage" but you still have the physics for collision.

[Raming ship]

Just now, Vorengard said:

That's fair, but you'd still have to balance it so those Ramming elements are expensive, to prevent the same abuse of suicide mechanics by numerous and/or wealthy organizations. 

Could be just a matter of price/size/mass of the weapon, if you wanna do massive damage you need a very expensive ship.
In another hand, I don't think that ramming should be allowed on static construct.

[Raming ship]

Hey guys, actually ramming mechanic could be a weapon type rather than a physics compute. You may have a ram weapon, you lock your target, if you are going in the right direction (to be defined) then you can activate the module and the damage could be a certain amount of damage either a fix amount or a computed one, let says something like :
"your ship mass * your velocity / target ship mass"

[Attach a ship to another]

1 hour ago, ATMLVE said:

Aside from that, in this thread I think we're talking more so about literally merging two constructs into one, to basically add to the original construct, rather than just put on a temporary part.

That's right, it should not be opportunistic docking, but rather something "planned" ie: you expect your ship to dock or to be docked by a certain already defined other DCU. But it could be unique in the technical point of view, but still exist several exactly same DCU construct you can dock with.
For example, you may have a big ship having a smaller one docket bellow your wings, if your small ship get destroyed you can still buy or rebuild the exact same according to a template. But you cannot dock anything you want, it must be the same.
That could be a rule to eliminate the chaining issue maybe. Altho, you can just says as JC said, only dock a smaller DCU to a bigger DCU.
In anyway, your "main" ship should actually have as many configuration as you can dock things to it, meaning that a chain ship wouldn't be possible unless someone planed every configuration.

[Raming ship]

2 minutes ago, CaptainTwerkmotor said:

WMD weapon

what's this ?

 

4 minutes ago, CaptainTwerkmotor said:

Thubg is, NQ doesn't want the extra load on the servers. Understandable.

Yeah right.

[Attach a ship to another]

Hi guys,
I heard NQ will think about an element which allow your ship to be "docked" to a station, like some kind of plug in/out system.
But wouldn't it be cool to have a a ship attached to another ? Like if you have a big one you may want to attach few smaller ship to it or any DCU construction. If you can even make the LUA script interract with different DCU it would be a whole new world of possibilities... Like automatic fuel reload or reconstructible ship, would be a great thing for the market as well as you may upgrade just one part of you ship very easily (let's say new thrusters) as long as they are provided by the same company or so ...

[Raming ship]

As we know there will be collision damages, I would love to see a Ram element, could be a weapon or some kind of special plate you put in front of your ship to protect it from the impact. What do you think ?

[For Pre-Alpha testers only: Saturday 30th Sept - FAQ]

1 minute ago, Akanixon said:

I know

 

Be carefull tho, if you can access it than you aknowledge implicitely the NDA

[For Pre-Alpha testers only: Saturday 30th Sept - FAQ]

2 minutes ago, Akanixon said:

One thing, i dont have Pre-Alpha Tester and Gold Founder Group in the forums but i can acces the Pre-Alpha Section, how?

 

 

can you ? this is not the pre alpha section

[For Pre-Alpha testers only: Saturday 30th Sept - FAQ]

Point Is, i have a birthday party to attemp tonight, if they delay it too much I will not even have time to put a feet on ailoth :'(