Thundercraft

Miscellaneous Parts (reserved spot)

Prototype Shapes Here are some 'prototype' shapes that I started on: #Thun_Diamond I.xml (This shell already supports 4 modules.) #Thun_Diamond II.xml (This shell already supports 4 modules.) #Thun_Diamond III.xml (This shell already supports 3 modules.) #Thun_Diamond IV.xml (This shell already supports 3 modules.) #Thun_PRE-claw.xml (This shell already supports 5 modules.) #Thun_PRE-cross.xml (This shell already supports 5 modules.) These are not finished ships, just a starting point. They're completely hollow in the back. Here's what the "Claw" looks like from the back: I may, some day, build on these. Maybe. But they're free to use or modify as you please, if you'd like. Download: Thun_Prototypes.zip

Void Tech Blocks (reserved, coming soon-ish™)

Thruster Nacelles & Leverage Arms Some words on thruster changes: Why use thruster arms and Directional Thrusters; suggestions on placement: Here are thruster arms (leverage arms + thruster nacelles) ripped from ships that I've designed. These are all "DTU" or Direct Thruster Upgraded, meaning they all use Direct Thrusters. And that means they (currently) require the Beta branch. ! Thun_Wing_Cutter.xml ! Thun_Wing_Caravel.xml ! Thun_Wing_Monitor.xml ! Thun_Wing_Predator_side.xml ! Thun_Wing_Predator_dbl.xml ! Thun_Wing_Tetralenos.xml ! Thun_Wing_Trilen.xml ! Thun_Wing_Trilenos.xml ! Thun_Wing_Azugalenos.xml Download: See attachment below. Note that most of my nacelles have at least some solar panels for added power. Usually, they're hidden under armor. They have less mass than hull blocks or most other blocks. At first glance, Wing_Azugalenos and Wing_Trilenos may look identical. However, the nacelle on Wing_Azugalenos is off-center to provide more Yaw (or Pitch) on off-center designs - those with less than 4 thruster arms. Look at Wing_Predator_side for a clearer idea. Also, Wing_Azugalenos and Wing_Trilenos both have rather large crew quarters and a large generator. Each is practically a ship in and of itself. For that matter, Wing_Tetralenos and Wing_Trilen have a small amount of crew quarters and power generators. By appearance, one may assume that these have beefy Engines. But, I only added thin wafers of Engines - enough for a glowing trail when boosting. (In my ships, about 98% of the Engines are in the main body.) Do note that most of these are made of at least some iron. In particular, 'Wing_Cutter' is 100% iron. Most of the rest have a titanium exterior, with void tech (see below) iron directional thrusters. But 'Wing_Azugalenos' and 'Wing_Trilenos' are 99% titanium. (I left a bit of iron holograms, which are invulnerable and shouldn't weigh anything.) If you don't like how these are iron or titanium, this can be changed. See the Upgrade Your Ships Materials topic to see how easy file editing the materials is. There's also Build Mode's transform tool. Or, you could paste as a Template and change the material from the drop-down menu. (Props to Delvar for pointing that last one out.) TIP 1: Don't forget that you can hold down the "X", "Y", and "Z" keys while pasting in order to flip a part's orientation. Specifically: Since most of these are right-side wings, you can hold down the "X" key to flip it so it becomes a perfectly-matched left-side wing! TIP 2: It's usually easy to edit these. What I do is either copy/paste a nacelle's side panel into my Templates or I copy/paste it elsewhere. Then, I edit the interior. Finally, I paste the panel back into place. Usually, I do this with X-Mirror on so I edit both wings at the same time. Important: Most of these use 'void tech' directional thrusters. I say "most" because 'Wing_Azugalenos', 'Wing_Trilen', and 'Wing_Trilenos' are exceptions. They're built the old fashioned way. See the Scytales Laboratories topic for Void Tech examples and details. It's worth mentioning for several reasons. For one, some players may consider it cheating. Basically, a little file editing allows me to fit five times the amount of thrusters in the same amount of space. This not only saves a lot of space, it allows me to protect my thrusters with armor without using so much armor that it slows down the ship. (Without void tech, it can be a vicious cycle...) To avoid cheesing, I only stack them five times, though more is possible. And, as it's built inside a framework, they're fragile past the armor. A single solid hit will likely destroy them. If you don't like the void tech thrusters, you're free to turn Safe Mode off and delete them, replacing them with regular thrusters, engines, or whatever. _Thun_Wing_Pack.zip

Engine and Thruster Props In my mind, protecting thrusters and engines with armor or by burying deep inside are valid strategies. Thrusters are vulnerable and easy to destroy. Engines don't seem quite as flimsy, but I think they're weaker than regular hull - certainly weaker than armor. Granted, I also like the glow of engines. And I like the look of thrusters firing. So, for me, there is some trade off. But I also create engine glow props and thruster props to make it look like it has external engines and thrusters. Props like this: ! Thun_Engine glow (1 x 1).xml ! Thun_Engine glow (2 x 2).xml ! Thun_Engine glow (3.5 x 3.5).xml What they look like on a ship: Or, how about a "recessed" engine prop like this: ! Thun_Engine recessed (1 x 1).xml (This version has tiny IFGs already integrated. But you should still have a plate of armor between this and your engines.) Download: See attachment below. On how to protect them with IFGs: On decorative thruster props: Perhaps you're like me in that you also want to hide your thrusters behind armor or something. Or, perhaps you dislike how ugly thrusters are or want something that is more eye-catching. If this suits your fancy, you're free to rip the decorative thruster props from my thruster nacelles (see below). However, instead of copy/pasting from a one-size-fits all prop, I usually find the need to customize a thruster prop to fit the design. If nothing else, though, you can see how I make them. Originally, I used thin wedge strips to give the appearance of a vent. But, even protected by IFGs, I found that these frequently broke off in combat. My later nacelles use thin dark gray hologram wedges for a similar appearance. Since weapon fire passes right through holograms, they never break. _Thun_Engine_Props.zip

Cargo Containers As mentioned here, the Cargo Bay scales weirdly. Despite being the same in volume, building a single 10x10x10 Cargo Bay is 685% more efficient than building 1000 1x1x1 Cargo Bays. (I'm not even exaggerating. :() The extreme way it scales strongly encourages The Cube Meta. It's such that I design my freighters around this mechanic. And they end up with only one or two large cargo bays (usually just one). My latest freighter designs (soon to be released) are all based on a single, huge, cube-shaped Cargo Bay with a cubic ship literally built around it: In my attempt to subvert the Cargo Bay Cube Meta, I've created a series of "cargo containers" that are copy/paste friendly, are aesthetically pleasing, and are rather space efficient. They come in a variety of sizessuit different sized ships. However, all have roughly the same length of about 9.7 units. I design most of my ships around this length and that makes them interchangeable. Note 1: These have IFGs. Often, I hide them, like at the intersection of bands. They're not all perfect, though. My "Cargo 336 Ir" has some red straps on the side that are not covered. (Though, I fixed that and other flaws in my "Cargo 336 Ti" the upgraded Titanium version.) Note 2: These use solar panels for the bands, for lighter weight and some extra energy. Note 3: The smallest two containers, size 74 and size 176, are not very easy to remove (delete). However, my larger cargo containers should be painless to remove if you turn Safe Mode off and delete the long IFG strip or the strap closest to your ship's hull. Download: See attachment at the bottom. ! Thun_Cargo 74 Ir Vol-0.06m.xml (Abbreviations: 74 cargo space, Iron, 0.06 million in volume) ! Thun_Cargo 176 Ir Vol-0.11m.xml (Abbreviations: 176 cargo space, Iron, 0.11 million in volume) ! Thun_Cargo 336 Ir Vol-0.18m.xml (Abbreviations: 336 cargo space, Iron, 0.18 million in volume) ! Thun_Cargo 876 Ir-Ti Vol-0.4m.xml (Abbreviations: 876 cargo space, Iron-Titanium mix, 0.4 million in volume) ! Thun_Cargo 336 Ti Vol-0.18m.xml (Abbreviations: 336 cargo space, Titanium, 0.18 million in volume) _Thun_Cargo_Pack.zip

This is my catalog of parts which I use to build ships. I wish to freely share them, both to help others in shipbuilding and in the hope of seeing more creative and high performance ship designs out there. For instructions on how to copy and paste with these .xml files as parts, see this post. Some tips: You will probably need to hold down [Alt] to select a certain block as the anchor in order to get these to fit or line up properly. Usually, the biggest block closest to the base works best, but sometimes a middle or edge block works better. Don't forget to adjust the Grid Size to make these line up properly. Often, I end up reducing it to 0.1 or 0.05. Don't forget that you can adjust the Scale Step and hold down W, A, S, D to scale these parts up or down. Want even larger cargo containers? You can do that. Cargo Containers Engine and Thruster Props Thruster Nacelles & Leverage Arms Void Tech Blocks (coming soon-ish) Prototype Shapes

They do take a ridiculous amount of energy. But I guess that's only fair. I do have some observations, though. And I would like to know if others are seeing the same thing: Robotic Crew modules always seems to have far more Engineers than Mechanics. (And I've purchased, found, and collected many dozens of these - probably over a hundred by now.) Rarely, I'll find a Robotic Crew module with equal or nearly equal Engineers and Mechanics. But, I've never seen one with more Mechanics than Engineers. And, usually, it will have about 50% or more Engineers than Mechanics. I found it irritating because my ships always need far more Mechanics than Engineers. If the ratio of Engineers to Mechanics was reversed, I think it would be about right. The "Petty"version of Robotic Crew modules seem to be equivalent to around 23 Engineers and 20 Mechanics. In contrast, the "Common" version is equivalent to between 25 of each and 60 of each. (Which is a very wide variation, to be sure.) For a "Petty" or level 1 module, I thought that it should only be equivalent to around 8 Engineers and 12 Mechanics, maybe even start around 6 : 9 (and with a proportionally lower energy cost, of course). My early ships are small. They only have 2 to 4 modules (or less than 90 k cubic meters in volume). They don't require anything close to 20 engineers or mechanics. Indeed, I usually get by with only 2 or 3 engineers.

From the first day I played, it irritated me that many randomly-generated factions have "The Pirates of..." as part of their name. As it happened, the allied faction in my start sector on my first playthrough was like that. :( (Also, there was another faction nearby like that.) When I tried to discuss on the forum about a way in which I lost rep with "The Pirates of Tloeciiyi", someone replied that I shouldn't worry about my rep with them. They're pirates! He failed to understand that I was talking about a faction and not those waves of bandit invaders. It creates such confusion to have randomly-generated factions with "Pirates" in the name because factions are quite different from bandit-type "Pirates". Also, I just don't like working for law-abiding, respectable "Pirates" that will confiscate any unlicensed or illegal cargo and impose a heavy fine. ::) Can't the name be reserved specifically for bandits?

Have you tried to use an unauthorized script/mod as a client in a multiplayer Avorion game? I tried, but the game tells me that the script is unrecognized. (I'm talking about a client-side script, not a server-side script.) Avorion is already coded such that only authorized scripts can be run. Are you confident that merely shifting more of the workload onto the client end would break (or allow players to easily circumvent) Avorion's block on unauthorized client-side scripts? That's already an issue now. Heavily modded servers require players to either install the required mods individually, or they must install the server's mod pack. AFAIK, the only thing that shifting more of the workload onto clients would change is maybe exacerbate this problem such that it would require players of all modded servers to install all parts of all of the server's mods, without exception. However, koonschi has been thinking about an actual mod system to make installing and updating mods easier and less problematic. (See his post here.) He does not go into great detail. But, perhaps he will support mods through Steam Workshop, like many other Steam games? Well... You've got me there. You have a point. :(

Wow! And all with only 10 crew! You've definitely fulfilled my request. And it is quite visually pleasing.

True, that is a limitation of 32-bit programs. Also, if properly optimized, a 64-bit program should be able to take better advantage of multi-threading (such as with 64-bit bitwise operations). Sadly, I doubt we'll see a 64-bit version of Avorion. I thought of that. However, Avorion is not an MMO, where that kind of thing is not uncommon. Avorion is hosted either by a player or a server host company. In either case, it should not be difficult to spot a cheater and have the admin permanently ban their IP. They should also be able to reverse the damages caused, reimburse or replace their ship, etc. Also, even if it was shifted more client-side, it should be possible to at least make cheating difficult or detectable. For one thing, the host can verify that the client copy of the game is current and valid and that it's not using any unofficial scripts... That is... interesting. This does suggest that there is a lot of room left to optimize Avorion. Perhaps part of the problem is Steam? Regardless, I still think that shifting more of the load onto clients' hardware should eliminate most of the lag. But, perhaps after Avorion is closer to 1.0 and gets an optimization pass, it will improve to the point that such a move won't be needed?

MMO games like Eve online and DDO require players to connect to a central host. Players are the clients and the MMO company's expensive computers with their expensive T1/T2/T3/T4 connections is the host. If there is significant lag, I think it's often due to limitations of the client's connection or hardware. That, or there are software issues or too many players. But multiplayer games like Avorion are not MMOs. Hosting maybe 2 dozen players is not "massively multiplayer". The host is either the hardware and connection of a single player or a paid game server service. Problem is, such hardware and connections can't compete with the hardware and connections of profitable MMO companies. Yet, Avorion is a massive game with a lot of things going on under the hood... From what I can tell, each Avorion client relies on the server or host to do most of the calculations and keep the simulations of all players updated and syncronized. But, with dozens of players and a lot going on, the host can not keep up with such demand. My Experience: Despite a decent ping rate, we've witnessed a lot of lag on the server where I often play whenever the player count goes above 1 dozen or so. Sure, there are various reasons. For instance, very predictable, very extreme lag occurs whenever someone is fighting the last boss in the galactic core. Whenever there is extreme lag, it become frustratingly tedious or impossible to do pretty much anything. Mining an asteroid or salvaging a wreck becomes either frustratingly slow or impossible. (The asteroid or wreck suddenly seems immune to our mining or salvage lasers...) Worse, combat can become nearly impossible. At nearly point blank range, I can shoot and shoot and shoot... and the enemy takes no damage. Then there's how enemies 'teleport' as the host suddenly updates their location to someplace different that our client did not predict. My Suggestion: Instead of requiring the host to do all of the heavy lifting, why not distribute the workload a bit with the clients' hardware? Depending on how this is done, that could relieve a huge amount of the strain on the host's hardware and connection. Specifically: For each player that is currently by himself (no other players) in a given sector, why not allow that player's hardware to be responsible for simulating that sector? As long as said player's client is updated with the server's copy of that sector when the player enters that sector and as long as it updates the server's copy whenever that player leaves or a new player enters the sector, I can not imagine a situation where this would be a bad thing. The benefits are obvious. Requiring clients to simulate their own sectors and keep the server updated (instead of requiring the server to simulate everything and keep clients updated) should eliminate the majority of lag for those clients - no matter how many players join. A multiplayer game really boils down to a shared experience and chat. But as long as players are doing their own thing in their own sectors, there's not much actual sharing going on - besides chat, that is. A bunch of multiplayer players each in their own sector is really not much different than each of those players playing in singleplayer galaxies that happen to be the same galaxy. Granted, when more than one player is occupying the same sector, that situation is different. That would require the host to do most of the calculations just to keep their simulations syncronized. But, in my experience, a majority of the collective experience in multiplayer (Avorion) games is spent with players off doing their own thing in separate sectors. As such, offloading the workload to simulate a sector to the one player occupying that sector would be a huge boon to the host and, thus, all players in form of much less lag.

These are really nice looking ships. However, the dropbox links to your .xml files do not work. I think that you copied the wrong URL or something.

I seem to recall reading that NPC ships never use integrity fields. A number of players have suspected that the core block is especially vulnerable - myself, included. But, I now wonder that how how collisions are bugged may have given us the wrong impression. Besides accounts of how players with a core block in front often lose their ship to collisions, there's not much evidence of that. That's a possibility, I suppose. That brings up a good question: How -does- the game generate wrecks? Problem is, players are not privy to a lot of details, like how certain game mechanics are coded. My theory is that each block only contributes about half of the actual, hidden, block HP to the ship's HP pool - perhaps less. That way, ships would typically only lose some blocks before it runs out of HP and blows. This is regardless of whether or not a ship has IFGs to protect blocks with x10 HP, which would be calculated separately. That would neatly explain how wrecks are often missing only a few blocks. Remember: When fighting enemies, our ship gets peppered with weapon fire all over. If we could see the damage to each block on our ship after taking a lot of weapon damage, we'd see a variety of damage from 0 damage to barely any left. Discarding excess damage merely means that an enemy has to do more damage to destroy a ship than would otherwise be necessary. It would also mean that ships with lots of little blocks would tend to last longer than a ship made up of only a few large blocks. That's a pretty good question. I've managed to cut a large chunk off of NPC ships on occasion. But, usually, either the ship blows before I manage this, or it doesn't have much HP left and blows after a few more shots after I've achieved this. Perhaps the devs intentionally made this is difficult?

Well, these collision mechanic bugs do not make collisions very realistic. If only "dense" people are capable of having a collision accident, then I'm surprised that the Earth doesn't contract into a black hole from the density. :P Seriously, collisions happens a lot - even of most players are reluctant to admit it. The other night, the chat on the server I was on was filled with reports of several players crashing into 'roids and gates, usually losing their ship in the process. Some of them lost their ship twice in the same night. Sometimes fog was to blame. Other times, not. Keep in mind: This was in a galaxy where collision was set to 0.5 (half damage)! Yes, adjusting our ship's trajectory can save it from collision - in a vaguely similar manner how a calm and experienced driver can correct a slide on an icy road. But that requires refraining from panic, a decent skill, and probably good timing and judgement. If you panic or you notice too late, then it's probably too late to avoid it. See above. Yaw/Pitch are not useless if you have enough, know how to use it, and don't panic. You change your orientation and apply the afterburners. Pay attention to your turret reticle, prograde and/or retrograde vectors. If aimed right, you can rather rapidly change the ship's movement or even stop. Granted, this is much easier said than done... Not sure what you mean by "strafing thrusters"... Are you referring to Directional thrusters? Directional thrusters pretty much act on the ship the same way as regular Thrusters. These are good points, particularly the point about fog. However, © only seems useful if you happen to have long-range weapons. Short-range weapons won't reach from outside a roid field. I think that Fox and SageThe13th have a point. Individual blocks can act as a sort of crumple zone. If having a core block in the front means a collision is far more likely to result in ship loss, this rather proves it. Unlike core blocks, which keep subtracting hp from the hull until the ship is destroyed, regular blocks get sacrificed to protect the ship from further damage. So, if a collision is calculated to do 1000 points of damage, even if the blocks on the front of the ship only have a couple hundred hp (combined), they may take the brunt of this and spare the rest of the ship. Good point. Another reason why collions in Avorion are not always the player's fault. Also, more evidence that they're not realistic. Another good point. It also depends on whether a player get's in a hurry to go someplace. Also, ever since that beta patch that increased engine speed and changed how thrusters work, things changed. I'm still learning how to not slide all over the place and overshoot my destination. Like you said, even with 1000% SETA, travel in the X games can be slow and tedious. But I think this supports the call to nerf collision damage. Games are supposed to be about fun and entertainment. Losing ships and valuable resources to collions can get old pretty quick. I agree that it would be nice to see our current speed. But, the rest of that sounds like information overload, IMO. And it's a lot to ask of the devs. (Avorion is supposed to be done by Q3.) It'd be easier just to add a current speed indicator, fix collision bugs, and nerf the default collision damage a bit. That, combined with the new prograde and retrograde vectors, should be enough.

It seems that I may have overestimated slightly. There's only somewhere between 46 and 48. (It's hard to count them all.) I've left it running for several hours and no more will spawn it seems that I've reached some coded limit. Though, this is still pretty ridiculous. :P

Well... Experience and the advice of others strongly suggests that core blocks are also a vulnerable spot that can easily destroy the whole ship if not protected. First, there are some serious collision mechanic bugs. Odd things can happen, like the impacted block being fine and a block on the opposite side of the collision being destroyed. IFG block protection can make it worse. Also, collisions to the core block will always do full damage to the ship's hull instead of simply breaking off a piece: I started designing my ships with the core block in front, thinking that this made the front block indestructible. But, then, enemy weapons seemed to chew threw my HP like a hot knife through butter. :( I'm thinking that blocks with limited HP (any block besides the core) can sacrifice itself to save the ship further damage. In other words: If a piece of armor gets hit for an attack that does 100 points of damage, but it only has 40 hit points, I suspect that the game destroys the block and that's that. That piece of armor's sacrifice probably saved the ship from 60 points of additional damage.

Very helpful. Thanks! This list was incomplete, though. So, I spent the time to find the rest: x= 4, 185, 186, 187, 188; Stone x= 9; Framework x= 10; Hangar x= 11; Dock x= 12; Turret Rotation Lock x= 13; Directional Thruster x= 14; Gyro Array x= 15; Inertia Dampener x= 60; Solar Panel x= 61; Light x= 170, 171, 172, 173, 174; Glass x= 190, 191, 192, 193, 194; Hologram x= 510, 511, 512, 513, 514; Rich Stone Complete list: Materials: Iron = material="0" Titanium = material="1" Naonite = material="2" Trinium = material="3" Xanion = material="4" Ogonite = material="5" Avorion = material="6"

I can see how a joystick + mouse combination could work for control. But - per cepheni - there won't ever be official joystick support. I suppose a programmable joystick or joypad could be mapped to up / down / left / right as well as a few important hotkeys. But the vast majority of gamers would be disappointed by the result. Unlike games with actual joystick support, that would completely lack fine control. With joystick support, a game measures degrees of rotation for very precise control. Most joysticks also have a speed or "thrust" lever with similar precision and control. Many sim games like the X series allows players to set their ship's (or aircraft's) speed just about anywhere between 0 and max with this lever. In contrast, keyboard or joypad button presses basically have only two states: on or off. Although I think it is far inferior to joystick control, mouse steering allows more precision than keyboard steering.

In my mind, protecting thrusters and/or engines by layering armor over them or burying inside the hull are valid strategies. What's wrong with that? Last time I checked, thrusters were very vulnerable. They're super easy to destroy. I don't think engines are nearly that flimsy, but I wouldn't be surprised if they're weaker than hull material. If koonschi didn't want players to hide thrusters under armor, then they shouldn't be so very, very fragile. Granted, I also like the glow of engines. And I like the look of thrusters firing. So, for me, there is some trade off. But I also create engine glow props and thruster props to make it look like it has external engines and thrusters. Props like this:

I do like the sleek look of the SW-30x series. Simple, yet oh so sleek. I was surprised to see that the AMR-101 is pretty big, with a volume of over 1 mil. At first glance, I thought it was a small ship. :D

I have some suggestions on how to make a station look nice, yet have a relatively low crew requirement: Hologram blocks do not require maintenance or energy, no matter how big you make them, and they are not destroyed. (Projectiles pass through, I think.) They can also be painted a spectrum of colors, which changes how they look. Depending on how they're painted and/or stacked, they can be used in place of glow blocks. Tip: If you turn mirroring on, you can get two identical hologram blocks to stack in the same place, which makes it sort of glow. Since rock type blocks do not add to maintenance, why not add building-like protrusions made entirely of rock, but covered by thin (0.1 or 0.05) sheets of crew quarters or other hull materials? That should look good, yet not add much to requirements. Building-like protrusions could be made of rock and painted really dark colors like black, midnight blue, or dark red. That should more resemble a station's hull instead of a hollowed-out asteroid - particularly at a distance. (I'm thinking that blocks of darkly painted rock could be covered in dark gray or black holograms to further disguise them.) The use of Rich stone blocks might give a station a unique look. It should also make it far easier to spot among the asteroids. Also, that was a good point about solar panels requiring less maintenance than generators. And they can be made of cheap materials like iron or titanium, I guess. One thing to keep in mind: Single, large solar panels have much more HP than large arrays of tiny solar panels. With IFGs, that makes them more difficult to destroy. (Shields should protect a station from most dangers. But they won't protect from collisions. And I'd rather not tempt fate.) I'm not surprised. When I design freighters, they end up with a comparatively larger Mechanics requirement once I add the huge cargo bay(s). Keep in mind: A single large cargo bay will always hold more than several smaller ones (of the same volume). It also requires less energy. Personally, 86 crew is still more than I'd like. And I'd agree that 23,000 cargo is a bit excessive. I don't believe that I'll ever need that much for temp storage. But I wouldn't be surprised if some players find it just about right. True enough. Most types of stations don't need much. (Do they need any?) However, I know some players want to build a station just to store the common materials they need to build turrets. And some build an extra ship just for cargo space to store the stuff they looted or accidentally bought until they can find a good location to sell to. That cost is very reasonable. And the salary for 21 crew should make most (any?) station types economical, I think. Now that's what I'd call a cheap, yet large-ish station! Nice job. Also, I like that you've managed to integrate a few IFGs to protect it. Might come in handy if built in a dangerous sector near the core. As for the power: I'm assuming that it is possible to add turrets to a station? If so, I doubt that is enough to support them as energy req. are already close to capacity. But it should be a useful design, nonetheless. Rather plain, I suppose. But I kind of like the look. I can see the practicality of trying to camouflage a station so it is not easily detectable by the likes of Xstoan, pirates or other hostiles. Heavy stone armor also makes sense. And I can imagine that a lot of stations are just hollowed-out asteroids. True. And I don't mind making a large initial investment. But paying a large crew hurts the bottom line if the station can't even break even. Might be better off relying on NPC stations, then. Looking forward to it. It'd be nice if you could make something reminiscent of Outpost 57, but with far less maintenance costs. Nice! Very station-y. 8) About 8.5 GW of excess energy? And only 23 crew.

The Xsotan forces continue to grow and now number almost 5 dozen. :o But, I think I'll just start a new galaxy now. I don't need another possible cause for game crashes. Those cause me enough headaches as it is. BTW: The author of the Hostile Factions mod replied with a method of fixing this issue: I'm not afraid. Well... maybe a little. :P So far, they've been neutral with me.

Just my two cents: I think the current system is great. If anything needs changing, perhaps allow some RNG turrets near the core to (randomly) appear at slightly higher levels than present. Also, I think that if turrets were changed to either an RNG-only or a crafting-only system, then a significant number of players would probably become bored with Avorion and leave. The element of discovery and anticipation in finding a particularly good turret (or module) from a random drop has a certain, very strong appeal. And being able to craft turrets has it's own appeal. There's also the element of discovery in finding a turret factory that is capable of producing particularly nice turrets. This element of discovery and anticipation is a strong driving force to encourage and reward players for exploring. And the drive to find good drops encourages players to fight and to salvage. This rewards different play styles and helps with game balance. Perhaps there is something to be said for adding a system to allow players to really customize the look of turrets. But, IMO, that would add complexity to Avorion that some would probably find unnecessary. Also, the devs can only achieve so much between now and when the game reaches 1.0 status in Q3 2017. There are probably changes and player requests which would be more appreciated by the majority. Fighter customization comes to mind, sort of like the Custom Fighter mod meets Build Mode... Excellent points. I agree.