Guswut

I'd be interested in seeing how your proposed change would played out, as it could work well to further balance the design of your ship/fleet. Smaller ships that are, on a per-capita (well, per-block as it were) basis, more powerful in firepower than larger ships would then make swarms a fairly effective tactic. With the advent of custom fighters, it might even be possible to make custom heavy fighters (things on the same scale as most people's first builds, etc), and the like. It could also be given as a way to handle "big ships are innately overpowered and cannot be countered except by another big ship" by having small ships able to overwhelm big ships. There, of course, would be the counter to that in that big ships would then have small ships (be it as fighters or fleetmates), and that increases the general complexity. All in all it'd be interesting to see! Yeah, railguns are certainly bugged in that regard, as it makes them FAR too powerful. To the point that I refuse to use them (or at least I can claim that is why I don't use them when I just really enjoy the usage of laser turrets, even if they aren't anywhere near as effective when taking that into account). It could be interesting if they had a slight multiplier based upon the projectile (certain turrets could have projectiles that would be better at piercing, or do more damage but pierce less effectively), or something else of the sort, but the current mechanic is just outright broken. It certainly makes sense that larger turrets will, on average, be more powerful, no? The balancing point would then be more smaller ships gaining more total damage, which should be more economical in regards to certain aspects of the game.

I'm sorry, I was not clear with what I meant. What I meant was a more general question of "Why do we need to try and argue for a specific type of design?" as opposed to why you specifically argued against cubes. I can understand how point A makes you, personally, not want to build them but does it go so far as to mean that you don't want other people to be able to build them/use them as they want? There is no need for the discussion to detail the mechanics that make a specific style of ship optimal (especially as, unlike with the offline world, those mechanics can be changed with ease). I think it more becomes an argument to try and limit a style of playing Avorion based upon a person's personal aesthetics. A similar situation could be attributed to MineCraft's "cobblestone house" hatred. Often times people will build simple structures out of cobblestone, one of the most easily-accessible materials in the game, and they'll receive a great deal of vitriol for doing it. In the instances I can think of, this is normally when a person is playing on a server and the house in question is in "town" or the like. Conversely, I cannot remember a time when it was ever suggested to remove the ability to use cobblestone to make "ugly" houses. In fact, just typing that down sounds absurd enough that I'm not even sure if the parallel is close enough to matter, but it is worth considering. Simply put, it sounds more like you want the game (and koonschi ) to treat Avorion less like a game centered around making a spaceship, flying around with it, blowing up pirates, mining stuff, and the like; and more like a game centered around making an awesome looking spaceship. I don't see a specific conflict so long as it is understood that making awesome looking spaceships shouldn't be directly supported by the actual gameplay itself. As in, you should have to take into considerations the game's mechanics to build something that will be as functional as you can make it so you can optimally kill those pirates, mine those asteroids, and whatnot. Conversely, when you want to build awesome spaceships for the sake of building awesome spaceships, you'd move over into creative mode (which I have yet to use, but I should give it a try at some point to try and make the most cubey cubic cube I can possibly cube) to design things to your heart's content. That removes the limitations of having to make it a functional craft, and gives you the ability to optimize your design form however you see fit. There, of course, is the middle ground of making a functional ship that also looks nice, which appears to be what most players do. I'm not sure why that these three options aren't acceptable enough. And I keep accidentally typing ascetic in place of aesthetic, which really change the entire timber of something. It could even be said that I design my ships to conform to my ascetic requirements, whereas others design them to conform to their aesthetic requirements. A bit tongue-in-cheek, but so it goes.

In the offline world we have, as you stated (and I trimmed) many more factors that denote our lowest energy state designs. The reason that there is a "car shape" is because that is the shape that works the best (also given the consideration of economic resources being a large factor (take a look at the shape of high performance high cost vehicles as an example) in the shape used) for the given requirements. Airplanes have an "airplane shape" because that is what works. Our spacecraft have a roughly "spacecraft shape", our boats have "boat shapes", and so on and so forth. The key point to see, though, is that even with some extremely hard and rough rules that fit all of the above systems, we still see a massive diversity of shapes within the "X shape" range. This is partially because of the overall complexity of the system (the offline world) which means that there is no simple answer to what is the best "shape". But furthermore it is also an aspect of creativity, as not everyone enjoys the same shape so we get different shapes. Why do "we" need to encourage non-cubic designs? From what I can see the entire argument boils down to "Because I don't like that cubic ships are more efficient than non-cubic ships" which transmutes down to "I don't like cubic ships". Is there a reason to make non-cubic designs a good design (if not one of the better choices) that isn't an argumentum ad populum (an argument based upon using popular opinion as the basis)? A heating mechanic would certainly be interesting (although perhaps a bit to hard-scifi for Avorion, given that the direction of the game is not really aiming that way as a whole), although I don't think your implementation of it would be very balanced. You could easily have a cubic design with a heat sink section that was designed to amplify the surface area through a lot of small cubes arrayed out. You could even have it be in a hollow section, connected to the surface (and thus technically in "space" and as a part of the surface area) by a thermal exhaust port (ideally protected against lucky/force-full shots of passing enemy fighters). Instead, I think a heat mechanic would be better modeled as a block-by-block system, and with the inclusion of three new blocks to handle heat dissipation. The first would be passive coolers which would be designed to maximize the amount of black body radiation for their space-facing surface area. The second would be active coolers which would provide cooling similar to passive coolers except at a greater efficiency by size but with a far higher energy cost (and ideally with a material cost as well as the lore would tossing out material after heating it using waste heat). But at any rate, that'd be better served as a Suggestion thread. Koonschi has stated (see below) that this is an intended function (and that Avorion isn't hard scifi here: http://www.avorion.net/forum/index.php/topic,547.msg2598.html#msg2598 which is unrelated to covering thrusters but something to consider when suggesting hard scifi changes) at least for now. Similar to the heat dissipation mechanic, this could be sorted by building a ship with a hollow part. I also don't think forcing shields to be on the outside of the ship fits with the concept of being able to armor your ship, but it would certainly make for an interesting design problem to try and resolve. Again, is there anything wrong with people building cubes? If, as a thought experiment, you were to make it so that people got the best performance out of building ships that looked like what you envision as an ideal space ship, would you have the same problem with that as you appear to have with people making cubes? Because it's the exact same problem (there is a simple ideal design) with the exact same results (people make their ships to fit this ideal design). ~~~ It doesn't. In fact, it promotes prolonged ship design. Elongated ships has lower forward profile, and maneuvering is not as uniform as in Starmade, for example. More to that, Thrusters that are placed further from the center-of-mass produce much more efficient turning and rolling, so even if you manage to face the broader side of a long ship, it takes mere seconds to roll it and face you with a narrow, heavily armored broadside. Good luck turning your brick all the way and trying to do it again. A cube-shaped ship will always have an easy-target profile no matter where you approach it from, even for Tesla weapons, and the worst possible maneuverability. I believe that when people say "cube" they are using it informally to mean "rectangular", or at least that is how I'm using it. Although if we take cubic literally, you are correct: A completely cubic design (equal on all six sides) wouldn't be as effective as an equally-volumed ship which was more elongated thus allowing you to minimize your profile to incoming enemy fire. Of course, that is assuming an ideal engagement where you are approaching a single enemy and not a group of enemies, aren't dealing with enemy fighters, and whatever other factors might go into making your decreased visible surface area no longer an advantage. Currently Avorion doesn't really have factors that make this as much of an issue as when you get shielding you rarely have to deal with losing bits of your ship, and handling your shield is pretty simply done through either overbuilding your shielding or by hit-and-run tactics.

You are certainly entitled to your opinion regarding what you find both "gamey" and "fun", but I don't think you should be forcefully imposing that upon others. The only person that can do that is Sir Developer, and thankfully koonschi is willing to listen to the community so no worries there. But as this is tangentical to the discussion about big versus small ships, I'd suggest you come over to this thread (https://www.avorion.net/forum/index.php/topic,2332.0.html) if you feel a need to discuss why you dislike cubic builds. ~~~ On topic, it would be very interesting if there were additional reasons to keep a smaller ship besides being able to fit through warp gates, being able to easily move around between asteroids, between stations, between other ships, between enemy (and sometimes friendly) fire, and for whatever roleplaying/personal challenge reasons a person might play with a smaller ship (which sounds like a fun challenge to undertake!). The key will really be when the AI for fleetmates is strong enough to warrant having a fleet of smaller ships. This may or may not ever happen, so having something like a cloaking field block which requires a geometrically larger amount of volume as the amount of volume it needs to hide is greater (thus giving a maximum range where you can no longer cloak a ship, and leading up to that range would be most of your ship having to be cloaking block to possibly cloak, and thus not be a realistic design), perhaps with a smaller increase as the materials of the cloaking field block become better. It would be better to have that kind of discussion in a Suggestion thread though, of course. The bigger issue is that trying to balance the game between small and big ships is not a very realistic task. Without a large enough level of complexity (and even in that case, but more difficult to find), a system is going to have a lowest energy state that players are going to gravitate towards finding. The only counter to this entropy of ship design is that players have their own desires in design, so they're willing to make things less efficient to fit what they want to make/play as. But trying to make it so that there is a clear way that a small ship can be just as powerful as a large ship is one heck of a task. One that I'd love to see the community undertake a brainstorming session to try and understand, and one that I'd love to see Avorion fulfill at some point in the future, but one that I don't think we'll see resolved in the short while.

Another thought might be that we keep your original suggested change that better materials will have better block durability multipliers (up to xanion which then removes the multiplier in favor of giving blocks unlimited health, and the only health indicator that matters is the ship's health bar). The volume of the integrity field generator block, though, would affect the size of the field (with a small multiplier based upon the material). A small integrity field generator block would produce a smaller field in comparison to a larger integrity field generator block. As in, it might be more block-efficient to place ten small integrity field generator blocks spread around the craft in a pattern that covers everything, but a single larger integrity field generator block (likely requiring more volume compared to the smaller integrity field generator block array), placed roughly in the middle of the craft, would then cover it in the entirety. The two problems I see to this are first it then makes more sense in most craft to build one large integrity field generator block (or perhaps two large integrity field generator blocks if you want to make sure to have a redundant system) which is a lot more secure compared to a few smaller integrity field generator blocks spread throughout the ship. But this isn't the full scope of the problem because the second problem negates it. The second problem is that, when you reach xanion and have a full ship health bar in place of block health, railguns become greatly less effective (unless I've entirely mistaken how railguns handle the current integrity field generator mechanic, as I have yet to do more than use them a bit in passing as I favor lasers). This issue also means that aiming for a ship's weak spots no longer works as a method of disabling them, as weak spots are now as strong as strong spots. Therefore, it might make sense to have weapons be able to have a modifier, similar to shield penetration, that is integrity field generator penetration. Ideally they'd be mutually exclusive (this then gives a reason to have more than a single type of mass-produced super-turret, and to have to explore to find another turret factor that makes them) and just as rare as shield penetration turrets. That would solve the second problem (if you really want to aim for weak systems, find/make turrets that penetrate a ship's integrity field generator). It also could be considered to solve the first problem as railguns with that trait would be perfect for digging away into ships that store their integrity field generator mega-block deep in their cores. And other weapons with the integrity field generator penetration trait would be able to slowly dig it out (but more likely you'd be more interested in just doing full ship health bar damage at that point). Realistically, by the time you're at xanion there really wouldn't be a need to keep the local damage to blocks model. It certainly makes sense that it'd be an earlier-game thing, and is thusly replaced later game by the full ship health bar damage model.

Hot damn, that is a BIG CUBE! I don't think it'd be possible to launch something like that in the stock game, especially not into a low Kerbal orbit given the engines used were likely something using an unbalanced (for the stock game) efficiency level. And with a bit more digging, it looks like they're from the B9 mod pack which is overflowing with interesting (and not in my cube-loving way, specifically, but in general it's considered a beautiful part pack) parts. Specifically, it's a hard of the HX series, which are as close as you'll get to a "cube" part pack in KSP (Kerbal Space Program (http://store.steampowered.com/app/220200/ is the Steam page for anyone that hasn't heard of it before)). Taking a look at KerbalX (a website designed to allow people to share craft files) with a search looking for ships that specifically state they require the B9 HX part pack (https://kerbalx.com/mods/b9aerospacehx), we get a listing of rather awesome looking ships and nothing that looks too offensive to an anti-cubist (although I could be mistaken/not be harsh enough on some of the designs). Kerbal Space Program is a good game to show the "other side" of the "engineering game" coin. In KSP, because you're dealing with mildly realistic (especially if you play with mods that make things more realistic) variables, you are forced to make ships that are as efficient as you can get them. Inefficiency can mean that making a small mistake can force you to scrub a launch, or be stranded on the Mün (which is likely how the very first Münar landing went for most of us). But even given those requirements, people still find ways to be creative with their designs (even disregarding people playing in sandbox mode, and especially people that use infinite resource cheats/etc). There does not need to be a hard line between creativity games and engineering games, as a great game can span both genres (as I'd say Avorion is doing, or is in the process of doing).

Do you honestly envision Earth's space agencies launching spacecraft that closely resemble Borg cubes? Granted, space does not have the restrictions we have on a planet like air friction or gravity. The relationship between practice designs in Avorion are not the exact same as the ones in the offline world, which makes "Borg" cubes a suboptimal design choice. Avorion is not even a somewhat accurate model of the offline world's requirements in that regard, but given that how many spaceships can you name that we've ever launched that were designed to be aesthetically pleasing instead of designed to be functional with aesthetics being a secondary (if even that) concern? You have to remember that space is expensive (even more so given the gravity well that we're dealing with) so making something that isn't designed to be as efficient as possible is not something you can do. Although there could be an argument made that, because until recently all space agencies were publicly funded, they had to make them at least partially appeal to the general mass's desire. That, though, is just another factor that Avorion doesn't model, shouldn't model, and honestly cannot model given the complexity of the problem. To note, Avorion has no way (that I've found at least) to make spheres, so I'm not entirely sure how that relates to the discussion. Personally, I'd love to have a spherical ship, and I'd certainly design it in the same way I design my cubic ships. Giant flying balls of layers of balls, constantly adding new layers for new functionality, etc. That'd be glorious! I must be grossly misunderstanding the severity of this issue, but I honestly don't see how "cubes are a great design" interferes with your ability to create aesthetically pleasing designs. How, exactly, is it going to "turn away" potential players? Simply put, it is unlikely that any of the popular media sources that'll give people their first-impression about Avorion are going to have only, or even a majority, or cubic ships. Youtubers are going to make ships that look awesome because that is what the majority of their fans will want, the Steam page is certainly going to have awesome looking ships, and it is unlikely anyone on these forums will start a weekly thread for "most cubic design" or whatnot. Please, if there is something obvious that I'm missing, enlighten me! Show me why it is better to force people to have to follow completely arbitrary design constrains that better fit what you (and likely the majority of players) feel are aesthetically pleasing versus leaving that level of creativity up to the player as they see fit. No one is forcing you to assimilate with the Borg. You have the choice to use a design that is less-than optimal, and in doing so you'll have to deal with the issues that entails. If you want to take away a person's choice in that matter, you are taking away the very element of the sandbox genre that you stated that you wanted (creativity)! Given that the types of shapes we have in Avorion is already limited to cubes, and a few different types of corner/edge/slope blocks, the diversity that I've seen in ships from Youtubers and on the forum is excellent. And that aside, I don't rightly think there is a possible way to make a forced-creativity-ship-design focused game that wouldn't have the same problem. How do you design it so that cubic ships are bad but ALL other ship designs are good? No matter what, a system needs rules, and those rules are going to have an optimal state. The more complex the system becomes, with more rules and more complicated rules, the more fuzzy that optimal state becomes, but there is still going to be good designs and bad designs. I'd like to see some statistics about the Avorion playerbase before anyone jumps to conclusions about whether more players are in a single-player vs. multiplayer environment. I didn't think we needed statistics to support that, but I'd love to see those statistics as well. An hour-by-hour breakdown of how many people are playing in single player, multiplayer but with only one person on the server, and multiplayer but with more than one person on the server. I simply cannot imagine a situation where Avorion has even a tenth of the hours of people playing multiplayer in a server that is actually used for multiplayer (as opposed to someone using the multiplayer option but always playing by themselves, such as I used to do back when I played Diablo 2). But I don't have anyway to back up that statement, so I guess there is nothing more on this end. And while multiplayer is a massively attractive element to games like this (I certainly consider it one of the key elements to why I've bought the game, as someday I'll play with a friend when we get around to playing it together), I still completely doubt that there will ever be even a tenth of the multiplayer hours-of-play that there are single-player-hours-of-play. But, as I said about, there is no way that either of us can prove this, so there is nothing else to state here.

Folders for your inventory would be excellent, and one that'd make the micromanagement minigame of handling a few different loadouts far easier.

Certainly: I support the base (unmodded) game having no artificial elements designed to encourage "ascetically-pleasing-to-the-general-concept-of-what-spaceships-should-be-based-upon-fiction" (because, as you stated, the system in both Avorion and the offline world both make the utilitarian design the go-to design for spaceships) system of thought. You should be able to have a roughly-optimal general design which, for the reasons you described, ends up being a cube for purely engineering reasons. If a person wants to min-max a design without any consideration for the appearance, is that actually a problem? Especially given that the majority of players are playing in single player environments, where the look of their ship matters only to themselves. I rather enjoy making a ship in a perfect cube, and then adding layers to it slowly like some sort of reverse-onion. The construction of a cubic ship can often have many more layers than you'd get with anything that people would find nicer looking, and often times it'll often be more easily expanded and adapted. I'd hate if I had to find a way to stick in some more crew quarters in something more fictional-spaceship-looking without having to tear it halfway apart twice, and completely apart once, just to make it look even mildly acceptable. Instead, I toss on another cube of crew quarters, and armor it up. My creativity is pretty limited, and lacking even more-so when it comes to making spaceships that look like the fantastical representation of what spaceships "should" look like. There is certainly nothing wrong with wanting to make an awesome looking spaceship, but it shouldn't be an element of the game forced onto the players. It should be rewarded in a fitting manner (such as weekly spaceship contents on the forums, multiplayer server praise, perfect chances to make excellent desktop backgrounds, and the like). Simply because it is "easy" shouldn't mean that you need to make it harder, but instead make it rewarding to do it in other ways as well. I really don't have any problem with your proposal (and in fact I've replied to it in support) as it doesn't hurt my ability to make cubic ships, and it would be a great addition to the game as it gives a reason to upgrade your integrity field generator blocks (even for us cube builders, as it'd help deal with collision damage). There is no reason that Avorion shouldn't be another engineering game, and it's actually one of the things that I truly enjoy about this game. If it wasn't an engineering game I certainly wouldn't have purchased it until the modding community "fixed" that, at least. But that aside I believe that Avorion's potential isn't so limited that it cannot be both an engineering game and creativity game. We should both be able to be satisfied with the base game, and the modding community will surely be able to further indulge our different play styles.

I completely support this proposal! Personally, I build "cubic" ships (and I even came from your other thread regarding the "cube-meta") but I see no reason that integrity field generator blocks shouldn't have this type of functionality when it's properly "locked" away under a better material (and xanion sounds fine to me, as you rush for titanium to get your integrity field generators, and then to naonite to get shields, and then trinium to get hangers (and to make everything a LOAD lighter) whereas there isn't really anything you "get" at the xanion level in that same manner). Additionally, I think it'd also be interesting if the quantity/volume of the integrity field generator somehow had some sort of relationship to the usage, but I'm not really sure what it might be. Currently I toss one unit cubes (or, in some instances for ease of balancing, two by two by one unit rectangles) in the smallest amount I can to fully cover my ship, and then I completely forget about it until I tear down my ship to rebuild it in a new material, or I re-design it to function differently. It could be that the more integrity field generator blocks you have in volume, the higher the bonus they'd give. And then higher quality materials would give an innately better bonus for the same volume. Additionally, at a certain point (when your bonus hits the "total ship value" point, and you have enough volume of integrity field generator blocks to hit that for the entire ship) you'd get the full-ship-health-bar setup. It'd certainly give me a reason to place larger integrity field generator blocks, but ideally it'd be balanced so that it'd be highly impractical (except perhaps from us "cube-meta" people) to do this until you hit the trinium or xanion.

True. But it might as well not exist, because no one is willing to waste a slot on that. I completely disagree as I find it is a perfectly acceptable use of a slot if your goal is to get rid of the gameplay-imposed top speed. The key is to switch it out when you don't need it (usually with a quantum hyperspace upgrade, as they're pretty mutually exclusive in usage).

This would be a glorious addition to this game as inventory management is one of the more bothersome micromanagement elements from my experience.

Yay, thank you!!

I didn't see anyone else with the same issue in this thread nor in the Beta Bug Report forum, but I've had the same issue on my end. I submitted a bug report via the in-game option (which takes you here https://www.avorion.net/bugtracker/report.php) and I've also started a thread in the Beta Bug Report forum here: http://www.avorion.net/forum/index.php/topic,2260.0.html . Could you also confirm if you're still having this issue, and if so what are the specifications on your machine? Thanks!

I just submitted this via the Avorion bugtracker (https://www.avorion.net/bugtracker/report.php), but as I don't see any way to actually track it I'm also starting a thread in case anyone else has a similar issue. Most of this post will be copied from that report. To note, this was reported on the beta branch patchnotes for 7565 by Vicodine, but no one else appeared to ever mention it again in that thread nor have I seen a bug report thread by Vicodine or anyone else reporting this issue. ~~~ Issue: When the bug occurs, the Avorion application freezes for roughly one second while my leftmost secondary monitor flashes a white screen around ten or so times. After that second the Avorion application closes, and around fifteen seconds later the Avorion Server application closes as well. There is no dialog box of any kind at any point during/after this crash. I have been able to reproduce this except for a few instances where it did not occur (none of which I could reproduce after testing further): The first instance (in hindsight) was when I first re-installed Avorion earlier today. I was able to check my inventory, and then went on to play for twenty or so minutes before exiting the game. When I re-entered the game, I played for a few minutes before going into the player menu to check my inventory as I just picked up a drop when I experienced the first crash. The second time it did not happen was after my testing to try and replicate the issue through a variety of situations and I had moved onto submitting this bug report. I decided a screenshot would be useful to confirm the exact specifics of the icons, but after I took the screenshot (using an application called Greenshot, specifically used to select a region of the screen) I then moved my cursor over the buttons and the game did not crash. I then closed Avorion and attempted to re-produce that result, but I was not able to get it to do the same thing. The third time was shortly after the second when I noticed, in the screenshot I took, the in-game tip popup was visible. Wondering if it was somehow related, I tried closing the popup first and then mousing over the buttons. It did not crash, but after I closed Avorion and re-opened it I was not able to reproduce this method of avoiding the crash. The fourth time I was in the process of exiting Avorion after checking what other items are on the interface in the player menu (specifically the button and checkbox to the right of the screen) when I pressed ESC, but then I decided to see if it would crash out after having opened the menu screen. It did not, so I left the galaxy (without quitting) and reopened the same galaxy. After the galaxy loaded, I pressed the ESC key again and then moused over the player menu top left tabs, but the same issue occurred. After reloading Avorion the first time I was able to reproduce this (first time in a galaxy the game would not crash after pressing the ESC key), but after I reloaded Avorion a second time I was not able to reproduce this. I tested with the default settings (everything in my appdata Avorion folder was removed prior to all testing just to be sure). I tested it in full screen (same issue) and windowed (same issue). I've also tested against the release branch (0.10.2 r7448) which did not have this issue. ~~~ Reproduce: 1) Load Avorion. [Tested with desktop shortcut as well as directly through Steam interface.] 2) Click "Singleplayer" button. [Tested and confirmed issue also occurs when hosting a multiplayer game, as well.] 3) Select an existing galaxy and then click "Load". [Tested that creating a brand new galaxy at both insane and normal difficulty have the same issue.] 4) When prompted, press the space key to exit the loading screen. 5) Press "i" to open the player menu. [Tested and confirmed that holding shift to unlock the cursor and clicking on the player menu icon also causes the same issue.] 6) Move your mouse over any of the four tabs at the top left of the screen (encircled with a red rectangle in this image, at the top left: http://imgur.com/a/3vjCW). [Tested by moving my mouse over all four buttons first (same result) as well as over Pay Crew button (did not cause the crash) and the Auto Pay Crews checkbox (did not crash either).] ~~~ Logs: Client log: http://pastebin.com/xs3UaAv1 Server log: http://pastebin.com/w79pzjz3 ~~~ System Specifications: OS: Windows 10 Pro 64-bit CPU: Intel i7-3770 @ 3.40GHz RAM: 16GB GPU: AMD Radeon HD 7870 2GB DDR5 (latest drivers)