TheSuMa

Did some tests with hoppers and was able to reproduce the problems. You cannot connect a hopper to a depot if you have a Survey Scanner on the vessel Hoppers vanish from WOLF-Registry and the resources they used get freed up, hoppers are still up and running Moving a connected hopper outside of current WOLF-Biome will not disconnect it until vessel is reloaded Detailed Description and possible fix in PRs #1511 and #1512 I think the check shouldn't be the way it is, currently it checks not only for Depots but also for Survey Scanners, message is always about depot. PR should fix this and check only for depots.

Ore is no option on MPU, it's on the drills: 1. Check what recipe you need in parts contextmenu and what resources you need: Recipe "LFO" You need Ore / EC (We ignore the Machinery for now as the MPU ships with a decent amount to start with) You get LF / OX (We ignore the Rocks for now as they get dumped away if it can not store it) 2. Create a craft that is capable of mining Ore And processing it into LF / OX with all the required storage: A drill set to ORE An MPU set to LFO An empty LF / OX tank A container for the intermediates (Ore) Some Power Some Cooling 3. Deploy in a Biome that has Ore (Check with Surface Scanning module) Deploy and Start Drill Start MPU

It's a bit tricky to get how it works. You should see three buttons: 1. Button to change the receipt (in your case currently "Silicon => LFO") 2. "Next receipt" 3. "Previous receipt" Click on "Next Recipe" until button1 changes into "Silicon => Ore", then click on button 1 "Silicon => Ore"

Aware of that, this one is a very small fix and without knowing the details of the implementation for the wolf-containers i think it should also eliminate the "at least partially, if not fully" out of you sentence , but this is only a guess as long as i don't know the implementation of it. Is it? If your fuel-depot is at the routes destination, how do you get there without paying for any fuel? Agree that if you refuel, then this fuel should be free to use and if you launch the vessel dry and refuel after connecting to source depot the route could become free. This is exactly how the current implementation behaves. Both of the PR's mentioned are implemented in exactly this way, even the simple one, i just eliminating the exploits as a side-effect of other fixes

It is a huge exploit even for SSTO. While docked your fuel station mass gets also counted as your vessels mass. This will not only reduce the cost (until zero) of the route but also increase the payload. There is a PR around the corner to fix all of the exploits i'm aware of currently, just need to test it and currently my game time is a bit limited due to RL work Once it's done we'll need to see if the devs like it or think it's overcomplicating stuff. If it should be too much i'll do a second PR that fixes only the docking and partially the refueling exploit, this could be done with 4 simple lines of code

Sure, just turn the problem around and produce more Credits instead of reducing the need, stupid simple, probably it was just too late to think of it that way, sorry I had nothing special in mind, just wanted to help, do not need it myself. The only reason i said it's hardcoded was the readonly double ROUTE_COST_MULTIPLIER in the TransporterModule. It looks like it should be configurable, but i agree, no need for it PR is done and @RoverDude already merged it to DEVELOPMENT branch, it will be available in next release, you will get a "Route Payload" and a "Cost / Payload" Because current implementation is based on vessel mass you're still not able to know the amount before you have flown the route as it is not a static value, once cargo-space is implemented this changes and the payload can already be shown in VAB/SPH. However, you will at least be able to see it before connecting to destination depot in next release

No, in current release there is no way, it's hardcoded, i'll do a pull-request to implement such a setting (as soon as other pull requests i'm working on are done)

Currently the Transport Credits required are only based on vessel mass lost between connecting to source depot and connecting to destination depot. Payload is currently also calculated by vessel mass (mass while connecting to destination depot) There is no logic present that accounts for solar system rescaling, calculation is static and hardcoded Transport routes are not cheap, even in stock they are expensive, i think this is by design That said, yes, transport routes are more expensive with rescaled solar systems as you need more Dv to achieve orbit. But 2200 seems to be a lot. Probably your craft is simply too big to kickstart your WOLF routes. A vessel with fewer mass would probably fit better. Another thing to consider could be an SSTO spaceplane. At least for me they often win the transport credit / payload battle. As the whole WOLF system is very new and the devs are open for suggestions and pull requests i would expect that there will be some changes in the future to account for such cases. Either a configurable cost-multiplier that other mods can change or automatically account for rescaled solar systems in any way. If i find the time i can take a look at it once the currently open pull-requests are merged.

Tanks for the reply. I'll do a second PR then for the repeatability based on the general PR, understand absolutely that this will need a discussion. Not much additional work if i base it on the general PR, just 2 Lines of Code The question was anyway more about the other info-only fields ("Payload" and "Credits / Payload"). I hardly miss them in current release (See left part of screenshot). If your good with them i include it in the general PR. Another small question is the grouping in the Context-Menu. As the field-count increases i'd like it to be grouped, but would it let expand by default. Especially if you have other mods installed that clutter the UI with a lot of fields (like HotSpot) you're always searching for the relevant fields in the context-menu. What do you think about that, should i include the grouping or should i remove it from PR (AFAIK no other USI modules use the grouping currently, so probably for consistancy-reasons...) Wow, looks very nice so far , looking forward seeing the result

We could add a 'communicator' part that's explicitly for this purpose that you could slap on a capsule, that way we don't clog the part PAW. Could also be a UI option but that could get confusing if you have a lot of vessels in the area and accidentally WOLF-ize your science base... Sounds like a good solution to the problem, easy and functional withoud UI cluttering The 'route cost' you see there is your cost in TCs - for payload see below The PrintScreen in my Post was my suggestion, not the current implementation, to clarify and show the problem, another screenshot with both transport-computers side-by-side (Completely dry vessel, so with my payload-calculation not a that good performing route ): Also, level 5 Kerbals are exponentially powerful in WOLF since you've probably seen the long chains you need to get stuff to work Sounds legit, was just a tought Lots of good stuff here. Refueling to reduce transport cost is by design. But the issue as you found out is folks loading up on mass at the end. We're going to be introducing WOLF Kontainers that are used specifically for route setup, so that's the only mass that counts for payload calculation (your loss of ship mass is still used for route cost in TCs). Refueling to reduce transport cost is by design: Well, ok, accepted. But the issue as you found out is folks loading up on mass at the end: This was not my concern, if folks want to cheat i have no problem with that. My concern was that you are in no way able to refuel during transports without cheating. We're going to be introducing WOLF Kontainers that are used specifically for route setup: I know, just tought by available resources would be easier to do because otherwise you need to add a lot of parts (different vessel sizes, mk3, ...) to keep the range open for small and large routes That one's a toughie. Part of the reason for making you do all of those journeys to build up your transport network is a balance function. @DoktorKrogg - thoughts? As my suggestion is to add it to transport-computer you still need to fly it multiple times if you need more payload later in the game. It is just a multiplier before connecting the computer to destination depot. This way you can only modify the current route and no additional information on routes need to be stored inside WOLF. As noted my main concern was when flying long routes (interplanetary) and you end up with a few less payloads than expected / needed you need to wait / timewrap for next TransferWindow just to fly the exact same transportroute again. I understand the balancing need to fly the transport routes / build vessels for it and all of that and think it is a good thing. Just tried to solve the edge case for interplanetary transfers More than happy to do this Thanks Will do

Missed one suggestion in my previous post: It is more a question than a suggestion and nothing tested on it so far, but what do you @DoktorKrogg think about a multiplier-setting on transport-computer (Only integers, no decimals) before connecting to destination? It was just, if i'm able to fly it once, i would be able to fly it twice. But when i fly a transport-route from Kerbin to Jool and after reaching destination i notice that payload is too low, i need to wait for next transfer-window to fly again. This would either result in forgetting the current project for a long time or timewrap multiple months.

You asked, so here you are First of all, @RoverDude and @DoktorKrogg, thank you very much for all of your great work. I really appreciate it. Your work make the KSP experience a lot more interesting! I'm playing since a long time with MKS and was recently able to get my feets wet on W.O.L.F in a new career game. Think it is a great addition to the game. I'm not that far progressed currently to have tested all of it as it took a long time getting to W.O.L.F in CTT (absolutely fine with that). So far i really like everything about the way W.O.L.F. works except the Transport-Computer. All of my findings / suggestions are already implemented on a GitHub fork (Well, almost, except point 1.3) to test them in game, i think it plays well that way. Just tell me what Points you like and i can do a Pull-Request on Github. My findings so far: Found some Bugs: Can confirm the finding of @MaxPeck, just needed to make sure first no other mod caused the problem (As far as i found out WOLF does not handle the Kerbals in any special way, they just automaticcaly "die" when wessel goes Poof, when Respawn is enabled they get state MIA instead of KIA) => Should be easy to solve, just change the kerbal Type to Applicant instead of let him die (Same logic in Stock if you fire them from Astronaut Complex, also no Penalty should kick in this way) The 3.75m Fuel hopper ratio for reqeip "Liquid Fuel" seems wrong (takes more resources than small version, but same output => HopperFuel375.cfg change Ratio = 0.0185185 As far as i can see there is no possibility to add only a CrewMember to depot => Not sure about that, but probably there should be a Button "Connect to Depot" on every part that can have crew?? Balancing Issue (probably, not sure if intended for some reason) Kerbal "Resources" are multiplied by experienceLevel (stars), regarding that star-leveling is not linear probably a balancing issue (https://wiki.kerbalspaceprogram.com/wiki/Experience#Levels) => It would better match to multiply by XP (depending on balancing probably XP/??) as it is quite hard to get a 5 star kerbal and you one get only the value of 5 zero star kerbals. This would make training kerbals interesting as you get a real good benefit on LifeSupport- / Habitation-Savings, it could even be balanced by XP/12, this would not give more benefit as currently, but it would be linear by effort provided to train the kerbal. In my opinion you should get more than just 5 points for a 5-star kerbal (But i think you took more time than me to think about balancing so far ) Transport-Computer If i havn't missed something i'm not able to see how good a route performs before connecting it to destination depot. Especially in career mode this is a problem as transportcredits are very expensive to get. => Add Route-Cost to in-flight context-menu (or simple, but not so nice => Add a confimation-ui for connect-to-destination where you see the cost) => Nice-to-have addon: Add "Cost / Payload" to easily compare different flights Refueling during transport increase payload (unrealistic, why should it) => Track lowest mass during flight instead readout while connecting to destination If a vessel is barely able to reach the destination and arrives completely dry, i can still get a lot of Payload if the craft is heavy enough (unrealistic, where should that payload be stored? With more weight the craft would not have been able to reach destination) => Calculate the payload based on resource-mass instead of vessel-mass Cost calculation Refueling during transport reduces cost (unrealistic, the opposite should be the case as more fuel is needed for transport) Flying with high-efficient fuels (like karborundum) a route will be very cheap because almost no mass is lost. But it should be expensive as the fuel is hard to mine and expensive to buy => Calculate the route-cost based on "burned fuel cost" + "vessel dry cost start" - "vessel dry cost end" Code-Suggestion Change some methods in code from "private" to "protected virtual", this would make it a lot easier to implement custom Transport-Logic for other modders (This would have saved me some time while testing ) - CalculateRouteCost - CalculateRoutePayload - ResetRoute => Or OnResetRoute (new method with calculation-related logic extracted from ResetRoute) - ConnectToOrigin => Or OnConnectToOrigin (new method with calculation-related logic extracted from ConnectToOriginEvent()) => Even better create a WOLF_AbstractTransporterModule and make CalculateRouteCost and CalculateRoutePayload abstract, implement calculation-logic in WOLF_TransporterModule : WOLF_AbstractTransporterModule Except the cost-calculation (Point 3.4) all of the suggestions are very lightweight simple changes adding almost no complexity. Point 3.4 is a bit more complex, but in my opinion well worth the added realism / possibilities. As it uses only basic KSP-API methods (vessel-resource-enumeration - vessel-part-enumeration - part-definitions - resource-definitions) i don't expect them to change in future => code should be easy to maintain. @RoverDude @DoktorKrogg If you tell me what of the above implemetations you like i can do a PULL-Request on github for them, just not able to do a single request for every point now as they interfere with each other

Thanks for the detailed replay and sharing some future ideas on WOLF @DoktorKrogg. Fair enough, i totally understand this Agree, probably you got me wrong, just let everyone cheat if he wants, i have no problem with that My main concern was that if i do things like refueling my transporter once in orbit i feel like cheating, and i don't want to cheat. But refueling is a gameplay style, and i thought that especially with WOLF (it's main purpose is to produce thinks like fuel off site) i should at least post my thoughts on this before you put even more effort into TransportRoutes. It felt just wrong to let you do all the work, and once released come up with "i think this is not an ideal solution...". I was just looking for a way around this single "problem", and once i was in the subject, well, i think you know how it is..., one led to the other But anyways, i don't want to argue with you, i totally understand your arguments and think you two did a great job so far on this, many thanks for all the time you're putting into making this great game even better

First of all, many thanks to making and maintaining your mods, really enjoying playing with them. @RoverDude @DoktorKrogg Sorry for posting it here, found no place to give feadback regarding WOLF beta. I understand that there is no thread before official release, but watched your last TwitchStream and have a suggestion regarding your TransportRoute exploit discussed at 00:40 As i can see there is currently not only the exploit problem: Refueling is like cheating as it raises Mass => More payload and less cost for route, but should be allowed as it is nothing special for large distances to refuel once in orbit A heavy ship will give a lot of payload => Why getting payload for i.e heavy engines? Cost is related to mass Regarding staging, an expensive but lightweight engine is cheaper than a heavy cheap engine If i have a ship flying with karborundum i have almost no cost as i don't use much fuel (but very expensive fuel) Possibility of free routes I think there is an easy solution to all of this: Calculate the payload as minimum resource mass in vessel during transport (This is the amount of resources you could have transported) Ability to refuel, no additional payload given Ability to dock / undock No exploit Calculate cost as sum burned resources + dry-cost of parts lost (staging) Cost relates to real resource cost used on route Cost relates to part-cost you staged away The implementation should not be very hard or complex, but as currently only binaries and no source is public i was not able to test anything of that. I checked the source with a decompiler (hope this is ok for you, if not give me a note and i delete the linked file immediately) and made an example implementation. As mentioned, no possibility to test as not complete source available / found Checkout this as implementation suggestion