lyravega

v0.005 -Fixed German localization

Range issues were fixed before 0.12, only thing this mod adds for pre-0.12 is lightning turrets to the list I believe. For 0.12+, don't use these fixes. The main post now says obsolete, sorry that I totally forgot about this :)

does that imply the mod is and will be compatible with 0.12.4 and beyond, unless you post an update? Bonus question: can someone tell me how to get the turret's OHM value or how it is calculated (best case: in what file I could find that)? This related to my previous question where I wanted to add an additional line showing OHM value (exactly as with adding recoil, example few post back). It is currently compatible. But may not be with a new patch. I'll update if/when necessary. And I don't understand what you mean by OHM value. You need to explain your terminology, because the weapons do not have any kind of OHM value. As I've stated previously, the only change is just one line. Also, when you are comparing the code for the changes, compare the previous game version's file with the current game version's file. The only change is one additional line, however it doesn't affect anything. Tooltip crashes are game bugs. If this mod is bugged, it'll cause a blank tooltip, it won't cause a crash. Nevertheless, I put another update which includes that unused line. But as I've said, crashes are game bugs, a faulty mod will be set to invalid and simply stop functioning. Seeing that the patch notes for 0.12.3 (for example) states that a crash related to tooltips has been fixed, there still may be a few more.

v0.004 -Updated for 0.12+ (download the other attachment that says "0.12+" if you are on that version) If you encounter any problems with either of my mods (this or Detailed Turret Tooltips), contact me directly on Steam (hint: my steam profile link is below my avatar)

After every patch, I skim through the changes and see if I need to push an update. As you also asked, I have no idea why "cargotransportlicenseutility" is required in this file as none of the functions on that Lua is not used over here as far as I can tell (but consider that I only skimmed through the changes). Actually, the only function from that file that is used in any of the Lua files is the "createLicense" function, and it is only used in the "cargotransportlicensemerchant". Anyway, long story short, after seeing that, I didn't push any updates. However if any errors are being throw and you suspect it is related to this mod, please provide me with a log so I can track the issue and fix it if possible. Regarding to the file you've provided, you have one extra function in your file, that may be the problem.

Oh yeah, burst turrets usually have insane DPS on paper but when you factor in the cooldown it really brings down the effective DPS. The only burst turrets I use are crafted ones if I can find a good one, if you lower their rate of fire sometimes they become good "normal" turrets.

I couldn't make any sense from recoil values so I skipped it. If you manually want to add it, duplicate a line (for example, Range; duplicate lines 339-344) then change ltext to something you want to see. Something like this; local line = TooltipLine(lineHeight, fontSize) line.ltext = "Recoil" line.rtext = round(wpn.recoil, 2) --can't remember if recoil is recoil or anything else line.icon = "data/textures/icons/target-shot.png"; line.iconColor = iconColor tooltip:addLine(line) More the Avorion folder in the .zip file or extract the zip to your "..\steam\steamapps\common" folder, where Avorion is located at.

Below is a code piece from passagemap.lua, line 157 local max = Balancing.BlockRingMax + 1 Shouldn't this value be between BlockRingMax and BlockRingMin? Like local max = Balancing.BlockRingMin + 1 or local max = Balancing.BlockRingMax - 1 Before, it was BlockRingMin, and some sectors may have been considered as outside the ring and allowing gate connection over the ring. But with this change in beta, wouldn't BlockRingMax+1 result in some sectors considered as inside the ring even though they are located outside visually, and result in a similar issue; allowing gates going over the ring?

Thank you too :)

Still happening in beta? Can I get a screenshot for it? I'm assuming they happen at a "corner square"? Below is a code piece from passagemap.lua, line 157 local max = Balancing.BlockRingMax + 1 Before the BlockRingMin was taken into action. BlockRingMin is 147, BlockRingMax is 150. Before a system at the edge of the inner ring could be considered outside even though it is visually inside. With this change above in the beta, another but a similar problem may occur; a system at the edge of the outer ring could be considered inside. Both can result in the same problem - a gate may lead from outside to inside visually, but as far as the game goes, it's well within rules. Basically the generation rules say that there can be no wormholes/gates from outside to inside, only from outside to outside or inside to inside, but you cannot have a perfect circle with pixels - this is the real thing that is causing the problem. That +1 is more or less for error correction, but I think instead of BlockRingMax+1, BlockRingMax-1 would solve this issue. In short what I'm saying is, change the +1 in the code above to -1, or even -1.5 as it'd be the average. Anything between 147 and 150. Let me know if this helps (I cannot play Avorion due to HDD failure, so I can only guess at this point :() Examples (all are the same, last one is more flexible) local max = Balancing.BlockRingMin + 1.5 or local max = Balancing.BlockRingMax - 1.5 or local max = (Balancing.BlockRingMax + Balancing.BlockRingMin)/2

This gate.lua handles naming and stuff, generation is handled by sectorgenerator.lua with the help of a few other files such as passagemap.lua. Don't take my word on this but I'm inclined to think that this change isn't retroactive. However occurence of having such gates should be very, VERY rare with the normal version (as it only leaves a handful of possible spots if my math is right, but would love to see a screenshot of it) and it shouldn't happen with the beta anymore. Also, a small hint: when comparing files, make sure you ignore the whitespace. I use tabs instead of spaces, and some compare tools go nuts over this.

Question in the title. For turrets, the function "getWeapons()" returns Weapon. For ships, the function "getTurrets()" returns Entity. Is this function not finished or something?

Not just description - it governs the blue "autolock" circles.

Yep, exactly. This is most noticeable with continuous beams, but all weapons follow this behaviour.

Hmm not sure. My data folder is where my game is installed, under ...\steamapps\common\Avorion\ folder in my case.

Nah I took no offense or didn't try to mean one myself :) I went with "pvelocity" instead of "reach" for weapons that only had one "reach" upgrade after testing the weapons a little bit. Some projectile weapons can get 7-8km range but with their default "pvelocity", I had a lot of trouble hitting the targets while testing, so I went with "pvelocity" instead. For weapons that have 2 reach values (cannons), I went with one "pvelocity" and one "pmaximumTime". I prioritized "pvelocity" over "pmaximumTime" because personally I think it is better to get a higher "pvelocity" as it makes hitting targets at long distance relatively easier compared to the other. It's more of a matter of choice. Some of these things aren't simply broken; some just didn't work the way I expected and required my input. So without trying to alter the vanilla stats that much, I went with the things that made sense to me. In the end, for a mod/fix I'm happy with the results, but there certainly are different ways to tackle the same problems. ---Google Translator Nah Ich habe nicht beleidigt oder versuchte nicht, mich selbst zu bedeuten :) Ich ging mit "pvelocity" anstelle von "Reichweite" für Waffen, die nur eine "Reichweite" -Upgrade nach dem Testen der Waffen ein wenig hatte. Einige Projektilwaffen können 7-8km Reichweite aber mit ihrer Standard "pvelocity", hatte ich eine Menge Ärger schlagen die Ziele während der Prüfung, so ging ich mit "pvelocity" statt. Für Waffen mit 2 Reichweiten (Kanonen) ging ich mit einer "pvelocity" und einer "pmaximumTime". Ich priorisierte "pvelocity" über "pmaximumTime", weil ich persönlich glaube, es ist besser, eine höhere "Pvelocity" zu bekommen, da es schlagende Ziele auf lange Distanz relativ einfacher macht, verglichen mit dem anderen. Es ist mehr eine Frage der Wahl. Einige dieser Dinge sind nicht einfach gebrochen; Einige haben einfach nicht funktioniert, wie ich erwartet hatte und benötigte meine Eingabe. Also ohne zu versuchen, die Vanille-Statistiken so viel zu ändern, ging ich mit den Dingen, die Sinn für mich. Am Ende, für eine mod / fix bin ich mit den Ergebnissen zufrieden, aber es gibt sicherlich verschiedene Möglichkeiten, um die gleichen Probleme anzugehen.

Ehh, no. "baseEnergyPerSecond" and "energyIncreasePerSecond" are "StatChanges.Percentage" so their difference is "difference = object[stat]" and thus always positive. And since they have a negative "investFactor", any investment on those will always be a decrease in those stats; a decrease in "baseEnergyPerSecond" and "energyIncreasePerSecond", and will not increase the energy consumption. That code piece, that statDelta is used to determine investable/removable primarily. The real place where statDelta is calculated is below that part: ingredient.statDelta = statDelta * (ingredient.investFactor or 1.0) * sign This is the real statDelta that affects the stat. And the sign here is this: local sign = 0 if difference > 0 then sign = 1 elseif difference < 0 then sign = -1 end Above, the difference can be less than zero for any stat that uses "StatChanges.ToNextLevel", and if that is the case sign will be -1, and thus ingredient.statDelta will result in negative. Each investment will reduce the stat instead of increasing it. statDelta is always positive, but sign can be negative for no reason, causing that bug at the first place. What you said is true, that the turret with better rarity can have a worse damage and causing this, but it doesn't justify the stat decrease as you invest more.

Well, thruster changes aside, before it felt like your ship had no mass when you did a forward thrust. The physics changes makes so much more sense now. Perhaps there was a bug attached to it; whenever I needed to do a retrograde burn, I had to use thrust left/right/up/down otherwise I'd change direction nearly instantly which made no sense. Perhaps the thrusters had insane force, or your mass wasn't taken into action that much. Still, as I've mentioned previously, liking the changes. I'm not expecting KSP levels of realism, but it was beyond arcade-y before. Now it feels just right for this game, in my opinion.

Loving the revised flight mechanics. Makes much more sense and doing 180&burn is not as wonky as it used to be. Time to redesign my ship, lost my last one to a gate crash anyway.

You have to navigate to, steamapps/common/Avorion/data/scripts/lib folder Find the file called tooltipmaker.lua, make a copy of it call it something like tooltipmakercopy.lua and replace the file ^ with the one you download for this mod author. :) Yeah, backups are always useful. Verifying works too, when you need to get rid of some stuff :)

New version. Nothing interesting really, got pissed off the other day a little. v0.003 -Added a "Not Ready" icon (after ramming my ship to a gate that wasn't ready and getting destroyed in the process, I thought this can be useful)

Wherever you installed Avorion, extract the zip; merge the Avorion folders. When asked to, overwrite the "tooltipmaker.lua".

Uploaded v0.002, added another fix. Changes in the amount of materials had an opposite effect on the turret weapon stats as the statDelta was getting multiplied by -1 unnecessarily, leading to negative statDelta and causing opposite effect on the stat.

Thanks :)

Need to check the /turret mod. It may be spawning turrets without weapons on them somehow. Or it is a rare occurence in the vanilla game as well. Because the error says "wpn" is nil, and that cannot happen unless turret:getWeapons() returns nothing; meaning the turret has no weapons on it. It may be a vanilla bug as said