endless-sky / endless-sky

Space exploration, trading, and combat game.
https://endless-sky.github.io/
GNU General Public License v3.0
5.92k stars 1.04k forks source link

Cargo space shown unified, but treated as per-ship #10599

Open opusforlife2 opened 1 month ago

opusforlife2 commented 1 month ago

Is there an existing issue for this?

Describe the bug

The game requires cargo items to completely fit inside a ship. However, the player is able to put items in cargo even if individual ships don't have space, due to the pooled cargo space shown.

The player isn't stopped from adding more cargo. Instead, a warning is shown upon trying to depart. Then, the player must play a small trial-and-error guessing game of which item(s) to remove from cargo in order to fit the requirement.

Steps to Reproduce

  1. Have a couple ships at least.
  2. Put very large items in the cargo, such that the last cargo item can't fit onto any one ship.
  3. Try to depart.

Expected Behavior

The game should stop the player from putting stuff in cargo if it cannot be carried in a single ship.

To help with this, the Outfitter screen shouldn't just show a single "cargo space" number, but a complete breakdown of each ship's cargo space. As individual ships get filled, they should become greyed out. Sure, the numbers might jump around as the game readjusts outfits from one ship to another as more get added, but at least the player will get some idea of what's going on.

The list would need to be scrollable to account for a large fleet.

Screenshots

No response

Link to save file

No response

Operating System

W10

Game Source

GitHub Releases

Game Version

0.10.8

Additional Information

No response

esksp commented 1 month ago

Even worse: Apparently if you park a ship, its cargo allowance remains active. Meaning you can park a couple hefty cargoes somewhere, forget them, and still use their virtual cargo space on a small, fast and nimble craft...

(Unconfirmed, since I've noticed this with custom ships, and given I was tweaking and fine-tuning all the time I can't be sure which part of this is my own fault, and which is a game oversimplification.)

xobes commented 3 weeks ago

I'll work this after my current Outfitter/Shipyard updates.

xobes commented 3 weeks ago

I also need to figure out how to do unit testing so I can add appropriate test cases for this stuff.

xobes commented 3 weeks ago

Even worse: Apparently if you park a ship, its cargo allowance remains active. Meaning you can park a couple hefty cargoes somewhere, forget them, and still use their virtual cargo space on a small, fast and nimble craft...

(Unconfirmed, since I've noticed this with custom ships, and given I was tweaking and fine-tuning all the time I can't be sure which part of this is my own fault, and which is a game oversimplification.)

I think that this portion of the issue is a little controversial as there are cases when things are going to be moved to cargo so that they are not lost altogether. Might need to add a checkbox or something to the UI to indicate if parked ships ought to be considered in a particular cargo-involved transfer. I'll give this some more thought.

I think I can fix the original issue with my current refactor of the Outfitter, though.

Oof... I can do the checks, but the problem is in the fact that on planet cargo is pooled, and on take-off it is distributed. I'll add the checks to the Outfitter -- but I think it would be prudent to implement this (original issue) in a separate update afterwards that focuses on the distribution algorithm to more strategically distribute large items first into large spaces.

We can come up with scenarios like:

I have 3 ships with available space, 3, 3, 4 and outfits sized 3, 3, 2, 2 -- it's not as simple as stick the biggest thing in the biggest hold, that would be 3/4, 3/3, 2/3, and the last 2 can't fit...

Needs more thought.

    // TODO: Check that a specific given ship can hold this item.
    // Example, cargo free in ships: A=3, B=3, C=6; i.e. Fleet can hold 12.
    // outfits already installed are 4, 3 in size, i.e. 7, leaving room for 5.
    // can we fit an outfit of size 4?  Yes because 6 is bigger than 4. But NO, because we only have
    // one ship that can hold an outfit of size 4, and we already have to consume that space for the
    // size-4 outfit that we already have in fleet cargo
    // for(Ship *ship : playerShips)
    // Can this ship Install the selected Outfit
    // bool OutfitterPanel::ShipCanHold(const Ship *ship, const Outfit *outfit)
    // {
    //  return (ship.cargo.FreePrecise() > selectedOutfit->Mass())
    // }
esksp commented 3 weeks ago

Some comments from a player:

the problem is in the fact that on planet cargo is pooled, and on take-off it is distributed.

The biggest problem is the player doesn't have anything to say about what cargo goes where. The computer tries to distribute it following a number of generic assumptions, which are very often wrong... I might have accidentally scooped "trade" flotsam which is now sitting among very rare pieces of alien outfits, but for the computer it's all "cargo".

to the Outfitter

I would respectfully suggest to (eventually) implement a full-fledged cargo management interface, allowing the player to 1. know what is loaded where, 2. be able to manually distribute it to his ships as (s)he sees fit, 3. sell it or store it or jettison it at will (all or partially, and especially knowing what he's selling or jettisoning: If you have to sell captured outfits in a planet without Outfitter, you can only sell everything at once. Too bad about that exceptional piece of tech you were hoping to hold on to...).

GUI-wise it could maybe be an extension of the trading panel? I don't know. All I know is that as a player wanting to do commercial runs, you want to be able to manage your loads, know at any moment what you have loaded, and load your ships intelligently: Cargo goes to cargo ships. Not enough cargo ship space? Do you sell it, or do you load it on your warships, weighting them down? It has to be your, informed choice. It would also solve your problem, as this decision is now made by the player, not the computer. It's the player who decides how (s)he manages the pool of merchandise before taking off. Just my 2 cents worth.

xobes commented 3 weeks ago

@esksp I'm very sympathetic to a lot of your points, I am also a player and I read a lot of your feedback recently. I had a lot of the same comments as you about the game and now I'm trying to implement what I can. Keep the feedback coming. You might like what I've done so far in the Outfitter (coming imminently, I'm about to send a pull request that is a revamp of Shop code. I'll tag you in it so you can help test it out :-D. It'll be my first code change on this project.

Keep the good ideas coming!

opusforlife2 commented 2 weeks ago

on planet cargo is pooled, and on take-off it is distributed

Dear pug, who thought up this monstrosity of an idea? Cargo distribution should be done the moment another item is placed there, at least.

I think it would be simpler (though CPU-costlier) if cargo is redistributed after each new item (or batch) is added to cargo.

esksp commented 2 weeks ago

Dear pug, who thought up this monstrosity of an idea? Cargo distribution should be done the moment another item is placed there, at least.

I fail to see the point in pooling either, but then again I guess "it's how EV did things" or some such... :-p

I think it would be simpler (though CPU-costlier) if cargo is redistributed after each new item (or batch) is added to cargo.

Is CPU cost really a thing in ES? I can't really judge, having a pretty fast laptop (i7), but ES doesn't hit me as a potential resource hog. Besides it won't happen often you do some cargo management while battling a huge fleet of enemies... Most of the time cargo management will happen as an exclusive task while landed, the rest of the time cargo will remain some inert entries in a database, isn't it.

opusforlife2 commented 2 weeks ago

but ES doesn't hit me as a potential resource hog

That's because the devs have made it a point to avoid much resource consumption. That's what makes the game so great. It can be played even on a potato laptop. It just takes some time to load up when first starting the game on old PCs.

esksp commented 2 weeks ago

That's because the devs have made it a point to avoid much resource consumption.

Isn't that what all devs routinely do? 🙄 Sorry, make that "used to do". 😈

It can be played even on a potato laptop.

So there definitely is some leeway to add some code complexity, especially since it will happen during a time when the computer doesn't really has much else to compute.

On my laptop ES takes 3 seconds to start, and while my laptop is currently upper mid-end ware, it will soon become entry level: ES is here to stay, so it can afford to grow a little fatter...

opusforlife2 commented 2 weeks ago

That's a little bit of consumer elitism speaking. :P My PC used to take at least half a minute to start it up on an HDD. And I still have to turn off some graphic-intensive options (or avoid turning them on, as the case may be).

Hecter94 commented 2 weeks ago

Ultimately, what matters is that it's still able to provide a good experience for any users who meet our minimum requirements:

Minimum Recommended
RAM 750 MB 2 GB
Graphics OpenGL 3.0 OpenGL 3.3
Storage Free 350 MB 1.5 GB
esksp commented 2 weeks ago

That's a little bit of consumer elitism speaking. :P

LOL. A little bit maybe, but it's also realism: Computers get more and more powerful, and (regrettably) old ones eventually die: I kept my previous laptop for almost 15 years (a Core Duo!)... It did indeed work just fine, even for some games, till the day its heart stopped. I wanted spinning rust drives on my new laptop (I don't trust those glorified SD cards), but I got SSDs. Not my choice, Dell's...

My point is that computers will slowly get more powerful, if only because one after the other, the old ones go gently into that good night.

any users who meet our minimum requirements

Impressive! But you'll have a hard time to find users meeting those minimal requirements! :-D When last were computers sold with less than 2 GB of RAM? That was back in WinXP times... From Win7 on, Windows' minimal requirements were 1 GB for 32-bit and 2 GB for 64-bit. How many of those computers from before 2009 are still in active use?

opusforlife2 commented 2 weeks ago

Welcome to 3rd world countries. :*

Hecter94 commented 2 weeks ago

Endless Sky, being a pretty lightweight game, is one of its strengths. I myself have a big, beefy gaming PC with 64 GB RAM, but I'd still prefer Endless Sky to remain lightweight for those who have older or less capable devices.

Many players play on mobile, for example. While it is unofficial, it's still good that even older phones can usually play without issue. We've even had reports of Endless Sky being packaged on prison computers due to its small size, lightweight requirements, and lack of network connectivity.

So I wouldn't really be a fan of increasing the requirements unless we have an exceptionally good reason to do so.

esksp commented 2 weeks ago

increasing the requirements

I understand that. But how much would this increase the requirements? As I've already said, I'm no developer, but it sounds to me like a minor overhead which would improve the game's enjoyment.

tibetiroka commented 2 weeks ago

But how much would this increase the requirements?

A lot. This problem is actually way more complicated than a lot of people think. If we implemented a solution that "works" every time, it would blow up even your modern laptop.

How many of those computers from before 2009 are still in active use?

I don't have any exact numbers, but quite a few. We even have a couple test systems of our own from that era (I even have a system with an i5 750 from 2009), and there are quite a few community members on discord with old computers.

opusforlife2 commented 2 weeks ago

Also, even in the early 2010s, the cheapest mobile CPUs put in loads of budget laptops were hardly competent at running even slightly strenuous workloads. Imagine stuttering at showing the cursor in MS Word. Playing a CPU/GPU-intensive game would be out of the picture.

esksp commented 2 weeks ago

A lot. This problem is actually way more complicated than a lot of people think.

Ah okay - Misunderstanding... :-D

I advocate to make this manual, i.e. it's the player who manages the cargo and distributes it, as (s)he sees fit, to the different ships of his/her fleet. Computer just notes what has been put where.

As I said elsewhere, the computer can only make assumptions as to what the player might want, assumptions which are often wrong. Precious rare loot or some worthless scooped flotsam, it's all the same to the computer, and the fact you have different ships for different tasks is also lost to it, in more than one way (not only about cargo distribution, but also concerning ship behavior).