Jump to content

jrodriguez

Members
  • Posts

    1,115
  • Joined

  • Last visited

Everything posted by jrodriguez

  1. I agree that the users should be "educated" about how to report a bug and minimun of information it must contain to be accepted. But this is not about "wishes". We need to acknowledge that since 1.0 the statement "The problem is KSP doesn't work, more or less, on win64" it is getting more difficult to probe, and each day the number of users playing on x64 is increasing. That is the reason why in my opinion, modders should know whether or not a mod is going to FAIL on x64. I said fail because as I mentioned before, I think with the smallest bug because of x64 the modder should block execution on x64, but if you cannot probe that is failing then you should have your mod enabled for x64.
  2. Hi Daniel, I know that Contract Configurator is using lets say a..."counter unfixer" to avoid the unfixer to work (I'm not sure if the developer did this on purpose, though) . I did spend some time to create a technique to hack it, but no luck yet. But I think in his last version Contract Configurator has partial support for x64. Are you using the last version https://github.com/jrossignol/ContractConfigurator/releases ? If you can try that one let me know if it is working for you. If it stills failing I will create a custom dll for you to check if it is because of the x64 check or it is related with other x64 real incompatibility.
  3. I think some modders have added the x64 protection just "in case" and because KSP is not giving official support to x64. And I'm not happy with that over defensive approach. I agree that if a modder has tested his mod for x64 and he can assert that his mod is not working on x64 then the mod should be disabled. Otherwise it should be enable by default. Let the users test your mod. You will get the feedback sooner or later about if the users are happy with your mod running on x64. And obviously you will need to test this everytime KSP is getting an update. It is painful, but I think is the way to go.
  4. haha ok, maybe the .old functionality is useful. I will implement that again as an option
  5. Thanks! I'm going to implement this feature on the next release. I will need your feedback guys about mods like this one. There are different reasons for a mod to fail once unfixed: - The mod is doing the x64 check but not to check compatibility but to do some necessary operations. - The mod had some logic related with Unity that is unsupported/buggy on x64 (during my testing with KSP 1.0.X I didn't found anything of this, however it was very common to have problems on <=0.90) About the .old backups I have decided to remove this feature because I didn't find it enough useful. Every time I'm going to unfix a GameData folder I have a backup done. If something is not working I will remove the folder and copy from the BK again. Also, using CKAN usually you will have all the mods cached and it is very easy to delete the GameData folder and install everything again. With the *.old files I'm increasing the size of my GameData folder with files which is unlikely that I'm going to need.
  6. Hi all, I have published a new release (v 1.0.1)! Changelog v1.0.1 Compatibility with KSP v1.0.x Removed the need of a KSP installation Unfixing speed improved Unfixer code (by cerebrate) integrated into the same solution. Summary of unfixed DLLs Compatibility with upgrade to Windows 10
  7. Good work! I'm pretty interested on this! Please let me know if I can help you with something . Either development or testing.
  8. I would like to try this challenge using Realism Overhaul to be more realistic. Are we allow to use it?
  9. Hi all, I'm going to publish a new version of the unfixer soon. I have found a couple of bugs. - The unfixer was not able to find my KSP installation (after upgrade to Win10) and if you are not running the unfixer from the KSP directory it will not work. I want it to work regardless of the directory. - The unfixer was using the KSP_x64_Data\Managed to resolve assemblies which since 1.0.X it doesn't exist anymore. I will change this to use KSP_Data\Managed instead. Yesterday I was playing unfixing the last version of FAR, and also the entire new Realism Overhaul package for 1.0.2. And good news, FAR is working fine (graphs, voxels, everything), and RO-RSS too!
  10. You are right! I was lying to myself thinking that I had a better performance! So it is all thanks to the x64 then.
  11. BTW Yesterday I tried the x64 version with the 4.6.4 Unity dlls, also I added the forcing dx11 non-threaded parameter. I added all the graphics mods like EVE, Scatterer, etc... and WOW! it looks amazing!
  12. @Schpulke I have been reviewing the lastest commit of ContractConfigurator https://github.com/jrossignol/ContractConfigurator/commit/eecab64ce5000390a28984493aec60a4732076a5 Done 5 hours ago 64 bit support has been added. So I bet that if you take the dlls from https://github.com/jrossignol/ContractConfigurator/tree/master/GameData/ContractConfigurator It will work But the reason why it wasn't working before was because he had a less standard check for x64.
  13. Thanks, I will try to find the code of that mod to check if it is doing something different.
  14. Hi Schpulke. I already mentioned before that the unfixer is not going to do magic I'm going to try to explain my self. Modders use different libraries from KSP, from Unity, etc. Some instructions directly or indirectly used by developers work fine on x86 but they don't on x64 platforms. Most part of the mods even those the modders have decided to block the x64 platform, work fine with x64. But some of them have issues (e.g FAR with Drag curve charts, voxels debug..etc. Tweakscale with the scale of some pods, etc) Is there any way to fix these issues? I'm not a modder but I'm a Software Engineer working with C# for the last seven years. I'm guessing that if there are alternative methods, instructions within the APIs to achieve the same results but that actually are compatible with x64 then it could be fixed, otherwise...I don't think so
  15. Yes, you just need to select your gamedata folder, it doesn't matter where the exe is. All the incompatibility popups will be removed. BTW if you are using 1.02 then you should know that there is not x64 version of KSP
  16. FAR doesn't work even with the workaround http://forum.kerbalspaceprogram.com/...ity-workaround . I think the graphs or voxels don't work with current version of Unity on x64. . Also there is a problem with Tweakscale and the pods, they don't resize properly when reset to launch. Also, I would like to remind that the unfixer only remove the x64 checks from the dlls (thanks to @Cerebrate for this), It is not doing any other magic to fix the x64 issue , so please don't expect miracles.
  17. Thanks. I need to try this! - - - Updated - - - Your welcome
  18. What do you mean with " unofficial KSP v1.0.2 64bit " is that a custom build or something?
  19. Hi! I just reviewed your figures and I think you made a mistake with circumference formula is not r^2*Pi, it is 2*Pi*R so each Kerbin Circumnavigation will be 3770 Km, and on Earth is around 40.000 Km
  20. Hi, I would like to know if it is possible (from a development point of view) to create a version of BDArmory fully synced in order to play multiplayer using DMP. If the answer is yes, my second question is how complicated it is? Thanks.
  21. Thanks Sparker! Yes I'm using the small heatshields at the top as spoilers to provide stability. Without them the SSTO is not fully stable.
  22. I think that is not very clear. I'd say the SSTO because this a SSTO challenge. My 30 tons of max payload can easily carry some kerbals to the moon and back but I can't land my SSTO on the Moon . But we are not talking here about what you can do with you payload is more about, what can you do with you SSTO right?
×
×
  • Create New...