Jump to content

FunnyBunny14

Members
  • Posts

    66
  • Joined

  • Last visited

Posts posted by FunnyBunny14

  1. I'm not sure what to think of this. KSP is stupidly mod-friendly in its current build, and unless there are some rather large changes made to the code base that will forever remain the case. 

    If that was all, though, we wouldn't be here discussing this. First of all, there's obviously the issue with mods overlapping or being outright identical to DLC content. That would likely be taken down if they ever decided to do such a thing. Which I'm kinda fine with, but also not? Mods tend to do things differently, and not everybody has money for essential and fairly simple things like parachutes (parts shouldn't be an issue, it's mostly gameplay funcitonality and DLLs we should be concerned about).

    Secondly, there's the problem where they conceivably could create multiplayer in such a way that mods would be regarded as cheats. This would easily be prevented by implementing dedicated servers in a way that mods would have to be server side too in order to be used (like in minecraft). Considering that that is by far the cheapest way to implement multiplayer, this should not be an issue... unless they want people to pay for online functionailty via subscriptions, in which case modding is most likely doomed.

    The third issue would be the notion of microtransactions. I'm not sure how they would implement it, but it shouldn't be too hard for a very determined publisher to find a way (i'm mostly concerned about multiplayer).

    Long story short, given the type of game KSP currently is there shouldn't be a problem. However, with enough time and dedication on their part this game could become a microtransaction loaded, mod-unfriendly hell. It kinda depends on which direction Take-Two wants to, well, take it in. And that, unfortunately, is something only they know.

    I kinda want to see some details now regarding SQUAD's deal with them to see how much control they can exertmover the development.

  2. Will they be looking to implement micro-transactions to the game? I really, really hope not, but considering their recent statements and track-record with things like GTA online where paying (a lot of) real money is pretty much the online way to realistically get most things, I wouldn't be too optimistic for this game's future... Sorry I couldn't be happy for you. Pretty much any other publisher would be mostly fine by me, it just so happens that is is actually one of the worst publishers out there right now in terms of consumer friendly behaviour. Micro-transactions are inexcusable in paid games. Heck, overprised DLC was bad enough, but what comes from free-to-play games should just stay there. They shouldn't be the industry standard for everything.

    Oh, and as if they really didn't have enough micro-transactions in their games yet, just an article regarding their current practices that came out this week: https://www.thetechgame.com/News/sid=11649/we-can-do-more-microtransactions-says-publisher-of-gta-and-red-dead.html

     

  3. Ah, linux. I'll probably use that next. Currently on windows 7, which has served me really well actually. But with its 'upgrades' being the ugly beast that is windows 8 or the platform on which privacy is a thing of the past (windows 10), I don't see myself sticking with microsoft for much longer. And since the apple computers are extremely expensive (for no good reason other than 'apple'), have less freedom and aren't that suited to gaming, I won't be using those either.

    I think I'll quite like ubuntu though, even if it gives me issues. And it'd better give me issues, I want to spend some nights wrestling with computers again. I didn't even know it was free until quite recently, but once I realised that it was, I was completely sold on it. And come on, who wouldn't want a penguin as the logo for their OS :P

     

  4. At the very least I would like to see a dv readout in the VAB and SPH per stage (not for jet engines though, that would a. near impossible and b. not so useful since dv in atmosphere means nothing). That information would also need to be available during flight then - not real time, just have the same readings as were given in the VAB/SPH - which could be accomplished by having the game save the dv readings from in the VAB with the craft file and then displaying it in a widget or somewhere. 

    That's very basic though, and doesn't even account for some stages being landers, satellites, etc. I know I certainly wouldn't except such a half-baked measure from Squad. But coding for real-time dv readouts and accounting for stages with engines would be a nightmare, as every time you load a new craft or trigger a stage the game would need to call up the (dry) masses of every object on the craft. Every physics frame while not in time warp (and if you're good, only while the engines are on) the game would need to check the current fuel levels, the fuel flow, the minimum fuel levels given the current configuration and stage (fuel lines are important people!), which engines are being used and probably a lot more. 

    The amount of call functions would be insane with all that going on, so the very first thing they would need to do is write some code to store most of the information for the craft in an easy to access way and then optimise it so it would only need to update the dry mass and minimum fuel levels when stages trigger or colissions occur (I forgot about those, that would not be fun). The fuel levels are already known thanks to the resource display, so that could still be separate. 

    Good luck doing that in a few days...

    Now that I think of it, it would be a good coding challenge for me. And having only a dv readout instead of the huge pile of data that KER throws in my face would be nice. Maybe I should try writing my own dv plugin...

  5. First off IMO don't know anyone would use a plugin if there is something close in stock has, I would drop Karbonite and MKS plugin and set it up all for stock but thats me and why are you removing them ?
    Karbonite is far superior :P

    It has atmospheric and particle harvesting and engines that run on Karbonite. This makes for a more interesting combination than stock. It also generally is better when running a modded game due to for example the distillers, that allow you to make other resources.

    The reason for removal of the stock parts is that the balance is completely different on them, and they would also become obsolete after all these changes.

    As for the code:

    The minimum drag is just being changed (because it was higher than the maximum for some reason). The temperature and impact tolerance are also just being changed.

    What exactly did did you mean with all the blue values?

    I'll try using the @ for MODULE and INPUT_RESOURCE tomorrow since I don't have time right now.

  6. This is a mod I am working on. It is still WIP and not nearly done.

    This work is licensed under: https://creativecommons.org/licenses/by-nc-sa/4.0/

    Source: It's only .cfg files ;)

    New

    I have implemented all the changes I wanted for Karbonite and KarbonitePlus (Karborundum). Changes mostly are just maxTemp rebalances or fixes. All drills and converters now have the engineer bonus, and have had their stats rebalanced to reflect that: power consumption has been increased a lot, and the larger converters and distillers can process a lot more Karbonite than the small ones. The larger converters only have ¾ the efficiency of the small converters though. The small parts have 1 on 1 mass conversion.

    Ore is removed, and the Karbonite ground resource got the same values as Ore previously had.

    Karborundum now also is on Moho.

    I also added Karbonite and Karborundum contracts. They can be used without having installed KRS, the folder in which all the changes for Karbonite and Karborundum are. I also added a file that *should* add contracts for Karborundum mining on Moho (This one needs testing!)

    Lastly, I have made a small pack that repurposes the stock parts to mine XenonHydrate (RadialDrill), store it (LargeTank and SmallTank), and convert it into water and XenonGas (ISRU). XenonHydrate can be found beneath icecaps (Poles on Kerbin and Duna), on Eve, on Vall, on Eeloo and occasionally in asteroids (25% chance). The reasoning for all this is that a requirement for the Hydrates to form in real life is extreme pressure and presence of water. But pressure can be created by depth, so I just chose everything with ice, or in Eve’s case, anything with a high atmospheric pressure that has a surface (sorry Jool).

    Very important!

    This all hasn’t been tested. There is a 99.99% chance that something, somewhere, did not go as it should have or that something is unbalanced.

    Major areas of testing: resource spread, asteroid mining and contracts.

    (Especially the Moho Karborundum contracts, I’m not certain if ModuleManager is doing what I want it to do).

    Future plans

    Very likely to be done:

    · Rebalancing of all Karbonite parts to match the new values if needed.

    · Adding the engineer bonus to all MKS converters and drills.

    What I would like to accomplish:

    · A contract pack for MKS

    Download

    https://www.dropbox.com/s/7ise2s4rq1rozdr/MEI%20Pre-Release%201.zip?dl=0

  7. I currently have KIS installed, and a bunch of other mods. But they all add text to the right-click menu... And, this id not a joke, some parts have menus that don't fit on the screen.

    I was thinking that maybe someone could make a mod that makes the menus smaller and scrollable, or makes it so a unity-style window pops up instead of the default one.

    Is this even possible?

  8. OpenGL doesn't render any shadows and has much less memory footprint (around 1,5GB in full res)

    DX11 is just better performing default renderer, but ATM will still not help due to DDS textures

    Also in case of OpenGL, remember to set up your AntiAliasing forced from driver software (Build in setting doesnt work with OpenGL), and disable crew in VAB/SPH, for some reason (probably due to problem with shadows rendering) they tend to lag really much. Up to 20-30fps more without them.

    Seriously speaking the game is now unplayable under DirectX without reducing texture quality, i'm astonished everyone is ignoring the memory issues. Memory leak when showing temperature indicators, memory leaks when changing scenes, basically any craft over 300 parts leads straight up to CTD.

    Don't forget memory leaks in the VAB. I gained 400 MB just by trying to place too many parts at once.
  9. This looks like it is going to be a brilliant first time using mods. Because I haven't used any parts mods before. In 0.25 not because that got updated just after I realised how everything worked, and also not in 0.90 because of the memory leak...

    But now in 1.0.2, with the help of a mod that disables temp gauges (why memory leaks, why?!) and a dds converter I can finally use all the nice mods without having my game running on a timer 'till death.

    And I am pleased to say that this mod is the only one stopping me from playing the game! Wait, no, that sounds wrong. Let me rephrase: your mod is so important to my game, that I am willing to wait for it, even though I have never used it before. That's how good this mod is.

    But I think Bill might not feel the same way about that after the "live harpoon demonstration"... Well, someone had to be on the other end of it, right? Right? Don't judge me! It's for science :P

  10. Well, I tried converting everything again, and for some reason it worked this time. Strange.

    Anyway, everything is now converted, and loading doesn't get stuck. I used the dds converter from @Lilleman by the way (http://forum.kerbalspaceprogram.com/threads/98672-WIN-KSP-to-DDS-texture-converter)

    It is simple to use, and works really well.

    The link to the working conversion: https://www.dropbox.com/s/vdzu8o7rfa4oqb3/KSPI-E%20dds%20conversion.zip?dl=0

    I think I may have somehow messed up the compressed and the non-compressed files. I was playing around with the different options the first time, but I am now using non-compressed, for all, with 100% certainty.

  11. I converted the textures to the dds format for personal use, but it actually went really well, so I decided to share it here.

    I used the dds converter for windows (http://forum.kerbalspaceprogram.com/threads/98672-WIN-KSP-to-DDS-texture-converter)

    The link to the dropbox file with all the converted textures: https://www.dropbox.com/s/pn7u2o7vzu6zlyi/KerbalFoundries%20dds%20format.zip?dl=0

  12. I thought I'd just update the textures to the .dds format myself, and upload them here. There is an issue with some engines though, the game got stuck when loading a cfg that belonged to them. It most likely has something to do with the textures, problem is, I don't always know which textures. There might also be another way to fix it besides not converting the textures, and it just seemed like the best idea to hand it 'as is' to you so you could hopefully fix it yourself.

    Memory usage is low: with only this mod installed just over 2 GB in the VAB with full settings, and with the half-res setting enabled at about 1,6 GB, so yeah... best change ever :wink:

    Oh, almost forgot the link to the dropbox file: https://www.dropbox.com/s/08ps5n4axoyvh1f/KSPI%20Extended%20in%20DDS.zip?dl=0

    Edit: Ok, so the loading problems can be fixed by not converting the textures that belong to those parts. So I managed to fix all but the aluminum hypbrid engine, since that one is just a .cfg file and I have no clue what textures it uses.

×
×
  • Create New...