<key>requires_cargo_space</key> is broken

Lestradae · Post by **Lestradae** » Wed Jan 14, 2009 11:08 am

<report>

Just found something else that's probably a bug.

Experimented a bit with giving items a cargo need - and attempted to use this command which it says on the wiki would work ...

<key>requires_cargo_space</key>
<integer>SOMENUMBER</integer>

... (SOMENUMBER could be any number) - and it doesn't work.

My original attempt was to script a new equipment item with it (Subspace Compression Cargo Bay) by setting SOMENUMBER to a negative value.

That didn't work, so I attempted it with weightings of different equipment items and positive numbers and it still doesn't work.

</report>

L

Post by **another_commander** » Wed Jan 14, 2009 11:24 am

It works fine for me with the Passenger Cargo Bay. requires_cargo_space is meant to be a positive integer.

Lestradae · Post by **Lestradae** » Wed Jan 14, 2009 1:18 pm

another_commander wrote:
It works fine for me with the Passenger Cargo Bay. requires_cargo_space is meant to be a positive integer.

It works only as intended with the passenger cabin. Attempt it with something else. Give i.e. the docking computer a 1 ton requirement to check. I assume you will observe the same as myself.

Post by **Eric Walch** » Wed Jan 14, 2009 2:14 pm

I think it still works as it always has since 1.65. But this key was only mend for the passenger bay.

Currently it is only used to see if an item can de displayed or not. The actual cargo bay consumption is still hard coded since at least 1.65. A passenger bay uses 5 tons (independent of the defined value in the key). And the removal gives back 5 ton.

Probably Giles added this key because he intended to give equipment cargo space but never came to it to let equipment itself read in this key value. But if it was that easy implemented, he would have done it right away.

The code contains a lot of ideas that never were finished.

Lestradae · Post by **Lestradae** » Wed Jan 14, 2009 2:24 pm

Hi Eric,

if that is the case, maybe the wiki text should be changed to reflect that.

The way that text is now, it confers the idea that this is a possible command for equipment.plists, which it is not.

Greetings

L

JensAyton · Post by **JensAyton** » Sat Jan 17, 2009 9:09 pm

requires_cargo_space specifies how much an equipment item requires, not how much it consumes. Does this distinction suck? Yes it does. Can the wiki be updated? No it can’t, because it’s currently read-only. :-)

Post by **another_commander** » Sun Jan 18, 2009 9:48 am

I tried to work on this a bit during the forum's downtime by making equipment consume space as the key implies. It turned out to be trickier than I thought and halfway through I realized that I was changing the gameplay mechanics to a degree that made me wonder if this should go in or not. Also I was not very happy with the way I did it at the end, so although I kept the changed files somewhere, it will need a revision of the implementation before going in and in any case I believe we should think twice about putting in a feature like this. This is more FFE stuff, rather than Elite and there are some problems inherent by design, like equipment occupying cargo space permanently after it's bought.

Wiki pages · Post by **Thargoid** » Sun Mar 29, 2009 5:19 pm

I've just hit this as well. I was trying to set up a bit of equipment (a mine in this case) as a trigger for something else to happen (in lieu of being able to assign it a key). But to make it realistic, the "whole package" would probably need a fair bit of cargo space.

I tried to set requires_cargo_space to 10, but as with Lestradae's experience it did absolutely nothing. The item was available for sale whether my cargo manifest was 0 of 35t or 35 of 35t (with a Jameson).

The conditions key also seems to have a flaw in it. The equipment screen refresh seems to be triggering before the new(ish) this.playerBoughtEquipment world script event. In that I set a mission variable to a value, with an equipment condition that the variable is set to zero (the idea being you can only buy one of the mines).

If I buy a first one though, a second one is also available for sale. If that second one is purchased, or if you leave the equipment screen and come back, then no further examples are offered (correctly) as the condition now comes into play. But currently because the equipment screen seems to be refreshed before the world script event happens, the bug with the second one being available is present. I hope that makes sense!

I'll report the second one as a bug on berlios, but does anyone else have any ideas? At the moment I'm getting around it by popping up a mission screen at the first purchase to take the player out of the equipment screen, and so preventing the immediate second purchase. It works, but it's less than elegant (although may stay in anyway).

Svengali · Post by **Svengali** » Sun Mar 29, 2009 8:10 pm

Thargoid wrote:
...but does anyone else have any ideas? At the moment I'm getting around it by popping up a mission screen at the first purchase to take the player out of the equipment screen, and so preventing the immediate second purchase. It works, but it's less than elegant (although may stay in anyway).

I don't think that there is another way (missionscreen) as long as we can't set the GUI in JS to force the refresh. Currently I'm ~~mis~~using this 'behaviour' as a easter egg in Hyperradio (at least as long as it is not changed). There I'm using the effectiveTechLevel - but for v1.73 I'll think about other ways for easter eggs :-)