Welcome to Keen Software House Forums! Log in or Sign up to interact with the KSH community.
  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.

Thread Status:
This last post in this thread was made more than 31 days old.
  1. Phoera Senior 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. Wicorel Senior 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. Malware Master 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 Donohue Trainee 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. mexmer Senior 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 Donohue Trainee 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. Malware Master 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. Cheetah97 Trainee 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. w0lf3y Apprentice 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. Malware Master 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. w0lf3y Apprentice 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. Phoera Senior 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. Malware Master 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. Phoera Senior 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. plaYer2k Master Engineer

    Messages:
    3,160
    That is in world space iirc.
     
  16. Phoera Senior Engineer

    Messages:
    1,713
    thanks, will try remind geometry then.
    (need to determine if ship descending or ascending)
     
  17. Malware Master 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. Phoera Senior Engineer

    Messages:
    1,713
    ok, i think i will just try to switch to LinearVelocity.
     
  19. jb_aero Trainee 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:

     
  20. Phoera Senior Engineer

    Messages:
    1,713
    !human
     
  21. Ronin1973 Master Engineer

    Messages:
    4,913

    I believe that Malware was referring to using a sensor block that's limited to 50 meters.
     
  22. BurninSun Trainee 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. Phoera Senior Engineer

    Messages:
    1,713
    by world matrix of provided block i think.
     
  24. Malware Master 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. BurninSun Trainee 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. Malware Master 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. taleden Trainee 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. Malware Master 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. taleden Trainee 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. Wicorel Senior 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 Agree x 1
Thread Status:
This last post in this thread was made more than 31 days old.