[0.7.79]Strip Miners Fitting Logic

[DaVinci]

One of the folks gave a heads-up on weird Strip Miners behavior, so i gave it a go.

Results:
- T1 Barges can fit regular T1 Strip Miners. Attempt to fit T2 will give the error pop-up (Your ship cannot equip this module).
- T2 Barges can only fit T2 Modulated Strip MIners. Attempt to fit T1 will result in the same error pop-up.

Weird thing about T2 strips - when i unfit them by dragging off, i managed to hang the server once...probably due to memory leaks:

  Code:

17:57:53 L InventoryBound::Handle_Add(): size= 2
17:57:53 L InventoryBound::Handle_Add(): Trying to add item 140000113 from args.InventoryID:140000093 to ClientID:140000093 or InventoryID:60014719
17:57:53 L ModuleManager::Deactivate(): Module 'Modulated Strip Miner II' Deactivating...
17:57:53 E GenericModule: MEMORY LEAK!


Un-fitting T1 Strips does not produce those log messages.
Want me to run them thru Valgrind?

[Allan]

no, at this point, valgrind will give many, MANY, MANY msgs about how there is no delete for the 'new' operator....and anything else will get lost. there is a post on here somewhere about running evemu under valgrind, and how it's basically useless for us.
many thanks to the programming logic of "return new Py%something%;" or ANY return new ...;
that error is printed when the virtual destructor for GenericModule class is called....which is shouldnt be.
that is more of aknor's module manager shit i have to figure out...

strip miners may have the same "primary charge type" problem (attrib 604 and company) as thys pointed out with missiles.

[DaVinci]

Mmmm...that kinda makes sense. It'll be a different attribute, though, but i wouldn't be surprised if that stuff is broken too.
Gonna take a look on that.

Cheers!

!EDIT!
Well,it seems like problem is, as i described in torpedoes topic - server only looks on the primary group, ignoring the rest.
Here's the query:

  Code:

SELECT da.typeID, da.attributeID, dt.attributeName, da.valueInt, da.valueFloat
FROM dgmTypeAttributes AS da
JOIN dgmAttributeTypes AS dt ON dt.attributeID = da.attributeID
WHERE da.typeID = 17912

TypeID's i used:
- 17482 (Strip Miner I)
- 17912 (Modulated Strip Miner II)
Here's the results for em:
Strip Miner I:

  Code:

17482   6   capacitorNeed      90
17482   9   hp   40   
17482   30   power   10   
17482   50   cpu      60
17482   54   maxRange   15000   
17482   73   duration      180000
17482   77   miningAmount   540   
17482   182   requiredSkill1   3386   
17482   189   targetGroup   11   
17482   277   requiredSkill1Level   4   
17482   422   techLevel   1   
17482   633   metaLevel   0   
17482   1298   canFitShipGroup1      463
17482   1299   canFitShipGroup2      543
17482   1768   typeColorScheme      11346


And Modulated Strip MIner II:

  Code:

17912   6   capacitorNeed      120
17912   9   hp   40   
17912   30   power   12   
17912   47   slots   1   
17912   50   cpu      60
17912   54   maxRange   15000   
17912   73   duration      180000
17912   77   miningAmount   360   
17912   128   chargeSize   1   
17912   182   requiredSkill1   3386   
17912   189   targetGroup   11   
17912   277   requiredSkill1Level   5   
17912   422   techLevel   2   
17912   604   chargeGroup1   482   
17912   633   metaLevel   5   
17912   789   specialtyMiningAmount      360
17912   1298   canFitShipGroup1      543
17912   1299   canFitShipGroup2      463
17912   1768   typeColorScheme      11347


ShipGroup 463 - Mining Barges
ShipGroup 543 - Exhumers.

That pretty much explains why T1 strips fit the barges and T2 fit the exhumers.

[Allan]

that does make sense.
so, it's probably the same thing, only checking one chargegoup/shipgroup and not the rest.
good find, dv.

[DaVinci]

Did some work around this bug.
Even though issue seems simillar to the ammo types (the one, reported by Thys), it is in another part of code.
Issue was - there was multiple variables, assigned during the single call, and it seems like all 4 variables bestowed the same value, even though they should've get the different attributes.
So, cookie cutter here - i broke those calls in parts and now it works just fine and added a little trace messages. Although i'm not entirely sure multi-assignment was the reason, everything seems to work just fine now

Long things short - bug is fixed. I'll commit it in pack with other fixes (including mining)

Cheers!

[Allan]

NICE!
great job.
will pull and rebuild when i get time.....