TheRag

Well, updating Photon Sailor still caused the issue, however removing Photon Sailor caused the error to fix itself. EDIT: Okay, I saw your post before.

Yep there seemed to be a Interstellar Redist in Photon-Sailor for some reason. Let me try it now EDIT: I am a idiot, I forgot to update Photon-Sailor. Sorry for the commotion over this.

I am reading 13:04 Sunday, May 3rd, on the created date from 7-Zip. EDIT: That is downloaded version from Curse.

I used to the Curse Release specifically, I'll try the github version directly. EDIT: It seems that that github version is affected as well. The method is inside of the plugin, let me see if I can recompile it.

Hey @FreeThinker You may want to double check the release, I am getting missing method exceptions for the Interstellar engines. Specifically Redist.IpowerSource.get_MaxCoreTemperature using the latest release. https://imgur.com/a/cMpF3RN EDIT: The error seems to affect all nuclear engines, however the more exotic engines are not affected.

Do you have the latest Community Resource Patch?

Excellent, thanks for the quick identification.

Also can confirm, that this happening too. What's more is that power megajoules management display indicates that 2.5 MW is being "requested" from an unknown source. I placed a PB-NUK to generate power to see if this would offset the bug, it did not. What I find interesting is that 2.5MW is 1000 times the maximum yield that a single gigantor solar panel can provide in MW, so there is something definitely messing up the conversion/power management files. I looked over the plugin-in files to see what could be wrong, but I did not find anything. EDIT: Okay, if you retract the panels during darkness or being obstructed you will not experience the bug. Time-warp divides the power demanded by the time-warp factor. So 5x is 500 Kw 10x 250kw and so on so forth. EDIT 2: You can delete the Solar Panels.cfg file in the Patches section under WarpPlugin however this removes their KSPIE integration entirely.

Awesome, now I just need a means for paying for all this equipment, and shipping it down to the sun.

DLCs aren't perpetual money machines, they cost time, resources, and manpower to create, promote, and maintain. Think again when I mean KSP reached its limit in a business sense. What can KSP do better that a new sequel cannot? Already for the complete version of KSP is $70 while KSP2 will be $60 and has a much expanded scope compared to KSP1. Any new DLC for KSP1 makes KSP2 more attractive from a consumer standpoint because hopefully those DLC concepts and features are already integrated into the base game on top of the new features. Unless KSP1 has sometype of innate advantage that cannot be replicated, there's really nothing but consumer sentiment, stopping KSP2.

1. Total package cost. Players are not going to buy all the DLC of a game unless it is heavily discounted. Paradox is notorious for having products with hundreds of dollars of DLC, so many people buy the DLC when heavily discounted during sales. Right now if you want the complete version of KSP, you will need Making History and Breaking Ground in order to do so. 2. Product Cycle, Every product has a cycle it goes through. Development, Growth, Maturity, Decline, and Termination. KSP is well past its maturity point, new DLC doesn't generate new sales in comparison to a new game release that is successful. 3. Opportunity Cost, Private Division cannot afford to just keep tacking on KSP DLCs because the market will realize this and try to out-compete them. With KSP2 it shows that KSP is still an active force in the market and pushes the new standard of competition for space management games, the opportunity of cost of just solely developing KSP is just too high. 4. Diversification, by having multiple titles it helps reduce concentration risk on a investment. Before KSP2 the entirety of the investment was riding on KSP DLCs and post launch support of the game. Now with a new title, the developers can branch away from support roles to actual developing and creative roles. This doesn't mean KSP2 will be a success, but there are multiple material reasons that necessitate and justify KSP2's development and primacy over KSP1.

It's not fraud, doesn't fit the definition of fraud, and I am an Accountant. Fraud would be if they announced KSP2 but it did not exist as product, but took pre-orders anyway. It's a company wanting to make use of their IP, so I see nothing wrong with that. So this is really bad question. KSP has been in development for nine years, which is very long development cycle that isn't owed to the players. The IP has changed hands to a new company on the tail end of KSP's development cycle. Obviously the purchaser wants to have a return on their investment and build good faith with community, so they didn't immediately cancel all post launch support after acquisition. It's more than likely that Take Two purchase the title for the indie portfolio and approved a sequel because its a very low risk and fills a very tight niche in the gaming market. It's easy money for them. Even then what is there to be done with KSP? It has approached the limits on what is feasible with the game's structure and architecture, they are still developing the game of course, but no company will develop a game forever.

I too also have this engine animation glitch as well for the same engine, for the NERVA. https://imgur.com/u52hOLD @lobf We share the following mods: Interstellar suite KAS/KIS So it could possibly be an animation misfire for the engine.

Hello, IFS is somewhat incompatible with Global Construction, specifically the tanks. The tanks throw a (Cannot find FX group of name for decoupler) when a vessel that contains them is selected, which upon starting kit construction causes the game to have NAN error forces a restart to clear the system. I am not too clear which mod is causing the error or if it is both of them. The output log points to Global construction, however in-game testing points to IFS. I have notified the maker of Global Construction about this as well.

Alright I seem to have found the problem. It is with Interstellar Fuel Switch tanks. Something with the decoupler group fx (Cannot find fx group of that name for decoupler) is causing the NAN problem, all other interstellar parts work fine. I will submit this to IFS for corroborative evidence.

I am having a strange problem with ground assembly line, it throws a bunch of exceptions and forces me to restart the game. https://imgur.com/a/LIdb8PX Whenever I press "start construction" the game simply gives me a NaN kraken. Log : https://www.dropbox.com/s/6zr50jea0s37jrg/KSP.log?dl=0 Output_Log: https://www.dropbox.com/s/ro6om8684m4g3xm/output_log.txt?dl=0

Anti-gravity drives? I am assuming that you can provide thrust by redirecting gravity through a warp field.

Okay, Beam Merging works too. I was a little confused on how the GUI displays it. At first I thought it would only show one transmitter, which would be the source of the beam merger satellite. However, after realizing that the beamed power would strictly relay instead of direct connection, that showed that the satellite was merging the beams of the two satellites. Great, that means the Dyson Swarm project is an official go.

I checked distances, and the seemed to work out correctly based on distance. It isn't phantom distance either, because microwaves would only give me kilowatts at that range, with the same set up. So it is actually taking into account the relay path. I also kept the transmitters identified. The album does have a instance were all power that was received was completely relayed, with transmitters being on the other side of the planet. I confirmed this by shutting down the relay, which stopped power from reaching the receiver. Ah, okay, so for example. Power Station is on the ground. It generates 5 GW Four Orbital transmitters are linked for relay and generate power each generate 1 GW. The receiver is at Duna across the solar system. What should happen is that Power Station transmit power to the closet transmitter Linked for Relay. The orbital relays then transmit their power to the transmitter that has either a direct or shortest path to the receiver (such as mirrors in various solar orbits). The beams should merge and generate a 9GW laser to the intended target. Correct?

Here's a ground station test. It also has a competing orbital station. https://imgur.com/a/hDHAnrq I still trying wrap up how to get beams to merge. Then again, my relay system was rudimentary at best. But it does work.

The commit only changes one file, Interstellar Beamed Power Helper, I should be only pull request. As for verification, To the extent of my knowledge, yes, it does allow relaying, along with no adverse effects to the rest of the beamed power system. I have not tried beam merging, but it should follow the same principle. If you want, I can do a ground-geostationary test, if I can get power on the other side of the planet that would probably indicate relay is working.

Just sent the request to Github, hope it helps.

Victory! Yep, that was the problem. I now have relay potential now. https://imgur.com/a/TgNjuhr I will try to insert it against the current version. EDIT: The old code runs perfectly in the latest version of Interstellar now. Relays are working in 1.7.1 and most likely 1.7.2. If you want, I can release the DLL that contains the old Beamedpower network system. https://imgur.com/a/8MAJWgl

So I've been trying to find a solution in the source code on fixing the network relay. On the the Github there was an issue filed on January 20 for the same problem, which referenced 1.20.5 I believe it might be related to changing the reference from relay.Vessel to relay.position. In which case the beamed power is sending to a position not a vessel, and in turn is not being received by a vessel. I will try to restore the old references in the relay section to see if anything works. I loaded up KSPIE 1.20.2 in KSP 1.4.5 for a test and sure enough relay sats are working. I will compile the old code back into the InterstellarBeamedPower helper to see if anything changes.

So basically the idea will be this? Low solar collectors will transmit to a local receiver on a lower but more efficient wavelength. I am assuming that there is a good ratio I want to target 10 to 1 or 20 to 1? Those receivers then transmit the combined power yield on large-dish ultraviolet transmitters to where ever needed. My goal is to have 1-5 Gigawatts available with the range of Neidon for 99% of its orbit through beamed power (might need to use an X-Ray Transmitter and Receiver at Dres). Assuming that my solar stations can generate 10 Gigawatts that mean 100 gigawatts per receiver station. I forget the conversion ratio of microwave transmitters so I go with a conservative 65%. Then assuming I get 50% due to the spot sizes of microwaves, then 35% to transmit the power into 10nm ultraviolet wavelength. So the wall to beam should be around 11 Gigawatts. With Neidon having a semi-major axis 409,355,191,706m and using a 30 meter dish on a 10nm wavelength using the formula on the kspie wiki: 1.44*409355191706*0.00000001/30 This gives a spot size of around 200 meters. Which means the craft will have to capture 9% to 46% of the wavelength in order to meet satisfaction. Is there anything wrong with this?