1. You are currently browsing our forum as a guest. Create your own forum account to access all forum functionality.

# The IMyRemoteControl and IMyShipController update

Discussion in 'Programming (In-game)' started by Malware, May 20, 2016.

This last post in this thread was made more than 31 days old.
1. ### PhoeraSenior Engineer

Messages:
1,713
why the hell you need multiplier? you use mass dictionary for blocks?
you have props to get max inventory volume, current and current mass.

2. ### WicorelSenior Engineer

Messages:
1,256
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.

3. ### MalwareMaster Engineer

Messages:
9,837
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.

4. ### Seamus DonohueTrainee Engineer

Messages:
90
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"?

5. ### mexmerSenior Engineer

Messages:
1,977
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).

6. ### Seamus DonohueTrainee Engineer

Messages:
90
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.

7. ### MalwareMaster Engineer

Messages:
9,837
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.
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.

8. ### Cheetah97Trainee Engineer

Messages:
31
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.

9. ### w0lf3yApprentice Engineer

Messages:
152
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*

10. ### MalwareMaster Engineer

Messages:
9,837
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.

11. ### w0lf3yApprentice Engineer

Messages:
152
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.

12. ### PhoeraSenior Engineer

Messages:
1,713
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)=)

13. ### MalwareMaster Engineer

Messages:
9,837
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.

14. ### PhoeraSenior Engineer

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

Last edited: May 29, 2016
15. ### plaYer2kMaster Engineer

Messages:
3,160
That is in world space iirc.

16. ### PhoeraSenior Engineer

Messages:
1,713
thanks, will try remind geometry then.
(need to determine if ship descending or ascending)

17. ### MalwareMaster Engineer

Messages:
9,837
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...

18. ### PhoeraSenior Engineer

Messages:
1,713
ok, i think i will just try to switch to LinearVelocity.

19. ### jb_aeroTrainee Engineer

Messages:
95
Is that hardcoded to only work for the space pirates or is it for anything !human ? I ask because of a previous post by you:

Messages:
1,713
!human

21. ### Ronin1973Master Engineer

Messages:
4,913

I believe that Malware was referring to using a sensor block that's limited to 50 meters.

22. ### BurninSunTrainee Engineer

Messages:
16
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).

23. ### PhoeraSenior Engineer

Messages:
1,713
by world matrix of provided block i think.

24. ### MalwareMaster Engineer

Messages:
9,837
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.

25. ### BurninSunTrainee Engineer

Messages:
16
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

26. ### MalwareMaster Engineer

Messages:
9,837
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.

27. ### taledenTrainee Engineer

Messages:
48
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.

28. ### MalwareMaster Engineer

Messages:
9,837
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.

Trust me, just wait a bit longer. The code is already written.

29. ### taledenTrainee Engineer

Messages:
48
Aye, waiting is all I can do. Though it's been over six months already, hopefully it won't be another six months yet. Thanks for the reply though.

30. ### WicorelSenior Engineer

Messages:
1,256
I believe it will be very soon (tm).
--- Automerge ---
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.

• Agree x 1