Hard Light Productions Forums
Modding, Mission Design, and Coding => The FRED Workshop => Topic started by: 666maslo666 on May 11, 2014, 03:37:55 pm
-
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?
-
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. :p
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.
-
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... :doubt:
#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:
#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.