Martin Levac

Thanks. I've used that mod for a long time, then it broke, fixed, broke, etc. Engagement range is the only reason I used it. If I knew what to modify in the files, that'd be best for me.

I want to increase the engagement range (from the player ship) of miners/salvagers. Is it possible and how do I do that? I don't do LUA, so I guess I'm asking somebody else do it if it's more complicated than just changing a value somewhere in the files. Also, is it possible to make armed fighters do burst fire? This one is a request for a mod proper. I'm thinking either keep the turret's property when it's got burst fire, or add an option for burst fire when building a new fighter. Also maintain DPS just for balance. Thanks in advance.

I understand that it was only a suggestion to bypass the whole dock then relaunch thing. If the Miners and salvagers ignore combat, they will keep on keepin' on while the fighters do the fighting. Like I said just a suggestion. - Surprise! I use the mod all the time and I've seen the behavior you described, even in vanilla game but I haven't played vanilla since I found this mod so I can't be sure if it's changed for vanilla. If I understand correctly, the mod script checks the blueprint to figure out what type of squad it is and what orders apply to it. It doesn't look at the fighters individually. So if you got a combat fighter blueprint for a mixed squad of combat/salvagers/miners, the combat orders will apply to all fighters in the squad regardless of fighter type. If you didn't set a blueprint for that squad, I guess the mod script looks at the first fighter in the squad or maybe the squad is considered combat by default or something, the mod author would have to explain. If it's a mixed squad with a combat blueprint, the salvagers/miners in that squad will not salvage or mine, they'll shoot ships. This is actually useful if you got salvagers in a combat squad cuz they do tons of damage to hull. Not so much with miners. Of course, it's totally useless to put salvagers or combat fighters in a miner squad cuz you get no resource from them. There's only one kind of target where it's useful to put miners and salvagers and combat fighters in the same squad and it's the xsotan breeders cuz it's part asteroid and part ship, but if I'm not mistaken this mod doesn't have any function to make this work and send out a fighter squad to attack those things. You gotta shoot them with your main ship or use AI-captained ships or whatever. I use only blueprints and build the squads from scratch so they're all dedicated, never mixed squads, that's the easiest solution to the problem you described. Oh yeah I forgot. If you use this mod, don't use the vanilla orders next to the squad icons on the left. Use only the mod icon/menu that comes with the mod. I don't know if using vanilla orders can mess things up cuz I've never used vanilla orders with the mod installed, just saying maybe it's safer that way.

0.15.1 changes turretfactory.lua significantly with the ability to set independent targeting, and adjusts DPS accordingly with various functions that weren't there before. I want to use custom seed with this new change. What specific changes do I need to do to make it work with the new .lua?

See this thread for more info on turretfactory.lua parameters: http://www.avorion.net/forum/index.php/topic,2335.0.html Quick and dirty edit below just for the OP. In turretfactory.lua, for the mining laser, change this line: {name = "Laser Compressor", amount = 5, investable = 6, minimum = 1, weaponStat = "damage", } to this: {name = "Laser Compressor", amount = 5, investable = 6, minimum = 1, weaponStat = "damage", investFactor = 100.0, } and change this line: {name = "Laser Modulator", amount = 2, investable = 4, minimum = 0, weaponStat = "stoneEfficiency", investFactor = 0.075, changeType = StatChanges.Flat } to this: {name = "Laser Modulator", amount = 2, investable = 4, minimum = 0, weaponStat = "stoneEfficiency", investFactor = 100.0, changeType = StatChanges.Flat } I just tested the above and it works fine. See where it says "investFactor"? You could try higher than 100.0 but that's up to you. You may have to hunt a bit for a good turret factory but when you got one, you can make mining lasers with uber dps and efficiency. For even easier mining, see this thread to get independent targeting on all turrets: http://www.avorion.net/forum/index.php/topic,1120.0.html Also see this thread to be able to change the seed to get different turrets from the same factory: http://www.avorion.net/forum/index.php/topic,1776.0.html Finally, see this thread to get the commands package so you can spawn the goods required to make turrets, without having to go all over the map to get the stuff: http://www.avorion.net/forum/index.php/topic,830.0.html

Did crew workforce requirement change? Officer workforce requirements seem to be based on workforce requirements, not actual crew count. Here's the 3 columns for crew, produced workforce, required workforce, from engineer down to pilot. Crew 9 12 6 28 20 total 75 Produced workforce 21.5 30 15 60 20 -- total 146.5 Required workforce 15 30 15 59 9 -- total 128 Now the officers, from sergeants down to commanders. Crew 6 5 1 Produced workforce 13 5 1 Required workforce 12 3 1 Sergeants workforce requirement is 12, but I have 75 crew (so, sergeants workforce req should be 7, or used to be). Lieutenants workforce is 3, but I have 6 sergeants (so, lieutenants workforce req should be 1, or used to be). Commanders workforce requirement is 1, but I have 2 lieutenants (so, commanders workforce req should be 0, or used to be). Instead, it seems that officer workforce requirements are now based on crew workforce requirements for sergeants calculation, and so forth up the chain of officers. So, need 12 sergeants because need 128 crew workforce, need 3 lieutenants workforce because need 12 sergeants workforce, and need 1 commander workforce because need 3 lieutenants workforce.

If it will help. The sides of the nose is tricky, but doable. The trick is to cut all non-existent (i.e. that don't exist in Avorion) angle/edge/corner "blocks" at all their intersections on all 3 axis to end up with only blocks that do exist in Avorion. Doing this will also give you the base square blocks of the exact dimensions required to fit the angles/edges/corners. For example, the larger non-existent corner "block" on the upper-side of the nose. Note how its intersection touching the central part of the nose is almost aligned with the base of the first edge/angle of the upper-central part of the nose (the angle right behind the cockpit, I believe). With the ship sitting on its belly and we're looking down at it, cut vertically width-wise at that intersection. Then, cut vertically length-wise at the forward intersection of that same non-existent corner block. We still have non-existent corner blocks, so we cut once more but horizontally thickness-wise this time at the new intersection created by our first two cuts. Maybe the above is not very clear, but just remember to cut the non-existent block on all three axis - vertically width-wise, vertically length-wise, horizontally thickness-wise. It's possible to end up with pieces that just don't play nice anyways no matter how many times we cut them like that, but it'll get you closer to the shape you want.

That's a really good idea. It would supersede a bunch of other "new blocks, please" suggestions. There's one way it can be done without changing anything about the current build system or existing blocks. For example, I want to make a multi-angle template for a spheroid or something, I'd need to build it up with multiple blocks and angles. With a mesh block, I could do the same, where it would create those multiple blocks and angles automatically (fewest blocks, best fit) depending on the mesh points I set for it, and I'd end up with the same template as in manual build-up. It could have a symmetric/asymmetric toggle, with edges for symmetric and corners for asymmetric. Mesh points could obey size/scale steps for better alignment. In case of blocks that don't have angles or corners, it would build the overall shape with the appropriate size/dimensions of smaller blocks according to size/scale step (fewest blocks, best fit). It could have the option of filling missing edges/corners with a choice of angle/corner type, i.e. armor, glass, stone, etc. Mesh would obey match block toggle for proper fit, by scaling its components accordingly. For additions to a multi-block base to keep proper alignment, it would need a match-template (or match multiple blocks selection) toggle where we set the outer limits (or the blocks) to be matched by current template. Basically we match two mismatched templates together so that their outer faces match for smooth external shape, and we do this by scaling the components of the new template appropriately. In effect, it would not be a new block, but a new method of block assembly and template construction. +1

For the alt-mouse view limitation, it's been requested in suggestions sub-forum already, add your +1 to that thread (forget exactly which, do a search). In the meantime, there's a few tricks you can use. Quickest is to add a holographic block that extends your ship's front so the camera is forced to focus further forward (with the bonus that you can dock from much further away cuz holo blocks can't make contact with anything but still register for docking, then color your holo block to make it invisible), but the problem here is that now the camera acts a little weird cuz its axis is offset from the ship's axis (due to center of mass staying pretty much the same spot) especially for yaw/pitch. Next is what I do, build mostly short, thin and wide, but then I hit the warp gate problem much more quickly cuz the ship won't fit even though it's still pretty small in terms of mass/volume (in fact the camera limitation is the primary reason for most of my ship designs to date). Finally, install turrets close to front upper point to mitigate parallax, but then it's kinda meh not so pretty solution.

I just did a few volume experiments to figure out the slot progression from 9 to 11, so you can have another option besides adding a huge computer core to get 11 slots. Minimum values for max slots ~19.5 mill total volume = 9 slots ~31.5 mill total volume = 10 slots ~41.5 mill total volume = 11 slots Your ship is 38 mill total volume, so total volume alone gives 10 slots. Computer core adds to total volume, so just its volume adds 1 extra slot (from 9 to 10), then the bonus gives 1 extra slot on top of that. The computer core you added is at least 6.5 mill volume. If instead of a computer core (to get 38 mill total volume + computer core bonus) you add other block types to get a total volume of 41.5 mill, you get 11 slots just from total volume. That's an extra ~3.5 mill volume on a 38 mill ship. In practical terms, it means that instead of having a 6.5 mill block that gives 1 extra system slot but nothing else, you could have ~9.5 mill of other block types for various improvements, i.e. generator, shield, gyros, thrusters, engines, inertial dampeners, cargo, armor, etc, and get 11 slots. But if your ship is perfect the way it is at 38 mill volume, then that means the ship design must become a little less perfect. But maybe it's possible to increase total volume by scaling so you wouldn't have to change its design. It doesn't fix the hyperjump recharge problem, but it gives you another option besides adding a computer core to get 11 slots.

Even though I set TdrLevel = 0, I still got a TDR error about 10 minutes ago. I was trying some changes with broadcastinterval and workerthreads in the server.ini file for one of my galaxies, and the error popped up first time I hyperjumped. So I figured the registry key doesn't work. So I checked it again and noticed that there's other keys but they're Dword instead of Qword in spite of my Win7 version being 64bit. Anyways, I changed it to Dword and the error didn't pop up the few times I HJ'ed again in the last few minutes. Dunno, maybe that did it. I did notice that now when I hyperjump, the mouse cursor now appears as an overlay right in the middle of the screen with the "working" cursor, as if to show the app is working, like when we start an app for example. Going to edit first post so people don't go with Qword uselessly.

That's a performance problem due to current lack of code optimization. It's different than a crash-to-desktop due to TDR. Turning off TDR will not fix/prevent performance problems. TDR is not a game feature, it's a Windows feature. Follow the Microsoft link in my previous post for an explanation of TDR.

Ever seen this? Not me. First time in a decade of using Windows 7. Never happened with directx games, of course, because it's an error message for opengl. However, personally I have see a similar error message for directx apps/games, and others with ATI and Intel graphics have reported this and similar error messages, so the problem is not unique to nvidia/opengl. Anyways, found the solution. Links to explain: https://msdn.microsoft.com/windows/hardware/drivers/display/timeout-detection-and-recovery http://nvidia.custhelp.com/app/answers/detail/a_id/3007 In these links (and about a thousand other links on the same problem), the proposed solution is to increase the delay (TdrDelay key) from 2 seconds (default) to 8 seconds (or more), with the logic that a longer delay will prevent the error message from showing, and allow the game/app to continue normally. That doesn't actually fix the problem, because the problem is TDR itself, not the game, not the app, not the display driver, not nVidia, not opengl, not the hardware, not a poor performance PC, not the overclocking, not the cooling, not anything else but TDR itself. I tried increasing the delay, didn't work. The correct solution is found in the Microsoft link, but instead of increasing the delay, turn off TDR altogether with the TdrLevel key instead of the TdrDelay key. === begin instructions=== Registry Editor: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\GraphicsDrivers If TdrLevel key does not exist, create it: While GraphicsDrivers is selected, open "Edit" menu and select "new"; DWORD value for 32 bit Windows QWORD value for 64 bit Windows (edit = QWORD doesn't work, use DWORD with 64bit as well) Then name this key: TdrLevel And set its value to: 0 (edit, sometimes people just do exactly what they're told without thinking, so here's a little extra instruction to make sure that doesn't happen) - Close Registry Editor, save changes - THEN Reboot computer. === end instructions === Be aware that it will not prevent a delay due to natural hardware/software limits, but it will prevent TDR from shutting down the game/app so that if for example a game appears to hang for a second or two because of poor computer performance, it will just appear to hang for a second or two, then continue normally, instead of crashing to desktop with an error message. In my case, it doesn't just shut down the game, it also corrupts my graphics drivers so that I end up with constant graphics artifacts, and I have to reboot to make them go away and return things back to normal. At first, I thought I broke my graphics card and would have to buy a new one (cuz I did break one once and it did cause graphics artifacts, but permanently, reboot didn't make them go away), that's the effect of TDR for me, but fortunately I have a brain and sometimes I use it. Well, others with really powerful computers working perfectly, or even doing seemingly simple activities like browsing the web for example, have also reported the same error message. What a brilliant "feature" of modern operating systems, ya? Anyways, if you've seen this error message (while playing Avorion, or doing anything else for that matter), and you try this solution, report back please.

TANSTAAFL Ships presents the next evolutionary stage of multi-plate armor designs - Stan LD Hybrid Widebody (he ate too much, but that's cuz he was doing the bulk phase, brah!). Featuring the popular Dual-Twinned-Stacked-Angled-Armored Weapon Mounts, and the potent Multi-Thruster-Matrix Packs (forward mounted, of course). The DTSAAWM's and the MTMP(FM,OC)'s should give gunners and pilots alike something to look forward to. In excess of 2,500 armor plates, each and every one of them individually QC'ed by qualified technicians and laser-engraved with a unique serial number and installation location ID for easier replacement in case of destruction. Your local shipyard or repair yard should have a record on hand. Currently awaiting a retrofit to add a shield module. XML file provided below as attachment. Stan-LD-Hybrid-W.zip

TANSTAAFL Ships presents Sten's bigger brother - Stan LD Hybrid (he's adopted). Barely tested, almost brand new, not nearly perfect, absolutely average performance, but what a bunch of armor plates, eh? Block count for armor is over 1,500. It should be fun enough as I progress toward Naonite. XML file provided below as attachment. Stan-LD-Hybrid.zip

It is ablative armor - plates have so little HP they pop when hit. I think there's very little difference in protection between plain layers and spaced. I prefer spaced because it just looks cool, but it's also highly functional in terms of collision protection. We can see a more elaborate configuration in this post: http://www.avorion.net/forum/index.php/topic,1047.msg15806.html#msg15806 The degree of complexity one can create with spaced configuration is virtually unlimited. In the Sten ships, the template is a simple 2-piece T shape, stacked. In the bigger ship, it's also a simple 2-piece T shape template, but with framework strut instead of armor. On an earlier ship, I made templates with over 30 pieces each, of various angles, framework struts and plates. In the Sten ships, we could describe it more as a grill-type config (plates are perpendicular to underside), while in the bigger ship it's obviously just spaced and stacked (plates parallel to underside). There's also the grid-type config, where the trick is to clip plates through each other perpendicularly. In a grill/grid type config, we could create a smoother external shape with thin angles, thereby saving a tremendous amount of mass for armor (which keeps mass distribution closer to CoM for better ship handling) while still providing decent protection, and creating a more aesthetically pleasing ship.

Intended strictly for function. No consideration for aesthetics. Starter ships at this time (heavier ships later as I get to it, maybe). Iron and Titanium versions (higher materials eventually). Spaced armor plating configuration. Frontal turret mount on an angle block (edge armor). The Sten-SS1a-Ir and Sten-SS1a-Ti Cheap and versatile starter ships. Sturdy enough to take on baddies in starting sector on insane difficulty, but be wary of Xsotan ships fire power (I've seen several with over 300 ohm, nearly bit it that time, got lucky) since just one of them can take it out in a couple seconds. Use longer range to your advantage. Should be a piece of cake at normal difficulty. Spaced armor plating pops, thus protecting the underside, cheap to replace. Identical in all respects, except integrity fields for the titanium version. Screenshots show cost when applying plan, as well as stats with full crew at or near lvl3. XML files provided below as attachments. Sten-SS1a-Ir.zip Sten-SS1a-Ti.zip

See my previous post, follow the link, I just posted a screenshot of what can be done with size in turretfactory.lua.

To show what can be done with size: All other stats are modded individually through turretfactory.lua, i.e. they're not the product of scaling size.

No, I don't think there's any restriction for external download links for mods. Screenshots are mostly external links because of their size, i.e. imgur.com for example. XML files for ships are also mostly external links, also because of their size. Personally, I see the benefit in the greater number of other types of systems (battery, generator, shield, hyperdrive, etc) that I could use by freeing up several slots with a single Jovian^2 artifact. I mean extra firepower is nice and all, but extra boost in other systems allows a much greater freedom in ship design, i.e. smaller battery/generator/shield/hyperdrive blocks. With a single legendary hyperdrive system for example, we can already plan for a half-size block for that. With an extra slot, we can plan for even smaller, and so forth. And then there's the extra surplus energy that is no longer required for full size blocks, allowing even smaller generator blocks.

Build it, and they will come. Aw shucks, I thought I had downloaded the mod. Keep us posted on your progress. No rush, but I promise you it's gonna become another essential for me, and likely for others as well. It gives a tremendous extra incentive to hunt for Xsotan artifacts.

Which Xsotan artifact is needed at first? Is it the turret artifact, forget exactly the name, but numeral is IV I think? I mean that would make sense since each gives +5 to turrets so 5x of those would logically produce a +25 super artifact, right? I'm gonna try this mod. By the way, keep this thread in the mods sub-forum, it's a mod after all. And now that you solved it, change title to [MOD]. And thanks for making it, I appreciate it. I just noticed that you modify the researchstation.lua file. I use autoresearch mod that modifies the same file. Would it be possible for you to integrate your mod into autoresearch, or work with the author of autoresearch to combine the two? I'm very likely not good enough with lua to do that myself, but autoresearch has become kinda essential in my game. I had tried an alternative where I just mod the systems directly by multiplying the turret bonus but I'd prefer to do that with a genuine mod like yours.

I've used the size parameter for a while now and I found a problem with it. The turret and weapon(s) change size, but the lateral (side to side) position of the weapons, when more than one, doesn't change so that if it's big enough, the weapons merge/clip into each other to become just one, misshaped larger weapon. I thought it was a fluke at first, then I made two of the same turrets (double cannon type) in different sizes and noticed that the bigger one looked pretty much like a single barrel while the smaller one had these tiny slits on each side of the barrel, then it hit me - changing size does not change weapon position on the turret. The weapon's height does change so vertical position appears to scale properly. Otherwise the turrets/weapons work normally, so it's just an aesthetics problem. I guess when somebody decides to make a mod that scales other parameters with size, this would have to be addressed as well if possible.

What I'm suggesting in this thread is different than what you described in your post. You're talking about boost, while I'm talking about regular thrust, i.e. spacebar boost vs forward key thrust. And you're talking about maximum speed and beyond to go somewhere fast, while I'm talking about very slow speed to navigate asteroid fields and wrecks and to dock. You should make a new thread so that we don't get confused about the specific suggestion.

I quit using the keyboard for look when I discovered mouse camera control in Doom before the intarwebs. Used the arrow keys for movement for a decade. Then I went to asdf. Never used wasd, unless forced, but quickly quit any game that forced this. Just saying, it ain't my thing. The x/c/v thrust, is it a sticky throttle, like you set it to a value and it stays there until you change it? That sounds like cruise, it doesn't serve my purpose. I want the same thing that's in the default controls, but with a throttle ramp up where thrust increases the longer the key remains pressed until ship/engine max, then cuts to zero when key is released. The ramp up time should be short, like a second or so. Normally, when max thrust and max speed is low, it's easy to navigate at slow speeds, but with my current ship with ~400m/s thrust and ~1,400m/s max speed, just a fraction of a second too long and I plow into astroids and wrecks and docks like a noob. Now compare current function with throttle ramp up (where it ramps up thrust from 0 to 400m/s in 1 second), using my current ship stats above. Current 1 second thrust = 400m/s speed Ramp up 1 second thrust = (complicated algorithm, which I don't know but could find on the intarwebs, but won't cuz I'm lazy) ~200m/s speed The example above is for 1 second thrust, where I would "forget" to let go. At 1/2 second thrust, current already gives 200m/s speed while ramp up gives about 100m/s, and for 1/4 second thrust current already gives 100m/s while ramp up gives about 50m/s. But the most important aspect here is not speed, instead it's distance traveled over such a short period. Given the acceleration/speed values and the fact that we're dealing with short-ranged mining/salvaging lasers and the short distance required to dock, we can certainly understand why people ram into asteroids and wrecks and docks as if they really loved to repeat the experience. Over and over and... In a different game, I literally smashed my mouse at that point (went out to buy a new one, then came back to the same game and server and players, including the guy that caused me to smash my mouse by headshotting me like 10 times in a row from the same gddmn spot in the same gddmn tree). I told him what I did and why, and he said "was it because of me?" (I'm absolutely positively certain he was laughing his butt off on that one), but that's a story for another time. The reason I want this is to have finer control at very slow speeds to navigate asteroid fields, wrecks and to dock. Throttle ramp up is the easiest to use in game because it's automatic/always on and requires no additional key press, i.e. toggle speed limiter for example. Nevertheless, any of the three options I already suggested will suit my purpose, so whichever is easiest to implement is fine by me. If it's a thrusters only toggle, then it becomes much easier as well because thruster thrust has always been much lower than main engine thrust in all my ships to date (we can already disable engines, but then forward key does nothing so this feature is useless for now). If it's a speed limiter toggle, then it doesn't matter how much thrust there is. Come to think of it, since we can already disable the main engines, I suppose the easiest to implement (and the one that makes most sense) would be the thrusters only toggle.