Wicpar

that is a simple solution, but the best way to do it in my opinion is to disable the offensive systems while building in designer mode, in real block placement, the AOE of the weapons will probably kill you. This would allow for people to repair their ships to some extent while fleeing thus increasing survival rate. it could be extended to removing the defensive capabilities too, except the ones that are projected onto it from another construct/vessel (star wars VI with the endor shield generator), if that fleeing construction seems to be OP.

they did it with real money, and that cannot happen. the question here is with in-game money that cannot go out IRL and that is done byquite some games. Companies and Politics get really scared and angry when they don't get their share of the cake, that's the sad world we live in... Using their power to bully people to take away their legitimate tax-paying profit. They either want that for them, or want to keep the money in their country...

alt tab can create quite some in game instability by forcing the game in the background during important calculations, and fixing that is harder than implementing a browser.

no, we are

NQ uses a GUI engine that fully supports .Net thus can host a browser without any effort whatsoever (you still have to make the window border but I assume they already did)

I have seen some people arguing if DU is really infinite, and i honestly don't know, but in theory true infinity could be achieved like this: minecraft isn't infinite because the world center is the center of the map, and thus due to floating point exceptions, the extremes become jumpy. additionally, the terrain generation has been fixed, but before that it was wired because of floating point exceptions too (and an error in the algorithm). recipe to make a truely infinite universe: 1: the center of the universe is literally the player, he will thus always experience the optimal floating point precision. 2: each planet/chunk must have its own plane of reference. no float as position, no double, Big Integers. they will only become expensive once in the 128 bit range: 1.7014118e+38 units, which for 1mm precision, you would have 1.7014118e+35 meters with the galaxy being 9.4607e+17 meters which is 1.7983995e+17 galaxies, so yeah.... try travelling that in a lifetime. 3: have planets in their own frame of reference and organized in an octree lookup table so you can easily get the reference described of all the planets around you so you can query them individually for different precision. lower precision are not generated until needed (the metadata is kept with the planet to resume generation of more detailed features. 4: every enclosing type has an octree of the types it encloses to promote efficient movement (galaxies could rotate efficiently with its people and planets inside) the Intel Xeon Phi already even supports 512 bit operations... so yeah... performance is not an issue... this system allows for a linear performance scaling in performance and memory needs of the world. I don't think NQ has implemented that, since 64 bit sizes already allow for a galaxy sized playing fields, but if they are gonna be around a long time (10 years) they better plan for a system, to use the available performance for optimum fun

the best way to insert them into the lore is you can play an alien species if you conquer their entire world, or do an alliance with them, both should be hard, and those aliens should be insanely rare (.0001% of planets)

there is a simple solution, and a minecraft mod already did it. This can only be used for terrain. when a block is updated it tests in a circle of voxels directly underneath him if there is a connecting voxel, if there is it doesn't collapse, if there isn't it falls and reattaches itself to the floor. This can be done if voxels are updated after every interaction, even terrain gen. if a terrain voxel collapses, it updates nearby voxels. here is the terrafirmacraft post

maybe for you, but what about hardcores? You cannot expect the same patience from every player, and if they are constantly limited for the sake of the unavailable players they will get bored

even aws doesn't necessarily have servers powerful enough. Those mostly use xeons that are good for long term computation, but have a low clock, unless they manage to multithread everything very well they will probably need to use the 8 core 4Ghz intel cpus, and possibly with gpus for computation. I have looked up the cost of dedicated rack rentals and those are around 200€ a month for a 5 unity tall rack, thus could build their own server for a total of 20k, that would cut the cost long term, as aws uses teslas and xeons that are hellishly expensive and not needed since their price is justified by ECC support (it isn't required as cosmic rays extremely rarely hit the hardware, and even then it usually gets absorbed by the casing).

I agree with your idea but not the implementation. Handling it block wise is extremely inefficient as if there is a breach or you enclose scaces you have to iterate over every block and update it. The best way to go in my opinion is to define an area and expand/contract it depending on the geometry around. When you are building, if you create a concave geometry it creates a new bubble that will be void while it is connected to void. When it becomes enclosed, it detects if there is a atmosphere generator or equivalent to insert that gas generated by it inside. This is efficient enough for if you breach a hull generate a force that pushes all gasses and you out . Even then it would be quite expensive but way less than doing it block based.

It may be on the mercy of the devs, devs are at the mercy of us! Viva la CADification!

And what if the attackers hacks and changes the output of your script to make you loose? These are flaws. That is why scripts should be either run on server or distinct from in game objects so you can setup your own server to manage that (raspberry pi or something like that).

nope, enclosed spaces cannot be detected without relative position, but you can detect some cases easily by doing the sum of all faces facing towards the center of mass, if it is zero, it is a simple hollow volume., more complex ones need the position to be able to detect those, as it is the reverse principle from detecting detached volumes i would add too, free octree leaves can be interpreted as void or air, but making fluid dynamics within voxels for those gases is ludicrously complicated, but not impossible. i think it won't come before the final release.

OMG, i got the best idea for an algorithm to detect if there are floating blocks with minimum power: take all triangles and make the dot product to the forward unit vector and multiply by the area and add that, it will always be 0. ∑(dot(forward vec, normal) * area) if not, the mesh has a hole. why? because every real volume ever has a derivative topology of a sphere that has a 0 normal sum. then to detect if there is a separate chunk you do something similar: do the same but: a = ∑max(dot(forward vec, normal) * area, 0) b = ∑max(dot(left vec, normal) * area, 0) c = ∑max(dot(up vec, normal) * area, 0) d = min(a, b, c); if ((a > d && a % d == 0) || (b > d && b % d == 0) || (c > d && c % d == 0)) it has a separated volume guaranteed , but doesn't account for every case... i shall think more about it. for now without taking in account relative position there is no way to know for sure.

Voxels will have physics upon placement right now but ghost images could be considered. I don't think travelling will take months, just making instant travel jump gates will as you will have to tractor them apart (quantum link). Floating voxels will exist, but they may be solutions for the terrain, but not for the ships. We will call that quantum struting when a flating part exists on a ship. But: it is possible to detect if a ship is cut in half thanks to baking (they talked about procedural mesh baking) so i expect them to be able to sample that baked mesh for separation. (There is probably a mathematical way to achieva that). For the terrain we could just detect if the below neibors exist or not and if not detatch the block of dirt and let it fall and rejoin the ground underneath. See the terrafirmacraft mining system for more detail. It is not feasible for ships as the materials are too strong to be able to use that technique effectively even tho it may be adapted.

with self replicating bot i imply an automated mining/crafting production chain behind of course (which is most of the work).

yes, please pardon my rudeness. for your other post, it is an excellent idea, as it is easily feasible since voxels are baked anyway (i think).

I don't understand your need to argue against a feature others like and that does not deprive you of doing yours. Please use objective arguments, or at least ones that objectively justify the non implementation of it. I understand your point but both are not mutually exclusive.

I agree to go with the more complex system. From the depths has an amazing system, that could be combined with material quality to combine stats and create variability.

i disagree, have you tried using a cad software? it's not that simple either. since voxels are not blocks, first person construction will never have the fine tuning a cad has. I have worked with catia and solidworks, and it is not easy to use either, but it is way more precise. you should be able to make ugly ships fast and beautiful ones slowly, as a decent cad does. not having ones will make ugly ones slow and beautiful ones slower to make. it's like the difference between sculpting with fingers or a fine stick.

remember the cobble towers in minecraft? well guess what will happen here...

in the stock market you sell shares to the dividend of companies, you could do the same here, and it would be quite usefull for early funding. Thing is you sell a promise you will share a bit of your revenue from the future.

Shynras, I dont think this is about what it is supposed to be, it is about what it is supposed to do. This would allow for a more comfortable user experience and is in no way a mechanic that can be used to unbalance the game. The only result will be that we will have prettier and better designed ships. why disallow something that hasn't got any disadvantages except the comfort of other people?

my point is it is possible to absorb inertia inside a construct by accelerating the whole construct and its content uniformly, and that is not impossible. (just need to find out how). the star treks ships don't accelerate to multiple of c, they warp the space, effectively it does, but relatively for its content it doesn't. additionally the mass of the vehicle doesn't have an impact on the G-forces of the object inside it, its speed does, thus allowing in theory to have a big ship as agile as a fighter, but would have to expense a ton of energy (cube to the scale of a small fighter) to do so. this would require making very efficient designs and having resistant enough materials to do so. sci fi has a minimum basis in reality, even star trek, and you cannot blame cineasts to make benine consoles explode like they were unstable explosives, or make the bridge shake every time a dust spec collides with the most bottom part of the ship. (it may be explained by their inertia dampeners malfunctioning tho... buy why did they never fix em in 300 years?)