Wicpar
-
Posts
208 -
Joined
-
Last visited
Posts posted by Wicpar
-
-
Both planet Entropia and Second Life had stock markets at the some stage. Both were shut down by government lawsuits. Both faced multi-million dollar fines if they continued. No company has tried since. It happens to be illegal world wide. Government's do not differentiate between real and virtual markets because the both are electronic and can be just as real in terms of tax, fraud and latter may show up the real thing. The bitcoin markets are fighting hard but it's costing a lot of real time and money. Even voluntary lawyers cost money.
It has also happened in other fields, i.e. hacking in games: http://www.sjgames.com/SS/ Governments sometimes can't tell fiction from reality.
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.
Thats nuts, trading stocks for an in game organisation is the same as a real life one in the eyes of the law? What's next? Am I going to have to declare my income from space piracy on my tax returns to the UK goverment?
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...
-
How hard is it to alt tab, I would prefer to use chrome
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.
-
Are you the Borg?
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)
-
The detached voxels on ships will be needed because the elements etc will fill the gaps. You don't want to waste mass by putting extra voxels inside the elements to bridge though them. You don't want clipping artefacts.
In landscapes floating voxels and floating mountains are a consequence of wanting caves, without them all caving in randomly and becoming ditches. On world generation many cave generators produce either artefact: small and large floaters; Generally at the point where two or more cave propagation processes collide with each other or the surface mesh. It is less of a problem if you have mining as the only way to create a hanging voxel.
In some games only some voxels can fall. The minecraft solution but you could add one that is stone not gravel or sand. (falling blocks actually comes from dwarf fortress) Hit that gravel and the gravel above above falls. There is a catch the JC mentioned in more than one interview. Every falling block in minecraft is three voxels: top falling, mid falling and landed. Mojang, I believe, is now optimising by creating one falling block with an inventory that can hold any other block and spawns it on landing. However it is still a lot of block up dates. Lag and desynching in multiplayer with lots of falling blocks is bad, and that's with 1 metre blocks.
With 25 cm blocks it is worse because our mining tools will not be the same scale. They will be 2-3 m spheres not one voxel at a time. A single 2 metre deletion leaves ~200 voxels with air under them. If they fall that's 600 falling voxels! and then the one's above them fall, another 200 and so on. A recipe for massive lag even in single player game and this is a multiplayer game.
There are some solutions but they are mostly not alpha or beta stuff. You just can' t test for every voxel in the world. We could not even test for every surface voxel [can see sky]. There are too many of them.
- We could in theory test for every floating voxel at high LOD to clear some extremely large floaters.
- We could make caves, and world gen tunnels propagate up into the sky far enough to kill most small floaters. Some floaters are a consequences of the cave algorithm ending at the surface. This would mean fewer over hangs at cave entrances.
- We could make the corner voxel in each chunk unmine-able without special tools and no drop. We could make caves also not able to remove this voxel in world gen. This would create a support grid to eliminate large floaters.
- We Should do a closed surface test only in the forward arc of the player out to 30 metres. This reduces the number we are working.
- It change could thus count as a player made change even though the player does not see it. However in some terrain that will add up fast.
- In the context of 5 we could do a migration test on rock and dirt. Any voxel that can see sky and has air under it turns to an unstable state voxel USV. This then infects any rock near it propagating, if it meets another USV it will Spawn a columb of voxels in all air voxels below. USV time out after 5 cycles. This may be a player proximity up date and count as a player change. This may wall off some caves.
- Or in the context of 5 we could do a per cent air in sphere volume on any voxel that can see sky and has air below it. And despawn the voxels if The percent air is two high. This would smooth some terrain a lot. That may kill canyons, ledges and edges.
- In mining we could replace the falling voxels with a sprite cloud and just delete some voxels above. Then create a rubble voxel on the floor. Add terrifying noise. This even worked in a mine in Second Life! All done with prims.
- We could do the above tests 5 & 6 and spawn vegetation or rock piles to hide small floaters.
- We could add a super cheap gravity gun that allows the players to delete any offending floaters at long range.
In short the floating voxel bits and pieces are needed on ships.
It's not needed in the worlds but they are hard to eliminate in world.
It can be done only if you segment the job down to the local player movement/ changes level.
But you can make it an 'unconscious' player process.
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 boredWell, when you don't have 12 hours of free time in a day to binge a game to progress, a skill system that allows players with real life obligations like a job to enjoy the game and progress as well.
As someone who works 50 hours a week I see it as a positive.
-
Monster of a machine = AWS Cloud-based hosting of servers. You know, the reason this game is so amazing? Wait... you knew that part about JC Baillie and his revolutionary server tech... right? >.>
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 outbut you still agree that air data within spaceship, by any mean should be calculated and associated to the ship, and diferenciated from the void?
.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!
-
Consider that AI turret defending your base.
Which client does the script run on?
What does it do when you log off?
Does the script actually run on the attackers PC?
What happens when you have two attackers?
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.
-
Floating voxels, hum, but no i cant make me the idea how the computer will decide if it is linked to an other object or not
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.
-
i would like to had the fact that creating any matter would requiere previously gathered matter
so the self replicating bot, could only be possible if you can incorporate to it an inventory
If can add the self mining functions, then its the end of the world
i think self production lines are more conceivable than self replicating stuff
Unlike in SL where you could put the object itself in its own inventory and rez it indefenitly
Sarah Connor?
with self replicating bot i imply an automated mining/crafting production chain behind of course (which is most of the work).
-
no need to be so rude, all this (voxels, mmo, space, politic) is a big discovery for most members
you sometimes, even for me, hard to follow because very pointy, that is very precious during this pre alpha periode for dev team (if they read all what you posted)
dont expect all members have same knowledge as you, and sometimes you should find better words for your explainations
there are tons of absurdities and misjudgement in the forum, but its like that
please take more time to teach what you know and can bring us
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?
-
Star Trek also has ships that, within less of a timeframe of this game's backstory, are able to reach speeds thousands of multiples of c. It also has a limit (8000c) where if you travel that fast, you're somehow everywhere in the universe and it takes no time to get anywhere. Also whenever the various Enterprises get hit with photon torpedoes the bridges shake.
Trek has some ridiculous concepts of its own, at least.
Enormous battleships shouldn't ever be able to fly like fighters. If they could, the fighters would probably be zipping around them even faster.
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?)
Ability to build on a moving ship? technicaly feasible or not?
in Builder Forum
Posted
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.