DMagic

Update to V0.8.2 Download from CurseForge New update adds two brand new science experiments. - Multispectral imaging platform; used from space to study planets, moons and asteroid. - Solar particle collector; used from space to study solar particles, planetary dust, and asteroid particles. Eight new parts added for use with Paul Kingtiger and Daishi's Universal Storage mod. - The four existing parts have been reworked to fit into the new science bay US wedge. - Three new stock experiments are included: Mystery goo containment pod, Materials bay, and the Atmospheric sensor. - A new version of my optical telescope is also included in US wedge form. Module manager is now required to use the Universal Storage parts. They will configure themselves to be available for use if US is installed. SCANsat modules will also be automatically added to the anomaly sensor (the BTDT SCANsat module) and the Multispectral imaging platform (the biome/anomaly SCANsat module) using Module Manager. The old, SCANsat specific parts are no longer included in the main download. All parts are now using Model {} nodes and must be placed in the correct location: KSP/GameData/DMagic Orbital Science/ A new system for asteroid science has been put in place. It allows for limited amounts of repeated experiments to be performed on different asteroids. It is fairly rudimentary at this stage and can be exploited. But in most cases it should allow for only one experiment of each type per asteroid. Repeat experiments can then be performed at several different asteroids. There are a number of other minor tweaks, bug fixes (and given the amount of code-rework, probably some new bugs), and balancing changes. The Exobiology Core Drill can now only run three experiments, instead of six as before, old science data should be in continued save files. Costs have been given an initial balancing pass, but will probably need to be modified further. I have also deliberately altered the ScienceDefs files so that science monitoring/activating mods won't be able to start my experiments unless they do so using the proper methods. ScienceAlert is the only mod I'm aware of that does this. Complain to the other authors if you don't like it. Check the first post of this thread for more information and a full preview gallery of the update. Change Log: v0.8.2 - Updated for KSP v0.24 - New multispectral imaging platform experiment - New solar particle collector experiment - Rudimentary version of multiple-use asteroid experiments added - Experiments can be repeated on several asteroids, but only once on any given asteroid - New versions of all Universal Storage parts - Parts are now installed in the standard empty US science bay - These require that Universal Storage be installed correctly and in the right location to function properly - Universal Storage and SCANsat compatible parts configure themselves automatically if the requisite mod in installed - Module Manager required to work - SCANsat parts no longer included on separate part files - External science monitoring/activating mods now require explicit support from me to function properly - Only mods the have a 'deploy experiment' type of button affected - All experiments are EVA deployable - A few, mostly minor bug fixes - Max atmospheric height is now properly determined - Experimental situation multipliers for flying high and in space high now use their proper values - This is most obvious for the sun; in space high has a multiplier of 2, in space low has a multiplier of 11 - General cleanup for inefficient animations and part models - Significant code rewrite for most modules - In addition to several bug fixes, several exciting new bugs have probably been added v0.8.1 - Hotfix for bug causing you to temporarily lose science reports after landing, taking off, or otherwise changing vessel situation v0.8 - Added asteroid science system - Asteroid specific reports can be collected while grappled to, or within 2km of an asteroid - Reports and science values vary with asteroid class - Asteroid experiments are only counted once per asteroid class (your current planet and experimental situation are ignored) - Four new parts for use in combination with the Universal Storage mod - Replacements for magnetometer and RPWS; both are functionally identical to their default counterparts - Combinations of the four basic science experiments; PresMat/2Hot and Accel/GravMax - Asteroid reports available for Accel/GravMax - Slight changes in atmospheric detection; PresMat/2Hot measurements can be taken while aerobraking, on escape trajectory etc... - Magnetometer simulation extended to all planets and moons; should also work on mod planets - Simulation update frequency reduced; should be little/no chance for performance impact - A few minor bug fixes - Clarified limitations on Core Drill usage in the in-game part description - Additional science reports for asteroid science; typo fixes for old reports v0.7.5 - Updated for KSP v0.23.5 - New RPWS model and texture - Existing vessels should still work, but the RPWS might end up attached backwards - New telescope texture, some adjustments made to the existing model - Resized parts so that they are all more similar in scale - Added resource usage to drill, laser, anomaly scanner and magnetometer - Can be configured in the part.cfg file - Limited magnetosphere simulation for Kerbin - Values read-out in right-click menu, can be disabled in the part.cfg file - Several changes to plugin code - Exploits for drill fixed - Lab reset for anomaly scanner should work as it does for stock parts - Most parts moved onto universal science module - Several default science reports added, should work on any mod planets that include ScienceParams values - Drill should work on any planet with an atmosphere now - Added reports for Krag's PlanetFactory planets v0.7.1: - Added SCANsat BTDT function to alternate version of the anomaly sensor. - Can now be used for both custom anomaly science scanning and SCANsat scanning. - Part has a different name and must be purchased separately in the R&D center. - Added my own telescope module to the SCANsat version. - Details are the same as for the anomaly sensor. - Both parts are found in the alternate, SCANsat folder. - No changes to the default parts. v0.7: - New anomalous signal scanner. Designed for rovers and spaceplanes. - Used to detect and study anomalies. - Single use only; return to Kerbin for complete study of the science report, or transmit and reset with science lab. - New textures for the magnetometer and laser; they fit in better with the recent parts. - Fixed .cfg file and plugin bugs for the laser and magnetometer - Laser returned to its proper tech node - will require repurchase, but should not affect existing vessels. - A few minor changes in other part.cfg files; dropped the mass of the telescope. - New science reports for the anomaly scanner, fixed many typos in old reports. v0.6: - New biological activity core drill. Designed for rovers and landers. - Features multiple storage containers. - Can be used up to six times before needing to be returned to Kerbin or reset with a science lab. - Two different animation modes, used for rovers or landers. Animation dependent on the drill's orientation relative to its parent part - preview animation in the VAB/SPH - use cubic octagonal struts or other small parts to modify animation behavior. - New science reports for core drill. - Included support for Trueborn's Custom Biomes plugin. * Requires separate download - Reports for custom biomes for the laser, optical telescope and core drill. - Reduced values for some science experiments. v0.5: - New surface scanning laser instrument. Designed for rovers and landers. - Changes in magnetometer and telescope part names to address compatibility issues with other mods (will not be backward compatible without manually changing the names or installing the alternate part folder). Re-purchasing parts in the R&D center is required. - New model for magnetometer, includes added details to the instruments themselves, cleaner animation, and lower RAM usage due to more efficient use of textures. - Custom part modules for all parts to address animation and science collection issues: - Magnetometer and RPWS animations are fully reversible while playing, animation speed for these parts is increased as well. - Deployed previews are available in the VAB/SPH for all parts - Attempts to collect science where not possible will trigger a message with suggestions about where to use the instrument; will not play the deploy animation if the part is in the retracted position. - Transmitting or resetting the instrument will not trigger the retract animation. - Repeatedly pushing the collect data button/action group will not spam multiple results. - The laser has only a single, forward animation. Data is collected midway through the animation. - Edited existing science reports, and added several more. Added full set of surface reports for the laser. v0.4: - New textures for all parts. - Changed non-SCANsat telescope to be the default, for the SCANsat version replace the default scope folder with the alternate folder. - Tweaks to models and animations for the magnetometer and telescope. - Add Langmuir probe to RPWS model (should not break existing crafts). - Added surface reports for the magnetometer, including biome support where available. - Added biome support for non-SCANsat telescope in low orbit. - Rearranged tech tree placement; parts moved to earlier nodes. - Decreased science report values, added and edited science reports. - Added FxModule to part.cfg to force deployment before science reports can be collected. v0.3: Initial upload.

It sounds like you have to versions of the same part loaded at the same time. If you have two part.cfg files with the same "name = yourPart" field then this kind of thing will happen.

I use TGAs for KSP too, I just meant that for importing textures into Unity I use PNGs. The file format is more universally recognized and I never have problems opening or editing PNGs in any kind of software, so they seem to be the simplest format to use while creating textures.

I always use PNGs for Unity. You might want a better PNG plugin if you're using Photoshop, but I think it's better than JPGs either way.

In the interest of not running afoul of forum rules I'll just leave this here: http://en.wikipedia.org/wiki/Kike It's a slur against Jewish people. The way it's spelled out in the video doesn't really help, either.

Oh yes, that's definitely doable. That module is getting a bit old, but the version of it that I'm using in the latest update for my mod has been changed in ways that would make this kind of customization much easier. Once I finish dealing with updating my mod and SCANsat for 0.24 I'll look at updating the generic science module. Most of the hard work is already done, it's just a matter of integrating a few changes here and there. It would still require some customization to work specifically how you want, but I could probably handle that; it's likely to only require a few lines of code.

If these aren't really being updated I can easily add a @Part...:For[DMagic]:NEEDS[KAS] line to my parts so that I can configure them myself and ensure that they always stay up-to-date (and probably the same goes for SCANsat). It's possible to check if the module already exists on the part using MM syntax right?. That way it won't get added twice if someone has this file also installed.

New mod idea! I'm guessing it might be a bit more complicated than changing the celestial body science multipliers, but we'll just have to wait and see.

Do you have to switch to the part to collect science data? I assume so, since standard science parts aren't EVA deployable. An EVA deploy button is something I'm adding to my own science parts in the next update and something that I'll probably add to my generic science module the next time I get around to updating that. That module also allows you, if you really want to, to make your experiments work only on specified planets. Let me know if you want to add my module to your parts, or if you have any requests for added functions.

We did get this info on the forums, an entire 5 minutes or so later...

I'm just going to cover my eyes and ears and pretend not to see or hear these comments.

I imagine that this is possible, but I'm not sure how I would actually go about doing it. It's an interesting idea though; I think it makes the most sense for EVA and crew reports. Surface and asteroid samples probably shouldn't matter as much. As for science bloat, I'm hoping that 0.24 will alleviate that a little bit. One thing that I'll take a quick look at before updating is any changes to the cost of stock science parts. I'll try to align my parts to be consistent with stock prices, but maybe a bit higher depending on the total science potential (the telescope and imaging platform have a pretty huge pool of available science because they can make orbital biome-dependent results). But any serious balancing based on the career mode changes will have to wait. I'll try to get the next update out pretty quickly to address that and to setup some initial contracts and such. And if you really want to make things a bit harder you can always use my celestial body science multiplier editor. You can lower the science multipliers to whatever values you want. In particular, lowering the Mun and Minmus' values can really make a big difference. I've also discovered that I probably need to increase the cost and/or mass of the Universal Storage goo and materials bay parts over their stock counterparts because it's so much easier to take 4 or 8 of them with you. The stock parts are pretty big, so when you cram a bunch of the US versions into a relatively small space it really throws off the balance.

Can a mod close or at least un-stick this thread? I might start another mod-working thread, but it should be separate from this one.

Currently there are two separate things going on with tech nodes in the R&D center. When you spend science points to unlock a tech node this opens up all of the parts within that node for research. Then separately, every part that is currently available in that tech node is purchased/researched. Each part has a specific research cost associated with it (separate from the VAB cost; both are defined in the part.cfg file). Because this research cost system hasn't been implemented (and it's not clear how it will eventually work), all of this happens in one step and you never have to spend anything to research/purchase available parts in the R&D center. This is where the problems come in. When you add mod parts to a tech node that you've already unlocked it doesn't automatically research those parts for you. You have to go into the R&D center, click on the tech node in question, then look at the list on the right. It should show all of the parts available within that tech node. You can click on the non-researched parts and select purchase/research. After that you should be able to use the parts in the VAB. There are some mods that automate this process if you are frequently adding more mod parts. But in no case should it be necessary to directly edit the persistent file to gain access to these parts. The short version is: The R&D tech node system is build with unimplemented systems in mind. If or when those systems are actually used it will probably make a lot more sense.

I'm guessing that ModuleAnimateGeneric explicitly disables the animation on loading and sets it to run in clamp/once mode. Mine does neither of those things.

Without any outside information I would guess that they just switched the Kerbin day tracker to solar days instead of sidereal days. A very quick calculation shows that there are 426.09 sidereal Kerbin days in one year. Take off 51 seconds and you get 427.09 days in a Kerbin year. There is, by definition, one more solar day per year than there are sidereal days. So this would make much more sense then pointlessly changing Kerbin's orbit or rotation rates. Derp. Or forget all of that because it's the other way around. A solar day would be slightly longer than a sidereal day...

I've never heard of anyone disabling cores while overclocking a CPU that they actually plan on using. Maybe for some type of competition, yes, but for something you're actually going to use that seems to be extremely uncommon. There are probably some circumstances where this CPU would be well suited; maybe you already have a high end MB for some reason, but not a CPU to go with it. It might also have more favorable power usage numbers when overclocking also. But for the most part, if you are looking for a relatively cheap, high-performance (and possibly short-term) solution, and you're willing to overclock, then you're best bet is to find reputable source for a used 2500k or 3570k. This comes with the added benefit (at least if you trust the seller) of getting an idea beforehand for how well the CPU will actually overclock. Something that you can never be sure of when you're buying new.

The default wrap mode should be 'once', but you might want to set it to that just to be sure. It sounds like you might have the 'play automatically' box checked and the culling type set to 'always animate'. Make sure the box is unchecked and the culling type is set to 'based on renderers'. Those are the only reason I can think of for why your animation would be looping all of the time like that. The plugin doesn't really support looping animations, and never explicitly uses them, so the Unity settings are the only things that should affect how the animation behaves.

It should be, you would still need to attach the relevant module to the part, not the Kerbal (I have no idea how to do that anyway). So you would be using external event buttons ([KSPEvent(guiActiveUnfocused = true, externalToEVAOnly = true)]) and having the start experiment and transfer data methods all wrapped up in one button. Another method might be to activate the experiment with the standard external button, then only transfer the data once you push the "keep data" button on the experimental results page. It wouldn't be difficult to add the code for that to the callback used by the results page.

Is there any consensus on this? I fully agree with K3|Chris. I think there are some valid reasons for wanting to have a stand-alone SCANsat part, but I think the advantages of not having to deal with that far outweigh any of those. There is a need for a non-scanning SCANsat module in some cases (getting RPM to work without SCANsatRPM), but that doesn't need to be visible to the user in any meaningful way, the buttons can easily be removed. With what sounds like a stock toolbar being available in the next update (does anyone know about this for sure?) I don't see any real reason to keep supporting non-toolbar versions of SCANsat. This removes the primary problem caused by removing the MapTraq, in my opinion.

I think this is doable, though you have to use some slightly wonky formatting for your results. The way to do this would be to create a science subject with a fixed celestial body and experimental subject and use the biome string to specify the part condition. ScienceExperiment se = ResearchAndDevelopment.GetExperiment(id); ScienceSubject su = ResearchAndDevelopment.GetExperimentSubject(se, ExperimentSituations.InSpaceHigh, FlightGlobals.Bodies[1], "Part Condition String" + "some kind of part ID number"); ScienceData data = new ScienceData(scienceAmount * su.dataScale, 1f, 0f, su.id, "Title bar string"); The science experiment id is what you have defined in the ScienceDefs.cfg file. Using a fixed experimental situation and celestial body takes those two elements out of consideration. You would presumably have a list of several possible part conditions, each with a short string associated with them. Appending a part ID number at the end would ensure that experiments would not be repeatable for the same part, but should be repeatable for other parts of the same type. The first field in the science data constructor specifies the data amount (which divided by the data scale and multiplied by the SubjectValue and ScientificValue gives you the total science points), the next two values are for transmission and lab boost, which you probably don't care about. You can set your science value however you want, it doesn't necessarily have anything to do with the values set in the ScienceDefs.cfg file; you can change the science subject values too. The su.id is the subject id; this thing: crewReport@KerbinInSpaceLowGrasslands. This must be valid, and must match the id generated in the step before. The formatting would be ridiculous in your case, since it has nothing to do with experimental situations and celestial bodies, but the biome string at the end is all that really matters. The title bar string can be whatever you want and is what shows up in the title of the experimental results page. In your ScienceDefs.cfg file you would want to have science reports with the format KerbinInSpaceHighBroken/GoodCondition/NeedsRepair, etc... Having a part ID appended at the end won't matter for your science reports. You could also break things down further by generating science subjects and science reports based on part type (KerbinInSpaceHighEngineBroken), but all of that can be handled with your "biome" string at the end.

It depends on what exactly you mean by procedural. The default ModuleScienceExperiment won't really be of any help here, at least not for what I think you're getting at. The closest thing I can think of to what you describe is SCANsat. It assigns science value based on scanning coverage, basically taking some information from what you've scanned so far, making some calculations to come up with a science amount, and converting that into usable science data. The most relevant limitation that I can think of is that you must create your science subjects (the thing stored in the R&D center and used to track existing science reports) according to some pretty rigid standards. I have never found a way around (and I have spent a lot of time trying...) using ResearchAndDevelopment.GetExperimentSubject() to create usable science data. You have to give this function a celestial body, a science experiment defined in a sciencedefs.cfg file, an experimental situation and a biome (even if it's just an empty string). You can still come up with lots of different methods for creating data within this limitation, Tarsier and CactEye both do so using their telescopes, and I've managed to fudge some of the variables to create asteroid science reports, but it does limit what you can create with it. There's a lot of room to make interesting science experiments, but I'd need to know more about what you want to do to say anything else.

You just put something like this in when you first initialize the scenario module. One problem to be aware of is that you might not be able to add extra target gamescenes once the scenario module has been created for the first time, at least not using the methods common in other mods. So when you're still tinkering around you might want to start a new save file or come up with a method to add more scenes target scenes to the module. Or you could just manually add them in the persistent file, I don't think I've ever tried that, but it should work (it should be the first line after the name of the scenario module, though I'm not sure which numbers correlate to which game scenes). Game g = HighLogic.CurrentGame; var p = g.AddProtoScenarioModule(typeof(DMScienceScenario), GameScenes.FLIGHT, GameScenes.SPACECENTER, GameScenes.TRACKSTATION); Edit: Here are the game scene numbers: LOADING = 0, LOADINGBUFFER = 1, MAINMENU = 2, SETTINGS = 3, CREDITS = 4, SPACECENTER = 5, EDITOR = 6, FLIGHT = 7, TRACKSTATION = 8, SPH = 9, PSYSTEM = 10,

The config node is unique to each part with that part module. Every time you add another instance of that part it will start-over with its initial settings. Diazo's probably right. Scenario modules are used for the tutorials but they can be used for much more. They save data for the entire save file (the R&D center is a scenario module, you can look at its entry in the persistent file and see things like which tech nodes have been researched and which science experiments have been conducted) so you can store your data in there and tell your part module to get whatever it needs out of the scenario module. You'll only need to store one copy of every variable that you're interested in, then each part module should be able to use the most updated value for that variable.

I don't really know how FxModules works. I though that it just called ModuleAnimateGeneric if it was present, but it's probably more complicated than that. I'm not aware of any way to get this to work using the stock ModuleScienceExperiment and ModuleAnimateGeneric. Those modules are really only suited for static experiments and for stock parts. And ModuleAnimateGeneric really doesn't handle multiple animations on the same part very well. It's possible to make this type of multiple-sample experiment, but it requires a plug-in and it's not exactly straightforward. My Science experiment plugin handles animations better: DMModuleScienceAnimateGeneric, but it still only handles one sample per module. You could try putting three of those modules on a single part, it might work better. I've since made a somewhat more generic science module that does work with multiple samples, I might try to work that into DMModuleScienceAnimateGeneric, but probably not any time soon.