[666maslo666]

Code: [Select]

add-background-bitmap
    add-background-bitmap
    Adds a background bitmap to the sky. Returns an integer that is stored in a variable so it can be deleted
    using remove-background-bitmap

    Takes 9 arguments...
    1: Background bitmap name
    2: Pitch
    3: Bank
    4: Heading
    5: X scale (expressed as a percentage of the original size of the bitmap)
    6: Y scale (expressed as a percentage of the original size of the bitmap)
    7: X divisions.
    8: Y divisions.
    9: Variable in which to store result

Notice that items #5 and #6 are percentages, whereas in the background editor, you work with concrete numbers. If the dimension of your bitmap is 1.5, it should be represented as 150 with this SEXP.
Add-background-bitmap SEXP for some reason only allows to set the scale in the range of 1% - 1800% (0.01 - 18), by 1% increments. However in background editor you can set it in the range of 0.001 - 18, and by 0.001 increments.

In my mission I need to continually shrink a planet from big size down to invisible size. With this SEXP it looks bad because when the planet is large the changes appear discontinuous (1% increment is too large). And I cannot shrink it under 1% which is still very much visible. Wat do?

Related question, is there a way to use floating point variables in FRED?

[Axem]

Well first off, no you can't use floating point variables or anything that resembles a non-whole number for sexps. The sexp system was designed that way and even doing things like dividing by 1000 or any other tricks won't work. Believe me, I've cursed many a times at that restriction.

Back to your original problem... The only way I think you could do what you want is to have an animation of the planet shrinking that you swap the bitmap too and then remove it when the animation is over.

[zookeeper]

I thought I had a clever workaround and wrote all this before I realized that the planet will always stay in the same orientation, so not very useful in this case after all...

Code: [Select]

#Conditional Hooks

$Mission: yourmissionfilenamewithoutextension

$On Gameplay Start: [

    planet_pos = ba.createVector(5000, -2000, 10000)
    planet_size = 5000
    planet_shrink_time = 30
    planet = ts.createParticle(planet_pos, ba.createVector(0), 999999, planet_size, PARTICLE_BITMAP, -1, false, gr.loadTexture("yourplanetbitmapwithoutextension"))

]

$State: GS_STATE_GAME_PLAY

$On Frame: [

    if planet ~= nil and planet:isValid() then
        planet.Position = gr.getCurrentCamera(true).Position + planet_pos
       
        local current_time = mn.getMissionTime()
       
        if current_time > planet_shrink_time then
            planet = nil
        else
            planet.Radius = planet_size * (1.0 - (current_time / planet_shrink_time))
        end
    end

]

#End


EDIT: Actually, this works:

Code: [Select]

#Conditional Hooks

$Mission: yourmissionfilenamewithoutextension

$On Gameplay Start: [

    planet_tex = gr.loadTexture("yourplanetbitmapwithoutextension")
    planet_pos = ba.createVector(5000, -2000, 10000)
    planet_size = 5000
    planet_shrink_time = 30
    planet_orientation = planet_pos:getOrientation()

]

$State: GS_STATE_GAME_PLAY

$On Object Render: [

    if not planet_drawn then
        local current_time = mn.getMissionTime()
       
        if current_time < planet_shrink_time then
            local radius = planet_size * (1.0 - (current_time / planet_shrink_time))
            gr.drawPolygon(planet_tex, gr.getCurrentCamera(true).Position + planet_pos, planet_orientation, radius, radius)
        end
       
        planet_drawn = true
    end

]

$On Frame: [

    planet_drawn = false

]

#End

However, there's a certain yet-unmantised engine bug which will cause the -normal, -shine and -glow textures of unrelated objects to bleed through to the planet texture and I don't know if that can be worked around. So if you don't mind waiting for a fix to that bug, this ought to work... unless I missed some other visual problem with it.