DMagic

The version 1.0 update is mostly working. The actual map-breaking bugs have been fixed and are relatively minor. Resource integration is fairly simple and seems to be working ok. Map overlays are working the same as before, though I'd like to get to the point where I can override the stock planet overlay so that easy-mode scanning can be disabled. One immediate issue that I've noticed is that not all overlay types actually seem to match up. Only the dot grid overlay seems to actually be accurate. The poles have very high Ore density, but they don't show anything using the line or blob overlay. There are other differences visible as well when switching between the different modes, but the dot grid seems to be consistently more accurate. The SCANsat map overlay is working the same as before. Regular SCANsat functions also seem to be OK (a minor tech node adjustment is needed) and MechJeb integration works with 2.5. Hopefully I'll have something ready by the weekend.

Yeah, I saw. That's disappointing, since I swear we saw some previews of new Duna biomes at some point. There have been a few changes to how science experiments work, but nothing that requires major changing. The actual bugs have been fixed, I just need to run through everything, especially the contracts and probably some asteroid experiments to make sure they are still working.

Did you have the "Alter Active Contracts" option turned on when you started adjusting the sliders. If you have it turned off, then move the sliders around, then turn it on and start moving the sliders weird things will happen (really it just doesn't have any way of "remembering" what the previous settings were). You should either turn that option on or leave it off, don't fiddle with it, as is stated in the instructions in the first post. To fix it, you can turn off the active contracts option, reset the science slider to 100%, then turn it back on, then you should be able to adjust the values and get results that make sense. You can essentially exploit the system doing this, getting nearly infinitely large rewards, but you might as well just use the cheat options if you're going to do that.

I'm going to need more information than this. What version? What version of KSP? The buttons on the left are red? that's the way they are supposed to be. Did you click on any of the Offered/Active/Completed buttons?

Probably doesn't work, orbit overlays will have problems, but I haven't actually checked anything.

KSP 1.0 seems to solve the external experimental deployment issue. ModuleScienceExperiment now has an EVA deploy experiment KSPEvent that should allow for the type of science experiments that you want.

It looks like there are a few interesting new additions to ModuleScienceExperiment. usageReqMaskInternal = 1 usageReqMaskExternal = 8 These seem to control the requirements necessary to actually start an experiment. The values are from an enum that specifies the crew requirement. Never = -1, Always = 0, VesselControl = 1, CrewInVessel = 2, CrewInPart = 4, ScientistCrew = 8, So you can make an experiment be unmanned only (I think, I'm not sure exactly how it works), require a crew, or a scientist. CrewInPart is interesting, as it allows for ScienceLab-types of experiments. The second field, usageReqMaskExternal, refers to the requirement for EVA experiment deployment. There is a new KSPEvent, DeployExperimentExternal(), this triggers EVA deployment if possible.

It's looking like no new biomes were added. I was hoping Duna would get a second look (and I thought we saw previews of this somewhere), but the biome names I'm getting straight from KSP are the same as in 0.90.

Yeah, I figured this would be the best one to get updated first. It also updates with new contracts added while in flight, so those automatically accepted achievement contracts show up (and the old ones can be deleted) as soon you finish the last one.

My contracts mods have all been updated and are working with KSP 1.0 in my testing. [thread=91034]Contracts Window + version 5.0[/thread] - Working and updated [thread=113277]Contracts Reward Modifier version 2.0[/thread] - Working and updated [thread=116002]CapCom version 0.3[/thread] - Working and updated [thread=64972]DMagic Orbital Science version 1.0.1[/thread] - Not Working. I haven't tested it, but based on API changes it will give errors when collecting science and contracts won't work. The tech tree position of parts is also changed.

It looks like the old method for getting the true atmospheric cutoff height doesn't work anymore. mainBody.atmosphereScaleHeight * 1000 * Math.Log(1e6) atmosphereScaleHeight isn't there anymore. I'm seeing: CelestialBody.atmosphereDepth That might accomplish the same thing, anyone know? It also looks like the onScienceReceived GameEvent returns a ProtoVessel object in addition to the science amount and ScienceSubject that were returned before. That could be useful for checking if the science returned is from a specific vessel for contracts.

The core aspects of Orbital Science seem to be working OK, science collection works, but a few updates are needed for 1.0 compatibility; old version won't work in KSP 1.0. I'll need to do more testing to make sure things are working correctly, I'll also need to sort out the new tech tree and check new biomes (if there are any). A second update will probably be necessary to handle all of the interop issues (Community Tech Tree, KAS/KIS, SCANsat, etc...).

Version 2.0 is out and updated for KSP 1.0, everything seems to be working ok.

Version 5.0 is out, get it on Kerbal Stuff. Everything seems to be working in KSP 1.0. I also fixed some issues where contracts with the same name would change positions, and I made the contract reward values display in a much more efficient manner.

Version 0.3 is out. Everything seems to be OK for KSP 1.0. A few minor additions were made using the stock Mission Control Center texture map, but otherwise this is the same as version 0.2.

Really? That's not what I paid Squad for. I paid for the game as it was, not for some future developments. Sure there is some expectation of support, but there is no requirement for it. And this totally ignores half of the question. Paying for the game has nothing to do with Twitch streamers or YouTube video makers getting money, sometimes as a direct consequence of using or featuring mods. Do you have an answer for why they should earn money, but not others?

Stay tuned. a is a possibility, though the middle-click or Alt+right-click serves basically the same purpose. Maybe some kind of arrows that appear when you mouse-over the edges of the map, so that extra buttons along the sides wouldn't be needed as I want to keep the zoom map as small as possible. I don't really like b though. For one thing this would require some kind of interface to activate and deactivate this, as you wouldn't want the zoom map to always follow the vessel. But more importantly it isn't really feasible because of the performance hit of constantly updating the map. Both the big map and the small map cache the elevation data, since they show the entire planet. This isn't possible with the zoom map because the zoom scale can change and the center of the map can change. Updating this data is very slow, so it won't really work.

Does anyone have a legitimate answer to this? One that doesn't resort to some mushy concept like the spirit of modding, or mods being made for fun, or being made strictly for ourselves. I can't really think of any reason for why this should be so. Not that I want to start selling my mods (Curse does give some money to people who opt-in, I'm seeing around $100/year, almost entirely from Orbital Science), or paying for others, but that doesn't change the fact that I can't think of a good reason for why others shouldn't be able to.

I think there were some minor adjustments to the parts around version 6 or so. But there haven't been any further changes that I can remember, certainly in not in this release. Edit: That does remind me that I've been meaning to tweak the parts forever. I converted everything to DDS, reduced all of the main textures, 6 of them, to 512X512 (they were 1k before), and switched everything to MODEL nodes, which means that the useless MapTraq part no longer needs its own texture as it can point at the BTDT texture (which was reduced from 512 to 128X128). This takes the part memory footprint from around 25MB to around 6MB. There is a slight drop in texture quality, but you have to be really close to the part to notice it. If you run with ATM (if it works with DDS?) there might be a more noticeable drop in quality, but that's what happens.

Version 0.2 is available now, you can get in on Kerbal Stuff or GitHub. Check the first post for details. Aside from some UI improvements and a few minor kinks I think this is mostly finished.

They should, plenty of contracts just ask for a random agency.

Completed contracts screw it up too, you have to remove them from the save file by hand, or delete them through the Alt+F12 menu. You also have to be careful when removing contracts that none get offered by the same agency while you're doing it.

When a contract is generated it gets assigned to an agency (sometimes randomly, sometimes not), which is then saved along with all of the other info about the contract. If you delete the agency definition (there are simple config files for these, along with the two flag textures) after you have accepted and saved a contract offered by that agency all sorts of bad things can happen. The next time the game loads a contract with that agency it can't find it and freaks out, this causes some problems with loading contracts (they don't show up correctly in the Mission Control Center). Much more importantly, it breaks saving contracts, which breaks saving the contract scenario module, which prevents KSP from saving at all, which prevents you from changing scenes. It basically breaks the game. It would be really easy for Squad to fix this, so hopefully they have in 1.0. But it can be a major problem for now; it's why I have a disclaimer about the issue on the first post of DMagic Orbital Science and an explanation of how to fix it.

Version 11rc5 is up on GitHub. It fixes the problems with MechJeb integration. It also adds a MechJeb-independent landing site selection system as described above, along with orbits viewable in the tracking station. I'm hoping to make this the last update before version 1 is released. So please let me know if there are any bugs or unexpected behavior.

I've fixed the broken MechJeb targeting. I've also gone ahead and added a targeting system that works independently of MechJeb. You can toggle MechJeb targeting in the settings menu if you have it installed. The standard targeting works the same as MechJeb landing guidance targeting, just open the zoom map, select the targeting icon and pick a site on the map. You can clear any existing targets by clicking outside of the map, but inside of the zoom map window (somewhere along the top or bottom for instance). Landing sites are persistent, each planet can have one site saved that will show up like regular waypoints. I've also borrowed MechJeb's map overlay drawing method. I used a different color and a four arrow target to help differentiate the two overlays if you are using both separately. I added Tracking Station orbit viewing as well, it was a simple change. You can see the different map overlay and the different landing icons used for SCANsat targeting. And MechJeb landing guidance targeting here: