lyravega

I gave MassCraxx my permission to maintain the mod.

Check this post by Raio_Verusia, he provided a small snippet in the meanwhile. From what I can tell, turret slots are more of a static value, and also a balancing factor for the devs. The more slots that a turret has, the more damage it deals and the higher reach it has. Everything related to the slots are already included in the calculations though. "DPS per slot" could be useful to decide what turret has highest DPS per slot though, I'll keep that in mind when I'm updating the mod. Actually, the official tooltips show eDPS now. For like 95% of the weapons I checked out (thank you, debug menu), I'm proud to say that my calculations were right on spot. I'm also glad that developers chose to calculate eDPS off of a full cycle as well. However, there are some weird stuff going on which I'm trying to figure out. Such as this, the vanilla tooltip is reporting a DPS of 2218 while my calculations report a DPS of 554.5, and there is a pattern to this issue. Certain weapons with "Independent Targeting" (such as Railguns and Bolters) multiply their DPS with their weapon count for some reason, and I think it is a bug for the vanilla. The screenshot I linked for example, it is a quad turret; it has 4 weapons and if you multiply my result with 4, you get the vanilla tooltip's result. But I bet it is a bug. Also, the vanilla "Time until overheated" and "Cooling time" are still inaccurate. What I don't understand is, for a weapon like this for example, the difference between "time until overheated" and my "(Heat) Buildup" is quite different, yet the eDPS result is the same. There should've been a variance, because that difference is enough to push the vanilla eDPS to a much higher value. I think vanilla eDPS does its calculations like I do but for some reason it shows the wrong "time until overheated" values? Dunno, I never trusted that value and did things the hard way anyway :) As for an official word on this mod, an update is coming, slowly. Since there are many changes, and additions, I'm trying to double check everything, go over my calculations and stuff which is taking time, but to be honest, it takes more time than usual because as my interest has shifted to other games. Still, don't just want to slap the torpedo additions and release an update, and then realize there is a bug that I could've avoided. I don't want to force people visiting this topic daily to see if there is an update, so to speak. If they add Steam Workshop support someday, I'll go with it, but as long as we're doing things on the forums, I'd rather avoid uploading updates as soon as I finish one. When I have spare time, and not playing another game, I try to work on it. Also, I'm trying to decide whether or not to alter the way the tooltip looks, and leaning on something like a table to display the values and avoid adding more lines on top of more lines. But a table-like look with multiple rows & columns might not look that great, so a bit on the fence about it. Nevertheless, have been trying to learn more about the UI for that case.

Unfortunately that is not possible due to several reasons.

Seems like a fighter had no weapons on it. I'll fix it soon.

Good to know. I mean it is definitely required on the clients, but wasn't sure for servers.

I remember that I was trying to access the ship power generation and battery size, but I didn't find a way to dig further either. There is a chance that some stuff might not be exposed to the modders. I didn't dig it that much though, there can be a way but I wasn't able to find it.

Entity() differs from script to script, I think the best way to find the turrets is to get player, then player's ship and so on. Never used those though, at one time I tried to so that I could provide better stats for energy weapons, but I wasn't able to access to the player ship stats. As I've said though, after failing to access those stuff, I didn't try again. Be cautious about where/when you execute your script though, you don't want to execute stuff unnecessarily. I wrote a different small mod to create a "Watch Window" for debugging purposes in which I intended to view certain variables such as heat. For heat, I actually did exactly what you're suggesting here which is to get the player then his craft then the array of turrets. Both getTurret() and getTurrets() returned a single entity rather than a TurretTemplate. getTurrets() should return multiple stuff, but if the assignment is like "turrets = X:getTurrets()" only the first entity will be assigned, "turrets = {X:getTurrets()}" should work. That might be what you are experiencing.

You can notice the max heat thing if you have a super-heat-generating turret that generates like 90% heat with one shot. The 2nd shot will take it beyond 100%, lets assume it has a 10% cooling between shots, the next shot will take it to 170% heat. If you can get the turretfactory seed for that particular example where adding components decreases DPS, I'd like to check that out though. Entity() differs from script to script, I think the best way to find the turrets is to get player, then player's ship and so on. Never used those though, at one time I tried to so that I could provide better stats for energy weapons, but I wasn't able to access to the player ship stats. As I've said though, after failing to access those stuff, I didn't try again. Be cautious about where/when you execute your script though, you don't want to execute stuff unnecessarily. You probably have noticed, instead of "obj" (turret or fighter) I use "wpn" in some cases (wpn is obj:getWeapons(), I only need the first weapon as all weapons are identical on a turret). The reason for this is to simplify some stuff for me, and I had a case once when a turret spawned without any weapons. Then I realized I could use it instead of obj for most cases. Anyway, back to the point... If a multi-weapon (multi-barrel) turret doesn't have anything special on it, the weapons take turns actually, except the continuous stuff which gave me a headache back in the day. Lets say it is a turret with 4 barrels, and the turret states 1/s for its fire rate, the individual weapons actually has 0.25s fire rate. But if the turret has "simultaneousShooting", when you fire, all of the weapons fire at the same time. This is shown on the vanilla UI as well, however there is another type of multi-shot. "shotsFired" is normally 1 for most weapons, but for some it can be 2 or 3. For these turrets, when you fire, you fire multiple projectiles at the same time. So a damage value of 1000 actually becomes 2x1000. This was missing in the vanilla UI I think. I really can't remember right now but I think simultaneousShooting is included in the vanilla calculations, but this multi-shot is not. Heat generation stays the same since it is still just one weapon shooting (multiple at once). For simultaneousShooting it is a different case though; if a turret's heatPerShot is 0.2, and the turret has simultaneousShooting, the actual heat generation is 0.2*weaponAmount. If you want to test max heat properly, I suggest you to find a weapon with massive heat generation. I was a hoarder, I had hundreds of loot when I was writing this mod, and some of the weapons surprised me. I've seen weapons that overheat with just one shot, simultaneous+multishot weapons that fired 12 projectiles with one shot, and so on. Unless the developers hard-capped it to 100%, I'm pretty sure they go beyond 100% as I've stated earlier. Also, don't think it as a competition or anything like that. This is perhaps my 15th game that I've made mods for, and for any game that I worked on, whenever I or someone else made a mod that had similar functionality to another, I have always seen it as an opportunity to learn or to teach or just to work together. You want to provide extra information in your mod for example, my first iterations of the mod was a colossal wall of text per tooltip believe me :) I had to dilute the information somehow, and compress it in a way. I used to use heat:cooling ratio as well but decided not to use it as shooting faster meant overheating sooner, and some weapons have way long cooldown periods. eDPS staying the same looks funny and incorrect till you include those cooldown periods and it surprises you. Still, it's much better and correct than what vanilla offers though. At the very least, you get to see heat/cooldown stuff, which was the main point of the mod :) I'll go over all of my calculations someday, but thinking of the headaches I've suffered trying to figure out some stuff, it's not any day soon!

No I won't :P I've uploaded a new version, and disabled those Not Ready icons for now. v0.008 -Disabled the Not Ready gate icons as the vanilla bug still persists. They'll return later, when the vanilla bug is fixed -Made the icons rounder

The bonus to fire rate is already included in that fire rate you see, as it is in the vanilla. The little deviation is caused by numbers getting rolled up or down; either the fire rate, or the damage. Fire rate could be something between 0.296 and 0.304 and ends up being displayed as 0.3. And adding more components to a turret should never decrease the DPS unless turret factories are still bugged; there was a time increasing/decreasing components had the opposite effect but I don't think that's the case. For eDPS, it should stay as it is as eDPS always takes cooldown and heat-up times into calculation. eDPS always assumes you keep firing without stopping, and firing faster in a cycle (from 0 to 100 and then back to firing again) actually doesn't make any difference due to a few factors. It looks weird I admit, you see fire rate going up but eDPS staying as it is, however when you consider some other stuff it is like that. To be honest, when I first saw that value not changing, I thought I had a miscalculation somewhere, but when I looked at it with some examples, seeing that not changing at all was actually surprising for a bit. Also, a few things for your mod, if you'd like to develop it more: • The heat is generated per weapon, and some turrets fire all weapons at once. Unless you factor that in, you'll have wrong stats for such turrets • You should pay attention to heatPerShot more, as a weapon can go beyond 100% heat, instead of capping at 100% unless a patch has changed it. Otherwise you'll have incorrect stats for anything that can heat • I think you are incorrectly showing the DPS of a weapon if it is one of those that can cooldown faster than it can heat-up. If obj.coolingRate is 1 and stats.heatPerSecond is 0.5, then the overall DPS you have shows 2x the amount Keep it up!

Ok, I've PM'd the folks experiencing the fighter creation UI lock-up, and it turns out one of them was using the wrong version :) If you are on stable (default) branch, use the older version of the mod, if you are on beta branch, use the latest version. But as always, if you are experiencing any issues and suspect my mods are the issue, after closing the game, navigate to %Appdata%\Avorion folder, and upload the latest log here and I can check it out and locate the issue. Any help & suggestions are welcome!

Yep, it's a sign that the mod is broken due to something, but I cannot reproduce it on my own, I've visited several docks, boughts tens of weapons, etc... but wasn't able to reproduce it. When that happens, it should say something in the logs; after it happens, can you close the game, and go to %appdata%\avorion\ and grab the latest log file, and then upload it over here so I can take a look at it?

Can you take a screenshot of the weapon you are trying to create a fighter from? Or is it any turret? More importantly, after that happens, it should say something in the logs; after it happens, can you close the game, and go to %appdata%\avorion\ and grab the latest log file, and then upload it over here so I can take a look at it? I've tried to replicate the issue, but on my end it seems all fine so I have no clue.

It should now. Try the latest version! Also, please read the "Known Issues" section, this time there is something odd with the vanilla game.

I think something is wrong with the gate.lua file. I was updating my mod, and noticed that a lot of the gates had N/A icon (which is used to show Not Ready state). Thinking it is my mod, I switched back to vanilla, and the issue persists. Some of the gates are reported as "Not Ready" even though they can be freely used. The gate entities have two callbacks, one on the server side, one on the client side. I think both of them are not functioning; on server side, the callback is "destinationSectorReady" which should invoke the "updateTooltip" function, and in turn change that "Not Ready" on clients to "Ready" eventually. Likewise, on client side, the callback is "onSelected" which should invoke the same function, but it doesn't change the description/icon upon selecting the gates. My previous experiences with "Not Ready" gates were due to server crashing but client going on for a bit, and if that happens you pass through the gate wormhole as if it is not there, or rather not functional as the "Not Ready" states. However, as I've said, since I can use the gates even though it says "Not Ready", I believe something is wrong with the callbacks. Maybe with somewhat recent Gate namespace addition, callbacks are actually not working? That or you guys added something to force the server get a sector ready as soon as a client collides with a gate wormhole. Sorry for any confusion.

At first, I thought this can be an error on my part, but but reading the reply above, I think it isn't. I think creating a fighter does a flat reduction on the fire rate, and since that one has a very low amount to begin with, you end up in a negative fire rate, and the weird results here. Just to be sure, can you guys disable the mod and see if it persists? I'm pretty sure it's not my mod, but as I've said, just to be sure. Also, is the vanilla tooltip showing the same fire rate for the weapon? I don't understand that part; is it showing 0.05 but shooting at 0.5?

Apparently I pushed an update at the same day? Kinda glad that I added something to prevent the mod from trying to calculate the DPS of an nonexistent weapon. I have a fix for cargo and crew shuttles, after I'm sure it is working properly I'll post it. edit: Put the update up, download 0.024 if you are on beta. Fixed the crew/cargo shuttles.

Sorry for late update. Like 1 month late.

That's... still interesting, because I cannot explain why you would see the vanilla tooltips. And the difference between that version and the previous one is one added line, which does nothing so far from what I can tell. I just added that line and a failsafe for a very rare problem, meanwhile working on some other little things and re-evaluating my calculations. Nevertheless, I'm glad its working again :)

I still have no clue... Are you playing on a server, or playing solo? I'm not sure how this game handles mods on servers; what happens when there is a file mismatch and so on so to speak. I play local/solo, maybe this happens when playing on a server. Other than that, I really have no clue, I mean it's practically impossible for you to see the vanilla tooltip when you have a modified tooltip mod. Curious... I'll try to look around, mind you share your save file meanwhile? edit: I noticed how big the save files can get, so how about you start a new different game, check if the mod is working, and if it is not working, share that? Don't know what I can do with that, but as I've said, I am literally clueless as to why this is happening :(

If you are seeing the vanilla tooltip then the mod isn't installed :P Maybe there is a different folder to install mods now that I'm not aware of yet, but on single player all is working fine for me as I've mentioned. Put the backup file to somewhere else just in case, maybe that'll fix it somehow?!? I have no clue on this issue, as this would've affected all mods not just this one...

Hmm, your explanation makes sense. I just tried a cheap trick to test it out, changed the code from dirString = dir.name.." /*direction*/"%_t to dirString = (dir.name.." /*direction*/")%_t and it works again. So you are right, %_t has a higher priority :) In my tooltip mod, there is a line like this for example: line.ltext = "Velocity" --lyr_nt The Lua comment is a simple reminder for me, and it still happens without that comment. In the game, this "Velocity" string is translated. There are a few other strings that have their translations in the localization files, however they get translated without a %_t which made me curious. Even if I get a vanilla "tooltipmaker.lua" and remove the individual or all %_t from the strings, they get translated. Also, thanks for explaining stuff :)

Same here after fresh install on the new update, seems alot of mods got affected lately... The Gate Icons still working great btw! 8) I'm not really sure what's causing that as it is working fine on my end. If you are seeing blank tooltips, then something is breaking the mod which I'll need to fix. If you can check the log files and see anything related to tooltipmaker.lua is giving an error, that'd help me. Logs are located here: %appdata%\avorion Put this on your search bar in the start menu (or folder path on windows explorer) and hit enter.

My old trick didn't work. Even if it worked, I realized I didn't include it at the first place. This is easier :P

Did something change in the way that the game interprets the translate tags on the Lua files? Specificly I'm asking about the "%_t" tags. As far as I know, these tags are used as a "catchphrase" by the game code to look for a translation if I'm correct. However, I noticed that some of the lines I've written are translated even though they don't use "%_t". I guess the game uses a translation if it is available, without regarding the "%_t" but if that is the case why do we have these tags everywhere? Moreover, I was wondering another thing, related to the same tags again. Before on the Lua side, I was able to do something like this and it'd get translated: dirString = dir.name%_t This working made me believe that translation tags were executed after the Lua was done with them, however in the Gate.lua directions now have some extra in their names. But my previous observation led me to believe that something like this would've worked dirString = dir.name.." /*direction*/"%_t The thing above doesn't work though. Something might've changed, or the translating part of the code doesn't like ".." perhaps, but anyway. Both of my questions boil down to one thing actually. How do these tags work?