sumghai

[WIP] Sum Dum Heavy Industries Service Module System (Stockalike)

Recommended Posts

I wanted to let you know, the SDHI Clamp-O-Tron Parachute Variant, has become my default docking port on Every single thing I build now. Never know when I might need to at least attempt to safely deorbit something.

I also put it on my Duna cargo craft as parachutes. Craft doesn't even need docking but, this has drogue and parachute, attaches radially, and just in case I do need to tock it's available. Super handy part.

Share this post


Link to post
Share on other sites
I wanted to let you know, the SDHI Clamp-O-Tron Parachute Variant, has become my default docking port on Every single thing I build now. Never know when I might need to at least attempt to safely deorbit something.

I also put it on my Duna cargo craft as parachutes. Craft doesn't even need docking but, this has drogue and parachute, attaches radially, and just in case I do need to tock it's available. Super handy part.

Same here. It has everything I could ever wish for and I really cannot see switching back to the lame only dock docking port or the only parachute parachute. The only thing I changed were some of the opening values so that my crafts don't spend 15 minutes decending from 2 kilometers up.

Share this post


Link to post
Share on other sites
The fairing for LES is interesting, could be a bit better in my opinion. IDK, just doesn't fit very well with the LES from KSPX... but its better than nothing.

That would be because the tangent at the base of the ogive on the KSPX LES is angled rather awkwardly, despite being technically a nice fit for a bare-bones Mk1-2 Pod.

As for the SDHI Boost Protective Cover / Aeroshroud, the primary design intention was to encapsulate the pod as well as any surface-attached bits and pieces folks may want to add (e.g. Firespitter/B9 Infodrives). I also had to have a reasonable thickness at the apex of the shroud in order for it to look structurally sound. Besides, the real Orion MPCV's LES and Boost Protective Shround has a bit of a discontinuity between them anyway.

In any case, perhaps, you could make a heatshield that has like one of the automatic-style interstages (such as the stock engines.). Sorry I don't mean to insult or be annoying/begging.

I've been meaning to do an avionics ring-only decoupler variant for the heat shield, but other stuff keeps getting in the way. Perhaps R1.1 :D

I wanted to let you know, the SDHI Clamp-O-Tron Parachute Variant, has become my default docking port on Every single thing I build now. Never know when I might need to at least attempt to safely deorbit something.

I also put it on my Duna cargo craft as parachutes. Craft doesn't even need docking but, this has drogue and parachute, attaches radially, and just in case I do need to tock it's available. Super handy part.

Wait until I figure out how to do the IACBM variant as well :)

Right now I have a working prototype, but the larger size of the IACBM doesn't mesh too nicely with the Mk1-2 pod, and the former's mostly-hollow design doesn't leave much room for parachute compartments.

Same here. It has everything I could ever wish for and I really cannot see switching back to the lame only dock docking port or the only parachute parachute. The only thing I changed were some of the opening values so that my crafts don't spend 15 minutes decending from 2 kilometers up.

If you could pass your amended values on to me, that would be greatly appreciated :)

Share this post


Link to post
Share on other sites

(Lack of) Progress Report, 4 October 2013

Here's where the IACBM variant currently stands - the tapers/bevels are a stop-gap solution, but obviously not ideal:

ksp_sdhi_paradock_iacbm_wip_4_oct_2013_by_sumghai-d6p4hd7.png

Fig 12 - SDHI FusTek IACBM Parachute Variant

Share this post


Link to post
Share on other sites

Would you be open to extending it down? So you have the parachute boxes draping over the upper command pod. So I guess like you said, blisters.

TkVjHfI.png

^ And obviously mirror the box on the other side. It'd look strange if it just had one. :P

Share this post


Link to post
Share on other sites

Perhaps have the parachutes come our of the inside rather than outside of the docking port ? Then you basically have all the room from the inner diameter as it is now to where the hatch would swing open through / to.

Share this post


Link to post
Share on other sites
I'm not 100% happy with the autocut for the drogue (probably a side effect of having two ModuleParachutes), and the pod doesn't realistically hang at an angle under the parachute riser attachment pivot

Not a perfect, but at least some kind of solution:

AF4zbjs.png

You need to fix cfg like this:

MODEL {
model = SDHI/Parts/SDHI_ParaDock_1_ClampOTron/model
scale = 1.0, 1.0, 1.0
rotation = 0.0, [B]180.0[/B], 0.0
}

CoMOffset = 0.0, 0.0, [B]-0.4[/B]

So this is all about CoM... Also I flipped parachute's position so that kerbals no longer awaits for touch down upside down ^_^

Great work though, sumghai! Thx!

Edited by ZobrAA

Share this post


Link to post
Share on other sites
Would you be open to extending it down? So you have the parachute boxes draping over the upper command pod. So I guess like you said, blisters.

-snip-

^ And obviously mirror the box on the other side. It'd look strange if it just had one. :P

Blisters that go downward may be the best bet.

However, my intention is that, assuming that the Mk1-2 Pod enters the atmosphere heat shield-first with the windows oriented upwards, the parachutes are to be deployed from roughly the trailing side of the docking port (i.e. just above and clear of where the original pod hatch is). Having the boxes on the sides wouldn't really work.

Perhaps have the parachutes come our of the inside rather than outside of the docking port ? Then you basically have all the room from the inner diameter as it is now to where the hatch would swing open through / to.

I considered that for some time as well. However, in real life deploying chutes from inside the port means they are likely to get caught in and ripped by the IACBM guidance fins.

Not a perfect, but at least some kind of solution:

-snip-

You need to fix cfg like this:

MODEL {
model = SDHI/Parts/SDHI_ParaDock_1_ClampOTron/model
scale = 1.0, 1.0, 1.0
rotation = 0.0, [B]180.0[/B], 0.0
}

CoMOffset = 0.0, 0.0, [B]-0.4[/B]

So this is all about CoM... Also I flipped parachute's position so that kerbals no longer awaits for touch down upside down ^_^

I'll definitely try out the CoM fix - thanks!

Share this post


Link to post
Share on other sites

Great mod, Have you considered adding Apollo style floatation bags (Those three round balls) for the SDHI Clamp-O-Tron?

Share this post


Link to post
Share on other sites

Spot on piece of work and will complient stock parts beautifully. May I offer a suggestion though, as this is taking its design cue from the ARES programme it would be nice to have a reimagined stock command module that can take more than 3 Kerbalnauts, without having to result to much higher tectured models.

Share this post


Link to post
Share on other sites
Great mod, Have you considered adding Apollo style floatation bags (Those three round balls) for the SDHI Clamp-O-Tron?

I thought about it, actually, and at the time I really wanted to.

However, I'm not exactly happy with the solutions currently available for deploying uprighting bags - I studied the CP Airbag system on Spaceport, and found that it basically used the legacy (i.e pre-PartModules) HLandingGear behaviour, which needs to be triggered manually.

I then considered integrating it into the ModuleParachute so that it would automatically deploy in sequence after my drogue/main combo, but then releases chutes generally autocut at speeds below 0.5m/s - as you and I would agree, the airbags are supposed to stay inflated long after landing.

I dunno, really. I'm more comfortable modelling followed by texturing, only venturing into custom plugins only under the most pressing circumstances. But I'll definitely keep this idea in mind for the future.

May I offer a suggestion though, as this is taking its design cue from the ARES programme it would be nice to have a reimagined stock command module that can take more than 3 Kerbalnauts, without having to result to much higher tectured models.

Actually, it's based on the Orion MPCV, one of the few systems to survive the cancellation of the Ares boosters and practically the entire the Constellation program.

A higher-capacity command pod would definitely be nice, yes, but that'd be a bit much for me at this stage. Your suggestion has been noted with thanks, however.

Share this post


Link to post
Share on other sites
However, my intention is that, assuming that the Mk1-2 Pod enters the atmosphere heat shield-first with the windows oriented upwards, the parachutes are to be deployed from roughly the trailing side of the docking port (i.e. just above and clear of where the original pod hatch is).

I'd almost rather a new (IACBM/chute compatible) capsule than trying to further hack the awful MK1-2 design.

Share this post


Link to post
Share on other sites

perhaps a mission module could be useful here?, (something perhaps like taking the place of the luner module on an apollo vehicle, but serving instead for habitation and docking rather than landing.

Share this post


Link to post
Share on other sites
A higher-capacity command pod would definitely be nice, yes, but that'd be a bit much for me at this stage. Your suggestion has been noted with thanks, however.

Consider a lower-capacity lander pod for an Apollo-style mission with your Orion-alike as the base instead. The extant 2-kerbal lander can is too heavy, not very pretty, has a very odd collision mesh and a fairly uninspiring IVA, and too wide for such a use, and meshing together two 1-kerbal landing pods is usually better on all counts except the need to handle two separate hatches.

Share this post


Link to post
Share on other sites

I wish I could make these wonderful textures like you can, I'm getting better at geometry but all my textures are so ugh.

Got any tips.

Share this post


Link to post
Share on other sites

Here's the code I feel comfortable with. It seems to work well with Deadly Reentry, although I haven't tested it out in FAR yet. I've also only tested these chutes on Kerbin with just the pod, Docking port, and heatshield setup.

// Drogue Parachutes
MODULE
{
name = ModuleParachute
invertCanopy = true
autoCutSpeed = 50
capName = chute_cover_drogue
canopyName = canopy_drogue
semiDeployedAnimation = SDHI_ParaDock_1_drogue_semi_deploy
fullyDeployedAnimation = SDHI_ParaDock_1_drogue_full_deploy
stowedDrag = 0.22
semiDeployedDrag = 4
fullyDeployedDrag = [B]80[/B] [I]//Down from a chute snapping 200[/I]
minAirPressureToOpen = 0.1
deployAltitude = [B]7000[/B] [I]//Down from 8000[/I]
deploymentSpeed = 1.5
semiDeploymentSpeed = 1.5
}

// Main Parachutes
MODULE
{
name = ModuleParachute
invertCanopy = true
autoCutSpeed = 0.5
capName = chute_cover_mains
canopyName = canopy_main
semiDeployedAnimation = SDHI_ParaDock_1_main_semi_deploy
fullyDeployedAnimation = SDHI_ParaDock_1_main_full_deploy
stowedDrag = 0.22
semiDeployedDrag = [B]40[/B] [I]//Up from 20[/I]
fullyDeployedDrag = 1500 [I]//Considering reduction to 500 like the stock chute, but otherwise doesn't seem to pose a problem[/I]
minAirPressureToOpen = 0.3
deployAltitude = [B]500[/B] [I]//Down from 2000[/I]
deploymentSpeed = 1
semiDeploymentSpeed = 1
}

Share this post


Link to post
Share on other sites
Blisters that go downward may be the best bet.

I considered that for some time as well. However, in real life deploying chutes from inside the port means they are likely to get caught in and ripped by the IACBM guidance fins.

Here's a more complicated / crazy variation: parachutes are packed in containers that are positioned within the docking port space (similar to how I suggested previously) but instead of opening through the docking ring, the containers slide and/or pivot outwards to be protruding past the docking ring / capsule edge then open to deploy. Realistic? Perhaps not. But it helps fit things in to the limited volume, and it's certainly more plausible that the mechanical engineering to pull it off and not have them snap off their rails or whatever, than creating magic parachutes that don't tangle or get cut off by the docking ring when deploying from inside it.

Share this post


Link to post
Share on other sites
Consider a lower-capacity lander pod for an Apollo-style mission with your Orion-alike as the base instead. The extant 2-kerbal lander can is too heavy, not very pretty, has a very odd collision mesh and a fairly uninspiring IVA, and too wide for such a use, and meshing together two 1-kerbal landing pods is usually better on all counts except the need to handle two separate hatches.

+1 - I keep trying to make Apollo style landers, but the 2 person lander can is too large / heavy for what it does, but I don't want to only send down one kerbal...

Share this post


Link to post
Share on other sites

A question on the dock-o-chute: the numbers are all working right for me (the drogue drag goes away when the mains deploy) but the drogues don't disappear until I manually right-click->cut chute. Is this what others are experiencing?

Share this post


Link to post
Share on other sites
A question on the dock-o-chute: the numbers are all working right for me (the drogue drag goes away when the mains deploy) but the drogues don't disappear until I manually right-click->cut chute. Is this what others are experiencing?

That is what I am experiencing. I didn't think it was worth complaining about, but if you can find a better set of parameters, I'm sure it will be well received here. :)

Share this post


Link to post
Share on other sites

Small is beautiful! :)

ei2VFVT.png

Relevant part weld configs:


PART
{
name = SDHI_2.5_ServiceModule-combo-small
module = Part
author = sumghai


MODEL {
model = SDHI/Parts/SDHI_2.5_ServiceModule/model
position = 0,0,0
rotation = 0,0,0
scale = 1.6,1.6,1.6
}
// RCS ring.
MODEL {
model = Squad/Parts/Utility/RCS block/model
texture = Squad/Parts/Utility/RCS block/model000
position = -0.78,0,0
rotation = 0,0,0
scale = 1.0,1.0,1.0
}

MODEL {
model = Squad/Parts/Utility/RCS block/model
texture = Squad/Parts/Utility/RCS block/model000
position = 0.78,0,0
rotation = 0,180,0
scale = 1.0,1.0,1.0
}

MODEL {
model = Squad/Parts/Utility/RCS block/model
texture = Squad/Parts/Utility/RCS block/model000
position = 0,0,-0.78
rotation = 0,-90,0
scale = 1.0,1.0,1.0
}

MODEL {
model = Squad/Parts/Utility/RCS block/model
texture = Squad/Parts/Utility/RCS block/model000
position = 0,0,0.78
rotation = 0,90,0
scale = 1.0,1.0,1.0
}

// Antenna

MODEL {
model = Squad/Parts/Utility/longAntenna/model
texture = Squad/Parts/Utility/longAntenna/model000
position = 0,0.3,-0.82
rotation = 190,0,0
scale = 2,2,2
}

scale = 1
rescaleFactor = 0.625

node_stack_top = 0.0, 0.544, 0.0, 0.0, 1.0, 0.0
node_stack_bottom = 0.0, -0.675, 0.0, 0.0, 1.0, 0.0
node_stack_fairing1 = -1.02, 0.275, 0.0, 0.0, 1.0, 0.0, 0
node_stack_fairing2 = 1.02, 0.275, 0.0, 0.0, 1.0, 0.0, 0

CoMOffset = 0, -0.8, 0

cost = 2500
category = Propulsion
subcategory = 0
title = SDHI 1.25m Service Module Combo
manufacturer = Sum Dum Heavy Industries Co., Ltd
description = Designed for use with the Mk1 Command Pod, this services and propulsion module is ideal for extended standalone operations in Low Kerbin Orbit, as a crew ferry to and from space stations, or short trips to the Mun and Minimus with the use of the client's own injection stage. The unit comes with pyrotechnic tension ties to separate the heat-shielded pod from the module itself prior to re-entry, ample surface area to attach RCS thrusters/communications antennae/PV Solar Arrays, as well as an integrated fuel cell assembly to generate electricity in the absence of sunlight. This variation comes with built-in RCS thrusters and communications equipment.

attachRules = 1,0,1,1,1

mass = 0.18
dragModelType = default
maximum_drag = 0.3
minimum_drag = 0.3
angularDrag = 2
crashTolerance = 8
breakingForce = 280
breakingTorque = 280
maxTemp = 2400
fuelCrossFeed = true

stageOffset = 1
childStageOffset = 1

//vesselType = Debris

fx_gasBurst_white = 0.0, 0.875, 0.0, 0.0, 1.0, 0.0, decouple
sound_decoupler_fire = decouple

RESOURCE
{
name = MonoPropellant
amount = 15
maxAmount = 15
}

RESOURCE
{
name = LiquidFuel
amount = 27
maxAmount = 27
}

RESOURCE
{
name = Oxidizer
amount = 33
maxAmount = 33
}

RESOURCE
{
name = ElectricCharge
amount = 200
maxAmount = 200
}

MODULE
{
name = ModuleReactionWheel

PitchTorque = 1
YawTorque = 1
RollTorque = 1

RESOURCE
{
name = ElectricCharge
rate = 0.1
}
}

MODULE
{
name = ModuleSAS
}

MODULE
{
name = ModuleGenerator
isAlwaysActive = false
activateGUIName = Turn on Fuel Cell
shutdownGUIName = Turn off Fuel Cell
INPUT_RESOURCE
{
name = LiquidFuel
rate = 0.0009
}
INPUT_RESOURCE
{
name = Oxidizer
rate = 0.0011
}
OUTPUT_RESOURCE
{
name = ElectricCharge
rate = 1
}
}

MODULE
{
name = ModuleDecouple
ejectionForce = 200
explosiveNodeID = top
staged = true
}

MODULE {
name = ModuleRCS
thrusterTransformName = RCSthruster
thrusterPower = 0.25
resourceName = MonoPropellant
atmosphereCurve {
key = 0 260
key = 1 100
}
}
MODULE {
name = ModuleAnimateGeneric
animationName = antenna
isOneShot = false
startEventGUIName = Extend Antenna
endEventGUIName = Retract Antenna
}

}


PART
{

// --- general parameters ---
name = JSI_dockport_parachute_small
module = Part
author = NovaSilisko / Mihara

// --- asset parameters ---

MODEL {
model = Squad/Parts/Utility/dockingPort3/model
texture = Squad/Parts/Utility/dockingPort3/model000
position = 0.0, 0.0, 0.0
rotation = 0.0, 0.0, 0.0
scale = 1.0, 1.0, 1.0
}

MODEL {
model = Squad/Parts/Utility/parachute_single/model
texture = Squad/Parts/Utility/parachute_single/model000
position = 0.0, 0.005, 0.0
rotation = 180.0, 0.0, 0.0
scale = 0.99, 0.99, 0.99
}

MODEL
{
model = Squad/Parts/Utility/spotLight1/model
texture = model000, Squad/Parts/Utility/spotLight1/model000
texture = model001, Squad/Parts/Utility/spotLight1/model001
position = 0, 0.05, 0.41
scale = 0.32, 0.32, 0.32
rotation = 164, 0, 0
}

scale = 1
rescaleFactor = 1

// --- node definitions ---
// definition format is Position X, Position Y, Position Z, Up X, Up Y, Up Z, size

// docking port nodes are
//node_stack_top = 0.0, 0.2828832, 0.0, 0.0, 1.0, 0.0, 1
//node_stack_bottom = 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 1

// So the resulting nodes are...
node_stack_top = 0.0, 0.1474114, 0.0, 0.0, 1.0, 0.0, 1
node_stack_bottom = 0.0, 0, 0.0, 0.0, 1.0, 0.0, 0

// --- FX definitions ---
sound_parachute_open = activate

// --- editor parameters ---
cost = 1000
category = Utility
subcategory = 0
title = Clamp-o-Tron Jr. Parachute
manufacturer = Junk Systems Inc.
description = This a Clamp-o-Tron Jr. with an integrated parachute is specifically designed for use with Mk1 capsule and should be sufficient to slow it's descent. Hopefully. Also includes a small light as a bonus to help with docking in the dark. NOTICE: Docking light needs to be manually added to the correct action group.

// attachment rules: stack, srfAttach, allowStack, allowSrfAttach, allowCollision
attachRules = 1,0,1,0,1

// --- standard part parameters ---
mass = 0.13
dragModelType = default
angularDrag = 3
crashTolerance = 12
maxTemp = 3100


breakingForce = 100
breakingTorque = 50

stageOffset = -1

MODULE
{
name = ModuleDockingNode
referenceAttachNode = top
nodeType = size1
}

MODULE
{
name = ModuleParachute
semiDeployedAnimation = semiDeploySmall
fullyDeployedAnimation = fullyDeploySmall
invertCanopy = true
autoCutSpeed = 0.5
capName = cap
canopyName = canopy
stowedDrag = 0.22
semiDeployedDrag = 1
fullyDeployedDrag = 500
minAirPressureToOpen = 0.01
deployAltitude = 500
deploymentSpeed = 1
semiDeploymentSpeed = 1
}

MODULE
{
//name = FSanimateGeneric
name = ModuleAnimateGeneric
animationName = LightAnimation
startEventGUIName = Lights on
endEventGUIName = Lights off
toggleActionName = Toggle light
}

}

Share this post


Link to post
Share on other sites
I'd almost rather a new (IACBM/chute compatible) capsule than trying to further hack the awful MK1-2 design.

It can't be helped, really. I suspect most people would want to use the (surprisingly decent looking) Parachute-equipped Clamp-O-Tron anyway with their Mk1-2 Pod to ensure compatibility with stock docking ports.

perhaps a mission module could be useful here?, (something perhaps like taking the place of the luner module on an apollo vehicle, but serving instead for habitation and docking rather than landing.

I'm not really feeling for a Soyuz or HTV-R style orbital module at the point in time.

My intention is to get the SDHI Service Module system officially released and FusTek overhauled as quickly as possible, so that I can get back to actually enjoying the game (I've never got much further than landing on the Mun once since I first started playing in 0.19)

Consider a lower-capacity lander pod for an Apollo-style mission with your Orion-alike as the base instead. The extant 2-kerbal lander can is too heavy, not very pretty, has a very odd collision mesh and a fairly uninspiring IVA, and too wide for such a use, and meshing together two 1-kerbal landing pods is usually better on all counts except the need to handle two separate hatches.

I'll think about it, but again, no promises at this time.

I wish I could make these wonderful textures like you can, I'm getting better at geometry but all my textures are so ugh.

Got any tips.

I have a confession to make - texturing is the least favourite part of my workflow.

Stuff like FusTek are reasonably nice to texture because of their "factory-fresh" aesthetics, easily allowing for shared UV maps (the upcoming revamp will be even more efficient); on the other hand stockalikes are massive nightmares, especially when trying to get the colors / non-repeating scorch marks right means fully unwrapping models into rather inefficient UV maps.

However, I do have some tips to share:

- I swear by Adobe Fireworks CS6 for editing textures; while a holdover from my web design days for Alpha Company, I find it exceptionally handy for blocking out editable vector shapes / gradients / drop shadows directly in PNG format.

- For stockalikes such as the SDHI stuff here, I first important the original parts into Blender via taniwha's .mu import/export addon, save all the textures / normals / emissives into separate PNGs, and finally eyedropper sampling or cutting/pasting bits and pieces into my own artwork.

- SQUAD's worn and scorched aesthetic is still very difficult to replicate perfectly; however, a "good enough" way to do the signature "smudged" shadows involves painting roughly around the edges in black or very dark grey, smudging the paint in the desired direction and blurring gently to lessen the number of harsh streak.

Here's the code I feel comfortable with. It seems to work well with Deadly Reentry, although I haven't tested it out in FAR yet. I've also only tested these chutes on Kerbin with just the pod, Docking port, and heatshield setup.

-snip-

The revised configs ran quite nicely - I'll be sure to include it in the next update.

Here's a more complicated / crazy variation: parachutes are packed in containers that are positioned within the docking port space (similar to how I suggested previously) but instead of opening through the docking ring, the containers slide and/or pivot outwards to be protruding past the docking ring / capsule edge then open to deploy. Realistic? Perhaps not. But it helps fit things in to the limited volume, and it's certainly more plausible that the mechanical engineering to pull it off and not have them snap off their rails or whatever, than creating magic parachutes that don't tangle or get cut off by the docking ring when deploying from inside it.

That's a possibility, although that means the boxes in their retracted positions would take up space where the guidance fins from the target vessel's docking port would slip into.

A question on the dock-o-chute: the numbers are all working right for me (the drogue drag goes away when the mains deploy) but the drogues don't disappear until I manually right-click->cut chute. Is this what others are experiencing?
That is what I am experiencing. I didn't think it was worth complaining about, but if you can find a better set of parameters, I'm sure it will be well received here. :)

Yeah, the parameters aren't quite ideal, even with BFGfreak's tweaks that I'll roll out in the next (and possibly final pre-official) update. Still, the drogues do get cut eventually when the mains fully open.

Small is beautiful! :)

-snip-

D'aww! :)

I might one day revisit the idea of a proper service module system for the 1-Kerbal Mk1 Pod - might end up being a stockalike version of the Mercury retropack or the Gemini utilities module (Shh, don't let the author of the FASA add-on know :D).

Share this post


Link to post
Share on other sites
Small is beautiful! :)

Yes indeed. This would be nice to have, but I'm not sure what to do in order to get it. Can someone tell me how to make this part from the code posted by Mihara?

Share this post


Link to post
Share on other sites
This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.