Jump to content

Now-defunct-thread-that-should-not-appear-in-google-search.

Cilph

By Cilph
in KSP1 Mod Releases

 Share

Recommended Posts

erendrake

erendrake

Posted
Posted
Not every one wants to use KOS and a fight computer is a flight computer MJ , KOS , and all the rest.

Of course not everyone wants to use kOS. The reason i bring it up is because kOS has some kind of integration with RemoteTech that works. Mechjeb does not and shows no signs of adding one.

Link to comment
Share on other sites
Mecripp

Mecripp

Posted
Posted
Of course not everyone wants to use kOS. The reason i bring it up is because kOS has some kind of integration with RemoteTech that works. Mechjeb does not and shows no signs of adding one.

Didn't think kos integration was in now last, I seen there was 2 forks of kos and he was waiting to see what fork was going to win, I guess you could say.

Link to comment
Share on other sites
erendrake

erendrake

Posted
Posted
Didn't think kos integration was in now last, I seen there was 2 forks of kos and he was waiting to see what fork was going to win, I guess you could say.

No other fork of kOS has ever had a release since Kevin's last release in 2013, and his mod release thread OP points to the new kOS.

RemoteTech doesnt integrate with kOS. It is the other way around. The nature of RT is a command blocker so when other mods issue commands RT intercedes unless it is called off through RTs API.

That API needs some love before it will be friendly to use by anyone.

Link to comment
Share on other sites
Drew Kerman

Drew Kerman

Posted
Posted

Update: It works when I'm entering a burn time (in seconds), it simply does not count down m/s! Any ideas what I'm doing wrong when entering m/s? Or can I somehow determine the burn time based on thrust, mass and dV needed? That would work for me until the new release hopefully fixes what I suppose to be a bug since I've seen someone entering m/s values in one video.

Update 2: And I know why!

while Hotrockets changed my engines to ModuleEngineFX and so we multiply by 0 resulting in an everlasting burn.

Conculsion: I would happily compile it myself wiith that fixed if someone could point me to the source in question (I know about Cilphs GitHub repo but I don't think that's the one with the community patch)?

Update 3: never mind, I simply decompiled the whole project and patched it back together. Bug fixed, flight computer working as intended (rough attitude control but it does what it should do).

yea the m/s burn was bugged with 0.23.5, it's been a known issue but you're the first to actually look at why. Makes sense, I think ModuleEngineFX is a base-level change to the game by Squad for 0.23.5 - nothing to do with HotRockets except that mod properly updated to account for the change.

Soooo, you going to keep this to yourself or release your hotfixed version so I (and others) can shower you with rep?

Link to comment
Share on other sites
marce

marce

Posted
Posted (edited)
yea the m/s burn was bugged with 0.23.5, it's been a known issue but you're the first to actually look at why. Makes sense, I think ModuleEngineFX is a base-level change to the game by Squad for 0.23.5 - nothing to do with HotRockets except that mod properly updated to account for the change.

Soooo, you going to keep this to yourself or release your hotfixed version so I (and others) can shower you with rep?

Ah I see. Yes, afaik ModuleEngineFX is a Squad change and yes HotRockets "only" updates the configs.

I can certainly provide my dll, but I have to warn you (and everyone who wants to use it): since I decompiled the dll instead of cloning the source (I was to lazy to figure out which fork or commit is the right one) there are some very creative constructs in the code like

(object) (bool) (flag ? 1 : 0)

which I fixed insofar that it now compiles but still boxes the bool since I didn't want to check if that's maybe needed somehow somewhere. That's just an example, there are a few more... crazy touches :wink:

Everyone who has ever written one line of code will know what I'm talking about. The bug "fix" itself is also veeeery sloppy!

So: yes it works for me, but it may be a bit less performant if the compiler didn't optimized all those flaws and here be dragons!

Don't blame me if your probes implode, you have been warned... DOWNLOAD

Edit: here the crappy source as requested. I'd still heavily recommend to look at the clean source at GitHub.

Edited by marce
added crappy source
Link to comment
Share on other sites
erendrake

erendrake

Posted
Posted
you have been warned... DOWNLOAD

Just FYI mods will very often remove links to dlls that dont include source. I am only saying something to keep it from being taken down :)

I will say that the new FX module makes for a lot of crappy looking code :P

Link to comment
Share on other sites
marce

marce

Posted
Posted
Just FYI mods will very often remove links to dlls that dont include source. I am only saying something to keep it from being taken down :)

I will say that the new FX module makes for a lot of crappy looking code :P

Well, as I said it's just the RemoteTech2 source in a veery crappy decompiled version with a copy-paste-and-rename second loop. There's not even a folder structure :wink:

But I uploaded it as well to please all mods out there.

Link to comment
Share on other sites
undercoveryankee

undercoveryankee

Posted
Posted
yea the m/s burn was bugged with 0.23.5, it's been a known issue but you're the first to actually look at why. Makes sense, I think ModuleEngineFX is a base-level change to the game by Squad for 0.23.5 - nothing to do with HotRockets except that mod properly updated to account for the change.

Soooo, you going to keep this to yourself or release your hotfixed version so I (and others) can shower you with rep?

ModuleEnginesFX was in 0.23, but Squad only used it for the RAPIER in that version. HotRockets started using it more widely and broke a lot of mods in the process.

Now that Squad is using it on the NASA engines in 0.23.5, more mods are getting the hang of dealing with it.

Link to comment
Share on other sites
Kevin_010

Kevin_010

Posted
Posted

I tried to find the source for the community hotfix, was unsuccessful, tried to apply the mentioned patches from the mentioned git repositories, and they don't fix the bugs in remotetech, and the person who released the hotfix never answered my message about the source. Yours is probably the only reference available, despite being a decompiled mess. props for going through the effort to do that, I just haven't been using remotetech since .23

Link to comment
Share on other sites
druidjaidan

druidjaidan

Posted
Posted
Alright, can do that!

Actually it's a very very simple ship since I'm currently trying to get my very first RT comsat into orbit. I also avoided RO/RSS for the moment, so everything is quite stockalike with the exception of some procedural tanks.

The ships has about 25t (first stage still has some fuel left, the probe itself is ~2t I think). Currently the stock Skipper engine of the first stage is in use.

No throttle limiter in use.

I tried to enter all data manually: 30s before node turn prograde, 5s before node start burning 181.2m/s at full throttle. The vessel stayed at prograde perfectly fine during the burn, but again, it simply didn't cut off the engines but kept burning forever :(

Here is a screenshot of my (over-winged) test vessel with vessel info, node info at the navball and my manual flight computer settings (RCS now turned off, different time settings then before but everything else is the same):

And after getting the dV needed down to 0 it just keeps burning forever resulting in ever increasing dV indicator at the navball:

From KSP.log (the burn messages at the end are going on forever until I killed KSP actually there are no further messages but it continues to hold the prograde direction and stays throttled up):

[LOG 18:53:28.618] Mode: Hold OBT Prograde
Signal delay: 0.00s + 0.04s
[LOG 18:53:28.618] Burn 100.00 %, 181.20m/s
Signal delay: 0.00s + 19.61s
[LOG 18:53:28.635] Mode: Hold OBT Prograde
Signal delay: 0.00s + 0.02s
[LOG 18:53:28.636] Burn 100.00 %, 181.20m/s
Signal delay: 0.00s + 19.59s
[LOG 18:53:28.646] Mode: Hold OBT Prograde
Signal delay: 0.00s + 0.01s
[LOG 18:53:28.647] Burn 100.00 %, 181.20m/s
Signal delay: 0.00s + 19.57s
[LOG 18:53:28.664] Mode: Hold OBT Prograde

[LOG 18:53:28.665] Burn 100.00 %, 181.20m/s
Signal delay: 0.00s + 19.55s
[LOG 18:53:28.682] Burn 100.00 %, 181.20m/s
Signal delay: 0.00s + 19.54s
[LOG 18:53:28.699] Burn 100.00 %, 181.20m/s
Signal delay: 0.00s + 19.52s
[LOG 18:53:28.716] Burn 100.00 %, 181.20m/s
Signal delay: 0.00s + 19.51s
[LOG 18:53:28.726] Burn 100.00 %, 181.20m/s
Signal delay: 0.00s + 19.49s
[LOG 18:53:28.747] Burn 100.00 %, 181.20m/s
Signal delay: 0.00s + 19.47s
[LOG 18:53:28.765] Burn 100.00 %, 181.20m/s
Signal delay: 0.00s + 19.46s
[LOG 18:53:28.783] Burn 100.00 %, 181.20m/s
Signal delay: 0.00s + 19.44s
[LOG 18:53:28.800] Burn 100.00 %, 181.20m/s
Signal delay: 0.00s + 19.42s
[LOG 18:53:28.817] Burn 100.00 %, 181.20m/s
Signal delay: 0.00s + 19.41s
[LOG 18:53:28.828] Burn 100.00 %, 181.20m/s
Signal delay: 0.00s + 19.39s
[LOG 18:53:28.848] Burn 100.00 %, 181.20m/s
Signal delay: 0.00s + 19.37s
[LOG 18:53:28.866] Burn 100.00 %, 181.20m/s
Signal delay: 0.00s + 19.36s
[LOG 18:53:28.883] Burn 100.00 %, 181.20m/s
Signal delay: 0.00s + 19.34s
[LOG 18:53:28.901] Burn 100.00 %, 181.20m/s
Signal delay: 0.00s + 19.32s
[LOG 18:53:28.918] Burn 100.00 %, 181.20m/s
Signal delay: 0.00s + 19.31s
[LOG 18:53:28.935] Burn 100.00 %, 181.20m/s
Signal delay: 0.00s + 19.29s
[LOG 18:53:28.973] Burn 100.00 %, 181.20m/s
Signal delay: 0.00s + 19.27s
[LOG 18:53:28.990] Burn 100.00 %, 181.20m/s
Signal delay: 0.00s + 19.24s

Update: It works when I'm entering a burn time (in seconds), it simply does not count down m/s! Any ideas what I'm doing wrong when entering m/s? Or can I somehow determine the burn time based on thrust, mass and dV needed? That would work for me until the new release hopefully fixes what I suppose to be a bug since I've seen someone entering m/s values in one video.

Update 2: And I know why! Since I don't know where the src for the "community patch" dll is I quickly fired up dotPeek and looked at the burn command.

else if (this.DeltaV > 0.0)
        {
          fcs.mainThrottle = this.Throttle;
          this.DeltaV -= (double) this.Throttle * FlightCore.GetTotalThrust(f.Vessel) / (double) f.Vessel.GetTotalMass() * (double) TimeWarp.deltaTime;
        }

This would be quite fine, if not FlightCore would be looking for ModuleEngines

public static double GetTotalThrust(Vessel v)
    {
      double num = 0.0;
      foreach (ModuleEngines moduleEngines in Enumerable.SelectMany<Part, ModuleEngines>((IEnumerable<Part>) v.parts, (Func<Part, IEnumerable<ModuleEngines>>) (p => (IEnumerable<ModuleEngines>) p.FindModulesImplementing<ModuleEngines>())))
      {
        if (moduleEngines.EngineIgnited)
          num += (double) moduleEngines.maxThrust;
      }
      return num;
    }

while Hotrockets changed my engines to ModuleEngineFX and so we multiply by 0 resulting in an everlasting burn.

Conculsion: I would happily compile it myself wiith that fixed if someone could point me to the source in question (I know about Cilphs GitHub repo but I don't think that's the one with the community patch)?

Update 3: never mind, I simply decompiled the whole project and patched it back together. Bug fixed, flight computer working as intended (rough attitude control but it does what it should do).

Thanks for your help!

You are [word we don't say on the forum] awesome. This is the bug I tried reporting a few pages back. I looked at the source as well and it all looked in order. I didn't think about HotRockets causing the module to change.

Also...the source is available on Github: https://github.com/Cilph/RemoteTech2

Link to comment
Share on other sites
druidjaidan

druidjaidan

Posted
Posted
just write Cilph a PM, he was online yesterday. RT2 should not die because of a lack of communication.

https://github.com/Cilph/RemoteTech2/issues/241

Cliph isn't providing it so far. I've been considering forking the project myself I'd like to work on it a bit, but if he really has this massive rewrite that the other devs want to work on there is little point in getting started on the current one. It's kinda frustrating, I want to help get this project moving along myself, but without the "current" source it kinda ties everyone's hands. I'm not sure I see any huge issues in the existing source that we could just fork from what is on github and run with it, but as I don't think that Cliph will even be processing pull requests I don't see a reason to try to commit time to it until things have been worked out.

Link to comment
Share on other sites
druidjaidan

druidjaidan

Posted
Posted
I tried to find the source for the community hotfix, was unsuccessful, tried to apply the mentioned patches from the mentioned git repositories, and they don't fix the bugs in remotetech, and the person who released the hotfix never answered my message about the source. Yours is probably the only reference available, despite being a decompiled mess. props for going through the effort to do that, I just haven't been using remotetech since .23

here is the PR that represents the community hotfix https://github.com/madadam/RemoteTech2/tree/quick-and-dirty-fix

Link to comment
Share on other sites
marce

marce

Posted
Posted
You are [word we don't say on the forum] awesome. This is the bug I tried reporting a few pages back. I looked at the source as well and it all looked in order. I didn't think about HotRockets causing the module to change.

Also...the source is available on Github: https://github.com/Cilph/RemoteTech2

Glad it's useful!

Yes I know about the GitHub repo, but the last commit of Cilph is the Christmas update while the version we are all on is the late Christmas community fix edition. Someone mentioned that it's based on a fix for issue #189 iirc. I even looked through this issue's thread, but there are so many people trying to fix it in various forks and multiple commits that I quickly gave up to look for the actual most current and stable version.

Link to comment
Share on other sites
Alewx

Alewx

Posted
Posted

Great so that does in fact mean: big chaos about "stable" version, unclear repository and no dev anywhere near or soon, that makes the mod dead. :(

That is really disappointing.

Link to comment
Share on other sites
Storywalker4

Storywalker4

Posted
Posted (edited)

Relay setup question: I have a 4-sat main relay set up, but only to track active vessels, I'm sending up more and aiming them at the Mun. To have full view of the Mun at an orbit of roughly 300k do I only need two sats at roughly opposite positioning or three sats? Also, where's the planetary threshold between 60 Gm and 350/400 Gm? And how far will the stock 40 Gm go?

Update: Ya, only needed two, but my other questions still stand

Edited by Storywalker4
Link to comment
Share on other sites
Metalsand

Metalsand

Posted
Posted
Is it installed correctly? GameData/RemoteTech/ not somewhere else. Do you have one and only one copy of ModuleManager in your GameData folder? And if you're in career mode have you actually unlocked the dishes in the R&D center?

It's a common bug in R&D; a bug I've been trying to figure out how to fix in my install. From what I've seen, sometimes the game does not even generate /GameData/RemoteTech2/RemoteTech_Settings.cfg and one time that I deleted it in an install with a similar problem it suddenly worked: but another KSP error forced me to reinstall. What's weirder is that glossing over both files, there weren't any giant chunks of data missing, it looked like it was more or less the same. It's not like it randomly started working independant of that file being replaced (as I had previously spent HOURS restarting KSP attempting to find the error) but still...it's weird.

Oh, and if you are curious, the error is:

-RemoteTech 2 exclusive parts do not show up in VAB or SPH. Not in the tech tree, not available for vehicles, nowhere no how. It goes so far as to even say that they don't exist, and that vehicles made with them have invalid parts. Sandbox works perfectly fine.

-HOWEVER, any ships already launched with said parts (in career mode) will retain them, and I even loaded up a ship that still had it's communication dishes, it mostly appears that the game *thinks* that they are an item that doesn't exist for selection purposes, but not for gameplay.

Link to comment
Share on other sites
Metalsand

Metalsand

Posted
Posted

Messing around with it more, the tech tree mod appears to automatically detect new tech tree stuff whenever mod files are modified and request a restart for update. The mod is TreeLoader (required for Interstellar and several other mods in Career mode), perhaps some sort of possible conflict, if the mod AND TreeLoader are both recognizing the updates, and interfering? It's a possibility albeit slim.

Link to comment
Share on other sites
druidjaidan

druidjaidan

Posted
Posted
Great so that does in fact mean: big chaos about "stable" version, unclear repository and no dev anywhere near or soon, that makes the mod dead. :(

That is really disappointing.

I wouldn't necessarily go that far.

The great thing about open source and in particular when combined with github is it's pretty easy for someone to pick it up and run with it:

https://github.com/Jaidan/RemoteTech2

That has the the burn time fixes provided by both marce (I even de-uglified it) and the hotfix from madadam. Now the artwork isn't under an open license so actually providing a packaged mod isn't really allowed without permission from the creators of the artwork.

I think there are enough people interested to keep it alive. The real issue is that Cliph has hinted at an existing rewrite(which could be a good thing I don't know what/why his motivation for the rewrite was), which has made people super hesitant to do anything other than hack hotfixes into place. I mean the hotfix from madadam doesn't actually try to fix the issue, it just comments out a performance enhancement and replaces it with recalculating the same value potentially multiple times.

I wouldn't expect anyone to bother with a 0.23.5 release. If any major issues or fixes come up I'm sure the community can come up with patched dll's. I'll likely merge any fixes that look completely baked just so I can keep a stable copy myself. If Cliph hasn't come forward with the rewrite by 0.24 I would expect someone to really try and take point, but what is out there now works.

Link to comment
Share on other sites
marce

marce

Posted
Posted
I wouldn't necessarily go that far.

The great thing about open source and in particular when combined with github is it's pretty easy for someone to pick it up and run with it:

https://github.com/Jaidan/RemoteTech2

That has the the burn time fixes provided by both marce (I even de-uglified it) and the hotfix from madadam. Now the artwork isn't under an open license so actually providing a packaged mod isn't really allowed without permission from the creators of the artwork.

I think there are enough people interested to keep it alive. The real issue is that Cliph has hinted at an existing rewrite(which could be a good thing I don't know what/why his motivation for the rewrite was), which has made people super hesitant to do anything other than hack hotfixes into place. I mean the hotfix from madadam doesn't actually try to fix the issue, it just comments out a performance enhancement and replaces it with recalculating the same value potentially multiple times.

I wouldn't expect anyone to bother with a 0.23.5 release. If any major issues or fixes come up I'm sure the community can come up with patched dll's. I'll likely merge any fixes that look completely baked just so I can keep a stable copy myself. If Cliph hasn't come forward with the rewrite by 0.24 I would expect someone to really try and take point, but what is out there now works.

Aah, excellent!

Yes that was my feeling too: we hope that Cilph comes up with a nice rewrite when 0.24 arrives. If not I'm very confident that there will be enough volunteers to clean up the current version and enhance it in the future.

@Alewx: RT is one of the big KSP mods and there are enough users with good enough skills to keep it alive, don't worry :)

Link to comment
Share on other sites
Cilph

Cilph

Posted
  • Author
Posted (edited)

I put my source online: https://github.com/RemoteTechnologiesGroup/RemoteTech

Handing over the reigns to Amaroq. I hope he can get a community developed continuation going. So if you're interested in contributing, go ask him.

Not that I can make demands, but I'd prefer if the code was kept modular and testable, so that it can perhaps be used as an example for other future modders.

RemoteTech 0.22/0.23 will not be on Curse as I don't approve of them, but do whatever you like for the next version. Putting the releases on github via either their release system or static webpage would be a nice way.

Peace.

Edited by Cilph
Link to comment
Share on other sites
marce

marce

Posted
Posted
I put my source online: https://github.com/RemoteTechnologiesGroup/RemoteTech

Handing over the reigns to Amaroq. I hope he can get a community developed continuation going. So if you're interested in contributing, go ask him.

Not that I can make demands, but I'd prefer if the code was kept modular and testable, so that it can perhaps be used as an example for other future modders.

RemoteTech 0.22/0.23 will not be on Curse as I don't approve of them, but do whatever you like for the next version. Putting the releases on github via either their release system or static webpage would be a nice way.

Peace.

Hey man I'm sorry to hear that you are abandoning ship, hope you aren't gone completely :(

I really appreciate your work and didn't had the intention to press you, hope you don't have that impression!

Link to comment
Share on other sites
Cilph

Cilph

Posted
  • Author
Posted (edited)

So it turns out Amaroq might not be present anymore. Would all parties interested in taking over the project contact me over PM so that we can sort something out over the coming week? Hoping to make this community developed, but it would require one or more people coordinating everyone. Of course, if Amaroq shows up and is willing, all is well.

Edited by Cilph
Link to comment
Share on other sites
Alewx

Alewx

Posted
Posted
So it turns out Amaroq might not be present anymore. Would all parties interested in taking over the project contact me over PM so that we can sort something out over the coming week? Hoping to make this community developed, but it would require one or more people coordinating everyone. Of course, if Amaroq shows up and is willing, all is well.

Don't say noone took the step?

Link to comment
Share on other sites
Guest
This topic is now closed to further replies.
 Share
Go to topic listing
×
×
  • Create New...