Jump to content

TheSystem

Members
  • Posts

    17
  • Joined

  • Last visited

Posts posted by TheSystem

  1. 1 hour ago, NoMrBond said:

    Some people were complaining that this .dll was (the) spyware, oh well.

    Otherwise KSP already collected non-specific data (play session time/s, progress and technical info) but you could sort of control the extent (well, pick one of two options). This data would now be available to T2.

    Most of the T2 data policy involves data from a T2 account, which is not required for KSP so wouldn't apply in this case.

    Kinda, the "WHAT PERSONAL AND OTHER INFORMATION DOES THE COMPANY COLLECT?" section is taken from http://www.take2games.com/privacy/ which is specifically for their online services account, and doesn't apply for KSP because you don't sign up for a T2 account to play it.

     

     

    Funny how the people who are most outraged over this are the people who either do not understand it or didn't read it.

  2. 4 minutes ago, CanOmer said:

    Is garbage collection still an issue?

    Yes, it will be a ongoing process to optimize the game. Although KSP 1.4.0 uses a newer version of the Unity engine which I have noticed an improved multi threading load on my CPU, evenly distributed all across my cores to remove stutters I used to get on 1.3.1.

    Memory allocation and management is still a problem that will be not solved any time soon I imagine

  3. 6 minutes ago, malkuth said:

    For a quick fix for you guys missing an Internal for the Mk 1-3 Pod replace this in your Mk1-3.cfg file. Use this instead of the default Internal. (It does not exist hence the bug)

    INTERNAL { name = GenericSpace3 }

    Or you can use Name = GenericSpace1 (Variant of M 1-2)

    Or you can use Name = PodCockpit (Is M 1-2 Version)

    You can find this file located in:

    \Steam\steamapps\common\Kerbal Space Program\GameData\Squad\Spaces

    On another Note you can really use any Internal you want. But this should get you on Your way if its annoying you.

    I fixed it by using steam verify integrity of game files tool, would of done essentially this fix anyway. Nice writeup

  4. This is amazing, the updated unity engine alone is amazing for modders in the community

    Quote

    The modding community is very important to the Kerbal Space Program team, and we continue to encourage and enable mods for KSP moving forward.

    We are going to hold you to that as well. Lets see how this DLC rolls out and the hot fixes shortly after. 

    This update contains a varied amount of additions and changes which is always welcoming, I hope you keep a consistent release rollover like you have today because this is great.

    Parachutes are fun, it should have a toggle on the options when choosing difficultly to either start with parachutes or none till upgraded as it removes any threat of losing herbals. 

     

    While I keep refreshing CKAN repository for updated mods, I do want to note that commitment to the modding scene will be vital in the longevity of this game.

    Quote

     For our mod creators, please note an additional update 1.4.1 will come alongside that release and will need to be integrated as well. 

    This update is fantastic so far, I hope the DLC will bring as much stability (on newly generated worlds as old ones are a bit incompatible) to my kerbals as this did.

     

    MK2-IVA-plz-fix

  5. On 12/6/2017 at 1:43 PM, Dagger said:
     

    Github hyperlinks to 0.05 release, latest version is 0.10 https://github.com/LunaMultiplayer/LunaMultiplayer/releases/

    Discord has links to edge releases 

  6. 1 hour ago, 0111narwhalz said:

    I believe the current favorite mode is timeline fragmentation. Players may warp freely, but in doing so they're split off into their own timeline. To avoid weirdness, vessels changed in the future are "locked in" and must play through their recording. If two players wish to play in the same time, the past one syncs with the future one and everything is standard.

     

    3 hours ago, razark said:

    There's quite a few ways to implement timewarp in multiplayer KSP.  They all either involve either paradox or someone waiting, and each has its supporters.  Each one has people vehemently opposed to it, as well.  Any way it's done in KSP is going to lead to a decent number of unhappy people.

     

    3 hours ago, Kerbal pancake said:

    they just dont have timewarp

     

    These guys have fixed the issue with time syncing with subspace allocation. Anytime someone warps they are sent to a separate subspace with that offset. People can "Sync" to your time if they wish to see your vessel, or the server owner can allow people to see past vessels. Multiplayer is not impossible.

    Ms7UCNm.png

  7. On 2/3/2018 at 9:29 AM, Foxster said:

    I've said it before and I don't see anything to change my mind: The console port and Making History are mistakes. 

    The console port was a bad idea because KSP is not a game that lends itself to console systems, the interface is wrong. Plus building and maintaining another completely different code-base is a huge drain on expansion of the core game that has seen it's development grind to a halt.

    Making History is slapping on an uninteresting feature that few or no customers have looked for. Having a kind of challenge-setting or contract creation tool will have limited appeal and is not what most current players want. What has been asked for for a long time is a big expansion to the core game so that there is more to do; like reasons to explore the planets' surfaces, more planets, more challenges, more tech, more complex science, a reason for space stations and surface bases, another star system, some flavour of multi-player, realistic aero physics, things to discover like another civilization, i.e. reasons to boldly go where no Kerbal has gone before.     

    The console port and Making History feel like tweaks around the edge of a game going nowhere.

    3
    3

    I feel they are missing an opportunity to work with the dedicated fans who build the modding scene and incorporate well-designed, highly embraced mods into the game with reference to the modder in the credits as a tribute.

    The modding scene, I believe is one of the main reasons KSP has survived as long as it did as each mod provides more replayability and overall enjoyability. The game menu screen hyperlinks to the forums when it should just be working with CKAN to integrate modding seamlessly; everything you suggested has been conceptualized and worked on by a dedicated fan of the game who decided to spend hours learning KSP's API (which looks designed as an afterthought than an actual API, the docs will prove this).

    I hope they upgrade the Unity3d engine to a version with .netframework 4.0 support so developers can create mods with a surplus of functions and robust features and optimization possibilities that we have been missing out on, currently, KSP is running on .netframework 3.5 which is limiting working being done by the guys at 

    The mod is great, the guys working on it are actively pumping out fixes and things like Weapons mods kinda work-ish..... But the point is that the game could be so much better if the mods were handled better, we have a mod called ModManager that helps mods, mod... I hope people see the redundancy and inefficiency this current experience provides rather than what the game could be if the modding scene was more widely embraced with. 

    MGw5q04.png

    People have stated in this thread that memory utilization and optimization issues persist in the game; which is a contributing factor to why the next update should have .netframework4 https://blogs.msdn.microsoft.com/pfxteam/2008/10/10/parallel-programming-and-the-net-framework-4-0/

    Task Parallel Library alone would improve multicore performances on machines, considering KSP is running on a CPU based game engine I would imagine the additional support for parallelism, the Managed Extensibility Framework for further mod compatibility and stability (less crashes and faster startup times). This is without even mentioning Managed Profile Guided Optimization.

    Not only that but the asynchronous modules and handlers that 4.0+ provides would provide a smoother multiplayer experience, which I'd personally enjoy so I have a little stake in having everything updated. And Dual-mode socket support.

     

    Back to the quote:

     " like reasons to explore the planets' surfaces, more planets"

    "realistic aero physics"

    "another star system"

    "Reasons to boldly go"

    "discover like another civilization"

     

    It's silly to think we have all these great tools, yet heavily un-utilized in the grand process.

    On 2/4/2018 at 3:34 AM, panarchist said:

    That's kind of how I feel, too - but I'm not a console player, so it's different for me. Also, I've owned KSP for almost 6 years, and started with 0.17 before there was even docking - so from my perspective, pretty much every feature I was looking for is in the stock game, except for Life Support and a Delta-V indicator. And there are plenty of mods to give me those features now.

    I can understand the console owners' frustration, though - as mentioned up-thread, KSP doesn't lend itself well to those platforms.

    1

    "And there are plenty of mods to give me those features now. " Console release had an array of missing features and stability issues that while modding, in general, would not solve. But simply providing console version with the tools needed to run using everything provided by Microsoft hardware, which certainly would have been compatible with net framework 4 for that multicore support, the experience would have been an improvement to the one we received.

    This also highlights the replayability factor modding provides a game. 

    On 2/3/2018 at 10:21 PM, klgraham1013 said:

    Actually not the worst idea.  It's not the game i would have made, but it feels pretty finished.  Thanks to the great mod support, I'm able to play the game i want.  I actually thought 1.3 would be the last major update we would see, and wasn't to upset about it.

    Maybe they will allow us to script our own missions? That would be a nice compromise to having the same mission constantly and providing a replayable game.

    On 2/3/2018 at 4:53 PM, Foxster said:

    I don't think that is the case. 

    Blitworks would not have been able to port KSP unaided, it would require considerable input from the designers, developers and testers of the original game and the weekly news suggests this is the case.

    Then the bigger issue is ongoing development and maintenance. Squad cannot now develop something for the other platforms that can't be also made to work on a console and every new feature will require porting. This means that only the lowest common features will be implemented and if something won't work on the console it is not going to happen on the PC etc.

    Plus everything will need to be duplicated and tested (and certified) on all platforms. This will put a big crimp in the development of new features. 

    Take it from some someone who has managed computer systems across multiple platforms: It is a pain in the rear and to be avoided wherever possible, which Squad should have done. 

    I think this quote highlights the limitations of a small dev team, attempting to work on a project that is quickly becoming cumbersome and falling into a trap where the game development is being interjected by Bug Fixing and catchup patchwork, which is highly speculative with only bases on the weekly posts provided by the staff team and the updates provided by SteamDB which can monitor the changes in depots (scratchpad_3 started getting updates before Christmas and has not really stopped since the holiday): https://steamdb.info/app/220200/history/

    lZJfsyT.png

    They are updating the QA builds as they said, they certainly are not lying, but there is no way to find out for sure how active development is at the studio as the depot is obviously passworded and therefore hashed to the public:

    3wQVKD8.png

    They could just be actively updating textures, we don't know unless someone at the team blogs about it... More transparency would be grand.

    If the posts provided by the staff contained insight into the actual sprint timetable they are working on or provide an active bugtracker which allows the ability for those who have dedicated time providing mods and support for this game to maybe contribute and provide help with the core mechanics that the team are having issues implementing or design on, which the team feels the need to keep hidden and provide illusive timetables at the expected time. I understand why the team do not want to state on the record a fixed date, but I feel its unfair for the community to be expected to feel excited about this: https://imgur.com/a/gWp4b

    when the team could have easily messaged @linuxgurugamer and @DMagic for an agreement to add these to the update:

     

     

    Those EVA suit textures need time to test... 

    At least the team confirmed that the kerbals will have new heads 

     

    Also spending time modeling new sizes of models instead of working with @starwaster or even just take notes from his code to scale up the number of objects in the game without the need to spend time on each size of the model.

    I believe these criticizations of our beloved game is fair as I don't want to see the game fail at becoming something spectacular.

     

  8. EDIT: Plugin help fullfilled

    I have decided to create a plugin that hooks into your Discord via RPC which allows KSP to send status updates for Rich Presence on Discord. The idea being, if you are orbiting the muun, or crashing spectacularly, or boosting at a certain altitude or joining a Multiplayer KSP  with DMP, then people on discord will know. The idea being RP will update with images of what moon/planet you are nearest too or what server, if you are using MP then a connection can appear on discord client.

    [Info on Rich Presence]

     https://discordapp.com/developers/docs/rich-presence/how-to

    Credit is given to nostrenz for base idea, standalone RPC version here: https://github.com/nostrenz/cshap-discord-rpc-demo

    It seems for RPC to work I need to have a compiled RPC client in the GameData/<mymod/plugins/ folder with my mod for it to function, I have used DLLImport and the compile works flawlessly, unfortunately, nothing posts to the console log when using Debug.Log and my plugin does not update my status with the vanity statuses set in MainCord.cs

    https://imgur.com/RJdYE07

    I've made my project publically accessible if you are feeling up for helping out a noob:  https://github.com/4669842/KSPCord-1.3.1 You will need to add this DLL for RPC Discord to your compiled version: https://github.com/nostrenz/cshap-discord-rpc-demo/releases (hope to merge into one)

    IDE is set to framework 3.5, VS says there are no compile issues.

    For now, I hardcoded the ClientID as I only need a single app to access discord but once I learn how to create nodes and assign key value pairs I can allow others to host their own apps on discord if needed (Once this actually works)

     

×
×
  • Create New...