DescentBB

You could enter, but not save the changes in the advanced objects tool. That has been fixed.

Powerup image for 4 Concussion Missiles is mysteriously not loading. Haven't found anything else that does that yet...

Fixed. The image was stored with more than 256 colors.

Hummm.. Is it possible for someone to make a step by step tutorial on making or converting plus importing true TGA alpha images into DLE-XP? Some screen shots and what programs you use would be great help! Also what size cubes (if needed) to apply the image for best results?
Thanks guys!

You can use any good image processing program to convert existing images into TGA images (I use Paintshop pro). It's a different story to (manually) bring alpha info into an image though, can't help you here.

To replace a standard texture with a TGA texture:

1. Select a cube side bearing the texture you want to replace.
2. Select the texture tool.
3. Click on "edit...": The texture edit dialog will open.
4. Click on "load...": A file selection dialog will open.
5. Choose the image you want to use as a replacement for the select standard texture.
6. Click "Ok" in the texture edit dialog.
7. There you go.

ummmm.. well I've gone through the steps but no good. Image comes up blank. I have no idea if the tga file is in alpha or what. I have PSP7 and Adobe Photoshop 8.

Diedel wrote:It's a different story to (manually) bring alpha info into an image though, can't help you here.

If you don't know how... then how do you get "true" TGA alpha images and know its in alpha for that matter?
Wish you could just make DLE-XP auto convert any BMP/ TGA file to the proper file (alpha) needed for the image to work in D2x-w32.

google is your friend, use it query string "how to create an alpha channel in photoshop"

first go here after you have looked at the pretty pictures, go here..

links provided just for your alpha channel noobness ...

save as 32 bit TGA with alpha

Aus-RED-5 wrote:If you don't know how... then how do you get "true" TGA alpha images and know its in alpha for that matter?

Because it's coded in the file header.

Please send me your image to karx11erx at hotmail dot com so I can take a look at it.

I noticed something kind of strange with DLE-XP... if you delete a cube adjacent to a cube with a wall - or I think insert one in that place - the latter cube's side of the wall gets deleted.

The cube that is deleted isn't the one with a wall itself, or this response would be obviously correct... it is one attached to the cube, and I think it needs to share a common edge with the wall. Or maybe just vertex, but I'm not so sure about that.

Will provide diagrams if further explanation is needed.

Ok, feature request this time. DMB2 used to have a mode which displayed only the nearby cubes, which helped a fair deal for editing and viewing only an immediate part of a level. Admittedly it didn't show objects, which was not particularly useful, although for texturing it came in handy.

DLE-XP seems to have mysteriously dropped this... it does still have the nearby cube lines option (not that this seems to do anything; I still see the whole level), but not Partial Texture Mapped.

Nonetheless, the aforementioned features were somewhat flawed anyway. What about a 'render depth' control, where you can choose to display everything, including cubes, walls and objects, up to a certain number of cubes distant from the selected cube? Then, if it worked in both wireframe and textured view, it would accomplish all the same stuff anyway.

Good idea. I will implement such a feature next week.

DLE crashes in the texture editing window when pressing "Default" after a TGA is loaded.

I know. And know what? It doesn't crash in debug mode. That makes it real nice to track this bug down.

DLE crashes when I delete a cube.

EDIT: Well, it crashes on levels that are created with the previous versions of DLE by deleting a cube

Ugh.

Actually, It occurs when I delete the a cube with an opening. Let me show you an example:

If you delete the middle cube, it crashes. This is just an example

Fixed.

Eh, nevermind-- I forgot to update DLE.

Hey Diedel, could you add support into DLE-XP for customized 256 color palettes, please ?

I know that you can insert Truecolor TGA pictures, but i want the custom palette support for some custom PIGs i have for the original D2 version (not D2X-W32).

I mean, if i have a pig named MINE.PIG in the main descent directory and a palette named MINE.256 stored in the main D2 HOG, could DLE-XP recognise the 256 palette in the hog to apply it to the PIG.

I don't think I will add this feature. You can easily customize level appearance using TGA textures.

I know you can use High-res Truecolor TGA pictures even with alpha channel, but the POGs that contain those, only works on D2X-W32, and i don't use D2X-W32 so much, i want more support for 256 colors palettes for use with the original DOS and Windows 95 versions of Descent 2 (the ones that doesn't need 3D cards and can run on old PCs).

But anyway, thanks for the answer

Found a wierd bug, if you split a cube and then reload the level, it'll result like this:

Pumo,

you'd need to load the palette into D2 to make textures based on a custom palette work. Even if I make DLE-XP display such textures correctly, how do you want to accomplish that?

DF,

image doesn't load.

Now it does. Reason: I'm using ImageShack to upload images

Well, i already have those custom palettes loaded on Descent 2 (and it works! )

It was very hard work to make completely new palettes, but everything goes well (i used 256ED and Paint Shop Pro 7).

In the game works very well, and i already have levels designed for those palettes, but i'm having problems to see the levels on editors only (Devil,DMB2 and DLE-XP).

The only problem is found when lighting or aligning textures, sometimes the weird colors confuses me, so for that reason i wanted support for those custom palettes (But i actually work with existing palettes and when the level is finished, i put the custom one) .

But in the game, everything is alright.I thing this is not a important feature, but it can be cool in Dle-Xp

But if it's difficult to implement, so there is no problem.

I might look into it, could take some time though (christmas, heh), as I am currently building a house and I am operating at my limit already.

DF,

i cannot reproduce that bug. I need the exact steps you took.

I've pondered the idea of a 'find texture' dialog. Would such a feature be useful? I imagine for those who can't see easily where the last rock021 lies, it might, although I don't need it myself. But if you think it's a good idea, why not?

Personally, I would re-use the mission diagnostics text box for this, but ... yeah.

Step#1- Make the level shape like some sort of question mark without the dot, for example:


Step#2- go to the cube menu and select "Split Cube" to Split Cube#36

Step#3- save it as split.rl2 or split.hog

Step#4- Open a different level or exit the editor.

Step#5- Reopen the level or Reopen the editor and reopen the level it'll result like this:

Any chance of making the concussion missile fly faster, maybe D3 speed or a bit slower?

NWRhino wrote:Any chance of making the concussion missile fly faster, maybe D3 speed or a bit slower?

Uh... That should be posted in the D2X-W32 (not DLE-XP) suggestions thread.

Anyway, the point of D2X is not to change the way the game flows, it's to make it possible to play again on modern computers.

That is a weird-ass bug, Falcon. Is there any relationship between the face numbers that get connected? And is the level playable in game?

Somehow DLE-XP seems to be mixing up vertices when splitting cubes.

I have finally been able to find and fix the cube splitting bug.

thought i'd mention that dmb/dmb2 (hereafter dmb) could act very strange at times. values would not affect the display immediately. number entry boxes were not updated properly. dark falcon's cube splitting example could happen when trying to paste a block into a level. sometimes when copying and moving, the vertices would dup or not and you'd have a line from one side of the block to the other. a real mess! SAVE OFTEN! level editors for duke3d and doom could do some strange things w.o. warning and trash a level that took hours to make.

this is kind of a suggestion/question.

each side of each cube has a 4 light levels in each corner. depending on how the cube was created, the orientation of those corners will differ from the orientation in the texture tool. why? what determines the orientation? i'll try a diagram:
cube1 cube2
|1\\\\2|1\\\\2| this is ref for the sides of 2 adj
|3\\\\4|3\\\\4| cubes and the corners in their
actual positions
|1\\\\2|2\\\\3| this is orientation of the
|3\\\\4|1\\\\4| values in the texture tool

dmb was like this too.
i think adjacent cubes should have the same orientation. if not why not? am i not comprehending how dmb or dle assigns the orientation of the values.
can i construct the cubes in certain way to align the light values better. i know the orientation would be different if i del'd a cube and then put it back in from a different cube.
i would like to edit the light values while looking at the texture as drawn in the level?
duke3d had this.
point the mouse at a corner and press a key and the shading would get lighter or darker in real time.
duke did change just the shade of the whole side and not each corner but it made lighting a level so easy.

i assume that whatever behaviour dmb had, dle also has because it was built using dmb source code? an alternate to this suggestion is to answer the real question = How to set the light levels easily.

jakee308 wrote:level editors for duke3d and doom could do some strange things w.o. warning and trash a level that took hours to make.

True enough, although Descent editors don't seem to be nearly unstable. But as you say, no matter what you're doing, saving copies of your work always helps, and at least saving your work every few minutes (it really doesn't take any time) is a good habit to get into.

why? what determines the orientation?

Generally the cube you inserted that cube from. If you have looping tunnels, chances are you'll see a bit of this.

i think adjacent cubes should have the same orientation. if not why not?

No. Three reasons:
1) It would basically screw over those who want to put D1 exit tunnels anywhere (it actually requires you connect specific sides of the cubes)
2) It would result in undefined behaviour or crashes where you had cubes connected in non-rectangular formations - such as a triangle junction between three cubes
3) Having different orientations ultimately does not affect function anyway; it doesn't stop anything working

can i construct the cubes in certain way to align the light values better.

Um... you can, by trying to keep cubes of a reasonably uniform size. However, cube orientation will make no difference whatsoever to the lighting algorithm.

i would like to edit the light values while looking at the texture as drawn in the level?

I think you can do this by entering a corner light value and refreshing the display (note you must have lighting enabled in DMB2/DLE-XP's view settings). Might not be what you're thinking of, but it works (and technically, you shouldn't need to do much manual light value editing with DLE-XP anyway).

an alternate to this suggestion is to answer the real question = How to set the light levels easily.

Use the lighting tab. It does it all for you, unless you don't actually have any real lights in the level (and then you can use tricks such as hiding them under secondary textures anyway). Duke3D's system - while fairly easy, I agree - doesn't translate well to Descent because the lighting values are based on a much broader scale (at least 65,000 lighting values rather than maybe a dozen with the method you've described).

And auto-lighting is really probably easier anyway. The problems it DOES cause you can fix just by putting little fudges in like playing with texture light values, adding extra lights and knocking up render depth/illumination.

I am asking myself how face orientation should cause any problems when editing a level. I haven't understood this. If it really does, create a small (2 segment if possible) example level and e-mail it to karx11erx at hotmail dot com.

Actually, D2 has 131072 light levels - but you won't notice much of a difference, so it's scaled to 200 light levels (0% - 200%). I could add an in-level lighting feature with the mouse like proposed, and I know of level designers manually lighting their levels.

Personally, I prefer putting light textures at the proper places and using the auto illumination function for a more natural and plausible result.

Some controls have an update lag; I have noticed this myself and will fix this eventually.

Manual lighting is only really recommended if you have some beastly geometry and structures that the algorithm doesn't do properly, and if you have a lot of patience and intuition with regard to optical physics, or don't care about accuracy.

That said, I don't think the click-on-corners method of changing light levels is inherently bad if people want it, though it won't be as precise.

The best explanation I can give about face orientation and editing from my understanding of the post is this; when you're editing lighting manually it can be confusing which vertex on the dialog corresponds to which in the level. (Appropriate highlighting could fix that, I presume.)

sirius
yes it seemed to me that that determines what orientation the new cube has. does anyone know the rule for what the orientation should be for a cube created from each side of the parent?

oopsy. you've reminded me that i saw a refresh hot key. arrgh! what an idiot i am!

perhaps i am not understanding exactly what the light tab does and how to use it correctly?
i find a problem with what corners in what cubes are affected by a light.
sometimes corners are lit that can't see the light lit. i.e. around a corner.

sirius, diedel
i think what i actual mean is the corner shading values that are used on all sides in every cube.
the cubes i am refering to don't have a light texture in them.

diedel
screenshot in dle? i suppose i can get an image of the window i'm editing in but the corner doesn't show up exactly as bright as they are in the game.
(and yes i'm now going to check my brightness setting in the game. perhaps it's too high)

i only fiddle with the corner shading when the lighting isn't as even as i want or is lit when the light texture/cube light shouldn't reach the side or cube that is lit up. as i said i had the same prob in dmb. couldn't understand how to adjust corner shading so the visibility of the wall increased/decreases uniformly from cube to cube.
as it would for real.
also can't seem to understand what exactly i am doing in the light tab and how to use it to get evenness from light to dark and back to light again when going from a lit cube to dark ones further away then getting brighter again as you approach another cube that has a light in it.
will look for how to load an image in a post. if i have to have a 24/7 site to host the image, don't know of where to do that.
what i want to have is as real a lighting as possible given limitations of display and code. i like to hid openings in shaded corners so that they can be overlooked that means the lighting fades with distance until an area is reached where it is dark and yet you can see behind you and in front of you lit areas. i don't like to use too much darkness.
this is an easy out to hide things and make it difficult. i want people to assume nothing is in that dark corner and go on by.
i know i'm missing something probably obvious cause it seems no one has the same question.
btw i have the original manuals that came with dmb and i couldn't understand what to do from that either. i'm not stupid. i'm just
r e a l s l o w.

Lighting in DMB2/DLE-XP

1. Brightness values are calculated per vertex (vertices basically are the segments corners).
2. If a face (segment side) has a light texture, the entire face is considered being the light; hence all vertices of that face will receive that lights brightness value.
3. Illumination will proceed to all faces in the vicinity of a light face up to a certain distance that can be reaching by travelling through connected segments and compute the brightness of each vertex of these faces. Brightness will decay depending on geometrical distance from the light source.
   
   This means that light will go around corners.
4. The light tools render depth sliders affects how many segments from the source face away brightness is computed; it does not affect the geometrical distance based decay function. So if the max. decay distance is smaller than the render depth, increasing render depth will not affect a level's lightning. If it is bigger than the distance that is covered by walking <render depth> segments away from the light source, increasing the light render depth will increase the distance up to where a light shines.
5. If a vertex is in range of several light sources, their brightness from several light sources add.

I hope this was understandable.

Increasing render depth always seems to make the light carry for longer for me, but I suspect it's because of the way I design levels.