CSBuild Tiles Replacement

[Gambit37]

Edited on April 26, 2003 by Christophe: The attachment has been removed to save space. The new alternate tiles are now part of the CSBuild distributions.

I was finding CSBuild difficult to use as I found the icons a little indistinct. So I built a new set of icons which I feel distinguish objects more clearly. They are based on the icons I've used for the maps on The Dungeon Master Codex (http://www.dmcodex.com), and luckily Paul Stevens had used the same size icons (16x16) so I had very little modifications to make.

[Paul Stevens]

Thank you. They look very nice. I will package
them with CSBuild as 'alternate' tiles which can
be used by simply renaming the file.

(You can tell that I am not an artist!)

[Gambit37]

A little gaudy perhaps, but my main gripe was not being able to easily see the secret walls...

BTW is there anyway way in CSBuild of making a visual distinction between illusory and toggle walls, and also all the different door types? It would be cool to have distinct graphics for all these items! And based on that, how about extra tiles for distinguishing monsters, items, etc....

[Gambit37]

Oh, and I wanted to say, it's very clever how you overlay and rotate all the special tiles such as triggers and items!

[Paul Stevens]

'Cool' is nice. But I dislike making extra work for
'cool'. When I am designing a dungeon I can pretty
much remember what I put there. So the little red
dot as a hint is sufficient for me.

If more graphics would make things easier then it
certainly can be done. But I don't want it and therefore
I will not be designing it. Either the graphics themselves
or the rules for displaying them.

For example, if there is a monster, a scroll, a Diamond Edge,
and a DexHelm in one corner of a square....What do I draw?
One option would be to simply overlay them so that one
may be hidden by another.

Perhaps we could have a config.txt file that would override
the default operation. Something like:

monster 7
misc 11 ; miscellaneous item like food
scroll 8
weapon 12
default

and they would be displayed in the order that they
appear in the config.txt.

The bitmaps for these would have transparent areas
so that they could overlay the cell graphics.

The 'false' walls are all one type in my mind. I don't
even know what you mean by 'illlusory' or 'toggle'.
As I recall there are two attributes for these walls
that can be independently specified as 'on' or 'off'.
So there are four wall types.
But again, we could override them in the config.txt:

wall01 13
wall02 17
wall03 4
wall04 12

You would have to tell me what names to use
for the four cases.

The doors could be treated likewise. Since the door
types might change by editing the graphics file it seems
that the only way we could name them is to use their
number. Or use the default names that the CSBwin
uses when you edit a door.

door01 6
door02 9
etc.

In general, if we adopt something like this then
I would change the way I do the graphics. I would
have the bitmaps for the cells and the bitmaps for the
items in a cell be separate. Then I would draw the cell
and overlay it with the contents of the cell. Probably
better.....assuming someone else does the artwork.

Suggestions??

[Paul Stevens]

By the way....the tiles don't have to be 16x16. CSBuild is
supposed to adapt to whatever size you draw. Untested.

[Gambit37]

You're clearly a heavy duty programmer!

Illusory walls are those that appear as walls but can be walked through. In your parlance that would be "False wall passable even when inactive (visible)". Toggle walls are walls that are either visible and impassbale, or invisible and passable, normally toggled by using a switch. As far as I recall there are no other variations in either CSB or DM, regardless of what bits can be set....

I see the problem with multiple objects on a tile. I believe that DMute simply draws a coloured dot for the topmost object, so yes, I agree that rules for the order of objects would need to be defined. Perhaps this isn't so important; what would be more useful is separate graphics for things like keyholes, alcoves, etc....

I am happy to create the artwork for your proposed tiles, if you are willing to implement the feature once it's been discussed.

[Paul Stevens]

OK. I understand your wall terminology. You
don't care to see if the wall is 'active' or 'inactive'.
Three cases:
1) inactive and you can pass through.
2)inactive and you cannot pass through
3)active and you can pass through.
The forth case I thought I might implement
in the runtime..
4)active and you cannot pass through.
Then that attribute would say:
"Pass thru visible and blocked by invisible"
or
"Passable = visible"
or
"Toggle passable" (I like this one)

Well, now. There are a lot of what I call 'wall
decorations'. Things like switches and alcoves.
I suppose we could do the same thing for them.
A wall can contain many decorations, also. An
alcove filled with objects is an example. A missile
launcher with many objects ready for launching.
A torch holder with two different graphics and a
torch.

At any rate......I don't want to think about these
things myself. I am willing to implement them for
someone else's benefit if they think there might
be a kind of universal need. But since I don't need
them I cannot be the one who decides what is needed.
(I would decide on 'nothing'.) And as a programmer
I need very specific design specifications. You are not
allowed to say "Make it easier".

[rain`]

Make it easier!

My thoughts about a great editor is ease of use, functionality, and quickness (in that order). If you have functionality but shitty ease of use/quickness, you may as well hex edit the dungeon =[

Here are some ideas for "ease of use" for CSBuild:

1) Actuator and Teleport targets able to be chosen by the click of a mouse, instead of looking up coordinates and typing them in (This saves lots of time). Simple way of doing that is to make a shortcut (F1), that when pressed, changes the cursor to a new cursor (perhaps an arrow w/ a question mark, signifying "what tile", then, when you click on a tile with left mouse click, it turns into a crosshair cursor, which allows you to just click on another tile to make the teleporter/actuator etc target that tile instead. As for changing the level, a simple pageup/pagedown keybind or up/downarrow would be more then sufficient. And at all times during this process, right click or Escape will cancel the action completely. Its things like this that make an editor really nice.

2) Cut, Copy, Paste (I'm not sure if CSBuild has this). It may be hard to do, but it is the standard for "ease of use"

3) Undo/Redo, again, extremely difficult and time consuming to code at times, but still a life saver in the "ease of use" category. This isn't that important, seeing as its not always a problem. In a simple DM map editor, a 75-depth undo buffer isnt exactly important (but for something like AutoCAD or photoshop, its almost manditory).

Making a functional editor is a hard enough process in itself, but w/o ease of use, i wouldn't enjoy using it =[

As far as quickness goes: Fill tools, box tools (fill an entire area with imaginary walls, etc), eye dropper, line tools make everything much faster. I noticed that in order to make a room, 5x5, filled with actuators in CSBuild, it takes a good 5 minutes, but if you had the fill tool it'd take 2-3 seconds.

I'm not demanding all this be done, i'm just stating that ease of use surpasses functionality (in my eyes). Its great you put all the effort in things like DSA's, but if we haven't even a clue how to use them or if they even make things easier (documentation? =[), its almost wasted effort.

-rain`

[Gambit37]

Although his thread has changed topic somewhat, I'd like to take the opportunity to agree with Rain.

Ease of use (or rather a lack of) is the main reason why I haven't got into dungeon editing as much as I would have liked.

DMute is probably the best all rounder because its simple point and click interface allows quick and dirty basic dungeon building. Complexity is achieved through hex editing which gives the most control but is 100% counter-intuitive.

DMBuilder I've hardly used because it doesn't support the mouse. Sorry, but in this day and age of right-mouse clicks, popup menus, context sensitive property lists etc, I really don't have the time or inclination to read a whole bunch of keyboard instructions just to do basic stuff. And the screen layout needs a lot of work.

CSBuilder opens up a huge amount of complexity in a reasonably easy to use format. But it's lack of simple point-and-click editing (the teleporters being a good example), it's usability is severely impaired. And looking at pages of AND/OR logic means nothing to me. I need simple options that make sense!

Between all you developers, you've made some great tools, and the amount of time invested has clearly been immense. But I fear it's all wasted if the power of these editors is locked away because of a poor user interface and lack of documentation. I understand that each of you initially designed these tools for your OWN use and that to each of you individually, the interface you've designed is 100% logical. This is compounded by the fact that you are all very obviously excellent programmers, but it's a well known fact that programmers rarely have great design skills....

CSBuilder probably has the best overall interface at the moment, simply because it does pretty much what I would expect (right clicks rule!), and that's the true measure of a usable interface. However, if the intention is to get people to start actively using the tools to develop dungeons quickly and easily, then improvements to all 3 editor's interfaces are required.

OK, so I'm in no position to make demands; indeed I'm not demanding anything. But if it helps, I am willing to document what I feel would make a great intuitive GUI... any takers?

[Paul Stevens]

The target selection is something I have planned to do.
For teleporters and actuators. Perhaps it could be
implemented with a "Brouse" button by each target
specification in the (for example) Edit Teleporter dialog.
Actuator targets need a level, x, y, and (for want of
a better name) direction. Teleporters only need level,
x, and y. I'll work on that.

"Undo" is not too well defined in my mind. It has to be a
very simple sort of thing because testing is difficult.
It is not clear what 'Undo' should do. If, for example, you
create a teleporter and then edit its properties should an
'Undo' undo the last thing you changed about the teleporter?
Or back up and remove the teleporter? And it seems you
really need a 'un-undo', too. I know that I would like these
things myself. Maybe I could provide automatic 'Checkpoints'
every time you change the type of cell on the map or leave
a dialog box after making changes. And ctrl-z ctrl-y to move
back and forth among the checkpoints. (Thank goodness for
fast computers.) A big problem here.....Let us say that you
change the destination of a teleporter and then work your
way around to the Edit Monster Generator dialog. Now you
press CTRL-Z. How do you know what it is that you have
'UnDone'? You are looking at one dialog box and the changes
are taking place on another...how will you know what changes
are taking place? It could seem very confusing. I think perhaps
the Undo/Redo should be confined to the time you are looking
at the map. Then I only need to do the checkpoint when you
change a cell or return to the map after making some changes.
Would that be OK?

Copy and paste. Copy could save the state of a dialog box
and paste could set it to the saved value. So that there
would be a 'clipboard' entry for teleporters, a 'clipboard'
entry for pushbuttons. et cetera. Better yet would be
clipboard entries with names so that you could save many
pushbuttons (for example) and restore any one of them.
None of this will come easy. Why don't you tell me where you
most need copy and paste so that I can try it and see if it can
be made to work.

What did I miss?

[rain`]

Undo, copy, paste, cut:

I was referring to the actual tile editing actually, for example, you can cut a tile, and you cut everything about it, making it a strict wall. If you paste, it will paste that tile anywhere, including monsters in it, items in it, type of tile, teleporter, door, actuators (including destination of them and all features). This could make some actuator work alot less time consuming (like i stated above, a 5x5 room full of actuators is a tough job to do!). As for Undo, it would simply undo the last tile change you did and/or cut/copy. Something as simple as that could make editing a lot smoother of a task. And what to copy/paste, I would say that when you CTRL-X/CTRL-C, it could simply cut/copy the tile thats underneath the mouse, and CTRL-V would put the tile where the mouse is. Perhaps instead of right clicking being strict "edit tile", you could make a popup menu containing "Edit tile..." and "Cut, Copy, Paste". Maybe even "Add monster...", "Add Item". Anything that makes the process faster makes your editor that much better.

Then again, every new feature/idea implemented causes more to be wanted *grin*. Please note i'm not demanding this be done, its just suggestions.

In the tile editor (with the 5 boxes, 4 for items and 1 for actuators when working on a non-wall tile), cut/paste would simply cut 1 or more selected objects/actuators and be able to paste them in a different room or different side of the room.

These few simple (i say simple, but depending on how you've been coding the editor, this could be quite the task =[) changes would be extremely nice.

-rain`

[Paul Stevens]

Thanks. That is very helpful. I will ponder
this a bit and perhaps have more questions.
Some of these things could be done easily.
Some with difficulty. But they seem like useful
additions.

[PicturesInTheDark]

Hi Gambit,

apart from agreeing I'm on. I also feel that the developers on this forum are doing a great job, but the work is seldom planned and nearly never documented. So the end user (and I'm also one of those who prefer simple options since I'm not a programmer) that wants to build a dungeon is at a loss with more than DMute which poses enough traps with the hex editor.

So: to enlarge your request a bit - I would like a poll about a unifying effort of different editors, tools and suchlike (including the various converters) to create one tool (or if not possible one package with various tools) that is planned, has bugfix notes and an intuitive documentation.

I think there are more than enough people here that if only 10 of them put efforts in different areas we could assist the programmers (and thank heavens they're there and all doing such great jobs!) in smoothing their tools for the end user.

Christophe. could you please make a poll for that? I'd like to know if that proposal gets a general agreement - including the programmers themselves of course, since it's their main work and they need to be willing to give up their "babies" for a joint effort.

Regards

PitD

[Paul Stevens]

There is no hope of unification. In my humble opinion.
We tried that with DMBuilder and CSBuilder. We broke
up after two days because of very basic differences
in our philosophy. And DMute is an entirely different
animal and George is into RTC.

Documentation is difficult and unrewarding. Some of
you folks who need documentation are probably best
qualified to produce it. That is one way you could help
with these tools without having to be a programmer.
And you could "unify" your documentation efforts!!!!
So why don't you have a poll to see who would be
willing to help produce unified, intuitive documentation.
I won't hold my breath.

If you want to produce a 'Windows Help File' and don't
know how to get/use the Windows Help File compiler, I can
assist you with that.

[Gambit37]

I agree that a unified approach would be impossible.

I would be willing to help with documentation, but not until I have my other projects more complete (DM Codex). So that's at least a few months away for me. Plus I'm not sure how much I could help with because I don't fully understand a lot of DM/CSBuilder's functionality anyway!

[PicturesInTheDark]

Probably right. But it seems a waste to think some of those highly creative tools will never be used by the majority (including myself) because their UI is not too intuitive and their features are never properly listed in one place.

I think documentation alone is too little - ease of use (although probably a programmers pain in the ass) is as important as features - maybe that's where some work could be put in, if programmers are willing to use the results.

Thoughts?

[Paul Stevens]

Well, I am willing to use your suggestions. I am
currently implementing copy/paste and undo/redo
as suggested a few replies ago.

The problem is that there must be a negotiation.
The suggestions and code must each try to mold
themselves to a common obtainable and useful
implementation. What might be possible with DMute
might be quite unreasonable with CSBuild. We carried
out a little of this negotiation with regard to the copy/
paste and I think the result will be good for everyone.

When this is done I will work on the target selection
as requested.

By the way.....Rain has told me that if I stop work
on CSBuild then he will make a small, easy-to-use
editor. So it sounds like you might have a volunteer to
do this right. So far, nobody seems to have adopted
the proper philosophy of dungeon editing. We have
1) Too much hex
2) Too little mouse
3) Too much mouse
4) Too little capability
5) Too much capability
6) Too little documentation
7) Too simple
Too complicated
9) et cetera

[beowuuf]

Lol, just to jump in to Gambit's comment aaaaages ago about the non-mouse...

I actually like DMbuilder's interface - you should really give it a chance, once you get used to the keyboard short-cuts (which is actually no time at all, most of them are very intuitive, I got it in under an hour when I properly tried it) you will find there are alot of things you can do so swiftly.
It helps that I like to sit back from the computer when I can, so no mouse is a nice change : )


I remember so long ago asking for hex documentation for Dmute, I can't believe my first manual draft is the only thing around.
At the moment I'm not too busy to do some documentation, or at least co-ordinating information. But I'm far too long winded to write it up at the end - I think someone else needs to do that for the final version!

Anyone with info/an ability to write technical stuff in simple terms? : )

[Paul Stevens]

Another thing I should mention.....there really
needs to be some sort of cost/benefit analysis
when it comes to making enhancements for the
sake of "Ease Of Use". Take the example of filling
a room with 25 identical acutators. It costs five
minutes. Say it is done twice per dungeon design.
Say that one design is prepared every week. That
is ten minutes per week or 520 minutes per year.
That is 9 hours per year. If it takes me 40 hours
to design, implement, test, and release and it takes
you 5 hours to document then that is a total of
45 hours. The payback is 5 years under very
unrealistic assumptions. Moreover, all the work is
being done by one person yet everyone agrees that
they would like to help but they are not "programmers".
Well.....spending five minutes twice a week to create
actuators will save a programmer 40 hours. That
is a REALLY BIG HELP! And you already know how
to do it.

Writing programs is easily as tedious as creating
actuators. Therefore a tradeoff is called for.

Things like "Undo" are a bit different in my mind.
Occasionally the lack of an "Undo" could cause a great
amount of work to be lost. This does not seem to me
to be an "Ease Of Use" enhancement. Besides. the
copy/paste that comes almost for free with Undo/Redo
can also be used to fill the room although not quite as
neatly as with some sort of tool like "Fill".

[Sphenx]

Ah .. we broke up after two days? ... I don't rembember well I just know that I have not enough time to spend into DMbuildeveloping.
That's right, our philosophy is different. I'd rather like to see pictures of items rather than just texts. I think it is faster to search an item through images, and it was my choice to make DMbuild eye-candy ; )

Anyway we tried to make DMbuild and CSBuild compatible, and I still hope we could do so in the future. CSBuild is based on the real run-time CSB engine, while I designed DMbuild according to the dungeon.dat format.
Knowledge were different.

As programmers, we design first the editor for our convenience I guess. In my case, DMeditor should have been a simple editor that edits little stuff that was wrongly done in DMute, such as door ornate editing, or floor pad graphics .. I just found that I couldn't edit dungeons as I want with DMute that I decided to make my own editor. It wasn't supposed to be released when I started this. Anyway, it offered some other features than DMute, so DMeditor was a "complementary tool" for DMute.
That's right I did not worked much on the interface, and I did not want to lose time on interface. Because DMBuilder is quite very functional, I find that I can edit very quickly things that would take MUCH longer to do with a mouse and clicks. Time loss. I know in these modern ages it is unusual to have UI without mouse, but really, I don't know what functionnality I could give to the mouse in DMbuilder.

On the technical part, I would like to hide any parts with hex values to the user, but that means I have to work on the interface .. and this is not my priority : ) And I have many many ideas to add in DMBuilder ...

About documentation, I admit this is not the prefered part of any programmers. Would be nicer if documentation were done by users.
(with one section about the secret features of DMbuild)

By the way, I still don't know if my programme is called DMBuild or DMBuilder. Could some help for that?

[Paul Stevens]

I agree with everything Sphenx says. Even the fact that
the keyboard is faster than the mouse....at least after
you practice a bit. And I agree that User Interface comes
after functionality. I think he said that.
And I agree that there is not enough time.

In fact, I never would have considered CSBuild if it had
not been for the fact that the first time I used DMBuild
it crashed every time I tried to do a very simple operation.
I posted a bug report and received no response. After
that it was all over - I had started and could not stop.

My goal was to provide a framework that was flexible
enough to handle ****ANY**** special cases without
any knowledge of the internal representation of the data.
And to be independent of the graphics.dat.

So now we have each other to agree with. Even if nobody
else agrees. The Irish should get along so well.

[Gambit37]

I only wanted to improve the images of the tiles... and look what happened!

You made an interesting point about the costs/benefits analysis. However, it doesn't change the fact that the perceived benefit to a dungeon designer will always be based on how quickly and efficiently they can build their dungeon. It's a bit of a lose-lose situation.

As for no mouse in DMBuild(er), I'm willing to give it another go, but I'm not confident. I'm not too bothered about how quickly I can do something, but how intuitive it is. Using a mouse will always be more intuitive that using a keyboard for this kind of application, the same way that using a graphics tablet in PhotoShop is better than using a mouse.

It's a question of real-world experience and expectation. 10 years ago I was developing CBT using a keyboard driven application called Quest. Although I got quite adept at using it, it was a pain, and I'll never forget the relief at moving to a mouse-based tool called Authorware--finally, I could just pick up stuff and move it where I wanted to. Indeed, it was this fundamental question that Wayne Holder asked in the early days of developing DM that led to its intuitive interface: "Why can't I just pick up an object in the dungeon and put it in my backpack?" The answer of course led to the development of the first real-time drag and drop interface that we know and love.

My view is simple: I believe that a similar approach is required for these kinds of programs; I don't want to have to learn lots of keyboard options, I just want to click on something that says "Add door" or whatever. This is not a criticism of CSBuild, DMbuild, or any other tool, but simply my view about how interfaces should be designed.

If any of the developers reading these forums what any further information about intuitive interface design, I am happy to provide it.

[Gambit37]

About documentation, I admit this is not the prefered part of any programmers. Would be nicer if documentation were done by users.

This is fine if two conditions are met: 1) That the user has already had the time and inclination to work out how to use the program 2) The programmer provides information about all the other things the user hasn't discovered/has documented incorrectly.

The main stumbling block here is that there's no way a user can document a program if they give up using it after the first attempt because it's not easy to use. A bit of a catch-22 don't you think?

[Paul Stevens]

I wonder if my bias is influenced by the fact that I
work on a laptop and my mouse is a part of the
keyboard. I don't have to reach for a mouse. It
is under my thumb and forefinger at all times.

I agree with Gambit, too. So I can agree with
at least two people!

The documentation: Having end-users do it assures
that the questions that end-users ask get answered.
Fighting the program and asking questions are great
preparation. These people SAY they want to help.
Writing the program requires "time and inclination", too!
And please, when was the last time I failed to give
a much too long answer to a user's question? I don't
mind answering questions whatsoever. I rather like it.
(Except for that fellow who used swear words, directed
at me, in describing his problem.)

[rain`]

About the time spent to time saved theory:

I totally agree, which is why i stick to visual basic for creating apps like that (It is, by definition, "ease of use"). But my suggestion is that if it takes 9 hours to make the "fill tools" etc that you say aren't worth your time, then I'd suggest saving that 9 hour job of making it until its the only thing left to do (anotherwords, the lowest on your priority). If you do manage to get around of it, its a few more happy campers out there. It is very important to discuss things like this with the people who are going to use the editor, not only do you get feedback (which motivates you to continue working on it), but you also get good ideas on what to do next, and what comes before what in the process.

Another argument on that point (Not that im debating it, just something to think about), is that if your editor is easy to use with really nice features (that you say may not be worth the time), you may get *more* people using it because of that, and it may balance the equation. It's not a pure fact, just a different POV.

Lastly, Its unfortunate that you have to make an editor to make your own dungeon (because the current ones out there "dont cut it" in your eyes), especially when you've already spent so much time on CSB4win: But since we are not a "warcraft 3" sized group of people who play this game, we cannot expect a gold shiny editor which sets the standard for all editors in all games to exist.


And as for documentation: I would make documentation for CSBuild, but documentation is needed for users (including me) to understand what things do (For example: DSA's, which in my mind are unusable to me w/o documentation). Most of the other stuff I could figure out eventually, but since you have first hand experience (since you are making the editor), you are the one most qualified to write documentation because you understand it at a "code" level. It doesnt have to be super fancy or tutorial filled, just as long as *someone* understands it other then you.

Now if only i spent half the time with your editor as i did here id have more then half the dungeon done =] *grin*

-rain`

[Paul Stevens]

Nobody has ever asked a single question about DSAs.
I was under the impression that nobody had noticed
them.

I guess I was wrong.

In fact, I don't think I have fielded more than one or
two questions altogether!!! So I assumed everything
was understood or unneeded.

Perhaps I was wrong.

What don't you understand? (It is all quite obvious
to me Certainly things like the teleporter edit
dialog are self-explanatory. Perhaps I am wrong.

Actually......
Another thing I would like to do is add some help in
the program itself where it is easily accessible. I did
this for the DSAs because I, myself, cannot remember
the details. You can help decide where this might be
helpful by asking questions.

Another hard question is whether an external Help file
is worth the effort. I like the fact that CSBuild consists
of only two files (I wish it were one): the executable
and the tiles. Adding a .HLP file? There are tradeoffs.
It is easier to modify independently of the program.
It is a little bit harder to access from the program.
It is very much prettier.
It adds another needed file.
It would be easier for multiple people to contribute.
It is harder to get started.
It could be as simple as a flat text file with embedded keywords.
Hmmmmm. Writing this down makes it seem like
a pretty good idea. But then, I am working on undo/redo
right now. With overlayed tiles and a GUI-way of
selecting targets waiting in the work queue.

****** IN ANY CASE ******
Documentation will NOT be written by me. I will answer
questions and someone else can put the answers in
a proper format. I can help decide the format and I can
compile it into its final location but someone else will get the
credit (we can include a by-line).

[PicturesInTheDark]

Hmm.

Guys, I'll try a different approach altogether, I still think we're stuck here.

First of all: I have the gut feeling there are a lot of (at least: enough!) people here to combine their efforts on improving the current state-of the-art of various tools already available.

Second: I also have the impression we're talking on a very theoretical level so far and pretty much leave out the actual planning. I can follow most of the reasons given here for/or against various changes, documents, work costs etc... but that does not actually get anything started.

Since my Personal want (need?!) is to have tools that are intuitive enough to have some joy with building and modifying dungeons I'm willing to be part of ONE workforce.

So here's my actual suggestion - I'd first of all like to get an overview that tells me (and others interested):

1) What programs/tools are available in which current version
2) Who is/are the programmer/s working on them (+email?)
3) Who are the people willing to put their time and effort into enhanements, documentation, programming aid, whatever?

On a second step I'd then like to assign (or let people choose) who wants to team up for which project/s - for example I'd be interested in CSBuild or a proper guide for the hex editing mostly, since those are the ones I have seen at least and they would help me most in my own dungeon creation.

Then we could start individual dialogs between programmer and his/her helper/s - reporting progress on this forum. On this individual basis (maybe asking for feedback if necessary, e.g. the mouse/non-mouse question could be a poll here for one program or another) I can see progress made faster and agreements being easier than if all people here discuss everything.

Let me know your thoughts please.

Regards

PitD

[sucinum]

the thing, that would speed up dungeon building the most for me are these options:
-draw larger floors and rooms with mouse button held in seconds
-copy/paste not only tiles, but also rooms and whole levels
-create shooters with some clicks
-have all options of textmute included
-when c/p teleportal, choose if you copy the absolute target (level 4, x 3, y 3) or the relative target (2 steps left)
-see, what i get instead of having to fiddle with tiles just to discover, that graphic doesnt exist on that level
-let monsters carry items easily (easier at least)
-set the color-offset at the level or even for each monster with some clicks (instead of all that stuff with check level integrity in dmute^^)

ok, its over a year you saw the last dungeon from me and i want to make clear that i am only asking for these things.
it took me hours only to make the plain level layout for prison-ii and i felt the whole time as wasting it, because the engine worked against me.

btw: the first time i saw csbuild, i decided that my next dungeon will be done with this. i really like your work, paul, and want to thank you for it