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.

New modding feature requests

Discussion in 'Modding' started by Ondrej.Petrzilka, Aug 13, 2014.

Thread Status:
Not open for further replies.
This last post in this thread was made more than 31 days old.
  1. Eikester Apprentice Engineer

    Messages:
    423
    what i would like to see is a Way to align small Models inside the Blocks space (Center, Left, Right, Top, TopLeft etc.)

    The Model would need a new sbc parameter like
    Code:
    <Alignable>true</Alignable>
    (defaults to false if not exists)
    The Game would than give you new Options i.e. in the Paint Menu where you can adjust the alignment and would just override the
    Code:
    <ModelOffset x="0" y="0" z="0" />
    this would be very useful for stuff like Chairs, Signs, Pillars etc.

    Edit: more a general suggestion
     
    Last edited by a moderator: Sep 22, 2014
  2. Eikester Apprentice Engineer

    Messages:
    423
    another thing that will be very useful is a Random Model feature for the fully Build Model, something like this:

    Code:
    <Models>
      <Model>Models\SomeModelVariation1.mwm</Model>
      <Model>Models\SomeModelVariation2.mwm</Model>
      <Model>Models\SomeModelVariation3.mwm</Model>
    </Models>
    the Game would than randomly pick a Model of that list, would give us more options, imagine a Table each version with different Props, or Flowers, or Walls with different Pipes and so on, the possibilities are endless.

    Yes, you can basically do this with different Build Models but it doesn't work for Models with Dummies in it (Dummies only work in a fully Build Model) and Grinding/Welding the different Models can be a pita with high multipliers

    Edit: should be very easy to code in
     
    Last edited by a moderator: Sep 22, 2014
  3. Ben Apprentice Engineer

    Messages:
    136
    +1 for the model variation.
    Would be great to see something similar for textures too
     
  4. Ravenal Apprentice Engineer

    Messages:
    362
    +1 Model variation as well
     
  5. NimrodX Trainee Engineer

    Messages:
    30
    Currently the behaviors for cube blocks aren't terribly object oriented in design. It seems like you just have block types (for example, InteriorLight) with specific code for how that cube behaves.

    This is fine if I just want to make a block that behaves only like an InteriorLight, but what if I want to make a block that behaves like both an InteriorLight and a ControlPanel? There seems to be no way to do it.

    The solution to this would be to implement "block behaviors". In other words, blocks don't have to "be" InteriorLights or ControlPanels, they just need to have one or both of those behaviors. So the relationship goes from "block IS-A InteriorLight" or "block IS-A ControlPanel" to "block BEHAVES-LIKE InteriorLight", "block BEHAVES-LIKE Control Panel" or more importantly "block BEHAVES-LIKE InteriorLight AND ControlPanel".

    A way to do this would be using a mixin pattern in C# like this:
    http://colinmackay.co.uk/2008/02/24/mixins-in-c-30/

    The CubeBlock.sbc would be extended with tags like this:

    Code:
    <Behaviors>
       <Behavior>InteriorLight</Behavior>
       <Behavior>ControlPanel</Behavior>
    </Behavior>
    
    Now at this point you're probably thinking something like "that's great but right now the UI control panel has to be just one thing or the other. If someone wants to make an InteriorLight that's also a ControlStation then the UI control panels will conflict. so this is too hard to implement in the short term". Here's a simple solution to that problem:

    Code:
    <Behaviors>
       <PrimaryBehavior>ControlStation</Behavior>
       <Behavior>InteriorLight</Behavior>
    </Behavior>
    
    In other words, one of the behaviors is the "primary behavior" that determines what UI controls the user gets. So if one were to combine ControlStation and InteriorLight behaviors, they just have to choose one or the other behavior to allow the player to configure. (In this example any InteriorLight settings would just have to be configured with XML tags.)

    Block Behaviors could coexist with the legacy "single behavior based on block type" code.

    Block Behaviors could provide a good Modding API for people to code new block behaviors. (Right now it seems like modding block behavior code would require people to hack away at the assembly in a nasty way.)

    This could also provide a starting point to making some things more easily modable. For example, right now InteriorLight doesn't seem to use a dummy object for anything at all; the lense flare and point source are just hardcoded to 0,0,0. InteriorLight could just be left alone, and a new Light behavior could be created that uses a dummy object, etc. That way InteriorLight can just keep doing it's hardcoded thing and there's no reason to change it and possibly create bugs, but new blocks people create can use a Light behavior that's more flexible instead of trying to base a block on InteriorLight's hardcoded values.

    Please seriously consider this because it could really clean up the modding interface and keep any new code modding API from becoming really nasty.
     
    Last edited by a moderator: Sep 22, 2014
  6. eobando Trainee Engineer

    Messages:
    96
    I love the design of this UI. Retains the greatness of Core Se while seriously giving it a face-lift.
     
  7. Gwindalmir Senior Engineer

    Messages:
    1,006
    On the API side, I'd like to see String extension methods enabled.

    For example:
    If I have multiple similar blocks, I can share functionality by comparing the SubtypeID. However I have to compare each and every one separately.
    I'd like to use String.Contains to check if there's a common part of a name (eg. "SpecialDoor_Small" and "SpecialDoor_Large" would both match String.Contains("SpecialDoor")).
    This allows more blocks (even from other mods) to extend the scripting I've already done, without having to supply their own, or even modifying it.

    EDIT:
    It looks like the string functions have be enabled in a recent hotfix. I withdraw my request.
     
    Last edited by a moderator: Sep 24, 2014
  8. RayvenQ Moderator

    Messages:
    562
    I'd love to see a grab tool, basically something akin to a player wielded landing gear.
     
  9. paul76au Trainee Engineer

    Messages:
    25
    LARGE ELEMENTS

    For big stations to decrease amount of blocks cause in survival to put 50 000 those by hand its kinda time consuming, and there should be less impact on server also with big ones i think.


    Ideal would be equivalents of 1x1x1 standard and armored building blocks in sizes 1x5x5
    1x5x10 and 1x10x10



    hope someone can make up something like that


    regards
     
    Last edited by a moderator: Sep 26, 2014
  10. RedPhoenix Moderator

    Messages:
    817
    This is a great idea, especially as it would decrease the amount of objects (and therefore polygons) beeing rendered.
     
    Last edited by a moderator: Sep 26, 2014
  11. MechanizedIT Apprentice Engineer

    Messages:
    354
    My request is to allow us to change friction parameters on collision boxes as well as some way to reduce collision damage.

    The mods I am working on, gears, racks, rails, etc. currently are extremely limited by the fact that even very small collisions between two objects can cause a large amount of damage. I am guessing that damage is proportional to speed and mass? So even when I turn up the mass, increasing steel plate requirements, damage is still done at the same rate because the mass of each object has increased causing more damage?

    I am not asking for the ability to make indestructible blocks, but just a way to reduce damage of slow moving objects like one gear against another. I would be grateful for just an overall reduction in collision damage. Anything and everything that could be done to help me make my mods a little better would be ever so appreciated.
     
  12. the_ZJ Trainee Engineer

    Messages:
    20
    Not sure if someone came up with it already, but being able to define the amount of power consumed and the exact conditions for consumption would be really handy, didnt find anything so far.
     
  13. Nanoo Trainee Engineer

    Messages:
    2
    i would like to see tank track style blocks with a dedicated wheels / sprockets, the issues ive seen so far with the designs/mods centre mainly around the limitations of the tracks being stuck with using rotors as hinges puls the control of the auto motive drive train, im probably asking a lot, but i feel there is sufficient interest and talent for some one to take up the challenge.
     
  14. MechanizedIT Apprentice Engineer

    Messages:
    354
    I'm working on that. Check out my modpack here: http://steamcommunity.com/sharedfiles/filedetails/?id=315432320
     
  15. KhorneSyrup Trainee Engineer

    Messages:
    87
    I would like to see more customization options with Custom edges. (Mirroring, scaling, patterns, etc.)
     
  16. LowTechRider Trainee Engineer

    Messages:
    23
    I really admit that the new G-Menu is good, even better if you make it wide as the modded G-Menu
     
  17. Quegga Trainee Engineer

    Messages:
    53
    I would love to have the ability to change a texture ingame.
    Like the "Emissive" texture changes from red to green.

    So if you toggle a block, a certain texture could change from orange to blue.
    Or a texture could get transparent/invisible when you toggle a block.

    This would help me a lot with my "Stargate" mod, which needs the blue horizon made invisible when the gate is not powered.

    http://s14.directupload.net/images/140929/n9tb7g2f.jpg
    http://s7.directupload.net/images/140929/jqpnoh9r.jpg

    Thank you very much
     
  18. Amancalledme Apprentice Engineer

    Messages:
    304
    A hovercraft thruster mod.

    [​IMG]
    like this, but as a square block with a circular hole in it.
     
  19. Raikkiri Trainee Engineer

    Messages:
    8
    Since I don't have very much experience in modding, I'd just like to run an idea by the people who actually know what they are doing. My idea is to make two new blocks, A 3x3 (large ship and station only) Block that can be placed on the ground that, when turned on, emits a sphere of magnetic energy that will pull Magnetic Masses (my second block) to the center of it. The gimmicks are that the center of the sphere has to be positioned a few meters above the Mag-lift block and preferably changeable from a control panel, the idea being that you can make a turret that will stay in place, but not be restricted in movement/rotation by rotors. Also, it looks cooler and cleaner than current rotor configurations. The second gimmick is that the Magnetic Mass cannot be affected by gravity.
    While I would like to add more ideas, I don't want to drown anyone with too much information, I simply would like to know if it is possible, and if anyone would like to try building/coding the blocks.
     
  20. Shadow_Flux Apprentice Engineer

    Messages:
    433
    Hopefully Keen is still monitoring this thread; even tho it appears to have been hijacked by people making requests for mods...

    1. Who do I contact about bugs I come across, posting in the main bug report thread does not seem like the place for modders to post legit stuff.

    Maybe we can get a modder only thread going just for issues. Would be a simple thing to add a new catagory / rank like admins have; then restrict access.

    Anyway the issue I have is the collision on doors (DoorLeft / DoorRight) does not affect ships, only the astro. Now that we can make larger doors, hanger etc; however you can fly a ship strait thru them.
     
    Last edited by a moderator: Oct 2, 2014
  21. Nilat Apprentice Engineer

    Messages:
    290
    Forget what I said, custom piston top part are working. I simply forgot that changing <TopPart> wouldn't affect already existing top parts
     
  22. Vdragon Apprentice Engineer

    Messages:
    326
    A way to disable shadows and diffuse lighting on models.
     
  23. DiscordedMuffins Trainee Engineer

    Messages:
    2
    I have had an idea that wouldn't specifically be expected to be implemented into the game by the devs as such, but I personally would like to be able to use in the game. The idea in question is a simple block preferably 1x1x1 that has an extremely large energy input but has no visible output. Essentially a power drain that would be attachable to ships as a form of sabotage either by wiring them into parked ships manually to drain almost all the ships power or by using them in weapon format, attaching the drain to a ships access point (e.g. Connector or merge block) to use up most of the ships power supply, leaving its thrust and defensive capabilities hindered and handicapped. I can imagine this would be very simple to mod into the game and I am starting to delve into modding myself so I'm suggesting this either as an idea for a modder here to take ahold of and develop into their own mod or a basic starting point for my modding future. What does anyone think here? A decent basic mod to start off with?
     
  24. GraphicsAndBeer Apprentice Engineer

    Messages:
    132
    Not sure if someone has said this, but a flat plate like a catwalk that is a landing pad (same settings as a landing gear).
     
  25. Vdragon Apprentice Engineer

    Messages:
    326
    dun can't read title yo.
     
    Last edited by a moderator: Oct 8, 2014
  26. moroder Apprentice Engineer

    Messages:
    170
    So currently, from a modAPI standpoint, I've found the top modding needs from my experience to be:
    • Expose properties in the game UI! All top script mods right now have to abuse ship/block names to 'get parameters' from a user. The UI could support a limited range of types (int, string, float, IMyCubeBlock, IMyCubeGrid, stuff like that) and provide the proper input fields for them.
    • Actual debugging tools -- in-game object inspection and proper logging, for starters (not just to a file, but streaming/filtered ingame), ideally towards breakpoints, watches, visual indicators (allow code to draw a debug dot/line in the 3D world to help debug)
    • New, custom blocks instead of overriding existing ones
    • Ongoing expansion and simplification of the API (less objectbuilder indirections, better access to havok, etc) and expansion of the whitelist
    • A better MoveAndRotate would be nice. It feels right, as a mod maker, to have in-world behavior be the result of in-game objects -- as opposed to 'hand of god' interventions. For example using a ship's actual thrusters as opposed to just using SetPosition(). However MoveAndRotate is a b**** to use since it overshoots in all DOFs and since the movement vector only bluntly fires thrusters at 100%.
     
  27. MechanizedIT Apprentice Engineer

    Messages:
    354
    1. Custom block sounds
    2. Effect player health and energy
    3. Ability to adjust collison damage and friction
    4. Different textures for damage values
    5. Custom grid sizes
     
  28. devanmedrow Trainee Engineer

    Messages:
    40
    Modder setting to restrict what a control panel is able to do. Then a tab or other ability in K-menu to set what a control panel is able to do (inside of the restrictions set by modders). This tab or other would be adjustable buy the owner of the block only. This would allow you to share a cockpit for the weapons with the faction with out letting them drive the ship.
     
  29. Greken Trainee Engineer

    Messages:
    5
    performance enhancing mod by removing wasted polygons?
     
  30. antarcite Trainee Engineer

    Messages:
    86
    Sugestion:

    SENSORS WITH MORE RANGE TO CREATE CO-OP SCENARIOS FOR SURVIVAL GAMEPLAY


    Hi

    I like to make a suggestion of a mod for sensors. More range to sensors in order to make co-op scenarios with NPC enemy's.

    I'd like to make scenarios with some enemy/NPC bases to play in survival mode with my friends, so i ask a mod who give more range to sensors, in this way i can build a enemy bases who will ACTIVATE[​IMG] their defenses only with players in range, when there is no players on vincity, the base is in sleep mode. When players are close to the station, defense system turn on and fight until is there no players in vicinity.. 50 max range is not enough..

    I could use solar panels, but is not a good idea, because players can destroy it and come later and station have no power.
    I could put many uranium lingots, but is not a good idea so.. survival mode could take mutch time and i don't want in survival mode players get unrealistic amount of uranium when scavenge, or attack a base with no power for turrets.

    I just need more range in sensors, not just 50 but 200, 300, 500.. or more

    Thanks for help....
     
Thread Status:
Not open for further replies.
This last post in this thread was made more than 31 days old.