Jump to content

Tiron

Members
  • Posts

    939
  • Joined

  • Last visited

Everything posted by Tiron

  1. I prefer NOT building them myself, but found it preferable to having to use out of date versions of the mods. And actually, after getting about 1/3rd of the way through the files, I got bored and decided to do something else instead. Namely, the first 10 seconds or so of glancing at the code for your version of SSRPM enabled me to figure out how you got it to work as a drop-in on the pre-built release of RPM: you changed the RPM project reference to referencing the pre-built RPM dll instead. (I should've thought of that.) So I installed release RPM, used your SSRPM, and then used the same trick on MechjebRPM to get it to work as a drop-in. It *seems* to work, but I'm in the process of inquiring if I applied the fix correctly. And yeah, it's pulling the version # through sharedassembly.cs somehow; your SSRPM has a ver of 0.0.0.0, for example. SA.cs only specifies the first two fields, however. I don't know where it's getting the 3rd and 4th, but they're the ones that have been the problem as far as drop-in replacements (the pre-built release and the source of the release come up with different numbers in those two fields.) The version only matters when one of the .dlls is used as a reference, though, so it's the version of RasterPropMonitor.dll that matters, not the versions of SSRPM or MJRPM. As long as SSRPM is built with the same version of RPM.dll that the user has, it'll work as a drop-in. If the user's got a different version, it'll blow up (which is why it didn't work on mine originally.)
  2. Hate to reply to something so old but I was going through working on this again because of SCANsat changes and was trying to make sure I did the change correctly in mine. Because no, default RPM has *not* been updated with the name change. Better yet, it doesn't even notice there's a problem, and loads up anyway. I presume there's some form of explosion/silently failing when you actually do something that calls one of those functions but haven't really tried it. RPM's still set up for the last main release, which didn't have it yet (Mihara generally doesn't rebuild for dev versions, only main releases, because too much work.) It also hasn't been updated to SCANsat v6, despite that having gone fixed version numbers as well as having a real release. I think Mihara might be away. I'm trying a trick based on what the SCANsat guys did to make a fixed version of SCANsatRPM.dll work as a drop-in to get a fixed MechjebRPM.dll to do the same. Here's a code snippet that contains three of the build errors in question: if (o.referenceBody == activeJeb.target.Orbit.referenceBody) { // Simple transfer. dV = OrbitalManeuverCalculator.DeltaVAndTimeForHohmannTransfer(o, activeJeb.target.Orbit, UT, out UT); } else { dV = OrbitalManeuverCalculator.DeltaVAndTimeForInterplanetaryTransferEjection(o, UT, activeJeb.target.Orbit, true, out UT); } If I understand it right, the activeJeb.target.Orbit bits just need to be changed to activeJeb.target.TargetOrbit , correct? It builds that way, but I've gotten it to build just by changing 'Orbit' to lowercase too, so I wanted to be sure.
  3. I'll compare the two to make sure, but that's the only error it's throwing. Using dev mechjeb shouldn't really affect it, since the two don't reference each other in any way. What's probably getting it is the fact that in order to get that to work, I end up with a different version number on the main RPM plugin, which the SSRPM *does* reference. In theory, it should work building off your code directly as long as that is referencing the same version of the main RPM plugin that I'm using, which it should just from building it on my setup. Also, that pretty much confirms it. It's using a rectangular map for the little map window, no wonder it turns useless at the poles.
  4. That's odd... my designs can't even get off the runway until at least 90 m/s, usually more like 94, and I've never had the wings rip off. In fact I generally need to be going closer to 200 m/s before it becomes a serious concern (control surfaces used to be lower than that, before the fix, but never the wings.) Generally when I get a failure since 13.3 I was either trying to, messing with a modified experimental part, or doing stupid things while screwing around. The oddest one I ever had was in 13.2, and this is what happened: It actually flew fine after that, having lost only its smallest elevators, one of its smallest wing sections, some redundant fuel tankage, a pair of engines that were shut down at the time, and the speedbrakes. Losing the brakes made it hard to slow down, and I kept losing the control surfaces as a result, so it took a few tries to get it landed. The second problem was that due to the loss of the second set of engines, once it slowed down it was unable to speed back up again (those ramjets only produce substantial thrust above mach 3.) So there was exactly one shot to land. I could've done it on the first try in 13.3, though: by far the biggest problem was the control surfaces breaking off.
  5. Okay, two problems: 1.) The included SCANsatRPM.dll doesn't work in my case, possibly because I built RPM off the last full version and not the release. It seems to have some version of the same problem with RPM that it has with SCANsat itself: if the main RPM plugin doesn't have the same version number as whatever RPM it was built with, it can't find it and throws a fit. At least, I presume that's what's going on since rpm's plugin doesn't call either of the extra dlls as a reference. If so, based on my experience an included SCANsatRPM.dll isn't going to work by itself in general, because the source of the release and the pre-built version of the release have different version numbers. Why is why I said you need all three for it to work. If you update and/or SCANsatRPM/MechjebRPM, then the one you updated gets a no-match on RPM's dll. If you do the main DLL and only one of SCANsatRPM/MechjebRPM, the one you didn't update gets a no-match on RPM's dll. There's one catch/exception: every time I've built RPM from a given set of source, all three plugins come out with the same version numbers every time I build them. In theory only the main RPM plugin's should matter, but none of them change. So you only need to do all three *once* for any given version of RPM, and after that can just replace the one that needed updated. All rendered somewhat moot by the fact that neither of them should need updated all that often in future. 2.) I can't get it to build with the last couple releases of v6. I get a build error on line 566 in JSISCANsatRPM.cs. The error is 'No overload for method 'resetMap' takes 1 arguments' Here's the function, I've bolded/underlined the relevant line. private void RedrawMap() { map = new SCANmap(); map.setProjection(SCANmap.MapProjection.Rectangular); orbitingBody = vessel.mainBody; map.setBody(vessel.mainBody); map.setSize(screenWidth, screenHeight); map.mapscale *= (zoomLevel * zoomLevel + zoomModifier); mapCenterLong = vessel.longitude; mapCenterLat = vessel.latitude; // That's really just sweeping the problem under the carpet instead of fixing it, but meh. if (zoomLevel == 0) mapCenterLat = 0; map.centerAround(mapCenterLong, mapCenterLat); [B] [U]map.resetMap(mapMode);[/U][/B] // Compute and store the map scale factors in mapSizeScale. We // use these values for every segment when drawing trails, so it // makes sense to compute it only when it changes. mapSizeScale = new Vector2d(360.0 * map.mapscale / map.mapwidth, 180.0 * map.mapscale / map.mapheight); redrawDeviation = redrawEdge * 180 / (zoomLevel * zoomLevel + zoomModifier); try { localAnomalies = SCANcontroller.controller.getData(vessel.mainBody).getAnomalies(); } catch { Debug.Log("JSISCANsatRPM: Could not get a list of anomalies, what happened?"); } // MATH! double kmPerDegreeLon = (2 * Math.PI * (orbitingBody.Radius / 1000d)) / 360d; double pixelsPerDegree = Math.Abs(longitudeToPixels(mapCenterLong + (((mapCenterLong + 1) > 360) ? -1 : 1), mapCenterLat) - longitudeToPixels(mapCenterLong, mapCenterLat)); pixelsPerKm = pixelsPerDegree / kmPerDegreeLon; } Mapmode's a private integer that's been set elsewhere, but I can't find any other references to a 'resetMap' function, so I'm presuming it's in SCANsat and got changed somehow in one of the more recent versions, which is why it's blowing up (MechjebRPM has a similar problem with the last bunch of dev versions...except in that case it can't even FIND the function because its name got changed, and I already fixed it.)
  6. They all three have to be in the right folders (the two <x>RPM.dll have their own folders, the main RPM dll is with the rest of the RPM stuff), for a start. For seconds, there's the versioning kerfluffle. the SCANsatRPM.dll and Mechjeb.dll have to have been built with the same version of the main RPM project that the main RPM plugin comes from. (note that it's version NUMBER that matters, and it's subtly different between the last release and the last release's source) Each of them further has to have been built with the same version of the respective plugin that you're using. You can't mix-and-match. If you try, squad's pluginloader will go all 'that's not the right version, you can't have that.' The combined upshot is that if you're trying to use it with v6 of SCANsat and/or the dev version of mechjeb, you need to have all three plugins built from the same codebase, with the newer versions of the respective plugins (and some fixes to the code in mechjeb's case, a few function names changed between the last release and the latest dev version, even though the latest dev version now has the same version # again). Both Mechjeb Dev and SCANsat v6 were modified to insure that there won't be such a problem with this stuff...as soon as Mihara updates the main RPM build to work with the newest versions of each.
  7. You're flying too low to be doing that kind of speed, is all. The higher you go the less air pressure there is, and thus the lower the dynamic forces are at any given speed. Get up around 25 km and you can do around mach 5 or 6 depending on your engines, and not break anything unless you TRY to.
  8. it'd probably still have a higher overall terminal velocity... FAR really dramatically reduces drag in almost all cases. The problem you'd have is not so much the drag, as the fact that it'd be aerodynamically unstable. You'd almost certainly lose control of it trying to gravity turn it, and then the aero stress might very well tear it apart.
  9. I think it has more to do with the fact that they changed crossfeed from 'off' by default to 'on' by default and forgot to add the line to the .cfgs
  10. Yeah, radial decouplers having crossfeed is 'what.' Easy to fix though. Just add "fuelCrossFeed = False" to the 'part.cfg' files for the decouplers. (They're in GameData\Squad\Parts\Utility\, radialDecoupler, radialDecoupler1-2, and radialDecoupler2. Or set up a modulemanager config to do it. There's really no reason for radial decouplers to have fuel crossfeed, it can pretty much only lead to bad things.
  11. Someone on IRC has been setting up flaps on the *underside* of the wings instead of the back, and says it works very well. I don't think I could get over the weirdness of how it would look, though, so I haven't tried it. I normally just don't bother with flaps, or maybe set up a few control surfaces I'm not really using as flaps. Almost all my planes are Deltas. Exception being the big rover carrier SSTO, which used the huge B9 Transport wings. I had a fair portion of its control surfaces set up as flaps, and that seemed to work fine. Also, they configure like any other control surface. You use tweakables in the SPH to set what axes it works on and the range. You seem to be able to set up stuff to work as control surfaces *and* flaps simultaneously now, which you couldn't pre-tweakables.
  12. Also, as I said previously, they're the *stock variables* used by the unmodified game. Nobody in this thread has control over how they're named. In the unmodified game, they're not confusing at all because there's literally nothing else to confuse them with. Only MFT's addition of the ability to modify tankage on the fly makes them potentially confusing. Changing the names of the stock variables, *if even possible*, is NOT a good idea regardless of 'best practices', because you'll probably break compatibility with anything you don't personally modify to use whatever you changed it to. You'd have to insure that *every single mod including a fuel tank* was getting updated to the new variable name. In the event you found some way to make it so that the old name still worked, it'd STILL be bad, because anyone that knows the stock variable names is probably just going to use those instead of whatever you changed it to (especially as using the new one would be incompatible with stock!) The simple thing you need to understand here is that 'maxAmount' comes from Squad, who have ZERO reason to change it and every reason not to. MFT is an addon, which has to comply with stock naming conventions and rules, regardless of how confusing that can make things.
  13. It actually still does exist...in realfuels. There's no need for it in MFT because it doesn't include the cryogenic fuels or boiloff. And checking the CFG shows *two* of the KW tanks are set to Cryogenic. To fix it yourself(and thus not having to wait for Taniwha to do it) just open KW_modularFuelTanks.cfg in your text editor of choice and change 'Type = Cryogenic' to the appropriate tank type (probably 'Default' given they're set to Cryo.)
  14. I see what you're having trouble with now. The thing you have to remember here is that MFT is a mod, not part of the default game. The reason it's 'maxAmount' and not something else... is because that's what it is in the default game, which isn't designed for modifiable tanks. It's the maximum storable amount for *that particular resource*, not the tank as a whole. The default game doesn't even need to *consider* the volume of the tank as a whole, just how much of each particular resource can be held. The key thing you have to remember is that as a general rule, anything within a pair of { } brackets is self-contained. They're called 'modules' for a reason: they may affect other things, but what goes in the brackets is, as a general rule, its own thing, independent of other modules. The way to read it is as 'Tank for Resource <x>, which can hold a maximum of <y> units, and presently holding <z> units.' It may help to think in terms of a real rocket, which inside a given stage has to has a separate tank for each thing it wants to store. They may share a bulkhead to save weight, but they're independent volumes. In our case it doesn't help that there's two different types of 'tank' going on: the structural container around the outside, and the actual storage area inside it are both called 'tanks', which can be a little confusing. The total volume for the outer, structural bit you put the tanks in is defined, rather appropriately, with the 'volume = ' line, outside of the TANK{} modules...because it defines how much room there *is* for TANK{} Modules to use in the first place. It's added to the tanks with a modulemanager config file. As far as documentation goes, keep in mind that Taniwha isn't the original creator, but in fact the second maintainer *after* the original creator. He's got a bunch of other mods he works on too, and in the case of this one is mostly just taking care of it.
  15. Quite simply, they're the resource arrays for each possible resource you can put in them. The presence of the nodes indicates that it's possible to put that resource in the tank, the maxamount=0 simply means that you haven't actually added a tank for that resource. The amounts in the .cfg files are the default tank setup. If the ones set to 0 weren't present, you'd have to somehow add the node in order to change the tank setup. Changing the nodes in the file normally requires a database reload, so it's probably just a workaround because of the way KSP loads parts.
  16. As Discussed on IRC, MM .cfg for the B9 6m S2 fuselage: @PART[B9_Cockpit_S2_Body_6m] { //!RESOURCE[LiquidFuel] {} //!RESOURCE[Oxidizer] {} //!RESOURCE[MonoPropellant] {} //!RESOURCE[XenonGas] {} MODULE { name = ModuleFuelTanks volume = 2760 type = Structural } } Just to make it explicit, feel free to include it in the mod.
  17. Good News Everyone! Someone reported the problem with the new build number system on the Mechjeb Dev Builds breaking hard dependencies, and it's been changed as of build #254, so dev builds of mechjebs are now drop-ins on RPM again (Tested successfully with #255). There was a change in the name of the 'target orbit' function in one of the dev builds, so it might not work *quite* right, but it doesn't completely blow up at least. So one more RPM Rebuild and I should hopefully not have to do another one for a very, very long time. Never if Mihara stays on top of things. I also want to suggest...that it would probably be a good idea to start a new post for SCANSat v6, since you can't get it in the first post of this thread. Call it 'SCANSat continued' or something seems to be the usual solution.
  18. Good news, everyone! Someone reported the new version number system on MJ breaking hard dependencies as a bug, and as of dev build #254, they've changed it so it pulls the build ID from a different parameter, instead of the .dll's version. This means that the dev build is back to having the same version number as the last release, and thus as of #255 (I didn't test #254), dev Mechjeb is once again compatible with the pre-built RPM build. Mostly. (There was a change in the name of the 'target orbit' function that RPM needs to be updated for, unfortunately it's different between the release and the dev builds so I don't think anything can really be done there.) SCANSat V6 (aka 'the toolbar version) has also explicitly changed to using static version numbers to prevent future updates from breaking RPM compatibility. He's said that he's only going to change it in the event of a compatibility breaking update. So as soon as Mihara updates RPM's base build to use SCANSat v6, it shouldn't be necessary to rebuild it again for a version number change in SCANSat for quite some time, one presumes.
  19. You have to compile the dev version of RPM yourself. Which I do, because compiling RPM yourself is also the only way to get it to work with dev MJ.
  20. The biggest thing you can do is to use struts to stiffen whatever the wheels are attached to. It doesn't matter if the wheels are straight if whatever they're attached to flexes. (and if it does, it'll be asymmetrically because of the bug NathanKell linked, which has been around for as long as I can remember and is why it always goes in the same direction on the same plane.) I also use Multiwheels Landing gear (many versions old though they be), which have the ability to slip realistically (complete with resulting smoke clouds!) They also have a much better than average suspension, which is also helpful.
  21. I've got almost as many struts on my wings as the Wright flyer. And if I let it go on rails on the ground, they rise up out of the wings and stick out all over. Just like the Wright Flyer!!!
  22. On the RPM subject, it turns out that you don't have to rebuild all three plugins every time(at least with my setup). Apparently, any given RPM codebase spits the same version numbers out regardless of which plugins you build it with, the problem's just that the 'release' source spits out a different build ID from the official pre-built release. So you can build all three *once*, and then only have to do do the <X>RPM for whichever one changes as long as you use the same RPM code. To change RPM versions you'd have to do all three again, though. Isn't this whole thing wonderfully terrible?
  23. It turned out that either something with the intake was the source of the drag, or just that removing it lets FAR give it a drag model (although it still doesn't show a drag force indicator, so I'm not sure it did.) It also turns out FSLiftsurface turning itself off in the presence of FAR actually works, and without a FAR wing module in the file, the part in question simply loses all lift generating ability entirely. I'm working on trying to add the hacky-FAR-Wing along the lines of what you said right now, but I think I'm doing something wrong(or it's a problem with the model orientation, which I can't fix). It's constantly stalled in forward flight (crabbing unstalls it), and seems to break off quite easily (doing severe damage to the plane as it flies backwards.) For the mo' I think I might just leave it in 'no lift at all' mode. Edit: well now it's showing a drag force indicator with the intake gone, musta missed it earlier. Edit2: I'm just gonna have to write the bloody thing off. It's a neat idea and cute, but it's got major issues at the moment. The drag in level flight is fine, no big deal. Put the nose up even the tiniest bit, however, and it goes titanic. I saw it spike over 100 kN once. There's something weird with it too, because when the drag shoots up it induces a massive right roll, the combined effect of which is to make high speed, high altitude runs difficult to maintain. Oddly, the unmodified double-rotor works better than this thing, even after I've chopped it down and hacked at it. And I've *still* yet to find a way to STOL this thing other than 'stick a helo rotor on top', which is so absurd it's not even funny. TT's engines come close but there's some pretty serious issues getting everything aligned properly, which the extreme non-uniformity doesn't help(the scorpions having different thrust and a faster spool up time, for example). The fact that all the pitch vector engines only generate half thrust on the runway doesn't help, either.
  24. Oh Ferram, as it turns out, the wing-rotor thing's drag...it has ModuleResourceIntake, so it wasn't using FAR at all the entire time, as it turns out.
×
×
  • Create New...