[ModPack] dZ_Consolidated_Company_Commander

[don Zappo]

I've changed my mind on that. It is possible now, but by no means inevitable.

Also, you have it working with InnerSphereMap?!? Did you do anything special for that? When I took a stab at that I couldn't start a new campaign.

 

[don Zappo]

Btw, you're a not meant to have to pay for the Argo early game! I will keep that in mind for compatibility with ISM. Do you have a suggested upkeep cost?

 

[crkessel]

I think the parallel mech bay repairs might be buggy. I've got a Hunchback I'm refitting that's been stuck at 4 days to finish for weeks. I've even cancelled it and rescheduled the repair and I have the same problem.

Well, shoot, I cancelled it and scrapped the mech even. Then put another mech up for repairs and it never finished either. My mechbay is hosed

Edit: ok, the last item to be repaired never finishes. If I add more things to the queue, the items before the last one will finish.

 

[me987654]

Imma just going to hold this here for now so I can try to fix the repair bays later. From NexusMods:

ArgumentOutOfRangeException: Argument is out of range.
Parameter name: index
at System.Collections.Generic.List`1<BattleTech.WorkOrderEntry>.get_Item (int) <0x00083>
at RepairBays.RepairBays/SimGameState_UpdateMechLabWorkQueue.Prefix (BattleTech.SimGameState,bool) <0x0010d>
at (wrapper dynamic-method) BattleTech.SimGameState.UpdateMechLabWorkQueue_Patch1 (object,bool) <0x0002a>
at BattleTech.SimGameState.OnDayPassed (int) <0x00439>
at BattleTech.SimGameState.Update () <0x00df0>
at BattleTech.GameInstance.Update (single) <0x0005e>
at BattleTech.UnityGameInstance.Update () <0x0005c>

That looks like it is trying to access a work order item that doesn't exist. Like the queue has 2 items and it's trying to access item 3

 

[wintermute66]

I've changed my mind on that. It is possible now, but by no means inevitable.

Also, you have it working with InnerSphereMap?!? Did you do anything special for that? When I took a stab at that I couldn't start a new campaign.

I didn't do anything special to get it working. The only parts of the mod I'm using are the latest main Inner Sphere Map file and Random Travel Contacts. There is no story, if that's what you mean by campaign. Or can you not even start a single player game?

As for the Argo upkeep costs, it's hard to say. I'm pretty much living paycheck to paycheck at the moment.

 

[n3ctaris]

I didn't do anything special to get it working. The only parts of the mod I'm using are the latest main Inner Sphere Map file and Random Travel Contacts. There is no story, if that's what you mean by campaign. Or can you not even start a single player game?

As for the Argo upkeep costs, it's hard to say. I'm pretty much living paycheck to paycheck at the moment.

sounds perfect!

 

[don Zappo]

That looks like it is trying to access a work order item that doesn't exist. Like the queue has 2 items and it's trying to access item 3

Ooh! That's a great theory. Maybe it is crashing when you aren't working g your bays at capacity!!

 

[don Zappo]

I think the parallel mech bay repairs might be buggy. I've got a Hunchback I'm refitting that's been stuck at 4 days to finish for weeks. I've even cancelled it and rescheduled the repair and I have the same problem.

Well, shoot, I cancelled it and scrapped the mech even. Then put another mech up for repairs and it never finished either. My mechbay is hosed

Yes, it is bugged. I patched it a couple of days ago. Repair Bays is currently awaiting a bug fix and has been removed.

 

[don Zappo]

Guys, I think I got it...

 

[me987654]

@don Zappo

I think I've almost got the changes coded up for permanent evasion. I can explain to you why that red text shows up and how to fix it (Short answer.... dnspy needs the library for that function loaded... so you have to open more dlls)

 

[don Zappo]

Oh, I know why it shows up, I just don't know how to explain it. It either needs more dlls loaded, or it needs the specific reference to the class pulled out so it can add it in compile.

 

[me987654]

Oh, I know why it shows up, I just don't know how to explain it. It either needs more dlls loaded, or it needs the specific reference to the class pulled out so it can add it in compile.

Yeah so the one problem I'm having is the Mech_ResolveAttackSequence just wont get the reference to PermanentEvasion.Settings for whatever reason.... did you run into that?

NVM - I used your solution and it seems to work...Maybe dnspy fixes self references at compile time

 

[don Zappo]

NVM - I used your solution and it seems to work...Maybe dnspy fixes self references at compile time

That is exactly right.

 

[don Zappo]

I've run into an issue with the Repair Bays. I need to access each item in the work queue, then check if it is a mech, and then repair it if it is allowed. It's all there except for checking if it's a mech. From some other part of the code there is this:

// Token: 0x0600E621 RID: 58913 RVA: 0x003F5DC8 File Offset: 0x003F3FC8
public WorkOrderEntry_MechLab GetWorkOrderEntryForMech(MechDef def)
{
if (def == null)
{
return null;
}
WorkOrderEntry_MechLab result = null;
for (int i = 0; i < this.MechLabQueue.Count; i++)
{
WorkOrderEntry_MechLab workOrderEntry_MechLab = this.MechLabQueue as WorkOrderEntry_MechLab;
if (workOrderEntry_MechLab != null && workOrderEntry_MechLab.MechID == def.GUID)
{
result = workOrderEntry_MechLab;
break;
}
}
return result;


That has the ability to check for a mech by comparing it to the Mech Definition file (I think). But, I can't seem to drop def.GUID in my code. I don't even know what that means. Heh.

 

[me987654]

I've run into an issue with the Repair Bays. I need to access each item in the work queue, then check if it is a mech, and then repair it if it is allowed. It's all there except for checking if it's a mech. From some other part of the code there is this:

// Token: 0x0600E621 RID: 58913 RVA: 0x003F5DC8 File Offset: 0x003F3FC8
public WorkOrderEntry_MechLab GetWorkOrderEntryForMech(MechDef def)
{
if (def == null)
{
return null;
}
WorkOrderEntry_MechLab result = null;
for (int i = 0; i < this.MechLabQueue.Count; i++)
{
WorkOrderEntry_MechLab workOrderEntry_MechLab = this.MechLabQueue as WorkOrderEntry_MechLab;
if (workOrderEntry_MechLab != null && workOrderEntry_MechLab.MechID == def.GUID)
{
result = workOrderEntry_MechLab;
break;
}
}
return result;


That has the ability to check for a mech by comparing it to the Mech Definition file (I think). But, I can't seem to drop def.GUID in my code. I don't even know what that means. Heh.

Try to find the code where the mechdefs are loaded and initialized... that might help you

 

[me987654]

yeah so my little coding project has failed so far... I'm going to test your permanent evasion by class and see if that works

 

[don Zappo]

Try to find the code where the mechdefs are loaded and initialized... that might help you

Right. But therein lies my problem. I'm still figuring out how to pull in values. I am learning, but it is slow going. The problem is that I know what has to be done but not how to do it.

 

[don Zappo]

I'm really good at getting mechs to repair themselves twice in one action.

 

[me987654]

Welp I could not get the damn evasion by speed to work.

I've got the source solution in visual studio now... so I'll give it another try later

 

[me987654]

BTW - I've been thinking about the permanent evasion thing...

If we are going to restrict it to ONLY Ace pilots I think we should just give a flat bonus regardless of mech class. Make it either 2 or 3 pips that the pilot gets to always keep.

I have a few reasons I prefer this. In particular though it gives you a pilots that can make effective use of banshees, dragons and other mechs along those lines.

I think it makes more sense too... seems like a piloting ability should work regardless of mech



Also - one thing to note.... I not actually sure this permanent evasion mod prevents sensor lock from stripping all the pips



bTW - has anyone actually tested if this stops sensor lock from striping pips? The code I looked at only overrides attack resolution.... I didn't look to see if sensor lock uses the same code path