Grid Sage Forums

Grid Sage Forums

  • November 10, 2024, 12:49:09 PM
  • Welcome, Guest
Please login or register.

Login with username, password and session length
Advanced search  

News:

LINKS: Website | Steam | Wiki

Author Topic: Auto-replacement Priorities  (Read 2196 times)

Widmo

  • Derelict
  • **
  • Wiki Contributor Shared a Confirmed Stealth Win Bug Hunter Supported Cogmind Alpha Access 2015-2017 (Prime Tier) Weekly Seed Participant
  • Posts: 83
    • View Profile
Auto-replacement Priorities
« on: December 29, 2016, 02:36:15 PM »

This is probably not a bug but I leave you to be the judge. I did a stupid thing and ended up being surprised when the game did not do what I expected it to do.

Having the following utility setup (integrity in parentheses):
E - Improved System Shield (10/10)
F - Improved System Shield (9/10)
G - System Shield (10/10)
Inventory
3 - Improved System Shield (10/10)

Hitting Control + 3 twice installed item 3 in slot F instead of in slot G. If F had full integrity then slot G would have been replaced but I view this as a waste of perfectly good improved system. Is this intentional?
« Last Edit: December 30, 2016, 03:27:14 AM by Kyzrati »
Logged

Kyzrati

  • Administrator
  • True Cogmind
  • *****
  • Posts: 4460
    • View Profile
    • Cogmind
Re: Auto-replacement Priorities
« Reply #1 on: December 30, 2016, 03:27:31 AM »

Yes, you're right that if F was at full integrity it would've replaced G instead. The problem is there are sometimes subjective concerns, so the simple priority approach used by the auto-management system can't be right in absolutely every case. The rules followed by the system are described in the Advanced UI section of the manual.

Quote
Part Auto-Replacement
-----------------------
When attaching parts from either the inventory or directly from the ground, if there are no available slots of the corresponding type, the interface will attempt to automatically pick a part to replace instead. Replacement candidates are prioritized in the following order:

* Replace an item of the same name that has a lower integrity. Prioritizes replacement of non-functional parts, if any.

* Replace a different part that has the same type of effect, but that effect is not as powerful, regardless of the two parts' respective integrity. This mostly applies to utilities. If more than one part has the same effect type, it will select the one with the worst value, breaking ties by choosing the one with the lowest integrity.

* Replace a different part of the same subtype (ex: "Energy Cannon") where the old part has a lower percent integrity than any other of the same subtype with a lesser or equal effective rating. "Effective Rating" equals rating, +1 for prototypes. Ties among potential swap targets are broken by choosing the one with the lowest effective rating.

* Armor without any special effect is replaced by other such armor, comparing purely for current integrity (rating is ignored).

If none of the conditions are met, it will simply report "No free slot." To avoid smart replacement entirely, simply use the manual swap commands, or free the required slot first.

Note that this feature only works for parts that occupy a single slot.

Auto-replaced items are moved to the inventory, or if the inventory is already full, space will either be freed by comparing the item to all those carried based on the same rules above and drop a worse corresponding item, or where no comparison is possible, the replaced item itself is simply dropped.

In addition to attached part replacement, when attempting to pick up an item and put it in a full inventory, the same rules are applied to auto-replace (drop) an applicable inventory item to make room for a better new one. Where no comparison is possible, the pick up action will simply fail with a message indicating the inventory is full.

The advantage of the existing priorities are that they are easier to follow (once you know them), whereas if we swapped priority 1 and 2, prioritizing effect comparisons, that may not always be so obvious in the heat of things and lead to unexpected swaps.

So yeah it's not a bug, but something that's up for discussion for anyone who would like to contribute. I'll move it to Ideas.
Logged
Josh Ge, Developer - Dev Blog | @GridSageGames | Patreon

Widmo

  • Derelict
  • **
  • Wiki Contributor Shared a Confirmed Stealth Win Bug Hunter Supported Cogmind Alpha Access 2015-2017 (Prime Tier) Weekly Seed Participant
  • Posts: 83
    • View Profile
Re: Auto-replacement Priorities
« Reply #2 on: December 31, 2016, 06:14:20 PM »

In my opinion the problem with this is precise integrity value is not visible at a glance unless one switches to dedicated mode. If I knew integrity was lowered I would have acted slower. I mistakenly assumed pristine condition of relevant parts since they were all green. This means essentially when need  to do processor replacement occurs I am much better off by detaching obsolete item myself since no storage space is needed. More keystrokes but still better than checking integrity of every piece.

I think it is not the algorithm that has greatest room for improvement here. Having the part to be removed flash red very briefly could be helpful in that regard.
Logged

Kyzrati

  • Administrator
  • True Cogmind
  • *****
  • Posts: 4460
    • View Profile
    • Cogmind
Re: Auto-replacement Priorities
« Reply #3 on: January 01, 2017, 04:01:29 AM »

Yeah when I'm worried about the potential results of a swap (i.e. anything at all is ambiguous due to multiple types), I'll just do it manually, though this only really comes into play with processors, since you won't permanently lose other items in the same way (you can still recover from the occasional mistake/mis-swap).

I think it is not the algorithm that has greatest room for improvement here. Having the part to be removed flash red very briefly could be helpful in that regard.
Ooh that's a very interesting idea... However, when you are going to permanently destroy-replace a processor, doesn't the UI already warn you which item will be removed with a text message? Since I don't think you'd want to require double confirmation on all swaps, I guess what you're saying is that in addition to the processor-specific message only processors would flash in that case? (Because for any other items to flash first that would mean the swap couldn't take place immediately.)

I like the flashing processor idea, which also makes sense to apply when simply confirming a regular (processor) removal, not just swaps.
« Last Edit: January 01, 2017, 05:45:01 AM by Kyzrati »
Logged
Josh Ge, Developer - Dev Blog | @GridSageGames | Patreon

zxc

  • Cogmind
  • *****
  • 1st place in the High Scores category during Alpha Challenge 2015 1st place in the Best Escapes category during Alpha Challenge 2015 Shared a Confirmed Combat Win Shared a Confirmed Stealth Win Kyzrati Patron Bug Hunter Achievement leader in at least one category during Alpha Challenge 2015 Participated in the Alpha Challenge 2015 Wiki Contributor Weekly Seed Participant
  • Posts: 726
    • View Profile
Re: Auto-replacement Priorities
« Reply #4 on: January 01, 2017, 05:28:52 AM »

+1 flashing things
Logged

Widmo

  • Derelict
  • **
  • Wiki Contributor Shared a Confirmed Stealth Win Bug Hunter Supported Cogmind Alpha Access 2015-2017 (Prime Tier) Weekly Seed Participant
  • Posts: 83
    • View Profile
Re: Auto-replacement Priorities
« Reply #5 on: January 02, 2017, 01:30:13 AM »

However, when you are going to permanently destroy-replace a processor, doesn't the UI already warn you which item will be removed with a text message?
No, it does not. It tells you what type of the item is going to be discarded. This is sufficient to deduce which one is exactly being meant but parsing this requires some effort. Why put that burden on player and interrupt the smooth game flow? As you can see understanding the algorithm failed in that regard because I am too lazy to check integrities. :)

Having the precise item being pointed out right there in equipment eliminates the whole issue. Improving the message to contain slot letter will also lessen cognitive burden but in my opinion not as well as marking the part directly.

(...) only processors would flash in that case? (Because for any other items to flash first that would mean the swap couldn't take place immediately.)
How about a color change of the item instead of flash so playing speed can be kept uninterrupted? Have it stay red for as long as the confirmation grace period is active. Giving the colon in front of prcessor item a way to stand out more than usual in this case to accentuate its meaning is welcome.

Also agreed about the subject of the topic being really much more about processors than anything else. As you wrote yourself price for mistake in other cases is usually some matter. Unless a compactor is nearby.
Logged

Kyzrati

  • Administrator
  • True Cogmind
  • *****
  • Posts: 4460
    • View Profile
    • Cogmind
Re: Auto-replacement Priorities
« Reply #6 on: January 02, 2017, 08:00:14 PM »

However, when you are going to permanently destroy-replace a processor, doesn't the UI already warn you which item will be removed with a text message?
No, it does not. It tells you what type of the item is going to be discarded.
Ah right, it gives the name but you might have more than one of the same. Adding the slot number to various messages could be an improvement, but extra work and, as you say, not as valuable as a more specific visual marker. I'll add it!

(...) only processors would flash in that case? (Because for any other items to flash first that would mean the swap couldn't take place immediately.)
How about a color change of the item instead of flash so playing speed can be kept uninterrupted? Have it stay red for as long as the confirmation grace period is active. Giving the colon in front of prcessor item a way to stand out more than usual in this case to accentuate its meaning is welcome.
Yeah, that would be better--I hadn't yet thought of the details, just using a "flash" as a placeholder approach. On thinking about it more closely, it would be best to have an oscillating glow for the entire state duration, since a static color change might not be as noticeable as something that is continually in flux. (With the UI in general, I try to avoid non-static elements because they draw unnecessary attention, but in cases like this that's precisely what makes it a desirable feature.)

Unless a compactor is nearby.
I do recall a particular story where that happened... :P
Logged
Josh Ge, Developer - Dev Blog | @GridSageGames | Patreon