Deepsea

Okay guys, I know how some of you feel about Deepsea, good and bad, but I just wanted to let you know that I have just received Deepsea version 12.13. It hasn't been updated on Deep's webpage yet but he should be updating it in the near future, I believe he's waiting for official updates for R3Dedit 1.6.34 before officially releasing version 12.13 of Deepsea. R3Dedit 1.6.34 beta can be used at this time with 12.13 until the official stuff comes out. The new version allows objects to be created inside of 3D editing. Here's part of what I received from Deep...


Most of the changes have to do with editing, so the old docs have a few revisions. Nothing complicated, should be easier than before.

Press F1 to get a basic overview for commands that are not listed here. Some keys have been changed.

For example, the cursor left and right keys strafe left and right Cursor up and down move forward and backwards (as before).

The < > keys rotate. Mouse movement also rotates.

You can change any object graphic (or thing type) without clicking on the object - but you can click too. Just press the Enter key to get the dialog.

To change a ceiling or floor height or to move a Thing (using the mouse movement). Here you do have to click on the object first.

"P" pastes prior texture as well as Ctrl+V. (don't know if I'll keep P or not).

Ctrl+C Copies current texture to internal buffer, next Ctrl+V uses.

Ctrl+Z Undo just 1 texture pointed to

Ctrl+R Resets ALL textures of the type pointed at back to original value. For example all middle textures.

You have to release Ctrl to repeat any of the Ctrl+ commands. Might change that too.

In Thing mode, pressing INS inserts a new Thing of the last type used at the location you are standing.

You can change the type/attributes by pressing Enter or Right clicking (same as for other objects).

For PNG textures, support for patches is not final in DS, but pretty much done in R3Dedit. There's a new option in "F5 - colors that determines the accuracy of the translation to the DOOM palette. This is a speed option. Translation is required because the editor maps to the DOOM palette.

That's what I have guys, take it easy.

Cool thanks for posting this, although I still don't have a reason to upgrade.

Cadman said:

I just wanted to let you know that I have just received Deepsea version 12.13. It hasn't been updated on Deep's webpage yet but he should be updating it in the near future, I believe he's waiting for official updates for R3Dedit 1.6.34 before officially releasing version 12.13 of Deepsea. R3Dedit 1.6.34 beta can be used at this time with 12.13 until the official stuff comes out. The new version allows objects to be created inside of 3D editing.

Just recieved ... ? JV also gave me a copy of both DS 12.13 and R3Dedit 1.6.34 ages ago. Deepsea.exe dated April 2006 and R3Dedit.exe dated Jan 2006. At the time I informed him of some very minor bugs and did not get a reply. With all the debacle with Risen3D in October 2006 I thought DeepSea had left the Doom scene. It's good to hear that they are still a going concern.

Useful information. Someone will appreciate it.
I still have no reason to upgrade my version though, and it's over 10 years old. Does everything it needs to do, which is a testament to how advanced of an editor it is.

Hopefully someday it will be released as freeware. Dunno how likely that is to happen. The price tag is sort of steep for an editor with a pretty worthy opponent (DoomBuilder), and it's the only reason more people don't use it. :(

That is good news. I thought Jack had left for good. I too had mentioned a few 12.12 bugs to him a year or more ago and we chatted about it but then he stopped posting on the various Doom related forums.

Has PNG support in the editor improved? 12.12 displays pngs in a funny looking palette, cannot display png sprites in thing previews, and multipatch textures that use pngs look odd in DeePsea and sometimes crash R3DEdit.

Also, decorate parsing for thing menus wasn't too good for the newer format of DECORATE objects.

Those were my main beefs with 12.12. I'm sure there were other niggling things but nothing at all was "show-stopping".

I have the registered version from like 4 years ago, and I notice that using F10/D to find unnecessary textures is buggy.  For example, on E1M2, <s>linedefs</s>sidedefs 667 and 669 each have two extra textures, but I only get warnings for the lower ones.  Is this fixed in the new release by any chance?

(Sorry for the bump, but I couldn't find a complete changelog on the DeePsea site.)

Xeriphas1994 said:

For example, on E1M2, linedefs 667 and 669 each have two extra textures,

F10/D looks for textures that are not needed.

Line 667 and 669 have on side 1 sector 40 (floor 16 ceiling 136). On side 2 is sector 41 (f 16 c 80). So, there is a difference in ceiling height either side of those lines, but not floor height. As a result, the texture on the lower side is not needed and the lower textures are correctly flagged up by F10/D. However, because of the difference in ceiling heights, the ones on the upper sidedefs are needed and therefore do not get flagged up.

No bug indicated by these results.

@Xerifas1994

What Enjay is saying is that your version of Deepsea is not buggy at all. The upper textures for those lines are required.

Gaah, I meant *sidedefs* 667 and 669.  Couldn't read my own handwriting, sorry about that.

I'm going to take a guess here and, again, assume no bug but rather that DeePsea is just being cautious.

These lines/sides are the red key door. DeePsea should not flag up extra textures when there is a chance of them being exposed by the sector moving (not 100% foolproof). Seeing as how this is a door, it's not flagging up any upper textures as being extra. OK, so these upper sides should never actually be exposed but I assume that DeePsea has a routine in it somewhere that says "if sector is a door, do not report upper textures as being extra".

Enjay, that is certainly a viewpoint I would never have discovered all by myself.  Redundancy helps stabilize a computer program, they say, and designing levels seems more and more like programming the more I learn about it!   :D    After I saw your post, I went through the entire DeePsea help file, and it does sort of address this situation obliquely (it says that any sector which moves up or down may need textures that aren't obviously required at its initial height, notwithstanding the actual menus from which the user selects actions, where "door" is a completely distinct category from "floor raise/lower" and "ceiling raise/lower".  It also mentions that rising stairs frequently screw up the texture-related error checks).

So I guess it's good that a mapper would not be distracted by a lot of "nitpicking" items in the DeePsea error log.  However, by that logic, a missing texture or an orphaned tag in a dummy sector cannot be a bug because it could never affect normal gameplay, yet many people consider these important enough to complain about or catalog.

Anyway, if I wanted a more complete inventory of redundant textures in a level, it sounds as though I need something like: (WP:BRFA pseudocode)
*  Get list of all sectors which are tagged to raising/lowering actions, including doors.  Then, for each sector,
* *  Does it abut another sector on the list?  If so, flag as "maybe" and return.
* *  Is it tagged to multiple action types?  If so, flag as "maybe" and return.
* *  Otherwise,
* * *  Based on the action type and the adjoining sector heights, figure out the maximum and minimum heights of the floor and ceiling.
* * *  Do a normal check (as you describe above) at each z value in between, as though it were a motionless sector.  If any texture on any boundary linedef is unnecessary for _all_ combinations, flag as "yes".

Is that right?

Designing a full-proof algorithm to cover all possible outcomes in this instance should be considered a "hard" problem, in other words; not really possible.

As planes can move freely and surface textures change at any time it is not possible to correctly determine with 100% accuracy as to which sidedef sections require textures without pragmatically running through the map and opening all doors, triggering all switches etc, etc in every possible order in which the player(s) are able to do so. However, due to the way that plane target heights are calculated there is also a question of timing involved. For example, if a switch moves a plane to a height relative of another which is already in motion.

All Deepsea is doing here is attempting to make life a little easier for modders by flagging up likely problems.

DaniJ said:

All Deepsea is doing here is attempting to make life a little easier for modders by flagging up likely problems.

And, to be fair, in most cases, un-needed textures are not problematic at all and merely add a few bytes to the size of the WAD. It's a check and clear-up that I sometimes run but, most of the time, I don't really bother with it.

I was commenting in the context of reporting textures that should be present but are not. Not the other way around.