(Req) Loot pull range?

[DistractedFerret]

I'm actually looking to modify the range at which the loot gets pulled in. I'd love to see it as a module that get plugged in, but I can't even find WHERE this range is determined to be able to start the project. I've spent several hours now digging through LUA files and finally decided to just reach out in here to see if anyone has come across the pull range information and I'm just blind?

 

I am thinking something along the lines of a module that would increase the range of the "loot magnet" effect, with a corresponding increase in power draw and maybe a penalty to shield or battery or something? I don't know yet, just spitballing and trying to find my starting point.

 

Thanks for any help!

[infal]

I haven't seen anything that would be an easy mod, like addBaseMultiplier(magnetRange, 2) or something... but I was also thinking about the idea that scooping loot can be tedious.

 

I wondered if a work around could be to have a module that scanned once per second for any entities in a bounding sphere with the property isLoot = true and just teleport them to the player ship's position, but haven't looked into it further.

 

There is another property on Entity called selectedObject. It's a long shot, but maybe loot entities move towards whatever that is set to, so you could use the bounding sphere again and set that value to the player ship entity.

[Gaalidas]

Wouldn't selectedObject be the entity that the player has targeted?  Just a thought anyway... or perhaps it's the target from the RTS-view.  I always thought a modification of the force gun to instead putt distant loot items towards you so they would be caught in your pull-field would be the way to go.  Sorta like a tractor beam.  Supposedly a force gun with a negative force rating would do the trick, but I don't think those things affect floating loot so modification would have to be made for its layer mask.

[infal]

Wouldn't selectedObject be the entity that the player has targeted?

Yes, but the loot drop is also an Entity with a selectedObject field of it's own. I was wondering if when a player gets close and the loot drop starts moving towards the ship, maybe internally the selectedObject of the loot entity had been set to the player ship. So if you could force it to be set to the player ship at a greater radius they might move towards the player ship of their own accord.

It's also possible that selectedObject for loot entities is just ignored.

[Splutty]

Wouldn't selectedObject be the entity that the player has targeted?

Yes, but the loot drop is also an Entity with a selectedObject field of it's own. I was wondering if when a player gets close and the loot drop starts moving towards the ship, maybe internally the selectedObject of the loot entity had been set to the player ship. So if you could force it to be set to the player ship at a greater radius they might move towards the player ship of their own accord.

It's also possible that selectedObject for loot entities is just ignored.

 

selectedObject has nothing to do with movement, so it wouldn't help you with the loot problem.

 

Also, getting all the loot objects in your sector every second is going to be incredibly inefficient :)

 

I'm actually currently working on a script to see what can be done with loot interactions. All your captained ships and fighters for instance will pull loot towards them, so if you could get those close enough to the loot, they should be hoovered in.

 

The biggest problem there is to not have it try and get the bazillion loot objects every second, or to try and fly to loot that no longer exists.

[infal]

Okay, the selectedObject was a long shot but worth considering. Obviously the loot entity stores a reference to the player ship once the player is close enough to pick it up but maybe it's not exposed to LUA.

 

Scanning every entity in the sector would be inefficient. Especially if it's a sector with thousands of asteroids. You can do it other ways though

 

Sector():getEntitiesByType(EntityType.Loot)

 

or you could build a table of loot entities as they're created with onEntityCreate event and then remove them from the list with onLootCollected (and maybe onDestroyed, for despawning?)

 

Then once you have a manageable list of loot entities you can test those for distance to the player ship.

 

I really like the idea of fighter craft that are specifically for loot collection only, no weapons.

[Wilponderoci]

I really like the idea of fighter craft that are specifically for loot collection only, no weapons.

 

OMG yessssssss!

[Splutty]

The fighter angle is what I'm actually thinking about, but I'm not quite sure if fighters are capable of doing everything I'd want them to do :)

 

Work in progress for me, but not very high on my priority list either. Stopping AI ships from crashing into stations is what I'm actively looking at now.  ;D

[Tigron]

the loot system I think is hardwired into the game code, have talked with Nexus in the carrier commands mod about trying to get fighters to pick up loot before doing salvage but its not possible in that respect.

[Wilponderoci]

is it possible to get the fighters to just do a few arbitrary loops around wreckage?

 

In order of farthest to nearest or some thing to that effect?

 

That should be sufficient to get most loot.  have them do an atom symbol around recently interacted wreckages.

[cy414]

I really like the idea of fighter craft that are specifically for loot collection only, no weapons.

 

OMG yessssssss!

from observation, i think this is already a function of the salvage behaviour.

so, a salvage fighter with no gun might do this already.

[Splutty]

I really like the idea of fighter craft that are specifically for loot collection only, no weapons.

 

OMG yessssssss!

from observation, i think this is already a function of the salvage behaviour.

so, a salvage fighter with no gun might do this already.

 

All ships will pick up loot, including fighters, but as far as I can see from the salvaging fighters' behaviour, the fact they're picking up loot is purely coincidental.

 

There are some lines in the mining and salvaging script that don't appear to really work from what I see happening, so I'm messing around with that as well.