Nexus
-
Posts
68 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Posts posted by Nexus
-
-
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.)
-
You have the following comment in line 135 of carriercraftorders.lua.
--window.icon = "data/textures/icons/fighter.png" --Sad, does not work =( I want to change it from the puzzle piece icon to something elseincase 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.
I keep getting an error with the scriptloader.lua file, although the "Carrier orders" icon appears in my interface. Checked that Devious brought this up some time ago in the thread, but i think the conversation died out.
attempt to call global 'Server' (a nil value)
I was trying it out in the single player. I am running the game in Ubuntu 14.04, on the beta branch with version 0.11 r7857. Did an uninstall, removed folder and reinstall before installing the mod. That did'nt seem to fix it.
Any ideas on what maybe causing it?
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
-
Thank you for the update :)
Will the cost for the replacable fighters be configurable?
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.
-
Doesn't the dev. said even turrets got entity IDs ? That why he want expand them to 128bit uuid.
So i am 100% sure even launched fighter got IDs.
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.
-
"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."
read this nexus and can you do this...... can you order each squad a target instead of each fighter?
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.
-
Ok forgive me if Im totally out of touch with this bc I am not a programmer....
Koonschi just implemented a new "salvage" order for ship menu.
Can it be possible to "assign" each fighter the command?
So (again forgive me for not using the terms correctly)
Make a table that sets each fighter as its own entity/ship and then the command (defend/attack etc) salvage/mine.
Then wrap that up nice so when you issue the order it randomly orders the fighters in that squad to act as if they are little ships in your fleet!
BOOM!
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.
-
Seen the other post you made about it, wish I knew enough about the coding to help, but you have the right idea seems with the modding community to ask for help. Which files are you modding maybe with my limited experience I can toy with it and see if I stumble onto the right part.
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.
-
I dont understand what your specifically asking for. do you want fighters to split and take on multiple targets?
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 endWhen 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...
-
great work, wish I could figure out the code like that. whats the deadline your shooting for to have a new release?
I know it will most likely take longer, I use to do programing but that was back when machine and basic was the big thing, I just cant seem to understand compilers and scripts.
I can't predict that with this one..the script has gotten so large and complex that I'm having to add/rewrite/remove alot when changing something simple now.
That being said the UI will be the biggest pain..heck I can spend up to a day just working on one element of it trying to get it where I want.
-
awesome work nexus, question.....limit of number of fighters per wreck? so if I have 10 squads of salvage fighters does this mean carrier salvage will work on more than 1 wreck at a time?
Yes, in fact here is a visual as to how it will work with the function turned on. In this pic I'm testing with a limit of 5 fighters per wreck. using 18 fighters they attacked 4 wrecks total with 5 fighters on three wrecks and the remaining 3 on another.
This is a image I took during testing, Squad one has fighters assigned to three wrecks.
Mind you this pic was taken before I fixed the wreck hashmap only memorizing wrecks near the carrier only.
For more funsies, here is a snippet logging I added to test this (The logging will be removed prior to release)
Tue Mar 21 00:43:57 2017| Fighter Target 4139 Fighter Index 4101 Tue Mar 21 00:43:57 2017| Fighter Target 4139 Fighter Index 4110 Tue Mar 21 00:43:57 2017| Fighter Target 4139 Fighter Index 4624 Tue Mar 21 00:43:58 2017| Wreck Table Size 25 Tue Mar 21 00:43:59 2017| Wreck Table Size 25 Tue Mar 21 00:44:00 2017| Wreck Table Size 25 Tue Mar 21 00:44:01 2017| Wreck Table Size 25 Tue Mar 21 00:44:02 2017| Wreck Table Size 25 Tue Mar 21 00:44:03 2017| Wreck Table Size 25 Tue Mar 21 00:44:04 2017| Wreck Table Size 25 Tue Mar 21 00:44:05 2017| Wreck Table Size 25 Tue Mar 21 00:44:06 2017| Wreck Table Size 25 Tue Mar 21 00:44:07 2017| Wreck Table Size 25 Tue Mar 21 00:44:08 2017| Wreck Table Size 25 Tue Mar 21 00:44:09 2017| Wreck Table Size 25 Tue Mar 21 00:44:10 2017| Wreck Table Size 25 Tue Mar 21 00:44:11 2017| Wreck Table Size 25 Tue Mar 21 00:44:12 2017| Wreck Table Size 25 Tue Mar 21 00:44:13 2017| Wreck Table Size 25 Tue Mar 21 00:44:14 2017| Wreck Table Size 25 Tue Mar 21 00:44:15 2017| Wreck Table Size 25 Tue Mar 21 00:44:16 2017| Wreck Table Size 25 Tue Mar 21 00:44:17 2017| Wreck Table Size 25 Tue Mar 21 00:44:18 2017| Wreck Table Size 24 Tue Mar 21 00:44:18 2017| Fighter Target 3621 Fighter Index 4101 Tue Mar 21 00:44:18 2017| Fighter Target 3621 Fighter Index 4110 Tue Mar 21 00:44:18 2017| Fighter Target 3621 Fighter Index 4624 Tue Mar 21 00:44:19 2017| Wreck Table Size 24 Tue Mar 21 00:44:19 2017| Fighter Target 3621 Fighter Index 4110 Tue Mar 21 00:44:20 2017| Wreck Table Size 24 Tue Mar 21 00:44:21 2017| Wreck Table Size 24 Tue Mar 21 00:44:22 2017| Wreck Table Size 24 Tue Mar 21 00:44:23 2017| Wreck Table Size 23 Tue Mar 21 00:44:23 2017| Fighter Target 3621 Fighter Index 4624 Tue Mar 21 00:44:24 2017| Wreck Table Size 23 Tue Mar 21 00:44:25 2017| Wreck Table Size 23 Tue Mar 21 00:44:25 2017| Fighter Target 3385 Fighter Index 4101 Tue Mar 21 00:44:26 2017| Wreck Table Size 23 Tue Mar 21 00:44:26 2017| Fighter Target 3385 Fighter Index 4110 Tue Mar 21 00:44:27 2017| Wreck Table Size 23 Tue Mar 21 00:44:28 2017| Wreck Table Size 23 Tue Mar 21 00:44:29 2017| Wreck Table Size 23 Tue Mar 21 00:44:30 2017| Wreck Table Size 23 Tue Mar 21 00:44:30 2017| Fighter Target 3385 Fighter Index 4624 Tue Mar 21 00:44:31 2017| Wreck Table Size 23 Tue Mar 21 00:44:32 2017| Wreck Table Size 23 Tue Mar 21 00:44:33 2017| Wreck Table Size 23 Tue Mar 21 00:44:33 2017| Fighter Target 3385 Fighter Index 4101 Tue Mar 21 00:44:33 2017| Fighter Target 3385 Fighter Index 4110 Tue Mar 21 00:44:34 2017| Wreck Table Size 23 Tue Mar 21 00:44:35 2017| Wreck Table Size 23 Tue Mar 21 00:44:36 2017| Wreck Table Size 23 Tue Mar 21 00:44:37 2017| Wreck Table Size 23 Tue Mar 21 00:44:38 2017| Wreck Table Size 23 Tue Mar 21 00:44:38 2017| Fighter Target 4086 Fighter Index 4624 Tue Mar 21 00:44:39 2017| Wreck Table Size 23 Tue Mar 21 00:44:40 2017| Wreck Table Size 23 Tue Mar 21 00:44:40 2017| Fighter Target 4086 Fighter Index 4101 Tue Mar 21 00:44:41 2017| Wreck Table Size 23 Tue Mar 21 00:44:41 2017| Fighter Target 4086 Fighter Index 4110
That being said its implementation is messy...I'll need to rewrite a few functions, and add a few, to clean it up a bit.
(Also, if you notice the icon is now changed thanks to that info I got from an earlier post)
-
So, its probably time for a small progress report..Mind you I was sick for a few weeks so I have been delayed a bit
1.8 Progress:
- *35% 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
- *75% Done* User Notifications: This *was* done then I found a few more notifications I can add
- *DONE* Attempting to add a wreck volume limiter and a fighter limiter
- *DONE* Option to limit the number of fighters per wreck...required alot of changes.
- *DONE* Additional logging for admins, now the player/sector is logged when someone uses the command...you know...like in a scrapyard.
- *25% 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.
- *90% Done* Fighter pilot ejection system, Its only 90% as it hasn't been tested yet but the code is in place
- *25% Done* Auto fighter replacement, I have a semi-working manager script in place, but it does have some issues and lags quite badly
- *5%* UI additions to support the above options...I HATE UI work....
- *Maybe-Unlikely* I may have a way of making fighters go after loot, not certain.
- *Maybe-Unlikely* add a fighter option to make your non combat fighters invulnerable for a constant power cost
- *Maybe-Unlikely* Armed fighters will get a option to increase survivability for a constant power cost.
That being said, I'm looking to get more done this Wednesday
-
Hallo,
zuerst möchte ich mich mal für deine Mod bedanken. Schön das du dir die Arbeit für uns nicht Programmierer gemacht hast!
Das salvage funktioniert auch prächtig! Jedoch Landen die Jäger nicht mehr im Hangar. Neustart, Sektor wechsel, neue Order und alles Mögliche probiert - Die Jäger stellen sich zum Hangar aber landen einfach nicht....
Wäre schön wenn mein Problem lösbar wäre.
zusätliche Mods:
• findstation_v0.5a
• miningsystem
• Salvage Command
• transfervanilla
• tooltipmaker
• crewboard
Danke!
lg
Sarok
Google translator: :-[
Hello,
First I would like to thank me for your Mod. Nice that you did the work for us not programmers!
The salvage also works magnificently! However, the hunters no longer land in the hangar. Reboot, change of sector, new order and all sorts of tastes - the hunters face the hangar but just do not land ....
Would be nice if my problem would be solvable.
Additional mods:
• findstation_v0.5a
• miningsystem
• Salvage Command
• transfervanilla
• tooltipmaker
• crewboard
THX!
Sarok
This is most-likely not an issue with my mod. The mod does not influence docking of the fighters in any way, as a matter of fact that is impossible to do since the FighterController component isn't accessible to us modders. The only thing i can really do is set targets when the fighters in the guard function, which is overridden by the docking command.
-
also, another idea is if you can modify the salvagers to pick up modules and material first then begin salvaging since modules despawn faster than the wreckage.
Fighters cant be told to target modules/resources floating in space sadly...been trying to find a way around that for a bit now.
-
im not sure if its your mod or not but seems like new branch has salvage command?
It does indeed it seems
-
There's a menu at the top right, has options for idle, slavaging and mining. No idea if it works, just use it for salvaging.
It's not accessed by clikcing your ship
No options for Mining. Just Idle and Salvage that shows up on mine. Like I said, if there was an update or something I missed, or I'm doing something wrong. Anyone happen to know?
-Edit-
Figured it out. Our server was still on 1.6 Didn't realize it.
I seriously need to see if I can make a version checker for the server/client.
Nexus, not sure if its a bug in the mod or in the game but think it may be in your mod. enemy fighters show as neutral when attacking your ship. sent in a bug report just incase it was a game bug but you may want to check the coding in your mod to be sure.
other than that the mod works great, love it.
That sounds like a game bug, I don't modify faction information at all for the fighters. I read their faction, but nothing else.
-
Would it be possible to include the player name and location when a command activation is logged to the console?
Some players are abusing salvage fighters by using a shitload of them with high dps in salvage yards, creating giants amount of lag because the netcode can't handle that many updates.
Ouch, yes that should be possible. Currently it already logs when a salvage command is activated...just doesn't tell you who and where...ill see if i can put something out for that.
EDIT: I should mention, that due to sickness, I haven't been able to work on the mod for the last few weeks..hopefully this clears up by next week ugh
-
Would it be possible to implement a function to call all fighters back at once?
That would make it even less tedious to operate them with your mod :D
You mean to dock or to idle? To idle probably, to dock? sadly no, that's part of fightercontroller component which I don't have access to.
-
Can I suggest another approach? Use the entity id multiplied by a large prime number modulo the amount of wrecks (or an arvitrary cap, say you want to limit to 5 wrecks, do modulo 5) then sort the wrecks by dostance and allocate the fighters according to the number that comes out of the module operation
Nah, thought of a better way to do it, its still two tables but its a simpler way.
[MOD] Carrier Command
in Mods
Posted
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.)