DSAs in DSB

[Sophia]

Sophia, are you ready for this? Will you have a tool to convert DSAs to LUA code?

As intriguing as this prospect is, I fear I am not nearly skilled enough with the DSA language to even begin to attempt to write something that attempts to parse/emulate it.

[Paul Stevens]

Couldn't be easier to parse....example this code
from Conflux:

Code: Select all

LA L2147485696 &THISCELL L0 L17834 L15 L16 F

Becomes:

Code: Select all

LA();
L(2147485696);
aTHISCELL();
L(0);
L(17834);
L(15);
L(16);
F();

There....that's done.

Now, to emulate (Interpret?) we simply need
to write a few functions. For example:

Code: Select all

void L(int i)
{
  stack[--sp] = i;
};

Imagine Conflux in DSB! Woot! Might make zyx come back
in a year or so to do it right. He needs a rest but he will
eventually become restless. Been there. Done that.

[Sophia]

Ok, so the grammar is rather simple, which is good for me. The problem is that I don't even know it all that well, as my own experience with the DSA language is rather limited.

Is there an easy reference available? I've looked at some of the documentation, but some of it seems a bit old and may not apply anymore. It also seems geared towards easing a user into it, not something that someone who is basically trying to re-implement the entire language would need. Not that there would've even been a need for this kind of reference before, so I can understand why there wouldn't be anything. I've found a pretty good command list, for the &COMMANDS anyway, but I'm not sure how much of the basic structure this covers.

For example, I've never heard of the filter/opcode/etc. stuff mentioned here: http://www.dianneandpaul.net/CSBwin/TechDoc/TDDSA.htm Is it very old, or just something not used much, or what?

At the moment, I'm thinking the best approach would be to have the translation app translate the DSA code into some extremely rough and ugly but perfectly functional Lua, which is then executed directly by DSB. I'd probably not try to use the Lua stack directly, but maintain a special DSA stack, like your code suggests.

I think the different states could just be functions inside a giant Lua table. The DSA's own state could be stored in here, too. More thoughts as I think of them...

[Paul Stevens]

Well, Good Kid (You don't reveal your age but, if
you check mine, you will see I am pretty safe), I
was more-or-less joking when I suggested this.
Sarcasm....I cannot help myself...sorry.

This would not be a trivial pursuit. The code
is easy to parse and interpret but the input and
output of the Conflux scripts is very much tied to
the particular way that DM was implemented on
the Atari.

It would be a lot of work on your part. I'd help.
We could do it. But the only value that I can
see is that it would make Conflux a more easily
extended game. And zyx is talking about not
extending.

The example you linked to is very old. It set
forth my original thoughts when I first invented
DSAs. Very simply a message filter so that you
could do things like 'exclusive OR', sequential
analysis, extended counter functionality, fancy
boolean functions, and such without having to
bother me to invent something new every day.
Since then it has evolved into something entirely
different.

Mostly, for Conflux, it has become a method of
'hooking into the code'. I call them 'filters'. The
DSA scripts filter the wired-in actions and modifies
them. When I am about to move the party to the
north, I call the 'Party Movement Filter' to see
if zyx has some other action in mind depending
on the number of Sar potions the leader has
consumed. He might display a message and
block the party's movement, for example.

For example, I've never heard of the filter/opcode/etc

That was just an example of how you might
build a relatively general message filter that
does different things depending on the 'opcode'
provided as one of its two parameters. It
is sorta silly and probably out to be removed
from public view because it implies that such
a thing might be useful. It was simply an
example of the versatility of the DSA. Nobody
ever wrote one like that. But you could.

In closing......If you really want to spend
a lot of time moving Conflux to DSB then let's
go for it. But maybe it is too late to
be especially helpful.

I think a literal subroutine-threaded translation of
DSA code will require a 'GOTO'. Hmmmmmm.
Perhaps direct/indirect/token-threaded would be
best. CSBwin uses token-treaded code and it
seems quite fast enough.

EDIT: Fixed threaded terminology in last paragraph.

[Zyx]

It would be a lot of work on your part. I'd help.

Me too.

But the only value that I can
see is that it would make Conflux a more easily
extended game. And zyx is talking about not
extending.

Not me, but other people might extend it.
I find the project interesting. I think it might be interesting to have DSA powers in DSB. It means that CSBuild designers like me could develop their ideas in DSB too. It means importing all the CSBwin dungeons into DSB.
In the recent years there have been a lot of new dungeons and designers who surprised me with their energy and creativity. I think DSB is very promising but needs good dungeons to showcase it.If Sophia keeps maintaining her pace with DSB, the community of recent designers could follow the DSB path for the next years, and it could give us a solid dev-designer platform to make a real game, with all new graphics, that we own collectively, where we can work on connecting the dungeons on a outdoors map, and create stories that are meta-connected. Ahem. Maybe not .

Mostly, for Conflux, it has become a method of
'hooking into the code'. I call them 'filters'. The
DSA scripts filter the wired-in actions and modifies
them.

There are relatively few functions that interact with the external world of a DSA:

Code: Select all

ADD   (posMsk <location> obj ...) ;Add item to dungeon
  &CAST(...) ; Cast spell using previously stored parameters
  &CAUSEPOISON ( poisonValue Char# ... )
  &CELL! (location index num ...); Set info about dungeon location
  &CHAR! ( char# index num ... ) ; Set info about a character
  &COPY ( idSrc idDst ... ) ; Copy an object (eg: Change Actuator target.)
  &CREATECLOUD(<location> type size ... )
  &DEL   (obj <location> ...) ;Delete from dungeon
  &DELMON (<location> index ... ) ; Delete single monster from group of more than one
  &FILTEREDCAST(...) ; Cast spell (with filtering) using previously stored parameters
  &INSMON (<location> position ... ) ; Insert single monster into group
  &MONSTER! (id index num ...) ;Set monster information
  &MOVE  ( <source> <destination> ... ); Move item within game.
             <source> and <destination> are identical. Each with 5 parameters.
             ( locationType objMask positionMask location depth )
  &SWAPCHARACTER ( charIndex fingerPrint ... successFlag )
  &TELEPORTPARTY (<location> ... )
  &THROW (type objectLocation launchLocation direction range damage delta ...)
-----

You can emulate most of them easily, the major difficulty being to find a parameter-translator for them. You also need a parameter translator for the filters. That's "all".
All the rest is internal handling, which can be provided by Paul.

[Adamo]

this could be good, since we already have a good reference guide: http://www.dianneandpaul.net/CSBwin/DSA.pdf

[Sophia]

I think that converting the dungeon poses some significant obstacles of its own. So, I think that the best solution for me is to actually defer the decision on what I'm going to do until that problem is solved.

That is to say, if someone can get a CSBwin dungeon.dat-- and more specifically, Conflux-- loading and playing in DSB, I'll worry about porting the DSAs. Until then, it's a non-issue.

[Paul Stevens]

Would it help if we were to start with an
ASCII representation of the Conflux Dungeon?

http://dianneandpaul.net/CSBwin/AsciiDump.txt

[Sophia]

Would it help if we were to start with an
ASCII representation of the Conflux Dungeon?

http://dianneandpaul.net/CSBwin/AsciiDump.txt

In this form, in all honesty, it's not hugely helpful. However, the fact that this exists is very helpful, as it means there is code somewhere that can take all of the important parts of the dungeon and output them-- which in turn means that changing it so that it is output in a form that is much more friendly to DSB might not be such a terrible task.

To me the most daunting thing looking at initially is that I/we/someone would have to figure out just what all of those wall/floor/door decoration types, monster types, etc. numbers meant.

[Paul Stevens]

In this form, in all honesty, it's not hugely helpful.

I think you are wrong. Writing a program external to
CSBwin to reformat this information would be a lot
easier than changing CSBwin itself to reformat this
information.

What you see is the raw data. It needs
to be reformated for DSB. Reformating it within
CSBwin would require a lot of code that would
be useless when playing the game. Reformating
it in an external program would be easier because
we would be starting with a program that serves
only this one function.....not the additional
"engine" function. And not the complication of
the internal representation.

At any rate.....I would do a lot of the work of
writing such a program because I am familiar with
the meaning of all those numbers. You would
have to tell me what you need.

figure out just what all of those wall/floor/door decoration types, monster types, etc. numbers meant.

I bet zyx could be a big help. It is a one-time thing
that needs doing. He did offer to help. I don't think
it will be as daunting to him as to you.

Notice that no DSA information is included in the
dump I posted. I believe that the DSAs will be
the daunting task.

[Sophia]

I think you are wrong. Writing a program external to CSBwin to reformat this information would be a lot easier than changing CSBwin itself to reformat this information. What you see is the raw data. It needs to be reformated for DSB. Reformating it within CSBwin would require a lot of code that would be useless when playing the game.

Oh, I agree that making large changes to CSBwin in order to produce code that is directly useful in DSB would be entirely too much work and probably not the best approach. However, the thing that is going to help us a lot here is that a DSB dungeon is actually just an ordinary Lua program and does not need to look anything like something ESB (the editor) saves in order to be useful to DSB. That is to say, I was thinking of pretty much only superficial changes to what CSBwin output. If this dump was in a form that looked like calls to Lua functions, that would be enough. All that would be missing would be understanding of what the type numbers meant. I think that doing the reformatting within Lua code that is parsed directly by DSB will be even easier than an external program, too.

You would have to tell me what you need.

All I really need is an ASCII dump in a form that looks like a Lua program, where each section is the name of a function, and each line of data is a call to that function. To avoid any namespace problems we should probably put it all in a "convert" table. But anyway, instead of

Code: Select all

##Level Information
#
#level width height x0 y0 numRanWall numRanFloor ExpMult doora doorb
     0    31    31  0  0     1           2         0       0     1
     1    31    31  0  0     2           2         2       0     1

We would get:

Code: Select all

convert.level_information(0, 31, 31, 0, 0, 1, 2, 0, 0, 1)
convert.level_information(1, 31, 31, 0, 0, 2, 2, 2, 0, 1)

Things like actuators or other things that have a variety of options could pass a table containing the relevant data. I'd prefer anything yes/no be changed to true/false, and any coordinates be specified in the form of a table { level, x, y }, but those are minor, I'd think. Anyway, as an example, a line like

Code: Select all

##Database 3 = Actuators
#
# index link type     Options
     0 16902 <Pressure Pad> OpBy:PartyMovesOrTurnsSouth Target:(01,00)0 Graphic:0 OO:Yes Sound:No Delay:0 NC:No Msg:Clear

would become

Code: Select all

convert.actuator(0, 16902, "Pressure Pad", { opby = "PartyMovesOrTurnsSouth", target = { 0, 1, 0 }, graphic = 0, OO = true, sound, = false, delay = 0, NC = false })

Well, depending on how hard it is, reducing that opby from a long string into some flags would help even more, like opby = "party", opby_direction = "south", or something. I'd need to know what OO and NC meant, too.

This is the basic idea, though. Most of the heavy work would be done by the conversion code written in Lua. I've already figured out how to use the ObjectIndirectReferenceTable and the "link" value to figure out exactly what's anywhere in the dungeon. It's tedious for me to do by hand, but I've hand-checked a few squares, and they were correct, so it'd be no problem to make my program use this data. The only field I still don't understand is the "flags" of an individual square on the dungeon map.

The other thing I'd need is to make sure the information provided was complete. Like, right now, I don't know where monster hp is stored in that dump, or if it's not dumped. But maybe I just didn't know where to look. Lua is pretty flexible, as long as the information is somewhere, it shouldn't create any problem.

I bet zyx could be a big help. It is a one-time thing that needs doing. He did offer to help. I don't think it will be as daunting to him as to you.

Yes, I agree.

Zyx, when you have some time, can you help here?

Notice that no DSA information is included in the dump I posted. I believe that the DSAs will be the daunting task.

You're probably right.

On the other hand, we might be helped out by the fact that so much of what Conflux used DSAs for is already done in DSB. There would be no need to port the DSAs responsible for monster grouping or monsters making footsteps, as DSB does that anyway. All that would be necessary is knowing what monsters like to group with what, and what kinds of noises they make.

Zyx, another way you could be a great help is, of course, explaining what the various DSAs of Conflux are actually intended to do. As much as an emulation of the DSA language would be a fun and interesting computer science exercise, in reality, perhaps trying to duplicate their functionality using native DSB features would be a better use of time. There would be no need to directly port any contrived mechanics responsible for making gigglers steal off the floor, for example, as DSB has a direct hook that is executed every time a monster moves. An explanation from Zyx of what types of objects the monster likes to steal and what it does with them would be far more useful than any direct conversion of the DSA.

[Paul Stevens]

Another way of saying what I'm trying
to say....The raw data is in a very arcane
format....almost enciphered. Dividing
the job into deciphering and reformatting
makes each job easier. CSBwin is attempting
to decipher. It is far from complete, by
the way. Not all the information is in that
dump you see.

OK......this sounds very promising.
I agree that knowing what the DSA is to
accomplish is exremely better than decoding
the opcodes. There may be some necessity
to do at least a little of each. And it may
come to pass that some 'hand-decoding"
into a "human-readable" form will occasionally
come in handy.

Can we start by making a dungeon? With
all the levels and at least some of the
contents? You say you have figured this out
to some extent. Start there.....if you want
CSBwin to be less wordy, or put semi-colons
where there are commas, or put function-names
and parameters around lines, or whatever,
speak up. What I cannot easily do is combine
information from several of these tables into
a single, more coherent mess. The individual
lines can be formatted however we please.
I can certainly make each into a function call
with string parameters very easily. Then we can
try to tighten it up into well-defined values if
it makes sense to do that.

"OO" means only once.
"NC" means normally closed. ie: toggle the
outout from 'Set'/'Clear'. Sorta.

[Sophia]

Another way of saying what I'm trying to say....The raw data is in a very arcane format....almost enciphered. Dividing the job into deciphering and reformatting makes each job easier. CSBwin is attempting to decipher. It is far from complete, by the way. Not all the information is in that dump you see.

Ok, I agree.
In this case, I think if CSBwin can decipher to a different format that looks more like Lua code, I'll be able to write a Lua program that can be executed by DSB that will do the necessary reformatting.

Can we start by making a dungeon? With all the levels and at least some of the
contents? You say you have figured this out to some extent. Start there.....if you want CSBwin to be less wordy, or put semi-colons where there are commas, or put function-names and parameters around lines, or whatever, speak up. What I cannot easily do is combine information from several of these tables into a single, more coherent mess. The individual lines can be formatted however we please. I can certainly make each into a function call with string parameters very easily. Then we can try to tighten it up into well-defined values if it makes sense to do that.

Ok, sounds good. These are the basic "rules" I would like to follow. It's mostly mangling various fprintfs so I'm hoping they're not too troublesome.

Every line of data should be designed to look like a Lua function, calling a function with the same name as its section inside of the "convert" table. That is, lines giving level information should become calls to "convert.level_information", lines giving information on available wall decorations should be calls to "convert.available_wall_decorations" and so on. The parameters can just be separated by commas; it doesn't have to look like a table any more.
All those -1's in the decoration lists aren't necessary. Lua functions can support a variable number of parameters. If it's easier to pass them to keep the number of arguments constant, it's no trouble to handle them, though.
Anything yes/no should be represented as true/false instead.
Coordinates should be represented as a table of the form { x, y, direction } instead of a string of the form "(x, y)direction"
EDIT: I formerly thought the direction parameter was a level. But actuators in DM can't target things outside of their own level, can they? So it's a direction, I think. Or a parameter of some sort, anyway.
Things like the "Pressure Pad" actuator info that uses a variety of named fields can also specify it as a table, in the form of { key = value, key2 = value2 } and so on. So a line like:

Code: Select all

821  7043 <And/Or> Graphic:1 Delay:0 OO:Yes  NC:No Target:(23,11)0 Initial:0 Final:15 Msg:Set

ends up looking like

Code: Select all

convert.actuator(821, 7043, "And/Or", { graphic = 1, delay = 0, oo = true, nc = false, target = { 23, 11, 0 }, initial = 0, final = 15, msg = "Set" } )

For something like "OpBy:Object=95" there are a few ways to represent it, but anything that doesn't require me to parse a string is fine. Even if it's as simple as something like: opby="Object", opby_parameter=95
Lua comments start with "--", not "#"
All numbers should be decimal. Lua doesn't understand the 0x prefix.
I think the code that dumps information about a "PushButton" actuator is missing a \n (or at least it was at the time that dump was made)
Information like where a teleporter goes and whether or not it has an associated blue haze, what a shooter actually shoots, and so on, is probably going to have to be included somewhere, too. Where in the dump isn't terribly important as long as it's in the form of a function call and I know what the parameters mean. This could come later, too, depending on how much work it is to extract this information.

Is this doable? If I can have output in this format, it would be very helpful!

"OO" means only once.
"NC" means normally closed. ie: toggle the
outout from 'Set'/'Clear'. Sorta.

Ok, thanks.
Do you know (or is there documentation online somewhere about) what the "flags" for each square in the dungeon are?

[Paul Stevens]

Flags for the squares depend on the
type of the square....

http://dmweb.free.fr/?q=node/217

7/8 of the way down....Map Data

I'll be working on your requirements. A couple
of iterations of changes should get us to the
dungeon maps and contents.

[Paul Stevens]

See if the new AsciiDump.txt is
more to your liking.

[Zyx]

Zyx, when you have some time, can you help here?

Of course. I'm travelling by plane in a few minutes, though, and I won't able to connect to the forum for a week.

Zyx, another way you could be a great help is, of course, explaining what the various DSAs of Conflux are actually intended to do.

OK, I'll document a few DSA for a try.

[Sophia]

It's getting closer, definitely.

Lua doesn't directly support named function arguments, so the current function calls won't work. I originally was thinking of just using C-style function calls, however, if you'd rather name the arguments to the function (and I can see good reasons to) this is simple enough to fix; the function just has to pass a table instead. In terms of how this is output, it's simple. Every "(" becomes "({" and every ")" becomes "})" so the call looks like:

Code: Select all

convert.level( {level= 0,size={32,32},offset={ 0, 0},numRanWall=1,numRanFloor= 2,expMult= 0,doors={ 0, 1}} )

It's the same as described here: http://www.lua.org/pil/5.3.html

The parameter passing for actuators is also not going to work at present.

Code: Select all

convert.actuator(index=  386,link= 4043,PressurePad(OpBy=Object=147,Target={08,05,0},Graphic=0,OO=true,Sound=false,Delay=1,NC=false,Msg=Set))

In addition to needing to be a table, that syntax you've chosen where the "PressurePad" part looks like a function call as well probably isn't the best way to get along with Lua. I'd rather pass the actuator's type as a string, and then pass that data in the table immediately afterwards. Any words that aren't Lua reserved words or variables we've already figured out would have to be passed as strings in quotes, too, such as the name of the actuator's type, the opby, the msg, and so on. The "Opby=Object=147" syntax won't work well with Lua either. How about something like:

Code: Select all

convert.actuator({index=  386,link= 4043, type="PressurePad", OpBy="Object", OpByArgument=147, Target={08,05,0}, Graphic=0, OO=true, Sound=false, Delay=1, NC=false, Msg="Set"} )

That is, everything is set apart into its own field of the table, and all strings are quoted.

Clothing indexes are specifed with a "CT" prefix, potions with a "PT", miscellaneous items with an "MT". These aren't necessary. It'll probably work better if the index is just an integer. Just 49 instead of MT0049, and so on.

Finally, roomType is another word that should be a quoted string, i.e., roomType="STONE" not just roomType=STONE.

Thanks.

[Sophia]

Of course. I'm travelling by plane in a few minutes, though, and I won't able to connect to the forum for a week.

Enjoy your trip.
I've got enough work ahead of me it'll probably take that long anyway...

[Paul Stevens]

The various actuators are so different
that I thought it best to use different
functions for them. Couldn't you provide
a function named "PressurePad" that would
return whatever table you like? Certainly
a parameter to a function can itself be
a function call.

I thought the CT0049 might be actually
better so tha you could define the various
contstants at the front of the program
(#define CT0049 "HELM" or whatever).
Generally goo practice not to put numeric
constants in programs. But I can do whatever
you think best.

Let me know.

The other things you suggest are easily done.

[Sophia]

The various actuators are so different that I thought it best to use different functions for them. Couldn't you provide a function named "PressurePad" that would return whatever table you like? Certainly a parameter to a function can itself be a function call.

Ok, I can see there is good reasoning behind that, but in my opinion calling this PressurePad function and passing its return value to the master convert.actuator function is the wrong way of achieving this separation. I'd rather make actuator a table rather than a function and build the functions into it:

Code: Select all

convert.actuator.PressurePad( { index=  386, link= 4043, OpBy="Object", OpByArgument=147, Target={08,05,0}, Graphic=0, OO=true, Sound=false, Delay=1, NC=false, Msg="Set"} )

How does that sound?

I thought the CT0049 might be actually better so tha you could define the various contstants at the front of the program (#define CT0049 "HELM" or whatever). Generally goo practice not to put numeric constants in programs. But I can do whatever you think best.

I was going to use the integer provided as an index into an array to get the item information. So I agree with you but I've just got a different method in mind (#define doesn't exist in Lua) so I'd rather just have integers. The array will be changed just as easily as the defines, though, so it'll still avoid the bad practices.

The other things you suggest are easily done.

Great.

[Paul Stevens]

We should be getting closer.
You will be happy to see that the latest
attempt has been zipped to save time and
space.

[Sophia]

Thanks. It's working.
Well, that is to say, it parses. It doesn't produce anything resembling a dungeon yet, but that's my next step.

I had to make some changes to the file to get Lua to parse it. It was nothing search and replace couldn't fix easily, though. I don't need anything further from you at this point, but they're bugs that should probably be fixed so we can automate this process and convert some other CSBwin dungeons. Further iterations of this one will probably be necessary, too, for that matter, because there is still plenty of information missing.

convert.dungeon doesn't pass its parameters as a table and should
convert.IndirectTable was mistakenly entered as convertIndirectTable (without the dot)
The first convert.scroll item ends up commented out (probably a lack of \n after the -- spacer)
The "Disabled" actuator put in a superfluous ) after the function call, same for "MonsterGenerator" i.e., })) instead of })
"local" is a Lua reserved word, I changed it to "Loc"
Occasionally a double comma got generated in an actuator's parameter list, I just changed it to a single one
The line before expool still contains a # comment (I don't know what expool even does, anyway...)
There is unnecessary whitespace inside of the string for types like "STONE" which shows up as "STONE ", other shorter strings do this too.
. in strings was showing up as \, which caused problems when next to a " (Lua thought it was being escaped) I just changed it back to . across the board for now. Strings still look like a mess so we'll have to sort this out later on...

I was wrong about Lua not understanding 0x for hex. It apparently does just fine with that. Good for us. However, it also has adopted the C convention of assuming anything with a leading 0 is octal. Not so good for us, because some numbers, such as targets and types for some of the databases, have leading zeroes and will result in the wrong number. I fixed this with some searching and replacing too, but the leading zero should probably be taken out.

[Paul Stevens]

Lots of things fixed and some things added.
New result has been posted.

Don't know about "Strings still a mess".

[Sophia]

Sorry, I got an iPad and kind of zoned out on this one.

I've tried the new version and it has the following parse errors:
The type= field for a Swapobject is blank (resulting in parse errors when you get a "type=,")
Msg is not in quotes properly in Swaopbjects either
Swapobject sometimes ends in )}, should be })
Andor's target is specified as target=Target=, which is a syntax error (should just be Target=), or sometimes there is just a blank target= without anything
true is sometimes misspelled as treu
. in strings shows up as \

I'm also thinking, once this is working, perhaps if you could dump the basic DM dungeon instead of Conflux, it might be useful as well... starting with something a little less complicated to at least write the converter.

[Zyx]

I've been checking my DSAs. Some are extremely long and complicated. It would take me a year to explain them down to the level of detail that you need.
I can send you notes about a DSA if you wish, so you can reproduce the generic functions, but someone will then have to do the dirty work of translating the specifics. Documenting everything is like creating again conflux from scratch on a verbose mode. I still think that the best way would be to reproduce the DSA code and mimic/translate the external structure they need (for example the codes for the types of objects, the information about monsters, the parameters for the filters).

[Sophia]

Yeah, I'm not sure about the DSAs...
I was trying to just get something resembling the dungeon loading first.

[Paul Stevens]

All of your complaints have been addressed by
the new:
http://dianneandpaul.net/CSBwin/AsciiDump.zip

Note that it was done under the influence of
just a bit of vodka. So please forgive me my
trespasses.

[Paul Stevens]

Yeah, I'm not sure about the DSAs...

I agree with zyx that there is no way these can be
translated into a different language by human beings.
The error rate would be too high with little means for testing.
I personally think that this whole business is a
lost cause. But.......if Sophia is willing to give it
a try then I am willing to help. The DSA language itself
will be the easy part. Implementing the primitive
operations of the language will be the show-stopper in
my humble opinion.

Vodka still at the helm!

[Sophia]

I personally think that this whole business is a lost cause.

What whole business?

You might be right about DSAs, particularly the sheer complexity of Conflux's DSAs. Still, I think it's doable and beneficial if we can come up with something that lets us load CSBwin dungeons into DSB, don't you?

[Paul Stevens]

What whole business?

Getting Conflux to run in DSB.

load CSBwin dungeons into DSB, don't you?

I do. That is why I am willing to help. And that is why
I have put forth effort to dump dungeons in a DSB-friendly
format.