Portraits on Trick Walls

[Paul Stevens]

I do not want to hang portraits on 'Trick Walls'.
Or on pits, teleporters, or stairwells for that
matter.

Let us discuss the problems this decision will
cause all you clever designers. Perhaps we can
implement somthing that will solve your problem
and have the potential of solving other problems.

PAul

[beowuuf]

Its more wide ranging, as that blocks putting any actuator on any false wall and pit, right? Or is it specifically the portrait?

The only concern about actuators on both walls and floors is that floors have less graphics available that wall objects, so you cannot allow a high number decoration be a floor actuator too...

The idea of puting portraits on a false wall is that you can steal their objects, or you could of course hide a better champion behind a worse one and no one would suspect.
We are so used to DM by now - that false walls only happen on plain walls, etc, that any tricks like these are unexpected and can have you scratching your head

[Paul Stevens]

floors have less graphics available that wall

I will admit that this is true. But do you want to
put a Torch Holder on the Floor? I don't get it.
====================================
It seems that the main idea is to put a graphic
on a trick wall to sort of 'hide' the fact that it is
a trick wall.

I will look into this a bit. I have no idea what
happens if the wall becomes invisible, for
instance. Will the decoration hang in space?
Should it?

I still think there must be a more clever solution
to the problem. I will ponder it as I do some of the
other things that need doing.

[beowuuf]

Ah, well with normal actuators what happens is, for example, a torch holder graphic wall object will, when the trick wall is solid, be a torch holder. When the wall is removed it becomes a floor actuator with, say, a floor slime graphic. So you need to make sure that the graphical number supports both variations - if the wall graphical number is above the floor support, glitch occur.

Functionalitywise a button on the wall operated by mouse becomes a floor actuator operated by anything when stepped on, for example.

For illusionary walls, if you touch the wall object it acts as a wall object. When you walk through the wall the actuator will act a a floor object. Graphical number doens't matter here, as the party can never see the floor object so no graphical glitching.

So you could have an alcove with a pit infront. The player tries to work out how to get to the key, not realising you can walk into the wall from the side and get the contents of the alcove that way. To be nasty you could give the alcove some floorpad functionality so when they step on it it does soemthing too.

[Paul Stevens]

And people complain about the complications of adding
an Alcove????? And you are suggesting the design of
a single actuator that can serve two useful purposes?
One on the floor and one on the wall? Wow!

Thanks for the info. That saves a lot of testing on my
part. But it reinforces my notion that this is not a trick
to be taken lightly. For example, you say that graphical
number does not matter, which may be true in DOS or the
Atari where there is no memory protection, but in CSBwin
it could easily cause a Memory Fault unless I check for
it explicitly. The original code did very little checking....it
assumed that everything was perfect.

At any rate, let us ponder this before taking any action.

[beowuuf]

The usual actuators by their nature do both, but I don't think a new one needs to go that far...

I hadn't realised you had beefed up the protection on the engine, then indeed half of these will raise nasty errors unless specifically coded back again as exceptions!
And I can see that the easier they are to implement in a game, the more you will get vague 'my dungeon doesn't work' complaints that will give you headaches to debug.

[Zyx]

Be careful with this thread. look at its numbers:

http://www.dungeon-master.com/forum/vie ... hp?t=23156

Let's not play too much with hell... Portraits on Tricks walls, maybe they're not so important after all :-)

[Paul Stevens]

You have convinced me.

Just to keep you informed. I am making CSBuild allow
Portraits on Trick Walls. Then I will make sure that
CSBwin does not get confused at runtime.

This is pretty easy to say; it is a little more tedious (not
difficult) to implement. But it will be 'clean'. And it will
allow additional kinds of things in the future without too
much chance of breaking everything.

[Zyx]

Thank you again for you efforts and congrats for having solved this affair!

[Paul Stevens]

OK....what in the name of all that is holy is a
door doing in the middle of the Stone Wall at
00(03,16) of TeamDungeon?

For now I will put code in CSBwin to ignore it.
But the original code attempted to interpret it
as an actuator with God-Only-Knows what
effect. The original code is full of this kind of
logic: "This is a wall and you don't put doors
in walls and it ain't an apple and therefore it
must be an actuator".

[beowuuf]

Its an alcove with a vorpal blade : ) It's a cut down clone of the teleporter tile with a teleporter above the 'alcove' floorpad at (0, 18).
So effectively the alcove at 3, 16 will teleport the vorpal blade away if you do the test successfully, because when the teleporter at 0,18 activates anything in the alcove goes too

[Zyx]

Hehehe I recognize the signature of Beowuuf here in this craft...

[Paul Stevens]

Yes. Beowuuf wrote me a detailed account of what he
did to that dungeon. I will no doubt find it useful
in the future as I try to make it work with CSBuild and CSBwin.

[beowuuf]

Lol, or just good betime reading if you have insomnia
I apologise in advance if level 7 is a nightmare, btw