Duck and Cover

An irritating problem has manifested itself, some of sprites I have made 'clip' or are partially blocked by a player character when it approaches the bounding box from the bottom of the screen.

I guess it could be caused by:

1) my computer is running slow because i need to defrag.

2)The sprite is too large. the one shown is 123 x 78 that doesn't seem too large to me but its a thought.

3)The bounding box of the sprite is too small

4)?????????????



This is what's happening, Has anyone else ever experienced this problem? Any help would be appreciated.

That has happened to me with the normal sprites, already in game, but I have no idea how to fix it.

Call it the unfixable bug from hell.

It's definitely not too large. Make sure you run occlusion data on the map. Also make sure that you have the bounding box set correctly.

OK..
new pvs built.
bounding box xpanded by 1 in width and height and 2 in depth.
center X,Y coordinate adjusted and.........clipping still happens.

Hmmmmmm what to do..perhaps I should do as JJ86 told me and take a look at all bounding boxes......so after adjusting the completely dicked up 2D bounding box for the default image in spray the sprite no longer 'clips' and is now a happy and well adjusted sprite.

thanks JJ86.

ill bet there are some tiny errors in the 2D bounding boxes of some of the stock sprites causing the clipping effect on those.

xbow wrote:ill bet there are some tiny errors in the 2D bounding boxes of some of the stock sprites causing the clipping effect on those.

Probably more sprites (and tiles etc) with errors than anything else in FOT, several sprites where included unfinished or broken.

Could someone make a map available with this bug (and if necessary the "Edited sprite" given you don't use one from the game) so I can see if there's anythign wrong with the sprite itself?

I have found that you can induce the error by putting incorrect values for the 2D bounding box for the default image. Say the sprite is 120 X 40 and you have the horizontal value set at left = 0 right = 60 the part that will clip is the right half from 61 to 120. likewise if you have the top set at zero and the bottom set at 20 the bottom half will clip. That's what I have discovered in my bumbling way.

My sprites are probably useless for your purpose (i think), because I do not build them from scratch, I always start with an existing sprite. I do this because when I try to make a new sprite in spray no matter how well I have filled out the header and related information or if I havent filled it out at all I get an error that reads.

Access violation at address 00435AB7 in module 'spray11.exe'. Read of Address 003FBE6C.

So I take the cheap way out and just import new images that replace the old ones and then load my color tables.

I had a similiar problem in FO2. Try cutting the sprite into two serparate sprites perhaps.

IIRC you can't build a new sprite from scratch in spray, you're meant to use an existing sprite as the basis.

I really should get my act together and make a proper tool

Or well, at least one that's as good as spray11 at first, then perhaps improve on it.

Red you have contributed a great deal to Fallout and FOT editing. I have found that the your RedViewer is a must have to take a gander at the critical 'Volume' bounding box and for adjusting its X.Y values so that it encloses the sprite. You can edit the sprite in spray but without that visual representation of the 3D bounding box getting the X,Y and Depth, Height, Width is just guesswork for me. I always have both applications open when editing sprites.
but Redview is the tool that makes it possible.

One of these day I will learn how to make tiles I can't seem to get a PNG to preserve its alpha channel at the moment, but ill blunder into the solution eventually.

A better tool is always nice but thanks for the fine work you have done already.

xbow wrote:You can edit the sprite in spray but without that visual representation of the 3D bounding box getting the X,Y and Depth, Height, Width is just guesswork for me. I always have both applications open when editing sprites.

Hey, what if I made the app check the "last modified date" of a sprite and if it changed, reload it to apply the changes? That should be pretty easy...

Easy for a C/C++ master but not us peons hombre!

What I think would be a sweet feature would be to be able to point and click to allign the volumetric bounding box.

Click an X,Y origin button,
point to where the Center X.Y should be left click,
and hold then drag the box to draw a rectangle around the sprite and then click the plus or minus Z button to get the height. take a gander at it and the save if you like it.

ha it would be cool to watch the numbers change in the X,Y,Z fields as you did it..just a thought!

Direct draw?

Red wrote:I really should get my act together and make a proper tool

Or well, at least one that's as good as spray11 at first, then perhaps improve on it.

We would all love you forever Red! There are still many FOT modders out there to make a new improved sprite editor worthwhile. Name your price...

xbow wrote:What I think would be a sweet feature would be to be able to point and click to allign the volumetric bounding box.

This is how Red!Viewer works for tiles.

ha it would be cool to watch the numbers change in the X,Y,Z fields as you did it..just a thought!

I guess...

Direct draw?

Direct3D, though I'm not using any depth.

xbow wrote:One of these day I will learn how to make tiles I can't seem to get a PNG to preserve its alpha channel at the moment, but ill blunder into the solution eventually.

Hmm, my photo editing software (Corel 8) doesn't allow me to save a png with an alpha channel, so I just add a selection mask around the item and save the image as an interlaced png which works fine for converting to zars and tiles.