Nexus

I'm using (for salvaging): Sector():getEntitiesByType(EntityType.Wreckage) and local resources = wreckage:getMineableResources() if resources ~= nil and resources > 5 then ... I'm using resources > 5, specifically to avoid fighters going after small bits on purpose. Because fighters tend to miss those pieces and try and fail to salvage them, while the big chunks slowly despawn. This is the reason, if I'm recalling correctly, I had two separate mining/salvaging options. One mined/salvaged everything while the other followed basically the rules your using, aka salvage/mine only what is valuable/big enough. (On a side note thanks for continuing this, life and work picked up to the point where I had to vanish.)

Oh look, I'm not dead. With the Alliances beta patch dropping soon expect things to be broken in the beta branch. Ill work on it when I get home tomorrow. (It should be noted that in the last couple of months i have been busy with a few different jobs, thankfully Im pretty settled in my current one.)

incase you havent already figured it out the fix is calling the following function near the start of script (i think it needs to come before initui). function getIcon() return "data/textures/icons/freedom-dove.png" end FYI: thanks for your mod; based the frame of my mod on yours. especially the UI. Yes, someone pointed me in that direction a few pages back =P It's in the 1.75 beta i have on my end atm. I'm currently trying to cleanup/optimize/tweak how the fighter reconstruction works. I'm also adding in fighter template saving and construction. Find a fighter you like? Good, now you can save it and build numerous copies for around 1-5k of the material and about 20k credits, replacing a fighter lost in combat follows the same rules. On a side note, I have decided that the Fighter Reconstruction system, and the fighter saving and building system (which are almost literally the same in how they work) will be released as 1.75 while 1.8 will be released after alliances in the hope koonschi managed to put in some of the squad control capabilities which would greatly simplify things. In short, 1.8 will include additional fighter configuration options(AKA, limiting material type, per squad targeting, volume targeting limits, etc.). While 1.75 will allow you to replace lost fighters and recover your lost pilots. As well as allow you to save blueprints of fighters you like so you can build whole squads of them. 1.75 will also include the server configuration that allows admins to limit certain things. Nope, that one I have never been able to reproduce, ill ask Devious about it.

When attempting to get a FighterTemplate stored in a hangar to show its material and rarity property for a comparison I was doing. I noticed that those two properties only return empty strings. Bug or intentional? (Kinda need the material to finish the fighter replacement I'm working on =P)

Ok, time for a Wednesday update on progress. Both bad and good have happened over the last week, But sadly most of it was bad. Laserzwei method of identifying fighters already launched fighters failed, as the blockplans of fighters aren't available when they are transformed from a FighterTemplate to an entity. This prevents many of the optimizations and other said features from working correctly. So now ill need to find other solutions. Thankfully Koonschi has given me hope. I managed to get sometime with him, along with everyone else in the #modding channel of discord, and he did manage to answer a few questions of mine. He mentioned why fighters cant be assigned individual targets. As well as touched on a few other issues I was having. That being said he did mention that adding the ability to issue targets to whole squads directly would be fairly simple. I'm hoping this means ill see said functionality added soon . Sadly though making it easier to replace lost fighters by linking the launched fighter with the docked FighterTemplate is further out as he stated that would be a far more difficult thing to do at this time. That being said I spent...probably 12 hours total working on a new way to store and determine what fighters where lost in combat yesterday. How the new system will work is you will have a button that will take a 'snapshot' of your hangar then there will be another button that will allow you to tell your carrier crews to check the squads for losses and replace them. Sadly the command to start fighter replacement will require all your fighters to be docked first before it will begin. It's not a perfect solution, there are some minor exploits where if you move a fighter to another squad it will think it was destroyed...but you still have to pay the replacement cost. But it's a far better one than what we had...which is nothing. You will also need to use this snapshot button each time you add new fighters to your hanger. There are also a few bugs which I'm currently waiting on a fix for, like FighterTemplates not returning their material or rarity but just an empty string. Mostly everything else..but the UI work... is done and is being tested

Not sure if that would be easily doable, it's something ill look into after 1.8.

1.8 Status Update: ETA is around 1-3 weeks currently. Many issues where encountered with this update and it's slowing it greatly. Per squad targeting was almost scrapped, but an idea from Laserzwei, may save it. The idea was initially intended to help link the FighterTemplate (which is how hangers store fighters) be linked to the launched entity by adding a hidden block to it with a custom ID. This could also be used to indicate what squad a fighter is in making it easier to assign targets. It also has the possibility to help with indicating what fighter is a salvage fighter vs mining fighter. That being said his idea is not tested and my fail..if it does expect per squad/fighter targeting to be scrapped for the time being. That being said I'm currently rebuilding/cleaning up the pilot return system as well as balancing costs of the fighter replacement system. Currently aiming for around a 2 minute re-construction time with a resource/credit cost of (RC)200/(CC)1,000 for a common fighter while a top of the line will be around (RC)1,000/(CC)10,000. While the mod mainly influences non-combat fighters, the fighter replacement system will replace lost combat fighters as well 1.8 Progress: - *65% Done* Code improvements: Still the same as before, mostly due to the fact that adding a few options forced me to rewrite quite a bit..so now I need to re-improve what I rewrote =P - *85% Done* User Notifications: This *was* done then I found a few more notifications I can add - *DONE* Attempting to add a wreck volume limiter - *TESTING* Option to limit the number of fighters per wreck Changed to limiting the number of fighter squads per wreck...may still be removed - *DONE* Additional logging for admins, now the player/sector is logged when someone uses the command...you know...like in a scrapyard. - *10% Done* Material Priority system, it required the fighter limiting system in place as it needed to be built off of it. - *10% Done* Material amount priority system, it's auto built into the priority system..it will always go after the largest resource containing ship first. This can be toggled. *I haven't touched the material system much lately...been working on other issues that I have found* - *DONE* Fighter pilot ejection system, Still needs more testing but barring any major problems it should be good to go. - *Testing* Auto fighter replacement, Its klunky and somethings aren't working as well as they should, currently working on this - *5%* UI additions to support the above options...I HATE UI work....*Update* yup...I still hate UI work! - *Nope* I may have a way of making fighters go after loot, not certain. - *Nope* add a fighter option to make your non combat fighters invulnerable for a constant power cost - *Nope* Armed fighters will get a option to increase survivability for a constant power cost.

The issue is the docked fighters, since they are stored differently I need something to compare the two that is stable across both launched and docked.

I have thought about it, and while possible it requires ALOT more work to function. Since I cant get the squad the fighters are apart of when launched I'll need to store the information before hand while they are in the hanger...then somehow find something comparable between the docked fighter and the launched entity. That being said, I did find out on accident awhile ago that docked fighters do have a entity ID attached...but i don't know if that ID remains the same when they are launched.

No, as that's not how it works. A ship is controlled using a ShipAI() component while a fighter has no direct component for control. What I'm relying on for fighters is the fact that in defensive mode I can set their selectedObject (aka their target) to the wreck entity I want them to go after. The problem is that the targeting system seems to be not individual, (Aka each fighter manages its own target) but linked as a whole to the whole squad. So if one fighter has a differing target to another and its in the same squad, it causes them to loose their targets.

Well, the biggest problem is that not much can be done without access to the actual component that handles the targeting. I mean...I spent a week of testing...rewriting...testing..and more rewriting...and just when I thought it was working I found out with another test it wasn't....admittedly, im sad that it doesn't work, I put alot of time into it.

In essence yes. I was adding in this functionality to carrier commands to allow you to limit the number of fighters per wreck/asteroid instead of a all or nothing scenario. It was a requested feature from a few people but it exposed a flaw in the current system where the defensive stance..which is the only stance you can issue target orders to, cant handle fighters going after multiple targets. After around 2-5 seconds the targets will clear and the fighters selectedObject will be set to nil. After doing some testing since...well I thought I was being dumb and doing something wrong, (lets face it..it happens) I made the simplest script to test what the hell was going on and it reveled the issue. function issueFighterTarget() local sector = Sector() local player = Player() local ship = Entity() --Target selection based upon fighters position local wrecks = {sector:getEntitiesByType(EntityType.Wreckage)} for _, wreck in pairs (wrecks) do local fighters = {sector:getEntitiesByFaction(player.index)} for _, fighter in pairs(fighters) do if fighter.isFighter and fighter.isUnarmedTurret == 1 then if fighter.selectedObject == nil then fighter.selectedObject = wreck break --Hurray for lua 5.2 end end end end end When placing the wreck field about 5-10k out the fighters will be given the targets..but soon after the targets will clear out...then be reissued again..and again. I'm hoping that access to the FighterController component will allow me to correct this issue. Or it may even be a more fundamental problem hidden even deeper in the code somewhere. That being said, if the target is within close enough proximity (< 1k distance it seems) and the fighter manages to start its attack run the target wont get cleared.

After encountering a recent, and fairly frustrating issue involving the defensive stance of the fighters being unable to cope with multiple targets; I decided to finally ask for access to the thing so I can make fighters all they can be. Of course this is a request, not a demand so I understand if things take time...or if you want me to wait for a while longer. At least I can tell the people who use the mod that its coming =P Of course this could also be the part where koonschi tells me that I'm an idiot and the FighterController doesn't even manage that aspect =P

Thanks for the heads up. Thankfully I get all the ID's at runtime so it shouldn't be much of a problem =)

Ok....I don't like to double post but this I feel needs to be said. Despite earlier attempts at what I thought was a working fighter limiting system I encountered another oddity with short/medium to long range wrecks when testing today. Apparently when the fighter is >2-5 seconds from the target when multiple targets are assigned, it appears as if the FighterController component is resetting their targeting system..preventing it from working properly at short/medium to long range. Unless the fighter manages to fire at the target within that time frame the target wont stick. So there is a good chance I'll have to remove it, sorry, appears to be a limitation of what I have control over. Which sucks...I put alot of time into trying to get it working...