Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Establishment of a Requested Stock % feature, and automating weekly checks to keep spare parts in stock #5321

Open
wants to merge 8 commits into
base: master
Choose a base branch
from

Conversation

Lapras
Copy link

@Lapras Lapras commented Dec 8, 2024

Making sure your mercenary company has all the spares needed to contribute to ongoing repairs is a massive manual endeavor once you have anything more than a Lance. This PR adds features to the Parts In Use report for the user. Allow them to request a percentage of stock of a part in use that they want to keep in stock. For example, if a company is using 20 medium lasers, and your stock percentage is 25%, you are asking to always have 5 spare medium lasers on hand for repairs. It adds a button that will compare current stock to requested stock and automatically put in orders (or add them via GM mode) to get you all those parts. Finally, there's a checkbox to make this check every Monday. Finally, your logistics officers can do their jobs instead of you having to direct them to buy every part necessary.

This is done with a couple of changes:

  1. In CampaignOptions, a default stock level percentage is added to the options that is applied to every new part in use by default
  2. We need to store our settings for parts in use now (ignore mothballed, minimum part quality, weekly check, and all of the stock percentages), so we've added some marshalling and unmarshalling in the XML so that saved games now track what parts in use are requested at what levels. Keep in mind that this is done by storing a simple map from PIU names to doubles, we don't actually store all of the information contained within the parts in use report, just a map from names to the levels, and reapply them when parts in use are generated.
  3. In the Campaign.java, we're keeping track of our partInUse options and have implemented functions to both purchase and add parts that aren't in stock.
  4. The Parts In Use dialog has a column added to it for the request stock % as well as buttons to fill stock that access these campaign functions
  5. A weekly check on newDay() has been added in campaign in order to check your stock levels weekly
  6. Parts In Use no longer derive their name (and therefore how they're compared) by the description of their part, but rather the AcquisitionName of the IAcquisitionWork object that is their partToBuy, this gives us a more consistent naming scheme and avoids problems with part in use recognition. I've added in a special edge case for turrets, as their tonnage isn't specified within their IAcquisitonWork but does matter.

@IllianiCBT
Copy link
Collaborator

Looks like this has picked up a conflict. Once CO IIC launches, please take the time to double check any campaign options you’ve added weren’t accidentally missed

@IllianiCBT
Copy link
Collaborator

@HammerGS i want the opportunity to review this before it gets merged, but it needs to be merged before CO IIC else it’ll create a massive pain of conflicts.

@HammerGS
Copy link
Member

HammerGS commented Dec 8, 2024

@HammerGS i want the opportunity to review this before it gets merged, but it needs to be merged before CO IIC else it’ll create a massive pain of conflicts.

I'll let you handle the review and merge

@IllianiCBT
Copy link
Collaborator

Looks like this has picked up a conflict. @Sleet01 I don't suppose you'll have time to cast your eyes over this as well? With this being a high profile addition that's going to get a lot of attention I wanna make sure we're catching any issues before launch.

Copy link
Collaborator

@IllianiCBT IllianiCBT left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm really looking forward to having this merged, however there are a couple of points of feedback.

The biggest ones are relating to weird whitespacing that doesn't match stylistically to the rest of the mhq codebase, and abbreviated variable names. This might seem petty, but we need to remain consistent where possible to make it easy for other contributors to drop in without having to learn multiple styles.

@@ -76,7 +76,9 @@ lblAcquireSkill.text=Acquisition Skill:
lblSupportStaffOnly.text=Only support personnel can make acquisition checks
lblWaitingPeriod.text=Waiting period (in days) between acquisition rolls
spnMaxAcquisitions.toolTipText=This number is the maximum number of acquisitions an administrator can attempt each day. Setting this to 0 makes it unlimited.
spnDefaultStockPercent.toolTipText=This number is the default % of stock to fill for parts in use
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor stylistic choice, can we change % to percent or percentage

@@ -10,3 +10,4 @@ ordered.heading=Ordered
part.heading=Part
stored.heading=Stored
storedTonnage.heading=Tonnage
requestedStock.heading =Requested Stock Percent
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Extra whitespace after .heading

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In fact, I've noticed a lot of weird whitespacing throughout your code. Lots of if( or while( instead of if ( and while ( which is more standard for our codebase. I'm not going to force you to change them, but I do think we need to maintain whitespace consistency where possible.

@@ -174,6 +174,8 @@ public class Campaign implements ITechManager {
private final TreeMap<Integer, Scenario> scenarios = new TreeMap<>();
private final Map<UUID, List<Kill>> kills = new HashMap<>();

private Map<String, Double> piuStockMap = new LinkedHashMap<>(); // This map keeps track of which parts i use are assigned which stock values
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This comment is a little hard to parse. Is there a typo?

@@ -271,6 +273,10 @@ public class Campaign implements ITechManager {
private FameAndInfamyController fameAndInfamy;
private List<Unit> automatedMothballUnits;

//options relating to parts in use and restock
private boolean ignoreMothballed, topUpWeekly;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Having a twinned variable isn't inherently wrong, but it's not something I've seen elsewhere in our codebase. Strictly personnel preference: I'd define these separately. However, I want to emphasize that this is personal preference so go with whatever your heart tells you. :)

@@ -2236,6 +2245,7 @@ private PartInUse getPartInUse(Part p) {
p = ((MissingPart) p).getNewPart();
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know this isn't your code, but we're trying to move away from single letter or abbreviated variable names. As you're doing a lot of work in this neck of the woods would you mind changing p to part?

int toBuy = needed-inventory;

if(piu.getIsBundle() == true) {
toBuy = (int)Math.ceil((float)toBuy * piu.getTonnagePerItem() / 5);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Abbreviations and same question as before: are we meaning to buy 0.2t of ammo?

}

if(toBuy > 0) {
System.out.println("TPI: " + piu.getTonnagePerItem() + " " + String.format("Inv: %d needed: %d tobuy: %d", inventory, needed, toBuy));
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's definitely push this to logger rather than System.out. System.out is fine for temporary logging, maybe, but for anything like this we need a record of it when players find issues and send in their logs.

@@ -400,4 +409,24 @@ public Component getTableCellRendererComponent(JTable table, Object value, boole
return renderButton;
}
}

@Override
public void setValueAt(Object value, int rowIndex, int columnIndex) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we want to do this, or would it be better to use a JSpinner?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did you mean to include this?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I could have sworn we already addressed this change? Clearly not, and it's inclusion isn't an issue.

@Lapras
Copy link
Author

Lapras commented Dec 12, 2024

I'm really looking forward to having this merged, however there are a couple of points of feedback.

The biggest ones are relating to weird whitespacing that doesn't match stylistically to the rest of the mhq codebase, and abbreviated variable names. This might seem petty, but we need to remain consistent where possible to make it easy for other contributors to drop in without having to learn multiple styles.

I've got no problem going through all these style changes, it's my first PR to the repo so I expected to have to readjust style a lot. I'm currently travelling, but I'll be able to readjust all of this over the weekend no problem.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants