Fwurg

[Chriz]

Introduction
I would like to mention again that hyperspace lane capacity bookkeeping is not possible without keeping a massive parallel administration of our trades...
There are multiple problems within the current datamodel that make it hard to get an overview of the capacity that is actually used.

Here is the list that I came up with so far which point out the dimensions of the problem.

• We use trades instead of trade routes.
• Hyperspace lanes are not only used by your outgoing trades but also by incoming trades which are the bookkeeping job of other players.
• Currency trades are included within the same trade system.
• Holonet trades are included within the same trade system.

If we would use trade routes instead of trades it would be easier to have an overview of the big picture. I require a query to find all the traded goods.
@ Brend how did you check all our trades? Do you already have queries or tooling for this? If this is the case are you willing to share this?

Proposals
My proposal would be to either:

• Abbandon the whole hyperspace lane capacity limit since it is not checkable or enforceable with the current tooling
  
• Or rework the trade system and provide the tooling to automatically check the hyperspace lane capacity.

My thoughts
I brainstormed on what I would need to check my trade capacity within the current system and already decided that I do not have enough knowledge about the query system to write the necessary queries at this point.

Currently the only hyperspace lanes that matter are either at the start of a trade route or the end. This coincides nicely with the FROM and TO of the trade.

I would already have a lot of information with a query that sums all traded goods TO my system and another query that sums all traded goods FROM my system.

Currently however I don't know how to write the 'all traded goods' in a query.

Furthermore there are multiple exceptions to this query.
You have to leave out the currencies (tax and credits)

We need an exception for holonet trade, however I believe we could mark these trade blocks with a class 'holonet_trade' or something and leave those out of the capacity query.

The same holds for trades that intentionally fly outside of the hyperspace lane. We could use trade block classes like 'skip_origin_hyperspace_lane' and 'skip_destination_hyperspace_lane' to exclude those from the query.

This would probably give me some insight into the current situation. However it might also be an option to look into the new trade model based on trade routes that we theoretized about some time ago.

Conclusion
I hope you guys understood what I tried to explain. I might have gone Brend on this topic but I had a lot on my mind that I wanted to share. Could you share your thoughts on the subject to see what we need?

[Elmer]

I understand your problem with the hyperspace lane capacity, and think this requires attention indeed.

Ultimately of course would be a graphical interface, assignable fleets and all that sort of simple click-and-play tooling, but since nobody has the money to do so, this won't be happening any time.

Therefore, I propose a faster simpler solution (which also immediately solve a challenge I am stuck with for a long time now). What about using a tech to remove the capacity limit? Like a super-computer tech?

[Brend]

I fully understand what you mean, Chriz. Unfortunately, I did all checking by hand (with some help from my trusty friend Mr. Spreadsheet), so I have no tooling to share with you all (yet).

Personally, I think that removing capacity limits either by rules decision, or by tech, is kinda overpowered.

I'm more interested in the click-and-play tooling thingy, that sounds much nicer... I was actually considering building a trade checker tool. This would require some changes to how we write down trades and such on the wiki, but the impact would mostly be that we have to note down trade routes as well -- instead of just listing some moving goods and hoping that we have enough capacity. Having the checker will at least give us an idea of what's what.

What would be the bare minimum needed for such a tool?