Jump to content

[0.22] Extraplanetary Launchpads Legacy Thread


skykooler

Recommended Posts

Not as such, but you can turn on Kethane's debug mode and use the "generate here" function. You can also play with the generator itself (I don't know the details, but look in EL's resources config file).

Link to comment
Share on other sites

Does the Smelter object have a particle emitter associated with it? I was looking to add some particle effects to show the conversion process is working, like I did with the Auger.

All I can see in the CFG file is some commented-out sections relating to the ModuleAnimateHeat MODULE. Has the animation been removed?

Thanks!

Link to comment
Share on other sites

As far as I know, the smelter too has no (working?) animations. I have yet to analyze it with my blender importer (partly because it doesn't import animations yet).

The smelter has a heat animation; it's supposed to glow when in use. But the stock heating module didn't seem to like it so I just gave up. I haven't tried with Kethane's converter animations.

Link to comment
Share on other sites

Yea I tried messing around with the ModuleAnimateHeat MODULE and it wasn't working. So no particle emitter in there? I'm not too worried about the glow, if I can just create some sparks or something that would be fine with me...

Thanks!

There is no particle emitter, I hadn't even thought of that.

Link to comment
Share on other sites

I still have some polishing to do (eg, ensuring fuel-lines don't break), but for the brave, I have just pushed support for orbital construction to my github repository. Once I'm satisfied, I'll send the changes to skykooler.

There is one semi-serious problem (with a work-around): the ships stay stuck together after releasing. The workaround is simply to quicksave/quickload after building (it seems both before and after release work equally well).

For now, anything that acts as a pad also acts as an orbital construction dock. The built ship is "docked" (docking ports not required) to the construction dock and must be released (via a context menu button).

Obvious todo items:

  • Take care of fuel-lines.
  • Fix context menu buttons after building in orbit.
  • Create a reasonable model (I used a modified clampotron sr for testing).
  • More testing.

orbital.jpg

Link to comment
Share on other sites

I've also tried applying standard KSP graphics effects with no luck. I've combined a few engine FX to make something that looks pretty good. Just add the following to your Smelter part.cfg file, below the node_stack section and above the TechRequired line:

fx_exhaustFlame_blue_small = 0.75, 0.0, 0.0, 1.0, 0.0, 0.0, active

fx_smokeTrail_light = 0.75, 0.0, 0.0, 1.0, 0.0, 0.85, active

fx_smokeTrail_light = 0.75, 0.0, 0.0, 1.0, 0.0, -0.85, active

fx_exhaustLight_blue = 0.75, 0.0, 0.0, 1.0, 0.0, 0.0, active

fx_exhaustSparks_yellow = 0.75, 0.0, 0.0, 1.0, 0.0, 0.0, active

Unfortunately this makes the FX appear all the time, not just when the conversion process is active. I've tried using all the FXGroups I could fine (running, power, engage, disengage, activate, deactivate, prelaunch, decouple, flameout) and none of them work. Would it be possible to have the activate/deactivate toggle in the GUI work in setting part states in a future update?

Or just add a particle emitter like the one that exists in the auger. Either way would work, although I think the built-in FX require less computing resources than the particle effects...

Link to comment
Share on other sites

I've also tried applying standard KSP graphics effects with no luck. I've combined a few engine FX to make something that looks pretty good. Just add the following to your Smelter part.cfg file, below the node_stack section and above the TechRequired line:

fx_exhaustFlame_blue_small = 0.75, 0.0, 0.0, 1.0, 0.0, 0.0, active

fx_smokeTrail_light = 0.75, 0.0, 0.0, 1.0, 0.0, 0.85, active

fx_smokeTrail_light = 0.75, 0.0, 0.0, 1.0, 0.0, -0.85, active

fx_exhaustLight_blue = 0.75, 0.0, 0.0, 1.0, 0.0, 0.0, active

fx_exhaustSparks_yellow = 0.75, 0.0, 0.0, 1.0, 0.0, 0.0, active

Unfortunately this makes the FX appear all the time, not just when the conversion process is active. I've tried using all the FXGroups I could fine (running, power, engage, disengage, activate, deactivate, prelaunch, decouple, flameout) and none of them work. Would it be possible to have the activate/deactivate toggle in the GUI work in setting part states in a future update?

Or just add a particle emitter like the one that exists in the auger. Either way would work, although I think the built-in FX require less computing resources than the particle effects...

I think Majiir added custom particle effects to Kethane that can be defined in the .cfg. Those would probably sync to the conversion.

Link to comment
Share on other sites

I think Majiir added custom particle effects to Kethane that can be defined in the .cfg. Those would probably sync to the conversion.

Yea the Auger model has a particle emitter, so I was able to add the KethaneParticleEmitter sparks MODULE to the CFG and it works like a charm, emitting sparks when the Auger is extracting ore. I tried the same thing with the smelter and neither the sparks nor gas emitters work so I assume the smelter model doesn't have an emitter defined.

The built-in effects are also Unity particle systems, so performance will be similar. Converters don't currently support particle effects, but I could add that easily.

Ah that's interesting, thanks for the info. I assumed the FX stuff was texture-based or billboards or something, but if they are just pre-defined particle fields then yea I guess the performance would be the same. Yea, if you want to add a particle emitter to the smelter model that would be great, or just define some FXGroups so we can add the built-in FX stuff ourselves.

Link to comment
Share on other sites

You misunderstand how KethaneParticleEmitter works. There aren't actually particle emitters defined on the auger model itself. KethaneParticleEmitter is a self-contained module for defining a Unity particle emitter from a part config file. In the case of the auger (and the normal Kethane drills) the KethaneExtractor module manipulates any KethaneParticleEmitter modules it finds, positioning them at the drill point and controlling whether they emit particles. The reason adding KethaneParticleEmitters to the smelter doesn't work has nothing to do with the smelter model. It's not working because your emitter definition has "Emit = False" and there are no modules on a smelter that programmatically turn emitters on. The Kethane particle effects have nothing to do with the stock FXGroups system.

Link to comment
Share on other sites

I am pleased to announce the release of Extraplanetary Launchpads v3.4. Source code (GPL) is available on github (my version. pull request sent to skykooler).

  • Orbital Construction.
  • Support for a placement transform in the pad/dock.
  • Can build sub-assemblies.
  • debug is now DebugPad.
  • New part intended for use as an orbital dock (very simple at this stage).

At this stage any pad, the runway or the dock can be used landed, splashed or in orbit. When landed or splashed, operation is exactly as it was before. When in orbit, the new ship is spawned "docked" (docking ports not required) to the construction dock and must be released (the build menu will be unavailable until the new ship has been released). To release the ship, right click on the dock and click "Release". Once the release bug (see below) has been worked around, the new ship will slowly drift away (as expected for two objects in orbit).

Known Bugs

  • Ships built in orbit do not properly separate from the dock, however, saving and loading (or any other means of causing the ships to unload/load) fixes the problem. The save/load can be done before or after release.
  • Docking ports spew NREs, at least when the ship is spawned on the ground. I expect save/load will fix the issue.

Link to comment
Share on other sites

With the 'release' mechanism effectively tying up the dock until it's hit this could act as an 'in construction' feature if that might get added later. IE, building things takes time, during which you can't use the orbital dock (unless you cancel the build). I know some people wouldn't want construction to take time, after all the VAB construction doesn't (Not sure if Squad ever intends it to take time in the finished game), but I certainly would. A switch to enable/disable this as a feature and maybe a 'construction speed' in the cfg would be very nice. Do you think that might get added in to this?

Link to comment
Share on other sites

That would certainly be possible and is something I hadn't seriously considered (if at all). The release mechanism wasn't for game-play purposes, but rather because my way of dealing with the various parameters for the spawned vessel was to destroy the vessel (by docking it). Once docked, it of course needs to be released...

It turns out there is something that still needs to be done, as shown by the need to save and load to get the ships apart properly.

Link to comment
Share on other sites

I have to admit it is fascinating seeing this develop. I'm definitely going to test this. Suggestion (I think already considered for the Orbital Construction) for the eventual release. Limit how much can be built at any given time, but the limit can be raised somehow. Maybe an extension on the 'builder' component, or added computer power, or just actual energy transfer mechanism (meaning a component and some energy needed, scaling with size of vessel). It would seem logical to have some off-world construction plant start small, able to build small rovers and escape ships etc, then increase the scale of output gradually. Myself I'd say the components to increase it's size should be a hair larger than it can build, at least at first, forcing you to ship upgrades from KSC at least for a little while. Eventually it should be able to upgrade itself. Of course this is just my thoughts on the matter. I'd like to hear what other players think would be a reasonable setup.

Another way would be to have the current unlimited ship size on the sandbox game, but in Career limit size based on tech nodes. Could be either just allowing mass of constructed items to be more as you go up the tree, or open up upgrade components that increase size as you go up the tree. If the latter I think then the off-world pad should be able to build the upgrades itself. It's already adding in another level of complexity putting in the need for research.

Just a few thoughts I had on where this might end up when complete (assuming Squad doesn't beat you to it with a release! :) )

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...