Thundercraft

The following designs were part of my failed attempt at designing a cheap ramming ship. (See this Ramming for the win topic for details.) BTW: In addition to the 5086 in hull HP, the Mk II also has 1890 in shield HP. As I wrote, they were not very effective for ramming. But, I thought I would share these in case someone finds a use for them as the basis for a fighting ship or some other design. COSTS: Ram-Rod Mk I Iron: 1382 Titanium: 73 Credits: 2517 [*]Ram-Rod Mk II Iron: 780 Titanium: 73 Trinium: 871 Ogonite: 406 (NOTE: I'm tempted to try Skytale's Fully Optimized Iron Starting Ship as the core of some new designs. I had a vaguely similar idea, but this "void" or overlapping blocks technique works miracles and his design seems very efficient.) DOWNLOAD: MediaFire: Ram-Rod.zip

I just wanted to say that I really appreciate these. Very nice mods. Though, I had a bit of an issue when installing as I couldn't figure out why they wouldn't work. Then, I realized that I put the player portion of the scripts in the /player/ folder when I should have put them in the /player/cmd/ subfolder. ::) Works fine now. But I thought I would mention this as it seems easy to overlook. (I could have sworn that an earlier version of /sethome required us to put it directly into the /player/ folder...)

I've since upgraded my initial design with Titanium. This allowed me to add generator blocks for much better energy generation and some integrity field generators to make it a bit sturdier. The generator blocks allows the ship to replentish it's energy much better and I can 'step on the gas' for longer periods of afterburner use. I can also use more energy-hungry turrets. Cargo is still 345 units. But no armor or shields. This design still isn't ideal for combat. (Though, it can stand up to some punishment.) Here's what the no-cargo and cargo versions look like: I'm including four different versions in this download because I've added crew quarters so one version holds 15 crew and another version holds up to 18. Here are the stats for each, side by side: COSTS: Eos Mk II no cargo (15 crew) 3228 iron 2621 titanium 34995 credits [*]Eos Mk II with cargo (15 crew) 4969 iron 2621 titanium 38868 credits [*]Eos Mk II no cargo (18 crew) 3270 iron 2527 titanium 34056 credits [*]Eos Mk II with cargo (18 crew) 5012 iron 2527 titanium 37929 credits P.S.: I've updated my OP with the costs for the Eos Mk I. DOWNLOAD: MediaFire: Eos Mk II freighter.zip A WORD OF CAUTION: I had planned to simply 'apply' the cargo and no-cargo versions of the ship blueprint to switch back and forth between having cargo space to haul stuff. This would allow my ship to have better acceleration and handling with not hauling cargo. However, I discovered a bug which limits my ability to do so: The great 'Turret Disappearing' trick Basically, one has to remember to remove turrets from the ship before applying a different design. Failing to do so will typically cause some of your turrets to literally disappear and become inaccessible. The only way I found to fix this issue is to re-apply the old ship design and remove the problematic turrets.

I just wanted to share my findings from a couple of experiments regarding the core (root) block. I had a suspicion that a ship's core block was particularly vulnerable in that if it was destroyed, then the whole ship would blow. To test this I performed a few tests. In one test I changed the default core block into a Framework block. As you may know, this type of block has virtually no HP. (It reads as "0".) So it should be very easy to destroy. Then I designed a ship out of this such that my Framework core block was in front. I built this ship in a regular galaxy (creative mode was disabled) and I very gently bumped into an asteroid with the front (Framework) block. The ship took damage from the collision, but - amazingly - the Framework core block was still intact. In another test, I shrunk the core block into something small, so it would not have much HP. And I designed a ship around this small core such that it was in front. I then built this ship as a separate ship in a regular galaxy. I had my regular ship damage the core block with a weak (iron) salvage laser. All it did was reduce the HP of the whole ship. In one test, I destroyed the ship entirely. I then rebuilt it and tried again, stopping just short of destroying it. Amazingly, I could not destroy that core block without destroying the entire ship. My conclusion is that the core block is a bit special in that it can't really be "destroyed" like other blocks. You can 'damage' it, sure. But the damage goes directly to the ship's pool of HP. And it won't disappear - at least not until the ship blows. I plan to take advantage of this fact in my designs by making my core block out of otherwise weaker materials like Framework blocks, Glow blocks, or Crew Quarters. (I plan to design combat ships with a lot of armor and, ordinarily, I would try to avoid exposed crew quarters.)

Try over 3000 parts, most of them at 0.05 or smaller. But yeah. IMO, the worst part about the way thrusters work and how it works so well to have thousands of small ones is what happens when such ships are destroyed. When someone attempts to salvage such wrecks, it creates a cloud of many, very tiny "Wreckage" debris. ::)

I just wanted a place to share ideas on new types of blocks. Fire Control blocks These would function as Ship gun fire-control systems. That is, they would scale with size (volume) to add a certain number of AI equivalents to gunners. These AI gunners would be stuck at level 2 skill equivalent and not gain any levels. As for how much they would scale with size, I'm thinking it should be similar to crew quarters. Then why use gunners instead of Fire Control? Because gunners will gradually improve in skill level. Also, Fire Control blocks could be made more expensive than Crew Quarter blocks. (Perhaps twice the cost in credits and materials?) Also, Fire Control would require Naonite or better. (See the Manually aiming even with Gunners and the Aiming Reticle topics for my reasoning.) Alternatively, I suppose this functionality could be added to Computer Core blocks, considering how they currently don't do anything for a ship besides add a few more module slots. (Some players have complained about how they hardly seem worth it.) P.S.: I feel like turrets with the "automatic" trait should be completely eliminated. Our turret inventory gets cluttered enough as it is without having to wade through all the mostly worthless "automatic" ones that don't do much damage. I think all turrets should be able to function in an automatic fashion if designated as such from a command menu or, at least, if we hire a Captain or Lieutenant to give them orders. P.S.S.: I feel that requiring 2 or more gunners per turret is just too much. It's not realistic to require that many to operate just one turret. If they must be scaled by size, then please make the smallest, lowest tier turrets only require 1 gunner. Shield Capacitor What are shields, but a protective field of energy? How do we increase the energy capacity of something? By increasing the capacity of the energy generation and/or storage, of course. AFAIK, adding more/larger Shield Generator blocks only increases the shield's HP. (Having more of them does not increase the shield recharge rate... does it? There's no indication in a ship's stats.) My idea is to change how Shield Generators work so that: Shield Generator blocks only give about 1/4'th the shield HP that they currently provide. Shield Generator blocks scale linearly to increase shield recharge rate - meaning that shield HP could recharge much faster for ships with a lot of them. Shield Capacitors would be to Shield Generators as Energy Containers are to Generator blocks. That is, Shield Capacitors would allow a ship to store more shield energy. They would scale similar to how Shield Generator blocks currently work, increasing shield HP without affecting the shield recharge rate. Thoughts? Suggestions? Anyone want to share their own suggestions on new types of blocks?

Exactly. I brought this up in my Aiming Reticle suggestion topic. Gunners don't even give us an aiming reticle to show us how far ahead of a target to aim in order to hit. Nor does it give us turrets that aim automatically. Apparently, we need to install "automatic" turrets to do that. Oh, and a captain. ::) Agreed. Why do so-called "automatic" turrets still require the same number of gunners per turret? With a name like "automatic", you would think these are computer (AI) controlled - especially since they do a lot less damage than a regular turret. This is the future where they have hyperspace travel, shields and all kinds of high tech. And they don't have the technology to produce cheap, small computers to direct all your ships guns to aim at the same target? Agreed. Exactly. I will admit that my opinion of how turrets SHOULD work has been colored by experience with the X-series of games. With those, the player has direct control over most guns - except the tail guns. I seem to recall using the tail guns required putting the ship on autopilot and switching to the tail gun cockpit. Capital ships were treated differently. At least, you could have automatic firing of turrets. Not even capital ships had a crew. Though, there was a mod which added crews (even requiring you to give them wages) to give the ship certain bonuses. Has nobody ever heard of Ship gun fire-control systems? This is old, WWII era stuff: Aiming weapons at a target is so simple a trained monkey could do it. Indeed, during WWII they managed to train pigeons for pigeon-guided bombs. We have much better targeting technology today. Now, imagine what this tech should be like in a few hundred or thousand years from now. It would probably be pretty small and pretty cheap, at that.

While Avorion does sort of support mods, it seems safe to say that it does not have true mod support yet - not like other games. The biggest issue with mods right now, I think, is the potential for mod incompatibility. That is, more than one mod trying to change the same files. But there are other concerns, such as when Avorion gets an update and your modded files are not updated to work with the new version. Also, there's the issue of uninstalling a mod such as when it stops working or you no longer want to use it. Some mods which I've seen that try to change the same files: Out of sector production, Carrier Commands, and Highlite Players all replace server.lua. Better Shipyard and Spawn Changer both replace shipyard.lua. Perhaps the solution would be for more mod authors to do like guiohm with Allow Multi Delivery by using a file comparison tool to compare their modified files with vanilla files and creating .diff files for players to patch their own game files (after making backups)? In theory, this might also allow mods to keep up with version changes as Avorion gets updated - to a very limited extent, anyway.

This is a mod that many players (myself included) has been waiting for. However, this mod seems incompatible with Highlite Players, because both replace the vanilla server.lua. I don't suppose someone could merge the two? Also... Carrier Commands replaces server.lua. So, I guess that's another incompatibility...

On how to use the trading system: See the High Tech Trading system How do you use it topic. Basically, you need to find and install a trading type module in your ship. On how to set a different starting point, you'll need to install a mod for that. There are at least two choices: [server] /sethome [Mods] Spawn Changer There may be a third mod, but I'm not sure if it currently works.

How about attaching a custom script/code to each of these stations so they will generate a small income for the player who owns them at a regular interval? (That is, a script to put money straight into your account, giving the illusion that it's making a profit for you.) It only makes sense that an equipment dock, repair dock, or turret factory would turn a profit for you. The research station is not as obvious. But I'd like to imagine that the owner could offer research services to a number of potential clients. As for the amount of profit, I think there should be a random element - perhaps +/- 50% of a base value. And the base profit should scale higher based on the distance of the sector from the core. The closer to the core, the more expensive the turrets and equipment tend to be that customers typically buy. Also, the higher the demand for expensive repairs of expensive ships.

I understand why both server and player would need the script in order for the script to function. However: If we decide to join multiplayer and the server doesn't have this script, will it crash the game or prevent us from joining?

This functionality should be added to the base game. Both server and client need to have this installed... correct? If so, servers should add this mod in case players want to use it.

First, I wanted to point out that Spawn changer is incompatible with Tarantel's "Better SHIPYARD": [MOD] Better SHIPYARD! 1.0 Both mods replace the vanilla shipyard.lua, so the only way both mods could work is if someone manually merged the diffs of both (as compared to the vanilla file). Secondly, when I used WinMerge to compare your shipyard.lua with the current vanilla file, I discovered that yours needs a minor update to keep up with the latest patch. Specifically, line 165 in your file reads as: nameTextBox.allowedCharacters = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-üöäÜÖÄ#' " But the equivalent line in the latest (updated) vanilla shipyard.lua reads as: nameTextBox:forbidInvalidFilenameChars()

Sadly, this mod is incompatible with Theoman02's Spawn changer mod: [Mods] Gambling, Dock Building, Pirate Warlord, Spawn Changer & more http://www.avorion.net/forum/index.php/topic,781.0.html Both mods replace the vanilla shipyard.lua file... I don't suppose someone could manually merge the changes from vanilla to get the best of both worlds?

According to this Avorion: Review and first look on the Linux-Game Consortium: Also, here's an issue discussion for GameServerManagers / LinuxGSM were they talk about Avorion. Someone posts: And UltimateByte replies to that with:

Nice-looking ship. And very fast. (874 m/s?!) But, wouldn't this topic fit much better in the Creations area?

Yes! I'm sure we're not the only players who lament the boring time wasted trying to approach a station's docking port safely - or who curses after crashing into it. Would be useful, sure. Though it's not as high on my priority list as other suggestions. Good idea. This would add more depth and realism. Also, a nice option for players who just want to jump right in without having to mine for ores. Please! This system could be either in the form of a module, or a new type of thruster that only provides thrust in one direction. (See the Single direction thrusters topic.) Currently, the Brake Thrust system seems broken. I've seen massive ships with a pitifully small, single-digit Brake Thrust slow down faster than a much smaller ship with double-digit Brake Thrust. Also, I would think that pressing "S" (backwards) while holding the [space] down should fire up the afterburners to slow down faster. But, actually, not pressing any movement keys will have the ship slow down faster than pressing backwards, which seems counter-intuitive. I would think that the only ways a sector would be claimable is if either (a) no faction currently owns them or (b) you "kick out" (i.e., wipe out) all faction stations. And to claim it for yourself, I think we should have to build at least one station of our own, maybe more. Or maybe we'd have to build a warpgate? Good idea. It's not terribly fun to run around several systems trying to hire enough crew. Nice idea. But this should be trivial for the dev to code. All that's needed is a button in the Shipyard menu to open up our presets window. Yes! This would be very useful. It's frustrating to select several dozen blocks in an effort to copy-n-paste or add to our templates, only to accidentally select the wrong block. Then we have to unselect everything and start all over again... >:( I've seen several players complain about how bright the engine's glow is. And it is, indeed, incredibly distracting, especially when the afterburners kick in. This is especially problematic if we stack several engines on top of each other as the glow grows exponentially. (See the Holy Light topic for a screenshot of an extreme example.) Yes! This would be very useful. This would be appreciated. The ability to apply decals to custom creations is a nice feature of some voxel-based games like Planet Explorers. I also have memories of X2, where we could apply a custom 'corporate logo' to our stations.

Exactly. Good suggestion. However, I don't see any legitimate reason why the Next target and Prev target buttons should indicate friends or enemies. We already have Nearest enemy / Prev enemy and Next ally / Prev ally buttons. So why should the Next target and Prev target selection be cluttered up with those?

Maybe not an essay, but this topic is definitely worth writing more than one or two sentences about. Making it so short implies that this suggestion doesn't seem that important. This suggestion has been mentioned several times in other threads. However, I think many new players don't realize that the game has a module type to detect Wreckages. Specifically, certain versions or tiers of the C43 Object Detector have this as part of the in-game description: The problem is, such modules do not seem to work as advertised. It does not seem to give me any sort of notification about wreckages in a system. And it doesn't seem to highlight wreckages, either. Well... I actually did get such a module to highlight a nearby wreck once and only once. I haven't seen a wreckage become highlighted like that since. This, despite the fact that I regularly find wreckages by visual identification and close to within salvaging distance. However, I have seen mineral-rich asteroids get highlighted to grab my attention. This happens frequently. I even insalled a "Scanner Upgrade" module to increase my scanning range. I was able to see asteroids at a further distance. But, still, no new wreckages came up. This leads me to believe that the wreckage identification portion of Object Detector modules is buggy. But even if it wasn't buggy, I would still be asking for an easier and more reliable way to find Wreckages.

I was inspired to start this topic by the following question: And the answer is... no. Salvaging turrets do not increase the chances of modules or turrets dropping. But I think it's safe to say that some of us find this fact to be very counter-intuitive. I'm writing about this as a player who's spent an embarrassing amount of time salvaging wreckages, just because I find it a fun pastime and because I enjoy the random chance of getting an especially valuable or good module or turret. And I can honestly say that I don't salvage for the sake of gaining ores - mostly because salvaging wreckages is not an ideal method for that. Mining mineral-rich asteroids with a good mining laser is way, way faster. I really think that there should be more incentive to salvaging wrecks. And part of my reasoning is because salvaging is too time consuming, compared with the relatively minor amount of ores we can get out of it. Part of that issue, though, is how a typical procedurally generated NPC wreckage has enormous amounts of really tiny blocks and pieces. And, generally, trying to salvage these pieces doesn't even generate 1 ore. These tiny pieces have a nasty tendency to break off, creating a cloud of debris. This can make finding actual wreckages actually worth salvaging a real problem, since the tiny pieces show up on our radar as "Wreckage"... :-\ Further: Please consider changing the game's destruction mechanic so tiny blocks below a certain size threshold are treated as a whole conglomerate and do not break apart. It would be much less of a headache if tiny pieces could be chewed up all at once, as if they shared a common pool of hitpoints. Also, perhaps tiny individual pieces should not show up on radar (at least not as "Wreckages") if they fall below a certain volume threshold. Or, at the least, you could have them gradually disappear (i.e., get deleted) after a while, much like how cargo pods, turrets, and modules eventually disappear if they are not picked up. Alternatively, or in addition, you could change the procedural generation of NPC ships so they do have so many tiny, tiny pieces. Another issues is how wreckages typically have some armor. Using even a good salvaging turret on armor is usually a waste of time and effort because they don't have much ore, but they take forever for the salvaging turret to chew up.

Wikipedia on Privateer In essence, some nations literally gave a license to certain ships to commit piracy on the merchant vessels of enemy nations. Privateering, or being a mercenary gun-for-hire, was more or less the basis for Wing Commander: Privateer, which was a pretty good space sim for it's day. You play the role of a mercenary who does missions for the Confederation... and/or other factions. And you get paid for it. I am disappointed that Privateering is very strongly discouraged in Avorion by the game's mechanics. Specifically, whenever I destroy a 'merchant' (i.e., a non-combat vessel), I get a warning message about destroying a non-combat ship: To borrow from another thread: I got a reputation drop for killing a civy ship. The factions whose relation with me dropped were at that time shooting at said ship. LOGIC I mean... really?! I understand that the faction who owns or has close ties with said merchants would be upset - and rightfully so. But why would a faction frown upon this behavior if they are mortal enemies of that merchant's faction? Instead of severely hurting my reputation, my reputation with them should increase. Indeed, they should give me a reward for hurting the economy and supply lines of their enemy. For that matter, there should be missions available that has us attack a freighter belonging to an enemy faction. It shouldn't pay nearly as much as for attacking pirates. But maybe it's protected by an escort or something. And not all mercenaries or independents (like the player) would be willing to dirty their hands or ruin their reputation with this faction. Also: Having a window to view each faction's relationship with each other would be very useful, IMO. It also adds more depth to the game.

Do players even use Framework blocks? What are they even used for, aside from just making a ship physically bigger? Framework blocks are dirt cheap in terms of both credits and materials. They don't appreciably add to weight, either. As you said, they are incredibly fragile and provide virtually no increase to HP. The upside is that they do not increase the number of required mechanics. If they were actually worth using, I think one could work around how fragile they are. All that would require is building them near the core of your ship and protect them with integrity field generators and armor plates on the ship's surface. I was hoping that adding enough Framework blocks would unlock more System slots to add more modules. Sadly, this is not the case. :( They don't contribute towards more turret slots, either. So, I can't imagine myself ever using them.

As part of an experiment, I tried designing a ship for ramming. Here's my iron version: http://tinypic.com/r/245iywh/9 It's all iron, save for some titanium for integrity field generators to protect all the blocks. It has 793 HP, masses at 4709 tons, and has a top speed of 271 m/s. In a galaxy set for full collision damage, I tried ramming a large-ish traveling merchant. But my ship exploded spectacularly without putting much of a dent in the target. (HP bar looked the same.) I also tried ramming some pirates and found that I could finish off damaged pirates pretty easily by ramming them - and come out damaged, but intact. Thinking I needed more HP, I redesigned it to use mostly Ogonite for the armor and Trinium for the engines, plus some Trinium shields: http://tinypic.com/r/xgd35e/9 As Ranakastrasz suggested, shields do nothing for collision damage. And that makes me very sad. :( Anyway, this version has 5086 HP and a top speed of 185 m/s. This is much more survivable as a ramming ship. I was able to repeatedly ram freighter ships many times larger than this ship's 3836 tons and survive. However, my targets were enormous, with hundreds of thousands of HP, and my impacts barely scratched them. Each impact was doing maybe 1% or so of their max HP in damage. By the time I could turn my ship around and recover my afterburners for another run, their mechanics had this damage mostly repaired. Bottom line: Ramming as a strategy is not worth it. Shields won't help. And to make a ship big enough to destroy the enemy without destroying yourself requires too much cost in credits and materials - even if only iron. It's more economical to build a ship for traditional fighting.

First, I just want to say that I enjoy your videos. And I appreciated this info, particularly the part about how to upgrading our ship's material with Notepad. Anyway: I followed your video and I created several tiny cores to choose from, including 0.2 cubed, 0.4 cubed, 0.5 cubed, 0.8 cubed, and 1.6 cubed. (The default core size is 2 x 2 x 2.) Unfortunately, I discovered that using a non-typical size for the ship core can lead to a very frustrating 'block overlap' issue. Essentially, blocks will frequently try to overlap by 0.025, preventing us from placing them due to "too much overlap". Since the Grid Size can only be reduced to 0.05, we can't adjust the grid to fix this. (I started a Grid Size = 0.025... Please topic to suggest that they add a 0.025 Grid Size.) I know this is a problem with a core size of 1.6 cubed (or -0.8 to 0.8) and I suspect I would have the same issue with 0.8 cubed. I'm not sure about other size. They might work okay or they might have the same issue. Bottom line: I would recommend just turning safe mode off and deleting the core block as a way to get a different core size. That should be safer than use the Notepad method as this should probably avoid the overlap issue. That said, if all a player wants is to build cube-shaped ships, the "Match Block" option will ensure that blocks match up. That much is no problem. But placing blocks without "Match Block" or trying to copy and paste arrays will cause issues.