Smoovious

And then you have KitOS... their ultra energy-efficient single-bit processor operating system.

I wouldn't even attempt to join 2 straight segments together like that... would have to use either a prefab curved piece, or a piece you could set start/end angle and radius on. As for switches, getting them lined up to a pre-fab switch assembly wouldn't be difficult. Each end would have to be configured to orient the attachment point, which is (should be) straightforward. The curved pieces would look like several small straight segments attached to each other, just for rendering purposes. Drawing a circle with 32 straight lines is faster than computing all the points of the circle, but as far as the code is concerned for collisions, it would still calculate as round, ignoring those slight corners. -- Smoov

Looks like that texture is being stretched over the whole length of the plane, instead of being tiled. -- Smoov

Well, my thought for track occupancy is having some automated traffic running... that's where not knowing how versatile the possible scripting was, came in. Also, if the efforts to have some form of multi-player available, has some significant success, you could have several cars running on the track bound for different places. Will have to see about how that project turns out. The axis-rotating points should work fine, as long as unbalanced weight isn't an issue. It would solve the space-at-a-premium issue where you need several parallel tracks. As for having a full yard, yes, space on undeveloped land is plentiful, but every single piece you use will have to be transported... so resource efficiency is a concern with which way you go. In this case, how many trips, and how much fuel, will be needed, that is where the cost comes in.

Well, I dunno how effective it would be in a yarding situation, but for the kind of track you're using, basically having a type of conveyor below the track segment where you want a line to diverge, to slide the straight section out sideways, sliding in a curved section to fit in there, would suffice as a switch for that type of track. It isn't elegant, but effective.A way to control it would have to be worked out, with perhaps some stops set up in the track to prevent a car from trying to go through the switch while the switch is moving (not locked in place), or if the switch isn't lined for that track... some way for the car to detect it has to stop up ahead, so it can come to a controlled stop, and a way to know it is safe to proceed again... I don't know what kind of scripting is capable, but might be doable... and if it is, then track occupancy and signalling can be dealt with too. As for a yard, that is why I was thinking of some kind of stackable system in place instead, just removing the unused cars from the track entirely. It would save on square footage, and in a space/vacuum situation where the building serves as a biosphere, the larger a construction is, the more danger you have for structural failure. If the cars are just going to be flatbeds with cargo strapped to the top, being stackable (like skids with wheels) would/should work. What the guys who have programmed Run8 have done for couplers, for the physics, was used a _very_ stiff spring between cars. Don't know how that would work out in KSP, but since I see our creations flex in different situations, that might be possible as well.-- Smoov

hmm... I wonder, if you're making them modular, then maybe in a shape that would make it possible to stack them when not being used... like... off to the side of the track at the loading/unloading point... crane lifts the car off of the track area (where the T section is missing), moves it onto the stack of unused... and when you need one, crane takes off of the stack, places it in the groove where it would be loaded, before sending it on its way. I have other thoughts too on how switches can be handled... not sure if occupancy detection would be possible... I can forsee some people wanting to make a whole transit system on one of the moons to support their base operations. (like me ) -- Smoov

hmm... ok, you don't even need to update the position all the time, either... only when you've used some kind of thrust to change your trajectory, or a gimbal or thruster to change your orientation... the rest of the time, you could just keep each other updated using orbital elements... back in the day I used to use a program called STS Plus, which I would use for tracking satellites (and the shuttle when it was up). I would get the orbital element sets through a NASA feed, and the sets get updated when a trajectory changes. Like, when one of the STS missions, would push the ISS up to a higher orbit, then we'd get updates for the STS and ISS missions after the maneuver and they have got a fix on the new orbits. When they had to have another satellite do a small burn because their computers are warning of a possible collision with another one soon, they'd send an update out for that too. So... probably don't have to send the info on position/orientation constantly... -- Smoov

KS-Dos v1.0

if spline editing were possible, you could make track similar to what the tubular steel roller coasters use. main advantage of that kind of track, is the vehicle is locked onto the track and can't fall off. (not without breaking something, anyways) that would take care of the problem of too much thrust/torque making you fly up off the track. that would be kind of nice. finally make it to Mun in one piece, and to celebrate, ride the Munar Coaster. -- Smoov

um, ok, perhaps we're getting a clash of differing ideas of what the multiplayer would even be. My thinking is a group of 3 or 4 (or even more) doing something cooperatively on either the same task, or similar tasks, while it seems others are looking for some kind of massively multiplayer 24-hour server for everybody to be on at once. The latter just isn't practical. If the celestial bodies didn't orbit, and stayed in static positions, no matter how fast you timewarped, then people independently timewarping their orbits around fixed objects wouldn't be an issue. [edit: It could be possible to implement this on a case by case basis, if someone wanted to run a server with static celestial bodies, accepting giving up some (well, more than some) realism, for the sake of camaraderie. This would make it possible for individuals to timewarp independently, but then you lose a big chunk of what makes KSP fun in the first place.] The celestial bodies do orbit, however, which effectively puts the player who timewarped, on a different 'map', than the players who didn't. You couldn't keep them in the same instance together. Even if you were just doing a planet and its moons, you still have the same issue. You end up being in a different, incompatible, reality. It is either all timewarp, or nobody timewarp. Those are the two possible choices. Any other combination, just isn't practical, or possible. Anyways, working out sync'ing timewarps between players is relatively simple, and probably the easiest part of coding a multiplayer addon. Sharing the rest of the data in a manner that keeps your position on everyone else's computer, accurate, is the harder part. Let them focus on that, instead of trying to keep arguing for something that just isn't going to happen. -- Smoov

that would be covered by using the lowest common setting of everyone involved... so I could set mine at 50x while someone else is still doing local maneuvering at 1x, and then run to the store for smokes, and he can raise his setting to 5x, 10x, 20x, 50x, as he wants while I'm gone without having to wait for me to answer a prompt for permission. My setting my side at 50x already gives my permission for up to 50x. My end wouldn't be running at 50x at that time, it would just be permissive up to 50x, as there are other clients who are running slower at the time. -- Smoov

The problem with one user timewarping and the other users, not, all revolves around the fact that everything (except perhaps the sun) is in motion. You cannot just timewarp your craft and have it reappear in the proper position when you're done, because by then, there is no proper position. Your planets and everyone else's planets are in different positions. At that point, you're not in the same universe, and you might as well just be running an in-game chat system, as everything else won't sync back up. Either everyone warps, or no-one warps. There just isn't a way around that. -- Smoov

Well, if you're able to override timewarping, you could end up implementing it as a lesser of everyone's setting... So if you have 3 people, one is set to 100x, another to 20x, and a 3rd to 10x, then all three would go 10x... then as the slowest one, speeds up after his maneuver, setting his to 50x, then all three would go 20x, as the 2nd player's warp setting is now the lowest. -- Smoov (ps: I'm new. o/ ) edit: Ok, I posted that early on in the thread. From what I've observed, the problem with multiplayer in KSP isn't very different to some behavior I see in another sim I play. (Run8, a multiplayer railroad simulator) In Run8, each client handles the physics for their own train only, and everyone else's trains just share positional data. The plus side is that it lowers the computational load on each client's computer. The down side, is that we always have sync issues. One person's train that I see on my screen, may not be precisely accurate, as it may be shown a few feet ahead or behind, on another person's screen. When we're doing some yard switching cooperatively (one engineer, one conductor), we have from time to time, thrown a switch when we saw the last car clear the switch, but on someone else's computer, the last car hasn't cleared it yet, and the thrown switch, makes the car split the switch and go down 2 tracks at the same time. This also becomes an issue, when one engineer, is picking up cars left from another engineer's train, and they're backing up to couple, and it may look to me like their couplers are perfectly lined up, while on their screen they still have another 10 feet of space to go, so even tho I tell him he's there, his physics (since he's in control of the train) disagree. I see this as a problem caused by the way they implemented multiplayer from the ground up, and I don't see anything they can do, to get rid of it completely, unless they change the way multiplayer is implemented from the ground up. Since they aren't truly sync'd up, we often don't see the same thing as each other. Different vehicle traffic on the grade crossings being the most obvious. Another game I've played, is OpenTTD... and while it isn't a sim in any sense of the word, the way it implements multiplayer, locks everyone up to seeing the exact same thing at all times. It uses nonces and seeded random number generators, and instead of exchanging positional data of our vehicles, it just exchanges the commands between the server, which in turn, passes them onto the rest of the clients, so all of the clients know to apply that command at the specified nonce. All random numbers are generated with the same seed based on the nonce, so we all end up seeing the same exact thing. Again, there is an upside and a downside. Upside is, everything stays in sync, and everything is in the same exact position on everyone's screen. Downside is, that everyone has to compute everything for themselves, increasing the processor load. There would also be some lag-time between when you moved a control, and when you see the effects, but that could also be realistic too. Also, this isn't a sim, but a transportation-related game, so there is no real freedom of movement to begin with, but the principle still applies. In Run8, if they switched to the nonce/seed method, then the clients would pass along the commands to the server instead of positional data. Throttle position changes, brake handle/pressure changes, etc. Then, assuming everything else stayed properly sync'd, every piece of rolling stock would be in the same exact place on the track, no matter which player's screen it is being viewed from. This would also allow us to kick cars (something that we really want, but just isn't possible with the current networking method. When we pick up and drop off cars, they are added/removed from our single train object, which sounds like it is similar to how KSP treats the joined pieces all as one object) So... since KSP wasn't designed with multi-player in mind, I don't think having that kind of precise interaction is very possible. We may have to accept being able to work near each other, without being able to couple up our pieces together. Even if that's all we can do, that would be HUGE, and I think it should still be tried. Last thought... is it even possible in KSP, to position objects, and keep updating their position, while ignoring physics on the non-host computer? (host being the one that is actually controlling the craft) -- Smoov