The game treats the mass from inventory in containers differently. For physics calculations, it is inversely scaled (reduced) according to the inventory multiplier.

This means that thrusters that work at 1x inventory will continue to work the same at 10x inventory. This is a good thing for ship designers.

To know how much THRUST to use to, say, balance the ship against gravity, the script will need to calculate effective mass of the ship. The cargo mass needs to be scaled inversely with the inventory multiplier.

Anything you can set up when making a world on a server and is public to every player when they join the server should be accessible imho. The inventory multiplier is actually a very useful thing to know. I have made quite a few scripts where the user of the PB script had to go in and change the multiplier in a static int to make the script work properly every time they set it up.

Possibly this is avoidable now because we can directly access inventory mass, but still I think it should be accessible, just like welding speed and refining speed. Other things are more important though, like center of mass for a ship and such.

In any case, great job so far Malware!

Click to expand...

I disagree because as I say, it's metainformation. It's not information available to the virtual astronaut. It's information from another world, as it were. I won't change my stance on this.--- Automerge ---

This is what I feel is the problem here. Not that the multiplier isn't available, but that the information that is available isn't right. The world should be consistent.

Click to expand...

For ores and ingots, the mass of a stack is the basic inventory amount of that stack. A "unit" of Platinum Ingot is 1 kg, so 600 units of Platinum Ingots is 600 kilograms. That's enough Platinum to make 1500 Thruster Components. But, on a 3x Inventory Multiplier, that 600 kilograms of Platinum Ingots only has a physics mass of 200 kilograms.

When player-made autopilots need their script to know how much Platinum is on-board, they need to know 200 kilograms. When scripts that manage Assemblers need to know how much Platinum is on-board, they need to know 600 kilograms. Which piece of information is "right"?

Anything you can set up when making a world on a server and is public to every player when they join the server should be accessible imho. The inventory multiplier is actually a very useful thing to know. I have made quite a few scripts where the user of the PB script had to go in and change the multiplier in a static int to make the script work properly every time they set it up.

Possibly this is avoidable now because we can directly access inventory mass, but still I think it should be accessible, just like welding speed and refining speed. Other things are more important though, like center of mass for a ship and such.

In any case, great job so far Malware!

Click to expand...

while you are right in some way, you are also wrong.
player knows multipliers, because they are on server select screen, but there is no other place to get/see them, and doesn't make even sense, since your game is affected by multipliers directly.

mods might get game setting from modapi, but PB doesn't know anything about mutlitpliers, like you don't know anything either you are in terminal or looking at hud.

i agree with malware on this one. metainformations and that includes game settings are not thing, that should be ever accessible to ingame (pb).

As it stands, scripts in Survival can determine the Inventory Multiplier by looking at the Max Volume for a Cargo Container and comparing it to the known Max Volume for a 1x Inventory World. Not terribly complicated, this only needs to be done once on Program construction.

However, scripts in Creative can't do this because the Max Volume for ALL inventories are the same extremely large constant regardless of what the Inventory Multiplier is.

The disparity seems a little odd to me.

That being said, the information we now have access to is an improvement over last week. So, that's good.

For ores and ingots, the mass of a stack is the basic inventory amount of that stack. A "unit" of Platinum Ingot is 1 kg, so 600 units of Platinum Ingots is 600 kilograms. That's enough Platinum to make 1500 Thruster Components. But, on a 3x Inventory Multiplier, that 600 kilograms of Platinum Ingots only has a physics mass of 200 kilograms.

When player-made autopilots need their script to know how much Platinum is on-board, they need to know 200 kilograms. When scripts that manage Assemblers need to know how much Platinum is on-board, they need to know 600 kilograms. Which piece of information is "right"?

Click to expand...

Which only goes to prove my point, even if my suggested solution is somewhat flawed - although I don't really see the problem. Assemblers work on volume not mass, that is what should be used in relation to them. If this information is not available - it should be. And, if information was consistent, then one could use the same value for volume, and always get the correct relative amount.

Many thanks for this — both for RC changes and posting the new API for them.
But... can we have an option to remove one particular waypoint by name? Yes, there's a workaround by clearing all waypoints and re-adding back what's needed, but it's ugly.

Yes well... It's not as easy as it might seem getting stuff in there, so I can't promise anything.

Click to expand...

But you're going to try and get it in, right? ( referring to altitude )
The info alone, that yes, I am trying to get it in, or, that's not high on my priority list right now, would make a world of difference IMO.

Something we're looking forward to is coming, then PB update gets mentioned int he update vid, we can get all giggity.
or
Not this week, oh well, maybe next week *crosses fingers*

But you're going to try and get it in, right? ( referring to altitude )
The info alone, that yes, I am trying to get it in, or, that's not high on my priority list right now, would make a world of difference IMO.

Something we're looking forward to is coming, then PB update gets mentioned int he update vid, we can get all giggity.
or
Not this week, oh well, maybe next week *crosses fingers*

Click to expand...

I have no control on the "if" and "when". The only thing I can promise is that I'll write the code for the altitude information, because that was the intention all along - but I cannot promise that it'll get into the game, or if it does, when it'll get into the game.

I have no control on the "if" and "when". The only thing I can promise is that I'll write the code for the altitude information, because that was the intention all along - but I cannot promise that it'll get into the game, or if it does, when it'll get into the game.

Click to expand...

I can understand that completely. I have often wondered about the difficulty of getting a community fix / alteration into the base code. My imagination tells me, it's no picnic.

I have no control on the "if" and "when". The only thing I can promise is that I'll write the code for the altitude information, because that was the intention all along - but I cannot promise that it'll get into the game, or if it does, when it'll get into the game.

Click to expand...

nevertheless you done great job, waiting for more news=D

actually i fall into need of elevation.(also i was needed thruster max thrust info, but this i can enter manually at least)=)

(also i was needed thruster max thrust info, but this i can enter manually at least)=)

Click to expand...

Yes I was quite disappointed to learn they changed that... thruster.GetMaximum<float>("Override") used to return the actual thrust at one point - this is the main reason I added the mass info in the first place, to be able to calculate if a ship is capable of lifting its own weight within the given gravity field.

Yes I was quite disappointed to learn they changed that... thruster.GetMaximum<float>("Override") used to return the actual thrust at one point - this is the main reason I added the mass info in the first place, to be able to calculate if a ship is capable of lifting its own weight within the given gravity field.

Click to expand...

btw.
how that possible that GetShipSpeed() and GetShipVelocities().LinearVelocity.Length() return different value?
and what LinearVelocity returns? world vector or ship relative vector?

btw.
how that possible that GetShipSpeed() and GetShipVelocities().LinearVelocity.Length() return different value?
and what LinearVelocity returns? world vector or ship relative vector?

Click to expand...

I don't know, this one was a "lazy" patch - there was very little actual coding involved, I simply exposed. Personally I was interested in the LinearVelocity, I added exposed GetShipSpeed as a novelty...

I don't know, this one was a "lazy" patch - there was very little actual coding involved, I simply exposed. Personally I was interested in the LinearVelocity, I added exposed GetShipSpeed as a novelty...

Hence my hesitancy. The only other viable option would be speed relative to the world, but axis relative to the ship... which I think would only add to the confusion.

Click to expand...

How exactly would one make this conversion? Specifically I'm NOT looking for a vector based on the orientation of a specific block (eg. cockpit, rc block) but in relation to the ship itself as given by block.Position. ie. if a block in the "front" of my ship has a block.Position with a high -Z and I'm traveling "forward" at 100m/s, I'd want a linear velocity vector reading (0, 0, -100).

How exactly would one make this conversion? Specifically I'm NOT looking for a vector based on the orientation of a specific block (eg. cockpit, rc block) but in relation to the ship itself as given by block.Position. ie. if a block in the "front" of my ship has a block.Position with a high -Z and I'm traveling "forward" at 100m/s, I'd want a linear velocity vector reading (0, 0, -100).

Click to expand...

You see, that's just it. It's the controlling block that decides what "forward" is on your ship. Which means you need the direction-transformed matrix of that particular block. If you always make sure the grid forward is forward, then, like @phoenixcorp13 says, all you need is the basic world matrix, without translation, multiplied with the velocity vector. I forget whether it needs to be the inverse of the matrix. I'm no good at vector math any more, it's been years.

You see, that's just it. It's the controlling block that decides what "forward" is on your ship. Which means you need the direction-transformed matrix of that particular block. If you always make sure the grid forward is forward, then, like @phoenixcorp13 says, all you need is the basic world matrix, without translation, multiplied with the velocity vector. I forget whether it needs to be the inverse of the matrix. I'm no good at vector math any more, it's been years.

This is more complicated than it should be.

Click to expand...

I'm specifically NOT looking for "forward" orientation per any particular block. I'm using the coordinates returned by block.Position and orientation returned by block.Orientation which are both consistent regardless of the controlling block (or even lack thereof).

It should be something along the lines of getting a block.Orientation of any arbitrary block, converting that to a direction vector in world coordinates, then transforming the LinearVelocity vector into that.

But I also haven't touched vector math in years and combined with not knowing the Vector3 classes that well, I was hoping this would be one someone could just give me the line of code

I'm specifically NOT looking for "forward" orientation per any particular block. I'm using the coordinates returned by block.Position and orientation returned by block.Orientation which are both consistent regardless of the controlling block (or even lack thereof).

It should be something along the lines of getting a block.Orientation of any arbitrary block, converting that to a direction vector in world coordinates, then transforming the LinearVelocity vector into that.

But I also haven't touched vector math in years and combined with not knowing the Vector3 classes that well, I was hoping this would be one someone could just give me the line of code

Click to expand...

You need a matrix to transform the velocity vector, that much I'm certain of. But you should then only need the basic block or grid world matrix I guess.

I saw the thread title and hoped that IMyShipController would finally implement IMyInventoryOwner, but alas. Every week or two someone reports the bug that TIM cannot see or manage items inside Cockpits etc, and I have to keep telling them there's nothing I can do because those inventories are invisible to in-game scripts.

I saw the thread title and hoped that IMyShipController would finally implement IMyInventoryOwner, but alas. Every week or two someone reports the bug that TIM cannot see or manage items inside Cockpits etc, and I have to keep telling them there's nothing I can do because those inventories are invisible to in-game scripts.

Click to expand...

It will never implement IMyInventoryOwner, that's a deprecated interface. What needs to be done is to update the inventory methods. Besides, the ship controller by itself cannot implement that interface as not all blocks deriving from that has inventory.

I'm specifically NOT looking for "forward" orientation per any particular block. I'm using the coordinates returned by block.Position and orientation returned by block.Orientation which are both consistent regardless of the controlling block (or even lack thereof).

It should be something along the lines of getting a block.Orientation of any arbitrary block, converting that to a direction vector in world coordinates, then transforming the LinearVelocity vector into that.

But I also haven't touched vector math in years and combined with not knowing the Vector3 classes that well, I was hoping this would be one someone could just give me the line of code

Click to expand...

But it's not consistent. Those directions are initially determined by the 'direction' of the grid. Which is determined first by the placement of the initial block (the landing gear).

It can be modified by using merge blocks (both grids will end up using one of the two 'directions').

Pasting the ship in from creative (or spacemaster) means it will keep the 'direction' from the blueprint. However, building the ship in survival means the grid will take the 'direction' from the initially placed landing gear which then has the projector block attached. Unless care is taken in exactly how the blueprint is placed in relation to the landing gear, this will result in a different 'direction' for the created grid.

So what you want to do doesn't always work in the game, depending on how it's used.