Wicpar

Full blown Blueprint Editor
 
OK there will be trade able BPs (BP=Blueprint) we knew that already and we will be able to "print" them.
And JC mentioned somewhere there will be a "testing" mode.
However I think there is much more potential in a good BP ecosystem.
 
Since it is very very very annoying to build only in first person view for some people. (Like me, an engineer who loves good CAD software)
I'd rather a have good editor which allows me easy access to all voxels, elements and tools like a x-ray view or a quick access to the elements for scripting.
Don't get me wrong here, the FP building is vital too and also needs love :-)
 
 
A little example to demonstrate what I'm bitching about, building a big box:
First person:
Select box tool adjust size, look at your starting point click move physically around until your view and the box size matches what you want to accomplish, click again.
(I acknowledge that first person is better for polish and details but that is it)
Editor:
Click and hold on the grid, move mouse for x/y size, scroll the mouse-wheel for z and stop holding the mouse button, done.
 
 
DU is a game where we will be able to build fairly complex constructs so we need good tools to make that enjoyable.
If you want a bad example how it's not done look at SE, building constructing stuff in the survival mode is painstaking annoying,
you can't make fast iterations or changes of your creation to find something that works or/and looks good.
(The actual building mechanic is rather enjoyable and hope DU will have something similar)
So to make live easy a good editor is a must. But since we have so many aspects already and to avoid a sensory overload of its users only "one" editor won't cut it and several "modes" should be available.
 
What the editor should support:
Voxel mode
Element mode
Painting mode
(Prefab and)Planning mode
Simulation mode
 
 
Voxel mode:
Well all the tools to shape the voxels to your hearts content.
It would be nice if the simple forms had handles for manipulation similar to those found in vector programs.
 
Element mode:
Designed for easy clean access to the parts list and friction free placing of the elements.
 
Painting mode:
Yes a dedicated mode just to bring out the artistic side in you.
No seriously, I personally, I don't care much about the paint job but a lot of people will do.
DU is going to be a very social experience it is in my opinion vital to give people the option to develop color schemes for their fleets.
(Feature wish: the option to load SVG files as decals, allows to put logos and such on your ships :-)
 
(Prefab and)Planning mode:
This mode is for managing and adding the brains to your construct.
It allows you to access all scripts/elements, setup limits/properties of the moving parts,
define areas/spaces for a use case, setup the access rights,
manage and create prefabs/templates for easy use later on and
allows you to select a area to move it around(cut, copy and paste).
 
Simulation mode:
Well a mode to test all the stuff you just made to confirm that it works before you put all the resources and effort into building it only to discover it is a total failure.
 
 
A live version of a BP of each individual construct should be contained in the core block so you can easily access it, make modifications or copy it for sale.
Once you made changes to the "live version" and hit apply you only need to grab your building tools to disassemble/reassemble your construct without the need to constantly fiddle with your tool bar for the right parts.
This mechanic would also allow contractors/friends to build your construct since they won't need access to the BP only to the building site.

Hi, welcome to mathematics. Try to calculate the surface area of a sphere with 100 km radius.
 
 
See, that planet, has a much larger surface area than Great Britain combined. See how many people live in Great Britain. Then look at how many people may end up playing the game.
 
 
Boy, math are weird, no?
 
 
Planets are perfectly sized. There are people with actual knowledge of math out there that calculated that.
 
 
Not to mention, you clearly missed the point of other planets existing on the same star system at the beginning.
 
 
 
When your teacher told you that math will be useful at one point in your life, THIS is what they meant.

Pretty sure that Aphelia is intended to act as a tutorial.
 
The Alpha Team will be acting as a model. Not quite the same as a tutorial, but, the Alpha Team will be working out how to build cities and how to guide newbies into guided gameplay.
Organizations should want newbies to help complete specific objectives.
I suppose the challenge for the devs will be designing kills in such a fashion that newbie skills retain value.

The point is, if there's "magical inertial forces removal" in the game, ships' mass plays no real part in the crew it has and/or how maneuverable it may be.
 
Take a battleship's hull and armor, add a lot ot engines, you got a battleship-sized starfighter. Problem? Yes. If I wanted fantasy, I would have asked for playable races as well, like orcs and elves.
 
And nobody even suggested redding out like it's some Star Citizen, World War 2 in space logic. We're talking for subtle things, like the crew experiencing a hinderance in movement speed and pilots getiing stunned if they pulled a very sudden turn.
 
Except if you want a 10 kilometers ship doing flips like it's a ballerina. Cause Cthulu knows that's not ridiculous. If a dreanaught can do a flip like it's a trained dolphin and can absorb the inertial strain exerted upon it, I don't believe there are many a weapon that should be able to damage it, safe from some black hole emitter weapon out of Star Wars' "science".
 
Good navigators for large ships? Nah, who needs them, everyone can do pitch perfect turns. In fact, every turn is pitch perfect.
 
What? 300 megatons accumulated mass on a ship as it goes 0.5 Light? Wut R diz physix stoff? Ninety degriz turn, no problem. Crew nut ded, lyke in rial phyzix.
 
 
Again, no G forces, no real reason for fine tuning in Lua scripts.

we are borg, the metaphorical cultish-space-commies.

i would say otherwise, first, you would have ways to counteract it with skills and ship modules, second, it allows for a more fine tuning of the balance of agility builds, thing is agility builds with the current theoretical system are OP, and will be nerfed in other ways that will make them less fun like limiting speed with skill, or else. anyways the modification will result in a linear downscale. G forces would allow for a logarithmic reality based (not stats) progression you can mitigate in various ways. The problem is not if you will die, it is how will you integrate your modules that prevent this.
 
You assume just G force is the end of the story but no. everything is connected. if you remove such a deep feature (deep because it changes the most basic mechanics and affects vastly every player) you also remove the interaction it has with all other aspects of the game, like ship deign that would need more thinking, industry to create the most efficient anti-G-Force module, battles that could be changed by propulsing ships too fast with tractor beams and killing its crew, destruction of probes too close to black holes, death upon impact on physical objects, ship ramming.
 
and i think there are more.
 
thing is it is a complexification agent, in the early game you buy a anti-G-Force module and that's it. later you will have to deal with it way more profoundly, in nearly every aspect of DU.
 
Thing is control over it has to be provided, but you have to provide enough for it, and if you don't you get punished, but you can use it against your ennemies.
 
This could even generate a new kind of weapon: a graviton well, that accelerates a ship into a singularity and then stops it dead in the center thus creating immense G-forces, the weapon would have a depth and radius relative to the energy used, so for instance a death star sized ship could easily gulp an entire fleet, but most fighters in it will survive because of their improved G-Force resistance.
 
That is the extent it can affect the game. It's not just a matter, dam i got squished, it's a matter of how can i use it to help me and destroy the ennemies.
 
and even more could be extrapolated if thought enough about it.

And that would perhaps be the way to "upgrade" components in the first place, simply using better materials to make a new version which is better than what you made with more common materials. And like you say, depending what you use you get different stats... So if you use a magnetic resonator you get high damage and low range, but if you use a dynamic oscillator you get longer range with less damage. Two equal components, using slightly different amounts of rare materials, but of course you have to choose between one or the other.

uhm.... people? ever heard of dual contouring (for the ones arguing over the enormounsness of the 25cm voxels)? they use that in DU, this allows for some degree of detail withing the 25cm volume, like slopes.
 
the point is a data point and a voxel are not exclusive, in the contrary. a datapoint is not a voxel, but a voxel has at least one datapoint to be able to be rendered. Euclidion has never demonstrated physics or real time modification, thus cannot be considered a voxel engine, but rather a datapoint visualizer.
 
if you want higher fine tuning of your structures i have already said in another post we could have custom parallax/bumpmap/custom shader textures and that would be feasible as option for people with monster rigs. Opengl is quite versatile in that manner. it would even be possible to use tesselation and a 3D texture to determine custom voxel interiors, or even raytraced voxel interiors for fractal effects.
 
all that is feasible. depending on their rendering engine, if they have enough control it could be implemented in 1-2 sprints.

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)

one dollar a day keeps the assholes away
 
that's why there will be a subscription fee, it filters people that want free fun by ruining other's

their tests seem promising, i wouldn't worry about that. my argument was mostly that there is no point to further reduce voxel size, and then proposed alternatives that would be cheaper.

I can't help but think there NEEDS to be the ability to have server side scripting in addition to client side.
 
Here's an example using the "Trains" thread.
 
A player spends a tremendous amount of time and energy to create a train / tram system.  They're going to want to make some credits off their invention.  This means selling tickets (granting limited rights) to ride their train.  The user would most likely have to use a DPU to perform some basic logic to detect those rights.  (what are the odds of  creating the train WITHOUT using custom code and a DPU)
 
In order for the Train to work while the player is offline, the solution needs to be scripted server side.

and even then you could use bots to do so if implemented.

Hello,
 
I cant help notice that models have a fixed scale and cannot be voxel modified. It could be an interesting mechanic to have a scale modifier that increases size of then model and the stats, so you can make tiny bots to run around conduits and repair your ship. The models are 3D and the scalar is 1D thus would have to scale to the cube to be realistic, with a linear loss function according to abs(original scale - scale) * balancingTweakingConstantScalar.
 
this would allow for quite interresting things like gigantic reactors, massive guns and tiny bots.
 
I hope you like that idea

api. complicated. cannot connect. both are mutually exclusive.
the thing they have to do is create a log-in system for accessing your personal stuff, and then use a token to access the rest. They may limit these by setting a per second interaction quota. this is really simple stuff, and data integrity can be checked with the bazillion of libraries already existing.
 
Please people, stop saying things are too complicated, because most things aren't. The most complicated thing they do right now is the voxel system, which requires quite complicated algorithms to handle the octree and dual contouring. This includes the physics. and even that is reasonably feasible.
 
be positive, don't limit yourself by underestimated technology.
 
please excuse my frustration.

This is actually a really good idea.

Having the ability to scale let's say, an engine, would result in a less powerful engine, but a smaller engine! It makes perfect sense and is highly possible (I think) This would allow for tiny drones and probes that could act as sentries, scouts, and so on!

Great thinking, Wicpar.

Hello,
 
I cant help notice that models have a fixed scale and cannot be voxel modified. It could be an interesting mechanic to have a scale modifier that increases size of then model and the stats, so you can make tiny bots to run around conduits and repair your ship. The models are 3D and the scalar is 1D thus would have to scale to the cube to be realistic, with a linear loss function according to abs(original scale - scale) * balancingTweakingConstantScalar.
 
this would allow for quite interresting things like gigantic reactors, massive guns and tiny bots.
 
I hope you like that idea

Imho that is not a good idea. Why? Because people will get extremely serious about making money out of the game, and if credits have a value irl, people will buy a lot less materials/ships/blueprints, and limit their experience, their fun (and would limit the economy, that is supposed to be a huge part of the game). DU is supposed to be fun, knowing that you're using credits that have a irl value, for everything you buy (that you could have saved by doing it by yourself), is not a good feeling for many. 

They are called humans and they are an integral part of an MMO.

I plan my ships in MS Paint, because Im a daredevil and all that stuff. I also code C++ in notepad, because yolo.

Paper and pencil.

The OP specifically addressed my concept of sensor "areas of influence"
 
A basic sensor would provide the "ObjectIDs" of everything in that area.
 
I DO like the idea of active and passive.
 
I also like the idea of detecting space-time curvature and tachyons.
 
I think ADVANCED sensors could provide additional data such as the object's vector. (This could be computed by the player at the DPU level too)
 
It would be nice to have different "icons" for the sensor display. Different sized dots, arrows, lines,etc.

I would concurr on half. each ore has a different random chemical composition. after that you can extract all different materials in pure form and then synthesize the molecules to generate the materials you need to build the ships. this would not only be quite a depthening experience, but could also tech people about chemistry and even help researchers discover new molecules if the system takes in account actual physics. (like eve did with the cell thing, but in a useful in game way.)
 
But we can go further, instead of requiring one precise molecule, you could need a family of molecules that have different stats depending on the variations, and thus let you the ability to min max it to make the best products you can, imagine a game where there is actual scientific-ish research involved as a game mechanic!

Hello Dualiers,
 
The plan right now is (according to what i have seen and heard) to have a stats based locking targeting system. it is extremely cheap. too cheap. the problem with it is that the battle becomes more of a dice roll, as can be seen in eve online. You target point blank on a battleship (miss) wtf... these kinds of things are frustrating.
 
there are tons of ways to contour the problem with kinetic weapons and their delay, the easiest way to reduce performance drain is to handle them like a shell + their movement, it calculates then an intersection on that 4D-ish object (it is in practice flattened into 3D) every frame, not more expensive than having a player. then you can put a limit in the form of reloading time, real battleship shells take 10-20 seconds to reload in best of cases.
 
besides that, lasers are practically free, but do less damage, and have tendency to overheat so you have to stop them quite often if not reducing their lifespan considerably, and use a lot of energy.
 
you get the idea of the gameplay implications.
 
this system would allow to handle all weaponry shots in one container, thus reducing development costs and code base pollution risks.
 
this is mostly important if we want to make weapons interact between planets and space, as punching a hole in a vessel in space would be ludicrous from the planets surface. and what about 1000mm planet-space cannons, do these not ark? 
 
in addition to that this system would allow for massive increase in need of good targeting scripts or canoneers (there would be visual aid for players (can be cheaply calculated with raymarching, but  it is relative t the memory architecture you chose for the physics mesh, if there is a phase where it is static in the loop, it may be worth it to do it asynchronously in a separate thread if it is the case)
 
eve online opted for that system because it uses 1 second ticks, i don't think you work like that, and if it is the case there is no advantage to it except a relatively small amount of computations, as you would have to determine the voxel to break anyway...
 
and what about people who want a fast fighter with Gatlings? locking would be so unsatisfying, especially if you target a starbase...
 
but anyway, this is my opinion and my vision of locking may be wrong.
 
hope you find this idea interresting .
 
just remember, my point is control vs simplicity (pro control).

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