Carry objects

[NickAragua]

Implements cargo carrier rules from TW:261 (mechs and protomechs only) and (partly) TOAR:90 (just the part where you can pick up a lighter object with one hand only).

Includes:

• picking up cargo (mechs and protomechs only)
• dropping/unloading cargo (drop if you keep moving, unload if it's the last step)
• can't fire if loaded/unloaded cargo this turn
• can't fire torso/arm weapons if carrying cargo (can use other arm when carrying really light cargo)
• cargo will get damaged if the carrying unit is shot at
• cargo may get destroyed if carrying unit drops it on the move (even more likely when flying/jumping)
• graphical indicators and reporting of cargo-related activity
• cargo can be 0-weight and invulnerable
• if you fall, you drop the cargo

Does not include

• TSM bonus
• Loading cargo for non-mech/protomech units

A story told in a few screenshots:

[HammerGS]

Would there be any opportunity in this to handle the Lift Hoists being able to load and carry a unit and drop on the map?

[NickAragua]

Definitely not units. I'll look into Lift Hoists/infantry being able to load cargo in a subsequent pull request.

[NickAragua]

Not quite complete, but can be put through some initial testing/feedback.

[NickAragua]

Removed this because it's being done in the base class already.

[NickAragua]

Removed this because it's being done in the base class already.

[repligator]

NPE when creating a 1,000 ton object.
megamek.log

[repligator]

A "So-and-so" has fled the map, taking (Object) with it message would be nice.

[NickAragua]

Refactored the ICarryable interface so it's part of the BTObject hierarchy.

I'm kind of ambivalent re: camo, as the cargo may not necessarily belong to the player (i.e. scenario rules call for "attacker nominates X squares that contain cargo"). The one thing that I do want to ideally do is have the cargo sprite appear "under" the units rather than over (it looks odd). Any advice on that?

[SJuliez]

Ah ok, I didn't know if they should be player-colored. My intention was more to not keep them this black/white. Giving them a fixed brownish camo (we sure have one) is a simple option. But we can leave that for any point later.

Sprite ordering ... is not in an ideal place. There is Sprite.getSpritePriority() but it is only used with the xyzSpriteHandlers while the older code just draws the sprites according to type. Since the handler sprites are mostly the ones that go over everything (move envelope) they currently draw after the units and it wouldnt be helpful to swap that. I'll take a look if the unit sprites can be added to the allSprites treemap without a big hassle so they would respect draw order, then the sprite priority should help. Will be back on this.

[repligator]

As of the latest push, the object names are displaying like this

[NickAragua]

Should be better now. Got a little too overzealous in my refactoring.

[SJuliez]

I have created #5801
That one injects the entity sprites into the AbstractBoardView sprite drawing process and so allows the Carryable sprites to draw under units. You can pull it into this one, if you want. I merged them locally and it seemed to work fine.
(It's draft only so that it doesnt get merged accidentally)

[NickAragua]

Ok, merged #5801 into this one. I think this one's ready to go now.

[SJuliez]

The briefcase sprite doesnt scale with the board zoom.

Suggestion: replace the empty prepare() in GroundObjectSprite with this:

    @Override
    public void prepare() {
        updateBounds();
        image = createNewHexImage();
        Graphics2D graph = (Graphics2D) image.getGraphics();
        UIUtil.setHighQualityRendering(graph);
        graph.scale(bv.scale, bv.scale);
        graph.drawImage(CARGO_IMAGE, 0, 0, null);
    }

:)

[repligator]

The report for a dropped object seems to get nested under the last physical attack. ID:95 was the one carrying the object.

[SJuliez]

I'm getting problems when trying to pick up stacked objects, i.e. more than 1 in a hex, specifically a light 2t and a heavy 30t. The game lets me pick up one, no questions asked (as the 30t is too heavy) but it does not really pick it up.

[SJuliez]

Would it make sense to show carried objects in the unit tooltip? (or does it already?)

[SJuliez]

Hoping I'm not missing something that's there already, I feel that it's likely we will at some point want to be able to identify specific carryables and maybe have them have an owner (thinking of capture the flag). May I suggest having ICarryable extend InGameObject instead of BTObject and adding the following to Briefcase.
As currently owner and id arent used anywhere, no other changes are necessary but this adds the infrastructure.

	private int id;
	private int ownerId;
	
	@Override
	public int getId() {
		return id;
	}

	@Override
	public void setId(int newId) {
		this.id = newId;
	}

	@Override
	public int getOwnerId() {
		return ownerId;
	}

	@Override
	public void setOwnerId(int newOwnerId) {
		this.ownerId = newOwnerId;
	}

	@Override
	public int getStrength() {
		return 0;
	}

[NickAragua]

Added sprite scaling and unit tooltip; adjusted the ordering of "cargo dropped" messages during PSR resolution; adjusted object hierarchy; make sure to pick up the correct object when the "default" object being picked up isn't the first in the list.