allista
-
Posts
2,208 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Everything posted by allista
-
While I'm not questioning your figures, I want to ask: does it really so cripple your game experience, or are you just playing purist out of principle? I've spend a good measure of time optimizing the textures lately and have lowered their number considerably. And I'm not a 3D modeler, mind you, I'm a programmer (well, to be honest, I'm a microbiologist, but no matter ). If you want to help, you are welcome to reunwrap and retexture any models you like. If not, I don't see the point: be assured that I'm concerned with the number and the size of textures as it is and try my best to keep it low. But still, this is not my priority until it is a real problem. Oh, and to be completely fair, I've also counted the number of parts in the Hangar and Squad: 44 and 218 respectively. So the number of textures per part in this mod is close to that of the stock game. *and I do remember your original request.
-
There's nothing suspicious in the Player.log; and that is very suspicious indeed. Here, I've compiled a debug version that should spam the log with some messages when you're trying to bind a new key. Try it, please, and share the log. https://www.dropbox.com/s/hdvhsgwhncv8lof/ThrottleControlledAvionics-v2.1.1.zip?dl=0
-
I doubt it could work. The HangarSpace parameter is a string, a name of a mesh inside a model which determines everything: volume, dimensions, walls. It can't be scaled. It would work only if the TweakScale could call the Setup methods of the HangarMachinery and HangarPassage classes. And this is only possible if I write a TweakScale updater and link it against TweakScale redistributable. I'll consider your request about models-textures. It will make my workflow a little more complex and error prone, though. A little. - - - Updated - - - But to what end? There's nothing inside the Fairing Hangar until you launch the payload. It's empty, and that's the whole point of it. And Proc.Fairings are much better for that anyway.
-
And how does it work?
-
Did you scaled the Mk2 bay with the TweakScale? If so, no wonder: Hangar currently does not support TweakScale (and provides its own scaler, for a reason). There are two possible solutions: either to add the HangarPartResizer module to Mk2 bays (this is simple, I haven't done it because they are match only to the stock Mk2 parts); or implement TweakScale support, which is not so easy and, again, I use my own scaler for a reason. Don't know what's best, honestly. -- It's because the storage space of the Inline Hangar is a hexagon, but the storage space of the extension is an octagon; these are real meshes and they are scaled with the parts. So yes, the extension has a little more room. Here, I've just written a short explanation about hangr dimensions and vessel storage.
-
Hangar v2.3.0 for KSP 0.90 is released All download links are in the main post of the thread. This the major update featuring the long wanted Fairing Hangar and more.
-
How on Earth? The little button in TCA window right beside the "Enable" button. It shows currently used key and pushing it should allow to change it.
-
True. And that behavior is described in their part info cards in editor: "Vessels can pass through:"
-
Changing height is not compatible with its swinging animation (the model space becomes anisotropic and the animation distorts). So I decided to make it closer to cube as a more general approach.
-
What a beast! Well, with this particular hangar you first need to add the HangarPartResizer MODULE into its config, because I made it just for Mk3 parts and thus didn't think it should be resizable. Look at other configs and at these two posts: http://forum.kerbalspaceprogram.com/threads/88933-0-90-0-Hangar-v2-2-1?p=1772233&viewfull=1#post1772233 http://forum.kerbalspaceprogram.com/threads/88933-0-90-0-Hangar-v2-2-1?p=1772821&viewfull=1#post1772821 And to increase the max size of the resizable hangars (e.g. inline ones), you need to change the size limits in Hangar/Common.cfg; names there are self-explanatory, I hope.
-
I doubt it. Don't possess the .23.5 version anymore and all the development was done on .90; but considering .90 API changes in autopilot callbacks it should not be compatible. Sorry. - - - Updated - - - Looks amazing! Actually, after the argument here, I have been thinking of at least dropping the calculations into a separate thread for speed, and maybe trying to use some third party solver; certainly, I don't believe I can do a better job than specialized code. But for me this mod was also an exercise; and I have started from an almost dead project with some code already written, and my time was limited. Anyway, why don't you just finish your mod? It already has the lpsolve integration and, judging by the video, copes much, much better than TCA! [uPD] I wonder, though, how does it manage with asymmetric designs that produce unsolvable systems for some input combinations?
-
TCA is not an AI, it can't "work out" anything. I've shown you the equations in general form; complete algorithms are available at GitHub. Please, feel free to examine them if the general form is not sufficient for understanding. You may also look at MechJeb's RCSBalancer code which does exactly what you want. And don't forget to evaluate its performance, for that matter. I'm sorry, but I have no other means to answer the "how come" question.
-
I don't know how KSP measures dimensions, but does this look like 85m long to you? Try to build it gradually from scratch and see how dimensions are changed in both windows, how the dimensions are added up. I'm pretty sure of the accuracy of my calculations.
- 1,633 replies
-
- 2
-
-
- part count
- storage
- (and 1 more)
-
Because there's no easy way to know if there's an obstacle; you can't raycast, as even the "flat" is actually a segment of a sphere, and there will be scatter objects and small folds and all. Besides, a random walk is the most general way to get from point A to point B on a fractal, procedurally generated terrain. We have no predefined tiled map, so conventional path-finding algorithms are not applicable. Don't worry, objects on a straight line without obstacles are connected by random walk in an instant, even if far apart. So waypoints, virtual or real, are needed only in cases where start and end points are disconnected by, for example, a huge gulf or a mountain range; something that forces the walker to go very far around. We're talking about several hundreds to thousands kilometers, not 5 or 10 (look at the pictures on the previous page). And don't forget, it's only the first test of the algorithm. I'm working on the improvement. So maybe the waypoints will not be needed after all.
-
Idea is a little the opposite: you put waypoints to speed up the pathfinder and help it navigate in a complex terrain. Anyway, virtual on-map waypoints or real ground hangars for maintenance?
-
When a vessel is Landed or Splashed, it is automatically positioned right above the surface in the correct orientation when you switch to it. So changing just latitude and longitude should be enough for it to be correctly loaded afterwards. - - - Updated - - - Exactly!
-
It does. But you're requesting to solve a very different mathematical problem. Currently TCA solves the following equation: F(t1,...tn) = Needed_[B]Torque[/B], where t1, ... tn -- are thrust limits of engines. That is why TCA kills horizontal velocity by pitching, not thrusting: it only controls rotation. Your suggestion, on the other hand, may only be expressed as a system of two equations: F1(t1,...tn) = Needed_[B]Torque[/B] F2(t1,...tn) = Needed_[B]Thrust[/B] That is a much harder problem which, I'm afraid, cannot be solved in a reasonable time in each physical frame (4-2 per visual frame). Even now the solver uses iterative optimization algorithm which performs fast approximation, not actual solving. - - - Updated - - - I'll add this functionality in the next release. But as I am now up to my ears in work, I can't estimate the time it will take.
-
As MCMC is essentially a random walk, you never can tell how much time it will take. But statistical average is bearable -- several seconds in coroutine for 100-300km with obstacles. But we're talking not only about time calculations: if the pathfinding works, we can move the real vehicle on the surface, so you can see it in the map and switch to it. I mean real transportation, not just emulated. What I'm thinking is that we can forbid a vehicle to travel more than some distance (say 500km) without maintenance in another hangar (which is perfectly reasonable). This will cover dispersed bases, but transfer to another corner of the world will require a network of hangars; this, among other things, will deal with the problem of looong searches of looong paths. And, IMHO, this should be interesting to implement in game. - - - Updated - - - I see. But if you're building the network of bases anyway, you could place several intermediate hangars along the route. I know, this is harder, but I feel it should be more interesting, shouldn't it? Nah, the walkers time out because they try too hard to go straight to the target: if a walker meets an obstacle, it "tries" (no AI, just probability) to search the neighborhood, but if it walks too far away from the course, its lure to the target overcomes its side-searching and it starts to whirl in ever increasing loops. Given enough steps it eventually should find a path, but not in the reasonable time. I see several possible solutions here: 1) dynamically change the temperature of the walker (i.e. its tendency to walk absolutely randomly) when it is stuck; the hard part is to define the 'stuck' state numerically. 2) create an in-map interface to add virtual waypoints; in difficult cases a user could just tell path-finder to not walk straight to the target, but through several intermediate points. 3) as I said earlier, implement a recursive walker that will first reach the target using huge steps, and then will use that path as a set of waypoints to reach it with the needed resolution. - - - Updated - - - Oh, I see: the pictures are somewhat misleading! The path you see is a final path, all loops removed. Loop removal is a part of the algorithm that keeps memory of visited locations. So you don't see all the steps here.
-
Not abandoning the idea of teleportation, I still find the pathfinding problem fascinating enough to try it first. Here are my results so far: 1) In most cases, with proper step probability construction a single MCMC walker finds a path to a reachable destination in less than 100000 generations; given the step is not too small, of course. 2) I haven't yet established a separate thread for the calculations, so I do them in a coroutine, 10 steps per frame. This still results in some framerate decrease as the search progresses, but not considerable. As a consequence, depending on the distance and relief complexity the search takes up to 4 minutes. 3) Walker fails if the characteristic dimensions of a relief feature that hinders direct approach is much greater than the step (you'll see this in the pictures below). I'll try to overcome this by performing a kind of recursive search with decreasing step size. But may be it's for the best: who would send a rover on a trip to the other side of a planet? Here are some examples: (x -- longitude, y -- latitude, color -- height in meters; start and end points are shown as small yellow circles; step 0.05 deg unless stated otherwise)
-
Hm... don't exactly know how the RMM works, but considering what it does I'm not surprised there's a clash somewhere. Thanks for your report and testing.
-
2D, my error: scalar fields do not constitute additional dimensions, as they depend on the position. Silly me. Or rather sleepy me I've looked into the way CelestialBody and SCANSat work, and found (not surprisingly) that planets/moons are quad spheres procedurally generated from seeds. It's not a problem, though, as the PQS class that defines planet's surface can report surface height at any given radial position, so we may as well set the walkers to walk the real lat-long coordinates with some step, restricting the change in surface height per step and heights below ocean level if there's ocean. I'll experiment with the thing a little and report back... But I still can't see how to justify the need for a hangar to build a route and send a rover. Command base with needed equipment? And does routing logically conflicts with teleportation? Could it be reasonable to have both at the same time? E.g. teleportation costs too much to transport anything heavier that 2-3t?
-
specificMass = mass_of_volumes, mass_of_surfaces, mass_of_cables, const_mass part.mass = mass_of_volumes + mass_of_surfaces + mass_of_cables + const_mass The same goes for the cost, except for the thing with resources: specificCost = cost_of_volumes, cost_of_surfaces, cost_of_cables, const_cost part.cost = cost_of_volumes + cost_of_surfaces + cost_of_cables + const_cost + cost_of_maxAmount_of_resources For a tank you would probably want to assign all of its mass (and all of its dry cost too) to a surface component. So it would look like this: mass = 0.14 cost = 500+cost_of_maxAmount_of_resources ... specificMass = 0, 0.14, 0, 0 specificCost = 0, 500, 0, 0 Then the dry tank would weight 0.14t and would cost 500. To calculate the cost of maxAmount of resources you need to look at the ResourcesGeneric.cfg in Squads folder under GameData, at the unit cost of the resources.
-
I like your idea and I like your reasoning. And naturally I now have plenty of ideas of my own about the teleportation and all But I've just discussed the whole thing with my wife and came up with an idea of a cheap routing algorithm: we just need to use the MCMC method. In a finite 3D space (and a small one, I would say; what are the dimensions of planetary maps?) it should crack the problem in a split second in a separate thread; why, even if it does that in a minute it won't be a problem! I'll try to implement this in python for a model problem and see how it'll go. And of course if you decide to implement it on your own, I'll be glad to help. UPD: ah, I would definitely like to see this functionality in ground hangars; as they are now, they're not very useful compared to inflatable ones...
- 1,633 replies
-
- 1
-
-
- part count
- storage
- (and 1 more)
-
Suppose you have a config like this: MODULE { //mandatory name = HangarPartResizer specificMass = 0.3392, 0.4730844, 0.0, 0.0 //let's call this [B][Mv, Ms, Ml, Mc][/B], measured in tons specificCost = 1930.46, 431.712, 0.0, 0.0 //and this [B][Cv, Cs, Cl, Cc][/B], measured in game funds size = 2 //the size of a model as it is; remember that by default resizing is limited in interval [0.5, 4], but that's configurable through Common.cfg (will be renamed to Globals.cfg in v2.3.0) [COLOR="#696969"]//optional sizeOnly = true/false //only allow uniform resizing; mutually exclusive with aspectOnly; [U]takes precedense[/U] aspectOnly = true/false //only allow aspect (size in the Y direction) changes; mutually exclusive with sizeOnly minSize = 1 //overrides lower resize limit; the same goes for minAspect maxSize = 3 //overrides upper resize limit; the same goes for maxAspect //starting from Hangar-v2.3.0 (coming soon); the part will ignore the status of dummy parts in the TechTree (if they were purchased or not) even in career mode; //this also allows to override the limits in the Globals.cfg (i.e. all parts are resized in [0.5, 4] interval, but the ignoring parts are resized in, say, [0.2, 10]) IgnoreTechTree = true/false[/COLOR] } Then given the new_size, the mass and cost are computed as follows: S = new_size/size [B]dry[/B]_mass = Mv*S^3 + Ms*S^2 + Ml*S + Mc [B]delta[/B]_cost = Cv*S^3 + Cs*S^2 + Cl*S - (Cv+Cs+Cl) // Cc is eliminated All other parameters, such as the amount of resources, torque of reaction wheels, etc., are recalculated automatically by the plugin. I don't have configs like TweakScale to add custom recalculations as I made the Resizer for internal use and add them as the need arises. But you made me think: should I, may be, factor out some of the plugin's code into a light for-modders-library, or should I follow the Firespitter's path and leave the plugin as is, allowing to use only .dll for such purposes? Still: no custom recalculations on resize without additional programming. TweakScale does this job too well to try to reimplement it. Another thing to remember is how KSP calculates total cost of a part. It's a pain in the ass, actually. The cost parameter in part.cfg should include the cost of its resources, even if the initial amount of a resource is 0, or anything, really. I mean, if you made a tank that is able to hold 100 units of LiquidFuel, but which starts empty (or half empty), its part.cfg should contain cost = dry_part_cost+cost_of_maxAmount_of_resources. I emphasize, that I'm talking about the stock 'cost' parameter, not the module's 'specificCost'. That's why I now use my HangarSwitchableTank/HangarTankManager modules almost everywhere... Which one?
-
It's strange, but in this model I couldn't find any colliders that would made it hollow. Unless the author used the auto-generated colliders in Unity, which is very bad for performance... but no matter. I see the benefit of such design, and of course it's easy to add a HangarPartResizer MODULE to this part to change its size and aspect, provided the Hangar is installed. But I don't see the need for such tank in the Hangar mod itself. Until now I only added those auxiliary parts that were essential for some new hangars I made. I try to keep additional parts count as low as possible, because heavy part packs are very memory-consuming and we still have the 4Gb limit. So despite my liking of that and toroidal tanks, I cannot incorporate such parts into Hangar. I'm not even sure the three (instead of one) hangar-extensions/resource-tanks were a good idea.
