Wicpar
-
Posts
208 -
Joined
-
Last visited
Posts posted by Wicpar
-
-
that's a man with vision, operating drones from inside the ship to repair on the outside.
well borg do...
-
Unless you plan on building a ship as it flies, you won't have any problems :V
and even then you could use bots to do so if implemented.
-
the most likely scenario, is that newbies will manufacture stuff before they are recruited, this way they do not need to mine and only need a small plot of land to install production machinery, this way not much degradation and easy maintainability of the law with plot permissions.
ideally you would have a protective bubble generator for that, that is invincible only within the confinements of the arkship. you should be able to pass those but node modify or interact with things inside.
-
I know that the modifications to the procedurally generated content is what's actually stored (it's a clever idea to keep used server space lowered) but having more voxels to track per unit volume still increases the amount of data that needs to be transferred. As you pointed out, there is some workarounds even within the 25cm space but I think that needlessly decreasing the voxel size isn't worth it at this stage when NQ isn't even sure how well their tech will handle all the players.
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.
-
Sorry to be that guy, but the earths crust is only about 50km thick at its thickest points and about 5km thick under the oceans. The worlds deepest mine is 3.9km deep and it gets up to 60c down there.
https://en.wikipedia.org/wiki/Crust_(geology)
https://en.wikipedia.org/wiki/TauTona_Mine
"By 2008, the mine reached 3.9 km (2.4 mi) underground. This made it the deepest mine in the world, surpassing the 3.5 km (2.2 mi) deep East Rand Mine by a considerable margin. This new shaft extended the depth from its previous 3.6 km (2.2 mi), and will extend the mine's life to 2015.[3]
The lift cage that transports the workers from the surface to the bottom travels at 16 metres per second (36 mph / 58 km/h) so together with traveling on horizontal trolleys the journey to the rock face can take up to 1 hour from the surface level."
"The mine is a dangerous place to work, with an average of five miners dying in accidents each year. The mine is so deep that temperatures in the mine can rise to life-threatening levels. Air conditioning equipment is used to cool the mine from 55 °C (131 °F) down to a more tolerable 28 °C (82 °F). The rock face temperature currently reaches 60 °C (140 °F)."
but we no primates like petty humans, we 2.0. death is irrelevant, dangers should exist, and solutions too. we can create a death star, why not mine in the hellish core for pure nickel. and what about dead planets with solid cold cores?
-
I don't think anyone knows how the LUA scripting is going to work. I've read the dev diary before but it did not really explain it in a way I could get my head around it seemed to be a modular plug and play where elements have inputs and outputs rather than something like computer craft.
yes i think so, but these are internal to components, having a dedicated component or a system like in Applied energistics to handle global construction ai, even offline, would be quite handy. Computercraft is quite useful for full fletched AI, but isn't needed for detection scripts or other things that are straight forward IO. for now only straight forward IO is planned.
-
right know there are not stuff like that (radiation, temperature, ...) but i guess wouldn't be too hard to add.
this is implementation dependant, it is likely they thought they might need that in later times thus have provided for the hooks necessary to it, thus reducing the production cost.
The easiest way to implement would be to do it atmosphere relative as it would be detected anyways and would only need to be hooked on the enter/exit event. Then there is the whole damaging/post processing for the different illnesses/damages that would take the most time in that case but would be a fixed element separated from the implementation part.
-
Indeed. Servers aren't some magical item that can run anything, just like our computers. Depending on how each voxel construct updates, it's performance, and the tasks it performs, it will affect the server differently. So, we can't simply just state that "yeah, microvoxels would be cool". We need to add the process of figuring out the impact on the server, deciding what these should be used for, and so on.
Each game has a development process. For DU, it's coming up with the ideas and systems, seeing if it's possible to create them, and then figuring out if they can handle them. They come up with so much stuff, but do you know how much stuff they've had to get rid of because it wouldn't be feasible? Not just server side, but client side. Every client will be more taxed the more stuff you throw at it. What would Microvoxels add to that stress?
The answer is, they are possible to implement. They would probably have to be restricted, but you could implement them. However, I'd rather see the game be here sooner and in a better playing state. Not to mention, I feel that already, we'll have the tools we need to create what we want. It's cool to have extra, but how many till we've reached a point where it's just not worth it.
dude, you have everything in the wrong way. First you worry about the idea, then you worry about the implementation and then you worry about the hardware cost. Servers ARE these magical boxes that can do everything and ARE like our PCs.
If things are not done in that order you cannot know if the idea is worth the costs in the first place and thus may miss on opportunities and even decide on implementing a stupid feature. you need to know why you do something before you know how you do it and then know what you are doing on the servers. If you start in the servers, you will use a raspberry pi to print hello world! instead of having a good DU experience.
I did the calculations for the cost/win ratio of a cuda computed space battle for 2000 people on the server side, and came to the conclusion there is no reason to limit the development cost as GPUs are cheap as hell nowdays, and cuda is extremely well implemented/documented and allows for reusability of cpp code which allows for an easy implemenation of cuda computed physics and other things.
-
Most people will have ships a few dozen metres long at the smallest, and I'm sure some organisations will be making enormous transportation vessels and capital ships that are kilometres long. With such enormous constructs and huge amounts of 3D space to keep track of on the servers, you want to make the server load more strenuous by subdividing the already quite small quarter of a metre blocks to something even less? Most things that one would want to build at that size is probably more suited to being an element to save on space.
they said they bake the meshes continuously, thus only modifications impact performance.
-
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 concur with the non regeneration pact. the planets will never be entirely uglified, as it would take too much time, but people with creative minds will probably more likely to say in one place for longer, as griefers have the tendency to be short term working people and loose interest easily.
-
yes, non incremental scaling might cause OCD problems with gaps, thus the scale should increase in 1 voxel increments, but still respond to the non incremental function to guarantee an analytical predictability of the stats.
but... i disagree to have it too straight forward: it is just too predictable thus boring. having some degree of uncertainty depending of the quality and nature of the material would be quite fun because it would have an exploration aspect to it. (not necessarily the higher quality the better, just more variability in the stats with a common tendency to go down but in absolute might be better than the high quality ones because of a rare beneficial impurity, but the advantages should be negligible (the maximum stats are determined by a gaussian curve around a predetermined random quality on the material, and the statistical probability to obtain it is 1/ (1000000 / quality / randomConstDependingOfRarity)).
this is just a suggestion tho.
-
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.
actually scaling models is one of the easiest things there are XD (visually), physically, there may be some caveats if they voxelize the mesh, but shouldn't be the mostly difficult thing to do. The most difficult and long part will be the balancing of that feature, as it cannot be precalculated and has to be found out with time.
-
In the Kickstarter video, JC mentioned that Lua scripts would be client side only. While I agree with the idea, will it be possible if scripts are only client side?
ideas change, if the depth having scrips server side is massively more important and useful for fun mechanics, i am certain JC will reconsider it.
The original decision may have been because of server side performance and not too much usefulness, including the difficulty of filtering malicious code, thus rendering that idea in that way, but if we point out all the benefits, i don't see why they won't eventually change that decision.
-
I think devs should implement only simple stuff, like functions that will allow sending data client <--> server. Creating API, like checking for data integrity, blocking unwanted connections etc., might be up to us.
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.
-
All I can suggest is the way that computer craft in minecraft works is that you can craft a floppy disk drive that you can store your programs on and that lua can read and write files to.
Perhaps you can plug in "storage crystals" into "IO port elements" and be able to access them.
good idea, i would even go further:
you can cerate an extensive AI system with storage, cpu etc... like in Applied energistics, with channels and stuff. Aditionally you would have an API interface to be able to access and modify that system outside the game (could be called Transquantum interface)
-
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
- Dominar and DevisDevine
-
2
-
i agree, to be able to have scripts server side will enable people using multiple pcs to have an easier time.
additionally, you will need to have your base run alone when you are offline anyways...
NQ may not have the need now, but i guarantee they will have it. and scripts are sooo light.
now the only question is: can we have an API for interfacing with the server?
-
i think branches are unwelcome: infinite subdivision is bland and boring, i'd say rather a net as some researches have two or more prequisites. this also can improve complexity thus end game content by setting multiple requirements for some researches, and some have 1/2 optional prequisites etc...
-
the reason NQ will never do that is that there are immense restrictions about money transactions in europe and you have to have licenses, rights, can be sued if anything goes wrong, because you do not play around with money. You can intake money and manage it youself, if it doesn't leave your product it is not considered a currency as it is one-way.
-
dividing the community is stupid, it is just gonna reduce the efficiency of sharing&caring.
there will be dissident groups that will try to do so but these should be reassimilated.
If they cannot speak english, they will adapt and learn.
-
Do you want the Borg? coz that is how you get the Borg
you got'em already. you cannot escape, resistance is futile.
On a side note, there is a way to make those a balanced part of the gameplay:
make them extremely difficult to balance (make replication factories super heavy, make limitations on the cpu usage etc... this would limit it quite a lot but would still be possible. i think it could be a good 'end game-ish' feature that would allow an overwhelming power to emerge and disrupt existing politics, create coalitions, force trust, forge alliances until the threat is over. It would be the best motivation there is: destroy the borg.
they would evolve in parallel, with real actual evolutive AI (not as complicated as you may think). evolutive AI can be extremely powerful if well evolved, but really weak at the start because it doesn't know how anything works. imagine a maggot like intelligence becoming a superhuman one. without emotion. perfect.
with the lore it could fit in if it is discovered later in game.
-
an interresting mechanic would be to make it more dangerous and more expensive to mine near the core but place rarer materials there.
-
using a modified version of makdown would be quite usefull, or be able to present them with html and/or lua scripts for speech etc...
Poll : G forces, should they have an effect on a ship's pilot/crew?
in Idea Box
Posted
Sad to see you don't see how deeply this feature affects the gameplay in a positive way. It may be less comfortable for the individual but it creates jobs and tightens the community together to fight the laws of nature.