Martin Levac

I just thought of a third option that would provide the same functionality. Toggle speed limiter with preset percent of max speed or absolute speed limit, i.e. 1/4 of max speed, 50m/s, 100m/s, etc. This is not a cruise suggestion or anything like that. It's just a simple way to give finer ship control when navigating asteroid fields, wrecks and also when docking. Just one of the three possible ways, however it's implemented, with toggle shortcut, is adequate for my purpose. I don't need all three.

I believe something almost exactly the same has been suggested already. Nevertheless I want that too. The toggle option is just what we have now, except without the need to keep the button actively pressed. Like many other gamers I have a programmable mouse (and a programmable keyboard as well) so I could program a mouse button to do the same thing, but I'd prefer if it was already in the game. A toggle becomes very useful, nay essential, with large ships built specifically for firing broadside. It would become a thing. Even for my current ship built for frontal assault, it would be most welcome since I could press a key (and release that key) to look around while the ship maintains its current heading. I would add to this suggestion: Independent mouse sensitivity config for each mode, i.e. mouse steering vs mouse camera. Another feature would be the ability to choose a snap-back method (either as a controls config with the function linked to the toggle, or as a key shortcut independent of the toggle), i.e. snap camera to ship heading vs snap (steer) ship to camera heading. For now however, just a toggle will suit me fine. +1

OK, never posted a screenshot in my life. Let's hope I do this right the first time, ya? Two top weapon pods house mining and salvage lasers. Each pod houses two angles, one upright, the other rotated 90d cc/ccw. The salvage turret configuration in the ss is: 2x pairs, each pair has a different range 1x 1.6km upright left side 1x 1.6km rotated right side 1x 1.4km rotated left side 1x 1.4km upright right side This should create 3 unique fields of fire, with the two uprights sharing the same field, i.e. they're both tilted at the same angle on the same axis/plane. That's why I put identical turret pairs, one on upright, the other on rotated, on different sides. The combination of different fields of fire and different ranges should, and does, create a genuine independent behavior with respect to target selection of individual turrets, except when starting on a group wreck and when there's only a few pieces left to salvage. Spaced armor config should be obvious. The present config has about 1,300 armor blocks (all blocks total about 1,800 blocks), all 0.05 thick, all a simple two-piece template, all framework/armor combo, 8x2x0.5 dimensions, layered/stacked/staggered, except the sloping arrangement directly in front of the top weapon pods. This is a big ship, 56 mill m3. In spite of the disproportionately huge number of armor blocks, the amount of armor on this ship requires only 2 extra mechanics (total mechs required 1,082). I could probably make the plates thinner with the template scale trick, but it's just so tedious already, I mean, let it go, ya? In this particular build, I put up two complete templates of 4 wide bottom, 3 wide second layer, 2 wide third layer, then 1 wide top layer, all top layers staggered to center. One template with the struts length-wise, the other with the struts width-wise. Then I selected parts of those templates (either a side or some top layers) to extend complete templates where necessary, or where a full template didn't fit, i.e. 6x8, 4x8, 2x8. I think a couple hours to do. Anyways, that's the general idea of spaced armor.

Ya, I read the same thing, though I don't think that's how it works exactly. If it's just a block and it gets damaged equal to its HP, it pops, simple as that. Ship takes no other damage. If it's just a block and it gets damaged greater than its HP, it pops, excess dmg transfers to whole ship. This is true only if there's no other damage model, but I've seen some weird things so I think it's not entirely true. If it's in a field, damage equal to its HP is absorbed by the block only, nothing else happens. If it's in a field, damage greater than its HP, block remains intact up to 10x its HP, excess above 1x transfers to whole ship. Also only true if there's no other damage model. If there's another damage model where dmg pens only a certain number of blocks depending on total damage incurred, it changes the whole picture of ship building with regards to collision protection for example. There's already the wreck chance thing so in a group of blocks that takes damage, or in a group where one block in the middle takes damage, there's a chance that the group detaches from the ship and the block that took the hit pops. There's also the chance that the whole group pops and no wreck remains. We can see this when salvaging, where often a group of blocks pops instead of separating into its constituents. A ship is a group of blocks, therefore wreck chance always applies. The question is how do we build ships to account for this? I thought I figured it out with spaced armor, but now I think it's more than that. Next I'm going to revert to more smaller internals and see what gives cuz it's getting annoying to fix a ton of damage from seemingly weak collisions.

I use fields as well. Recently, I don't know what I did different but in spite of plates popping, ship takes a whole lot more damage from astroid collisions. So now instead of single layer, I'm doing 3 layers where most impacts occur. I'll see what gives. Either way, it still looks cool.

Nice ship. Simple and effective. Middle part looks almost modular, like you could extend it with a layer template. Thruster pods on framework struts, the win! For astroids impacts, consider spaced armor in those spots most likely to make contact (i.e. corners and front for example), either with thin armor plates or thin framework plates. Space armor saved me lots of headache replacing thrusters.

I'd like to address all your points because I'm in the habit of giving others' opinion a proper respect, but like you with framework angle suggestion - I don't see the necessity. There's only one person on this planet who's opinion matters with regards to suggestions to the developer about what to add to or change in the game - Koonschi. Literally, your opinion doesn't matter one bit. This means, for example, that if you post a suggestion of your own about what to add to or change in the game, it would be utterly futile for me to criticize it. Your suggestion would stand on its own, and only Koonschi's opinion would matter. However, as I have done with the suggestion in this thread, if I wanted the same thing, I'd put my +1 below your suggestion.

I think angle armor blocks look silly. I don't see their necessity. Ergo, by your own logic, they should be removed from the game. Doesn't sound right, does it? It would be more appropriate for you to specify that it would look silly to you, that you don't see the necessity for yourself. But then again, if that's the case, there's no reason for you to post in this thread, because whether there is angle framework or not, you will not use it anyway. What if somebody else uses it at some point, will you then complain about it, if and when you see it on his ship "yuck, your ship looks silly with all those framework angle blocks"? That would be your prerogative to criticize somebody else's ship, I guess. What if by some weird twist of fate, you do see it on somebody else's ship, and you think to yourself "hm, that actually looks cool"? Besides aesthetics, do you see any reason why a framework angle should not be in the game? I don't. Nothing technical prevents it - there's angle blocks for other block types. Texture can be made to look appropriate for framework angle, just like it's been made to look appropriate for other angle block types. One more block type - especially one with a strong aesthetic element to it (very little use for framework otherwise, ya?) - increases the possibilities in terms of creation.

Good thing I found your suggestion, I was just about to suggest the same thing. I want framework angles so I can make a more consistent spaced armor template instead of using armor angles/framework combo. Also with framework angles, we could make tilted arms like we can with armor angles. So, +1.

Ya, that's pretty much it. We can't put flat blocks at an angle, but we can put a series of thin angles instead, this would be the grill style rather than the spaced style. I'm hoping we'll see some creations that use grill/grid style cuz when done right it's awesome. Shame there's no framework angle, I'd be all over that stuff (come to think of it ima suggest it right now). In my experience, the most effective was a framework/armor angle complex template with thin framework plates acting as the armor plating. It's weakest so it pops easily, lightest and cheapest to replace. And it looks really cool to have a bunch of framework plates in a spaced config covering the front, top and sides, especially if it partially covers thrusters and lets their exhaust through, i.e. some plates are omitted for that purpose. But, it adds a huge number of blocks so I guess that's the down side. To illustrate, the save file for my current ship without armor plates is 30kb, and 150kb with armor plates. Biggest save file on an earlier ship was around 800kb, most of it spaced armor plating/complex.

@Brigadon Spaced armor is a tank term (learned that in a tank game, hehe) meaning that there is space between armor plating and hull. Ablative means just that, it will shed as it takes damage, keeping the hull underneath intact, as opposed to being an integral part of the hull and this gets damaged too. Game mechanics allow ablation of thin plates of armor, but not of thick blocks because of wreckage chance, i.e. several blocks attached to each other break off from the main assembly with the weakest block popping instead of the block that takes the initial hit. In other words, armor must be weaker than what's underneath in order to shed and protect internals, rather than to remain intact and transfer damage to internals. Field of fire for turrets is a half sphere, where surface plane tilt determines field of fire tilt. If turret is on an angle, its field of fire is tilted according to angle tilt, i.e. 22.5d, 30d, 45d, etc. Imagine we cut a sphere in half on horizontal plane, then tilt it forward. That's field of fire 1. Now imagine we rotate this half sphere clockwise 90 degrees. That's field of fire 2. Ya, the framework/field thing, I'm not too sure anymore. I think it's a matter of the field itself, i.e. is it strong enough to spread across the framework blocks? They were farthest than other blocks, and the field block was pretty small, so I could have been mistaken about that. Found another trick to change internals easily. Zoom inside the ship, then click select, it should indicate selection on the bottom right, also allowing to change the block. I just did that with my current ship. Easier than to remove a bunch of armor templates, but then I also did that cuz I wanted to revert to 0.05 plates instead of 0.1 plates. We can also focus on an internal block we selected. A trick to scale whole ship, if you keep same ship across several scaling as you progress through materials/size. Remove all armor plates, save ship, then scale. Once scaled, put on armor plates. Otherwise, armor plates also scale, they get thicker/heavier as you scale up. Also, since internals are exposed, it's quicker to adjust once scaled, cuz not everything scales equally, i.e. thrusters for example.

Spaced/layered/ablative armor works really well against collision with anything. Just a few moments ago I noticed that I had more armor than I usually do (0.1 instead of 0.05, cuz I scaled the current ship by 2x), and the plating didn't pop, but the ship took some damage anyway. When plating is thinnest, it pops and ship takes no damage for same collision. I usually make a T shape template, stick it everywhere I expect contact, i.e. corners, front, top. Framework plating works really well for that too cuz it pops easily and cheap to replace. In my previous ship, I had about 2,000 pieces of armor, but a total of only about 2,700 blocks. At one point I had over 3,500 pieces just for armor but that was too intricate with about 30 blocks per template. Various template shapes, T, H, plate/angle complex, framework/armor combo, grid, grill, etc. All as thin as possible, typically 0.05 but I figured out that we can make it thinner if we c&p the template then scale it thickness-wise.

turretfactory.lua has a code to take credits/goods from the player at turret creation. Maybe that could be used in this mod? Come to think of it, this mod is a kind of fighter factory, minus the factory, so it makes sense to create a fighter factory. Whoa Jebus, Fighter Factory!!! OK, going sideways on this thread but think about it. Found station -> Fighter Factory. Need more fighters? No problem, just tell us the specs, we'll make em for ya, cash or card, please? Otherwise it's a good mod. I might use it when I decide to make a carrier cuz it's just a pain to replenish fighters now.

I selected ogonite. I tried it again and it hung again, but I clicked "wait" on the firefox warning a few times and it finished. The output window was empty after that, but I was still able to copy the file. I didn't try that ship anyway because I wasn't sure it wasn't corrupted. If I may suggest a methodology for your script/page. Instead of filling output window after scale pass immediately, do scale pass then replace pass (or replace pass then scale pass), then fill output window. You'd have to use click boxes for scale and replace instead of buttons, then add a proceed button. This way, we can select scale and replace individually or together. On my current ship, I use framework as ablative armor in a layered/spaced template so it's cheap to replace and light so it barely affect maneuverability. Spaced/layered armor looks really cool. Anyways, I'd like to be able to replace the material for the framework.

I just tried it and I forgot about cubed scale, so I ended up with 0.2bt mass. Oops. Anyways, it works fine, but replace armor hangs for me.

I'm not that good with scripts but I think I figured out why the mod doesn't work as intended. In the shipyard.lua, function setSeed includes argument updatePlan, which calls function updatePlan, which includes argument "local seed = seedTextBox.text", which becomes the actual seed to be used to create the ship. If I'm not mistaken. Your mod has function setSeed, which includes argument refreshUI, which calls function refreshUI, so that's where you should add argument "local seed = something appropriate" -edit- Or, maybe you have to change function onSeedChanged because it still includes the argument "setSeed(seedTextBox.text)", which according to the rest of your mod is not the seed but +1/-1 to the seed. Something like: "setSeed(same as argument "local seed = xxx" in function refreshUI)"

The size parameter code I used in the previous post is for the window on the right. I'd prefer to do it with the window on the left (where type and rarity is changed), and size scaled everything else related to size. The left side menu stuff is in the file but somebody else would need to figure that out. Bear in mind that size changes everything cubed, so if it's 2x the size, it's 8x the volume/mass(for ingredients maybe?)/etc. This means a great deal of difference for heat/energy weapons like cannons and lasers for example. It should affect firerate for cannons especially because of heat, but it should also affect it for other weapons, so that even though dps scales up, firerate scales down. So, while we could make bigger guns, total dps output would not scale in a linear fashion.

Can you add recoil please? I figured out we can change size with turretfactory.lua, and I would eventually like to scale recoil (and basically everything else related to size as well, i.e. dps, firerate, psize, etc) with size but I'm not that good with lua code for that. Anyways, if recoil is shown, we can see the effect of changing size, and the modder who's gonna try scaling recoil with size will see immediately if his mod works at least visually if not in game mechanics.

Turret size can be changed through turret factory. Some info to help you mod the turret factory: http://www.avorion.net/forum/index.php/topic,2335.0.html When you're done, post some screenshots of your hugegunslol, ya?

Turret Size Works!!!! I just made a size 2 railgun, installed it, works just like a normal size 0.5 railgun. Code I used: {name = "Copper", amount = 2, investable = 50, minimum = 1, turretStat = "size", investFactor = 10.0, changeType = StatChanges.Percentage } Code above can make a size 5.5 turret, if indicated size is 0.5. Normally default size is determined by tech level and weapon type. For example, mining lasers are smaller than salvage lasers at same tech level, i.e. 0.3 vs 0.5 at TL36. All other variables remained the same, i.e. it didn't change tech level or dps or anything else, just size changed to indicated. I don't know if recoil is affected so that's something to test.

A computer control system (i.e. auto-aim, or in game terms aimbot) for turret is intended to maintain target in sight. It does this with the help of the turret's own inertia, i.e. the gun stays pointed wherever it's pointed because of its mass, the control system compensates for friction and for linear motion which also changes angle or alignment as the ship/target do not necessarily move in parallel in the same direction. If we acknowledge lag within this control system, then we can argue that the turret should turn with the ship for a short time while it lags behind as it reacts to ship's motion. However, inertia does not react, it always acts, the gun is never going to follow ship's motion if there's nothing to cause it to do so, i.e. no friction, no reaction lag from the control system, no lock pin on the gears/motors, it's not yet reached its stoppers or range of motion limits, etc. An object at rest remains at rest unless acted on by some external force. So, if we argue for control system lag, how realistic is it to say for example it takes about 0.3s for the system to react to ship motion and engage its motors to turn the turret in the opposite direction to keep the target in sight, or in this case to track back to its target because it has lost target lock due to this lag? In real systems, motors and gears and whatnots are specifically designed to take full advantage of inertia, i.e. they do not oppose its action because the action of inertia is an integral part of the tracking system. For example, it uses gyro assemblies that detect all rotational motion. I searched and found a few where it's a box with gyros inside and connectors for the system. You attach the box to the moving part you wish to control, when this part moves, the gyros apply some force on the motion detectors, the system then interprets this and sends the appropriate signals to the motor controllers and so forth. When this happens, the motors are not turning the turret in the opposite direction with lots of force. Instead, they turn it with only as much force needed to compensate for friction, because inertia does most of the work (without friction, inertia does all the work). In other words, the motors do not compensate for the whole turret's mass/inertia, only for its friction. The above is when it's keeping its target in sight. When it must turn to acquire a target, then the system sends the appropriate signals to the motors/etc, which then apply as much force as they can to turn the turret as quickly as they can. In this situation, we're dealing with tracking speed in the game. Think of the motors themselves. How are they activated, how is their force generated? It's not by some physical device that's always attached, it's by electromagnetic force between rotor and stator. Now imagine that the entire turret was one big motor with only electromagnetic force to make it turn (ignore friction for the moment). Would this EM field always be on, therefore always prevent the turret from turning? Of course not, the control system would be designed smartly to prevent that, and would only apply force when needed. A mechanical control system is designed just as smartly, it does not prevent the turret from turning (or from staying put) unless it's actively acquiring a target, at which point it must overcome inertia to do so. === The fast-and-slow suggestion is to compensate for the start-and-stop behavior. With current behavior, it does not track, it acquires target, then stops, then re-acquires target, then stops again, and so forth. This causes the salvage beams for example to chase tiny bits forever, until somehow the bit goes out of range, or by some lucky twitch of the turret (it's a bug), the beam finally hits the bit and it gets destroyed. But 1 minute to chase a slow moving tiny bit of wreckage is just retarded. Instead, with fast-and-slow, the turret will acquire target at full tracking speed, then slow down to a fraction of its tracking speed, overshoot, re-acquire target at full tracking speed, slow down again, overshoot again, and so forth, thereby sweeping across the target instead of chasing it, giving it a much greater chance to actually hit the bit without relying on the twitch bug. It's a beam, if I was in control of it, I'd sweep across it, which is exactly what I do in game anyways when I control salvage turrets manually. With other moving targets like baddies, it becomes much more realistic as well. We're talking 5-10km away, not a few hundred yards. Even if it was just a few hundred yards, with automatic weapons, sweeping is standard procedure just to get 1 bullet to hit, that's all that's needed for living targets anyways. The reason for sweeping is to use tracers to home in on the target, that's the sole purpose of tracers. In game, all projectiles are tracers. With modern computer control systems, there's radar that tracks the bullets, compares against the target, adjusts accordingly. This will result in a sweeping action, albeit an ever decreasing sweep as it will eventually zero in and then actually track. Inertia always acts. An object in motion remains in motion unless acted on by some external force. If the turret is set in motion - it's made to turn - it will continue to turn unless it's acted on by its control system. If a target moves across its field of fire in a constant linear fashion (it does not swerve or change direction), tracking is easy, just set the turret in motion to match target motion, then let it go as inertia does the rest. Of course the control system is mechanical and is always in contact, so it can't let it go. Instead, it compensates for friction losses by helping the turret maintain its orientation, i.e. it tracks the target. === We cannot argue simultaneously that turrets should be able to track a target dead on, while also arguing that it must follow ship's motion as the ship turns even only for a short time (reaction lag). The way it tracks a target is by using the turret/gun inertia (the turret is set in motion synchronized with target motion, then let go as the turret/gun inertia keeps the gun in sight), and the way it cannot follow ship's motion is also by using the turret/gun inertia. So basically there's only two things that oppose the turret/gun inertia - friction and reaction lag, neither of which would be significant for our purpose. === I accidentally figured out how to get around several behavior problems with salvage turrets especially. I wanted to create a 5 point cross with the beams to overcome the chasing part, that's how I discovered the other benefits. 3 IT turrets - 2 doubles, 1 single Install on angles all facing same direction, I prefer front 1 double on an angle at whatever orientation, the other double on another angle cw/ccw 90d from the first, this creates two different fields of fire, key to independent target acquisition Each double on each side of the ship, the single with one of the doubles Turrets should be a bit mismatched in range, about 100-200m Because of the angle installation, one of the doubles will have its beams 90d from the other, in conjunction with the other double and the single, it creates a 5 points cross that can catch bits more easily. The two fields of fire created by the two angles 90d from each other somehow prevent tandem operation with regard to target acquisition, i.e. they no longer all go for the same bit, instead they all go for different bits independently. At first I thought it was a matter of the odd number of turrets, but then I tried with another single to get 4 turrets and they continued to act independently, so I believe it's the different fields of fire that matter most for independent behavior with regard to target acquisition. Range difference also matters a little, as some turrets acquire targets before others as the ship moves towards targets. Even when the ship stays put, individual turrets will engage their own individual target.

Layered/spaced/ablative armor works nicely against collisions with asteroids and wreckage. I had started with layered, then I went with spaced, it looks cool and works very well. Only the first piece gets blowed up, cheap to replace, the ship is otherwise intact. So, you're in a situation where you're boosting towards baddies, and in between you and them is a tiny bit of wreckage that pops a block as you hit it, but of course you couldn't see it and would only know about it with a hit sound and the damage icon. With spaced armor, it's just a tiny piece. The trick with that kind of armor config is to build templates, c&p, stack it, etc. The simplest form is a T shape template that you stack to make a series of H blocks. Orient to cover the underside from attack/collision angles. More fancy configs are grill- or grid-like spaced armor, a bit like when building a boat with wooden slats in crisscross fashion, with squares and then angles for a smoother outer shape. For even more fancy, build up the underside with spaced armor, then stick shaped blocks for finish esthetics. Another idea is bumpers. Exactly like it sounds. Personally I haven't experimented with that but I did make some thruster pods and the framework on which it's stuck often gets blowed up with collisions. I guess a bumper is a sort of spaced armor, only more massive. Based on my experience with spaced armor, I find unlikely that the whole ship's HP pool gets hit by collision damage before the piece that makes contact. Instead, I think it's the wreckage chance thing, where if a piece is to explode, a random generator determines the chance for wreckage based on the number of blocks attached to the piece that is about to blow up, then breaks off all those pieces as the case may be. If there's just too few pieces in a whole ship, this matters much more than the HP of the piece (or indeed of the whole ship) that initially takes the hit. Furthermore, I also believe that there's a per-block damage model rather than a total HP model, a bit like railgun pen mechanics, so that damage can only pen so far into a series of blocks, making spaced armor configs more protective against collisions. So for example, between a ship with fewer large blocks and one with lots of smaller blocks, but of equal HP, the one with more blocks is more likely to survive and keep its internals intact. So, it's a test between fewer and more blocks, but with equal total HP. Spaced armor just works.

A few tricks I figured out. Using c&p, it's possible to make non-standard thickness, like 0.07 for example. This way, it's possible to make very thin layered armor plates. First, put two pieces together, the first is the plate you're going to use, the second is the throwaway that's going to allow shrinkage below standard thickness. Start with 0.05 thickness blocks. Select the two pieces, c&p, scale it down, stick it somewhere, remove the throwaway, select the piece you're using, c&p it, use it wherever. Be aware that using the asd scale keys on this piece will revert it to standard thickness, so prepare the piece accordingly. Layered armor, ablative armor, spaced armor. Use flat blocks, make either an H or T template, c&p, use it wherever, stack it. Game mechanics with regard to armor pen is per block, not per thickness. So, more blocks is better than fewer, even if they're super thin. Also, spaced armor is much lighter than full block armor so it can be used to build up a shape, then stick shaped blocks on top for esthetics. Spaced armor is very good against collisions, since only the first block gets blowed up, then the ships/objects react and move away from each other so no other block gets blowed up, and it's much cheaper to replace a very thin piece than a full sized armor block. Also, spaced armor just looks cool. Spaced/layered armor doesn't necessarily need to cover the entire surface, a grill-like configuration should protect from most attack angles except directly head-on, and it looks really cool too. Angle block is key for turret placement for several reasons. First is field of fire, next is rotation when sweeping across center line, then there's independent targeting especially for salvaging. Field of fire is obvious, if the turret is on top, side or bottom, and firing front, its field of fire only goes to center line horizontal/vertical. If it's on a front mounted angle, its field of fire is up to 45d past horizontal on the narrow side, whichever orientation the angle is set. Rotation is a problem with front mounted turret on a flat block when sweeping across center line. When on an angle block, the turret can sweep much quicker. Independent targeting for salvaging works best with this setup: 3 IT turrets, with 2 doubles and 1 single, to create a 5 point cross for chasing tiny bits 2 angles front mounted, 1 at 90d cw/ccw from the other to create 2 different fields of fire turrets must be a little bit mismatched in range, something around 100/200m the doubles should be the same configuration to create the 5 point cross, where 1 is rotated 90d from the other due to its angle block each double is placed on its own angle block, 1 straight, the other at 90d from it, and away from each other on each side the single should be placed with one of the doubles, so you'll get 1 double and 1 single on one side and 1 double on the other side install orientation should be forward for all turrets My goal with the above was to create this 5 point cross to work around the problem of chasing tiny bits, but then I accidentally found that this is the way to make all 3 turrets behave independently with regard to target acquisition, even when chasing tiny bits. They no longer chase tiny bits all at once forever. Instead, they target bits independently until destruction. Their targets do not reset all at once, they keep firing until their respective target is destroyed, then each will switch accordingly. They go for the big wrecks first as well. It changes the whole way to salvage. And in the event they do chase tiny bits all at once, they take care of it more quickly due to the 5 point cross made by the 5 beams. We can't stick blocks - like flat armor for example - on the angle side of an angle, but there's a way around it. Build it up on an inverted template with smaller blocks and angles, then c&p this template and stick it on some throwaway block just for that purpose. Once stuck, throw away the other block, the angle is now covered with armor. Or, stick a flat piece on the side of the angle, then build up the pieces on that block. We can make slanted blocks, like those on shipyards, using angles. Use a long angle, stick it somewhere, rotate another one 180 on its end, stick that one under the other, voila. We can also make a slanted arm with the ends perpendicular to the length so that it appears to be a genuine block but slanted a bit, it takes 6 (3 pairs of same respective dimensions, 2 mains, 2 smaller ends, 2 much smaller finish) angles of the same proportions, using a similar method as with 2 angles. Scaling with Q and W should allow to shrink and keep proportions, methinks. Framework does not allow integrity field to reach whatever is stuck on it. I learned that by making thruster pods, I had to stick extra fields on the pods. However, framework covered in spaced/layered armor should be much more sturdy and lighter than just framework or just armor, so we can make long arms to put weapon/thruster pods on. Fields spread linearly across their thickness, so the thicker it is, the farther it reaches, and conversely the thinner it is the shorter it reaches. Big blocks for internals for easy material upgrade, smaller blocks for exposed surfaces for ablative protection. Select box, and template save, are your friends for bunches of blocks to upgrade material. Also think of an easy way to access internals for that purpose, so some single piece somewhere well protected but easy to remove and stick back on. Or just use the xml trick on the ship's file.

I figured out the simplest way to simulate inertia on turret/guns is: Turret - ship = turret current tracking speed So, whatever the ship is doing, subtract that from the turret's motion, i.e. from its tracking speed. For example, if the ship is turning right at 1deg/s, then the turret turns left at 1deg/s. This maintains the turret's orientation as the ship turns, thereby simulating the turret/gun inertia. But if the turret's tracking speed is lower than the ship's motion, the turret will have to catch up to track back to its target because the subtraction will result in positive, i.e. 1deg/s - 0.5deg/s = +0.5deg/s, the turret will follow ship's motion at 0.5deg/s until the ship stops moving and the turret can now turn at its full tracking speed of 0.5deg/s. === Turret tracking behavior is determined in large part by the target acquisition tick rate, between 2/s and 3/s from what I've observed. This also determines reaction time when the ship turns. For example, when the ship turns, the turret follows ship's motion for 0.3s, thereby making it look like it has no inertia for that time. Increasing target acquisition tick rate will also simulate turret inertia, as the turret will react much quicker to ship's motion. Gunner's level could increase target acquisition tick rate accordingly, to give them greater value. For example, untrained = - 1/s, level 1 = no change, level 2 = +1/s, level 3 = +2/s. === Combined with the target acquisition tick rate, tracking behavior is also determined by the start-and-stop target acquisition behavior. It does not track the target as the target moves, instead it turns to line up, then stops, if the target moves or is moving, it turns to line up again, then stops again, and so forth. This is especially obvious with beam weapons, as the beams appear to jump at the tick rate. It is most especially obvious with high tracking speed, above 2.0. I tried it with tracking speed 5 and the twitching problem is so bad, it leads me to believe that the source of the twitching problem is this start-and-stop target acquisition behavior. Most likely the problem occurs when the turret stops. Probably because it's now idle with regard to orientation, not firing, therefore uses the idle code for this part of tracking. The code for idle points turrets at some target, typically the last target, or some point in space, always anywhere else but directly in front. This idle code has to be fixed, cuz it's just retarded. Idle turrets must point in their default install orientation. A simple solution is to never stop. Instead, when target is acquired, continue to turn the turret at a fraction of its tracking speed in the same direction. So, instead of start-and-stop, it's fast-and-slow. Maybe except if target is stationary. But even if target is stationary, salvage beams for example will sweep back and forth as they turn to acquire, turn slower, overshoot, turn back, turn back slower, overshoot again, and so forth. With this solution, acquisition tick rate will determine sweeping rate as well. So, while it will fix problems, it will also add some simulation of realism. === Manual control should remain untouched, it works fine as it is. The above is specifically to address IT turrets when in automatic mode.

Throttle ramp-up is, instead of going full on/full off, it ramps up to full throttle over a short period, like 1 second or something. This allows finer control at slow speeds. Make it configurable, with option to keep current throttle behavior. Also make it configurable when button is released between resets-to-zero, or ramps-down. Toggle thrusters only, for finer control at slow speeds, especially around asteroids and wreckage. This turns off the main engines, and forward button now activates only thrusters like the other directional buttons. I realize that both fulfill pretty much the same need, so I don't need both. Whichever is easiest to implement is fine with me. Secondary to this is view of xyz linear thrust values on ship/build menu. This allows finer tuning of thruster size/dimension/position installation.