Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[xenoargh]

OK, I think I figured out what's causing the crash bug with generating new FleetMemberAPI objects and attaching them to CampaignFleetAPI objects.  Basically, there's a discrepancy between the stored copy of the CampaignFleetAPI that's being stored as the "before state" and the "after state", and checks against the two are causing the crash.

It's therefore necessary to not work with a stored copy, but to manipulate the Object data in the battle context and then work from that.

I can see how that's going to cause issues; amongst other things, there's storage of things like getAllEverDeployed(), which is one of the areas that's going to cause the runtime error.  

Not quite sure how to work forwards from that- tbh, I'm not sure that trying to hold that data for reference later is a good idea in general, as it's probably quite cheap to simply update within the battle context and then read the raw output when returning to the Dialog state- but it's apparent that if these things don't come into conflict, then we won't see crashes when new FleetMemberAPI objects are created.

In case the above seems a little confused, here's kind of what I see as the sequence problem:

1.  Enter EncounterDialogAPI state.
2.  Fleet copy for future reference appears to get created there.
3.  Combat begins, FleetMemberAPI objects change state (disabled, destroyed, or in this case, added).
4.  Check against copy is made to determine further stages of Dialog.  Created FleetMemberAPI members causes difference between stored state and new state --> crash

What I think it should do:

1.  Enter EncounterDialogAPI state.
2.  Combat begins.
3.  ShipAPI objects change state (become isHulk, get destroyed, get added).
4.  FleetMemberAPI objects change state (disabled, destroyed, or in this case, added).  CampaignFleetAPI object's state gets changed immediately.
5.  Dialog returns, using the current CampaignFleetAPI object and relevant FleetMemberAPI objects.  No reference made to out-of-date copy data ensues, therefore no crash results.

I am fairly certain that the above can work correctly, but I haven't quite gotten through all of the other wrinkles of writing up a new Fleet Encounter system yet to test this thoroughly.  One of the issues I haven't explored is whether there's a way to set the Deployed state for created FleetMemberAPI objects, etc. so that when it returns it's all matching up again.

[Alex]

I don't know what the crash is, but a couple of notes:

1) The reason it works the way it does is combat also has to support missions, in which a CampaignFleetAPI doesn't exist.
2) If there's a crash caused by it, you should probably not make changes to the fleet during combat. Is it possible to instead note down the changes and then make them after combat is over?

Another thing, though - there's no second CampaignFleetAPI being created; if you're think that's what happens/is causing whatever issue you're encountering, then you might be on the wrong track.

(A different type of object that holds the data for a fleet for the duration of combat is initialized before combat, and then data from it is used to update the CampaignFleetAPI. It's not another CampaignFleetAPI.)

[xenoargh]

Well, what's happening is that any FleetMemberAPI object being added to the battle like so:

Code: java

engine.getFleetManager(FleetSide.PLAYER).spawnShipOrWing(variantID, loc, facing);
FleetMemberAPI newShip = Global.getFactory().createFleetMember(FleetMemberType.SHIP, variantID);
fleet.addFleetMember(newShip);

Can cause a crash at battle end. 

It also spawns at 0 CR and the AI / malfunction code thinks it's 0 CR even after the CR gets set to 100.

Similarly, using this code in a Campaign context causes a crash when the battle ends and we re-enter a Dialog state:

Code: java

ShipAPI thisShip = engine.getFleetManager(FleetSide.PLAYER).spawnShipOrWing("clover_Standard", missileLoc, facing);

That it doesn't cause the crash until then means there must be a data mismatch somewhere; the first should not cause a crash, because we're adding a ShipAPI in the battle sim but we're also updating the CampaignFleetAPI, the second shouldn't cause a crash, because we're merely adding a new ShipAPI but there aren't any changes to the CampaignFleetAPI object data at all.  But I get consistent crashes with both.  Anyhow, I'll have a more definitive answer to what, exactly, causes this problem when I have finished up the last of my experiment in constructing a fleshed-out encounter system that doesn't worry about second-round combat- my thoughts right now are that it's related to multi-round combat states

[Alex]

Right, I see.

Code: java

engine.getFleetManager(FleetSide.PLAYER).spawnShipOrWing(variantID, loc, facing);
FleetMemberAPI newShip = Global.getFactory().createFleetMember(FleetMemberType.SHIP, variantID);
fleet.addFleetMember(newShip);

The problem here is that the two aren't tied together, it has no idea that the fleet member you've created is supposed to relate to the ship/wing that it spawns. The variant ID isn't enough to go on since multiple ships can have the same variant.

And there's no way to actually tie the two together I'll see what I can do here.

Similarly, using this code in a Campaign context causes a crash when the battle ends and we re-enter a Dialog state:

Code: java

ShipAPI thisShip = engine.getFleetManager(FleetSide.PLAYER).spawnShipOrWing("clover_Standard", missileLoc, facing);

Do you mean inside combat, not inside the campaign? Can't quite make it make sense otherwise.

[xenoargh]

Aha, I get that.  Too bad there isn't a way to get that into the right context, I had in-game capturing mechanics working.  Oh well, as I noted in Suggestions, I'm going to try and take it another direction anyhow

Yeah, inside combat; I was generating "defense stations" during battle after capturing points and was allowing for "ship-launched fighters" in battles back in 0.54a, and I'm still trying to get these things working again.  Oh well, that can wait