I asked you for your WS submissions and you refused. I have all the right to assume you do not. It is not my fault.
Not wise to make it personal. You just gave me the right to ask you the same thing. Who are you to tell me whether or not I can subject to suggestions. Besides you are missing the point of the OP. There is a poll up there....that's it scroll up and then little more...there you are, you can see it now. Now, can you think a reason why object? Spoiler: ...food for thought. No? Read again the poll until you understand it. Other wise I do not think you can follow what is my argument about. Oh wait. I know now you mentioned it, indirectly : I am nobody therefore I have not right to argue.
I think it would be excellent from a "creative" stand point to increase that limitation. It currently doesn't really bother me, as a size 17 CV is the largest I have ever spawned in a SP survival game, and though it was absolutely awesome to walk around in and explore, it was pretty much over kill for just one guy to functionally use. Now...if having crews benefited ships in some way, the it would make more sense. Or if we could assign AI to "drone" fighters that we had to carry, or any other reason for the additional space other than "it looks cool" then maybe those mega ships would make more sense. And while I love my big ol mega ships for the RP factor of it...having to walk for 2-3 minutes to get from the bridge to the exit gets a bit tedious. On an MP server I could see it possibly being much more beneficial.
@Myrmidon It all depends on which way you look at it. You are using the term 'personal' as you want to be the victim in this. Your statement about telling someone what they can suggest is wrong. Deal with it... Don't play the victim card..
I think the main problem is that this limit is tied with the "voxel" system they use. This has been mentioned a long time ago, some players here relayed that information on the forum. I'm not going to give more details given the actual "negative reviews" context that has some people trying to use all and everything they can find to try to "hurt the game".
Nice idea. But again the current creative should remain as is since whatever is build with this mode is used to survival mode. A special creative where lets say the textures are lowered in detail and without decorations in the playfield, to help with performance would be nice. Then again there is the 3D geometry of the game and the many triangles of anything build, which increased numbers cripple performance. In the imaginary world the limit is increased it will be bad for the gameplay, since performance would be seriously severed. Just spawn something like this https://steamcommunity.com/sharedfiles/filedetails/?id=2171524553 which is well within the block limitations and try to fly around it with another SV i.e. and the CV stationary. Pay attention to the FPS now. Do you like what you see? And even if you do I guarantee there are many players that do not like. I agree that building something gigantic would be an achievement solemnly, but that's it...and maybe a couple of screenshots.
Umm no. There is a POI category specifically on the workshop for builds that aren't for anything other than creative or scenario making. These builds have alien/forbidden blocks that would otherwise prevent them from being used in normal survival.
The limit should be whatever the config file is set to. If someone wants to crash their game or server. That's on them. To say anything else is just arbitrary control, and to be frank, no one's business but the one who wishes to do so. Players who have access to better hardware for both their client computer and the server they play on (for SP they are one and the same), should have the opportunity to use that. There's always going to be hard limits that a program can do. But players ought to be able to push those limits if they choose. Other games handle this by having defaults in the setting to ensure a new player doesn't break their game on their first play. That's fine. But once they know what they can do, they should be able to change those limits to suit their needs.
If a 250^3 limit was made for performance reasons that are absolutely insurmountable, then I think the least that could be done is not a dimensional limit but instead a volumetric limit -- That is, rather than a hard limit of 250 blocks long for any given axis, allow me to place my 15.6 million blocks in any orientation I want. That said, it still is a good idea to have a length limit (because some knucklehead is bound to try to build a 15.6 million block long stick), but servers must absolutely be able to change this length limit, as was proposed by the OP.
I won't get into all the discussions here, I'm just giving you a little insight into the technical aspect, for those who care. Nothing is really impossible, but I'm pretty sure this won't happen. Simply due to major technical reasons: As I've worked myself into the blueprint file format lately during EPDs development, all positions of voxels are defined by unsigned Byte datatype, which is limited to values of 0-254. Changing this to a higher datatype would not only break all blueprints out there, but would need major changes in every single part of the code that handles voxels and blueprints. You just need to think about EVERY SINGLE occurence of a voxel position in the code that would need to be changed to work with the new datatype, as well as all conversions between datatypes would need to be redone. One single simple example is DSL (dynamic structure loading), that has some fixed distance (~500m, if I'm not mistaken) to unload blueprints. Imagine that you would be able to build 10,000 blocks in one direction. Then DSL distance would be need to set to the highest occurence of a dimension in the playfield, which would render DSL mostly useless. And I can't even image, what other code parts would be affected by a change of this magnitude. There simply need to be some hard limits to some things, and they chose to set that limit to 255 blocks in an early development stage. Of course, if there was a 50 people coder team, you could simply take ten people to try and change this in a new code branch and test, while others work on regular development, but a small team like this would need to stop every other development and do nothing else but work on this change. And then you couldn't even tell, if it would finally work out. Changing that now would most probably take weeks to change and months to test and fix all the bugs. And would make the game basically unplayable due to crashes in that time. But one can dream of course. /jmc
I really appreciate the technical detail from someone who's got actual know-how. IMHO, people should maybe be a little less absolute in their demands where they are assuming a feature is "easy", although it's still a reasonable suggestion or question to ask if it's done with a little respect of the challenges of implementation.
this is why I always go with datatypes one step higher than the size i need when i make my own file formats. some guy is gonna want to stress it Yeah that's easy enough to understand. It lets blueprint files stay small among other things, and in the context of the game that does make a lot of sense especially given the existence of the DSL system.
I think the game ( Unity, not the voxel system ) could support much greater distances no problem (computers... maybe not !) if we look at the "actual" limits that we can even change in the gameoptions.yaml : ### Distance at which a structure on a planet will be invisible and finally unloaded if no player is near it. Minimum is 600 # DSLDistancePlanet: 1200 <<< can be adjusted ### Distance at which a structure in space will be invisible and finally unloaded if no player is near it. Minimum is 1500 # DSLDistanceSpace: 3000 <<< can be adjusted They made the small/ big blocks with a 1/4 ratio and the only missing part to make things really cool is the possibility to "merge" blocks from both grid sizes. The blocks already have 1/2 and 1/4 subdivisions and much more in all the shapes we can use, which shows that by either refining each block's definition or simply appending another block's "shape" is all feasible, which brings me to another point I mentioned long ago on the forums : making a "big big block" grid size that would be 4 x the actual CV/ BA blocks. So even with the same 250 blocks limit, we could actually get builds that reach 2 km - just "blocks", no "devices". Then we could "refine" shapes by adding smaller grid size blocks in there. That is pure theory, once again, but just to show that even with a "blocks limit" there could have been other ways to expand the design than by changing the voxel's position datatype.
Finally someone with a brain. I'm certain Myrmidon just has an inferiority complex about how he can't afford a good computer, therefore people with better computers than him (read: everyone here) shouldn't be allowed to voluntarily stress their hardware beyond the lowest common denominator. I'll never respect people who shoot down optional features that won't even affect them if they don't want it to; it's like they think the way they play the game is the way everyone else needs to play the game. Regardless, as a software engineer myself, you and I know that unsigned chars can be implicitly promoted to unsigned shorts, unsigned ints, and unsigned longs, so that's not an issue. Additionally, in a project as big as a video game, you'd expect important constants to be defined in a header file somewhere or by macro, so it's likely that MAX_STRUCT_DIM or something similar is being used to check loop exit conditions and in malloc() buffer allocation calls. Have you by chance gotten to look at a disassembly of the game? I'm asking because as you said, there are a lot of places where this limit would be needed, however, if the dev team foresaw increasing the limits at some point, the project could have been written in a way to make this straightforward. DSL could be modified to check for intersections between a sphere centered around the camera with radius DRAW_DISTANCE and the planes of the bounding boxes around entities, then draw only the entities which have an intersecting bounding plane. The number of calculations will go up, but the algorithm's time complexity will remain the same. The nice optimization here is that once you find one intersecting plane attributed to an entity, you don't need to test the rest of its planes. Alternatively, you can work with vertices of the bounding box instead of planes to check if any of these vertices are less than DRAW_DISTANCE from the camera; stopping once a single satisfying vertex is found. Idk, there are ways that I personally wouldn't consider difficult to facilitate a dimension increase, but I'm not sure how far down the rabbit hole goes and just how spaghetti their code is.
The use of a BYTE to store voxel data in a blueprint is not really a good way to explain the problem space. Saying it would break old blueprints to change the BYTE to a WORD is illogical. It was a mistake to assert this, and I'll not hold that against you jmcburn I am wanting to build a pretty large structure, but I need to use the 1/3 block size because the human-build scale and detail of the MS blocks does not allow the "scale" I am after and the "detail" levels at the same time. So yes if you allow me to build an SV that is physically the same size as a CV/BA, that would do the job for me. Yes the BYTE thing is a misnomer, it's why 16-bit applications can still run on the very good 64-bit O/S's with just a little bit of magic (even 8-bit apps for that matter.)
Most game developers frown upon suggestions like this, I think you already know that anyway. As for the possibility to change anything regarding how the voxel code was made, it's a question of knowing first if they have access to modify it, because if they used a paid package similar to "The Voxel Farm" (just one example) they may not be able to change anything in there. I can make a wild guess that some external assets like these might be obfuscated, for obvious "copyright" reasons.
