Dragon Fogel
Level: Smitemaster
Rank Points: 2561
Registered: 06-21-2014
IP: Logged

Replying to skell: I think the fact it's trivial is exactly why it's getting so much discussion. It seems like it wouldn't be a big deal to implement any one solution, because it's such a minor edge case, so people feel fine proposing things because it's not like it's going to have a huge impact.

But also, there is no actual obviously best solution so anything that gets proposed will be disliked by somebody else so they want to speak up to prevent the thing they dislike from getting implemented without objection. I know that's why I won't shut up about it, at least, even though I've basically already accepted that my own suggestion won't be implemented.

In fact, I probably should minimize confusion by not bothering to clarify the reasons I suggested it, since it's not on the table and I'm honestly okay with the "no connections by default, do them yourself" approach happening instead.

Someone Else
Level: Smitemaster

Rank Points: 2357
Registered: 06-14-2005
IP: Logged

I'm going to throw my vote in on the "default to toggle" side of things. Here are my reasons:

1) If door A is connected to door B and an orb is connected to A, it should have the same connection as it had to A to A+B.

2) If both A and B are connected to the orb, the orb should still have a connection.

3) We don't really want this to have puzzle potential. If we did, it would be better if Open+Closed=Toggle, Open+Toggle=Open, and Closed+Toggle=Closed. Therefore, Toggle should be the default.

TFMurphy
Level: Smitemaster
Rank Points: 3118
Registered: 06-11-2007
IP: Logged

Dragon Fogel wrote:
Build order would not impact the eventual suggestion other than "splitting" a door into two or more separate pieces before connecting one of those pieces, which is an impact of build order that is unavoidable no matter what the system is.

If multiple doors are connected, the set of connections that remain are the ones that apply to them all, regardless of what order the connections happen in.

No, in your last edit you said that "any connection" would conflict with "no connection". A newly built open door has no connection. A newly built open door automatically conflicts with any door with a confliction. Case 1 fails. If the door being built is considered an exception, then a newly built door that connects another newly built door that is not yet connected would conflict, but would not conflict if the two doors were built the other way around.

I see nothing in your proposed ruleset that sidesteps this. I assume by the 2nd paragraph that the next part of the rule would be "no connection only counts if the door is connected to another orb"... after which this particular proposal of "delete" is quickly becoming more complicated than anything else proposed.

Dragon Fogel wrote:
But also, the plan is to add scripting to change door connections, so we're only talking about what to do with default behavior in situations where the architect decides not to use that scripting. Consequently, anything that gets decided can be overridden by an architect.

Scripting is difficult and finicky. Sure, in my contrived example, I could wait for "no building markers" in the rectangle and then painstakingly hook up the orbs as I wanted. I'd probably have to disconnect the orbs before building started though, or Beethro will have been happily toggling his way to some interesting results. (Interesting results are going to happen if he's toggling a door I'm working on anyways, but the point is that I can't trivially determine when I should finish hooking up the doors correctly if the game deletes them unless I take full control of everything here.)

I fully expect that if and when these proposed script commands go in, they will be used to just this effect. It's good to have them. If a bad edge-case came up, a good architect would just wipe the connections themselves and set them up correctly. But a good default is still desirable, especially one that isn't so destructive about existing information.

Dragon Fogel wrote:
So I think it would be a mistake to add rules that are complicated to deal with on the player end. Specifically, for this to be relevant to a puzzle, the player would have to have some degree of control over which doors get combined - otherwise they can just let the combining play out and check what the final door does afterwards.

This proposed system makes it much more complicated to find a "bad door", because every connection in the system is relevant. To me, this basically sounds like a worse variant of a "hit the orbs in order" puzzle.

This is one of those times where I don't think "puzzle viability" is a great argument. This is about building tools given to an architect and having them being simple and relatively intuitive to use without causing dire problems (multiple connections) if used carelessly.

The proposed solution has very few rules attached to it. It may be possible that someone may try to make a puzzle out of it... just as they might make a puzzle out of "conflict->delete". The merits of that puzzle will likely be judged on how it communicates itself to the player... in the meantime, I still prefer a simple non-destructive default that doesn't require the architect to script everything up again (though they can if they want to).

Dragon Fogel
Level: Smitemaster
Rank Points: 2561
Registered: 06-21-2014
IP: Logged

Okay, I think where we disagree is that I don't think this is simple.

It's simple on the player side if you don't use it in a puzzle, but so is every system. Even a system which is completely ludicrous, like "the door will be opened by the most northwest orb in the room", will just boil down to "the player clicks on the door and sees what it does". It may not make sense but they'll be able to work out what to do with it afterwards.

The architect can't always get away with that, though. In fact, now that I think about this, the system you've proposed sounds awful to architect with. If I want to change the properties of the final door I end up with, trying to figure out how to modify that just by changing the orbs will quickly give me a headache and I'll be running to the script command anyways. Which does not really do anything to make this system sound more useful to me.

Dragon Fogel
Level: Smitemaster
Rank Points: 2561
Registered: 06-21-2014
IP: Logged

Also, I just realized: in your contrived example, there are no issues with rescripting things until doors with conflicting connections get connected to each other.

You can just check one of the starting tiles of each door, and re-add its initial connections.

Conflicts are trickier, but shouldn't be that bad if the script command is implemented so you can use it in an If statement to check for a specific connection. You have to add the connections in a specific order, but as long as it all processes in one script this shouldn't actually impact anything - nothing will be able to happen while one connection is hooked up and another one isn't.

The one thing that could seriously complicate this would be replacing doors with something else partway through, if you did it in a way where it would be hard to predict which tiles stop being doors. Short of that it doesn't seem like a very difficult script to make, though.

TFMurphy
Level: Smitemaster
Rank Points: 3118
Registered: 06-11-2007
IP: Logged

I just want Cases 1 to 4 to work as I expect them to work (no orb conflicts anyways). I don't want some inconsistency in build order (and there will almost always be build order considerations even with a simple rectangle plot) to wipe all connections when I might not even know it happened.

Case 5 was always the debatable one, and I'd default to expecting the orb to still do *something* to the door. "conflict->toggle" is independent of build order, and independent of any extra doors being added later, and a single rule for edge case. If I don't *want* that orb to do something anymore, I'd prefer to make that decision myself.

With the "delete" proposals, all I keep thinking about is that some odd combination of plots ends up deleting every connection from an orb to a door without any indication that this has happened (or even could happen).

Dragon Fogel wrote:
The architect can't always get away with that, though. In fact, now that I think about this, the system you've proposed sounds awful to architect with. If I want to change the properties of the final door I end up with, trying to figure out how to modify that just by changing the orbs will quickly give me a headache and I'll be running to the script command anyways. Which does not really do anything to make this system sound more useful to me.

If you want to change the properties of the final door, you *should* run to the script command. The point of the default is to have some sane result that might not need changing as a result of some chaotic (where chaos may not even be intended to be so but is simply because of room orientation or order of build commands) combination of room changes.

Dragon Fogel
Level: Smitemaster
Rank Points: 2561
Registered: 06-21-2014
IP: Logged

TFMurphy wrote:
The point of the default is to have some sane result that might not need changing as a result of some chaotic (where chaos may not even be intended to be so but is simply because of room orientation or order of build commands) combination of room changes.

This is basically impossible to do because we have no idea what room somebody is going to try to make where it might be relevant. Any system is just going to be a guess.

I'm just not convinced that this is a good enough guess to be worth the potential headaches. Deleting all connections is almost certain to be wrong, it's true, but at least it's easy to understand why it's wrong.

Nuntar
Level: Smitemaster

Rank Points: 4964
Registered: 02-20-2007
IP: Logged

Dragon Fogel wrote:
I would like to note that I do not like this option because it is a whole set of priorities to learn for a situation that will almost never come up.

As I have said, though, the player does not have to learn the priorities, because conflicting connections will only happen in a small minority of cases. Having some way of dealing with conflicts (and one that at least has some internal logic that can be learned) is the price to pay for having a simple system that does what would be expected in the 95% of cases where there are no conflicts.

It's the same reason why we have things like the list of directional preferences for brained monsters, and probably other examples that aren't coming to mind right now.

____________________________
50th Skywatcher

Dragon Fogel
Level: Smitemaster
Rank Points: 2561
Registered: 06-21-2014
IP: Logged

I don't think it's that unlikely.

A scenario where an orb opens one door and closes another is fairly common. And I have no idea what sort of rooms somebody would even want to make around connecting doors - but it certainly doesn't seem that unlikely to me that they'd use this common setup somehow.

To me, this feels like making things more complicated for the sake of maybe avoiding scripting, and in a lot of cases you're going to go for the scripting anyways because the complexities of the system aren't worth the trouble to untangle. The main situation where you wouldn't is one where you just want to see what happens.

Kalin
Level: Master Delver

Rank Points: 233
Registered: 01-25-2016
IP: Logged

Any sensible Architect or Engineer would disable any involved orbs (or plates) before modifying a door, and only reactive the orb after modifications are complete.

____________________________
he/him
~170th Skywatcher

mrimer
Level: Legendary Smitemaster

Rank Points: 5195
Registered: 02-04-2003
IP: Logged

Okay, I'm starting to read posts more carefully now so I'm not continually restating what's already been said like the noob I clearly am.

After reading through all the new material, I'm now soundly in the "conflict -> toggle" camp. That seems such a simple rule to clean up the entire current mess, and I don't believe there's one simpler.

TFMurphy's thought experiment was super helpful to get me to this point.

I think the idea of adding connection scripting is intriguing...but my spidey sense tells me it might lead to more rooms like my Worst Room Ever With the Builders at the End of TCB (TM) more often than not.

The above rule still works fine to resolve any and all current bugginess even if no new scripting ever comes to light, so I'm good with that option.

Edit: ...and...um...do we *really* want connection scripting? Do we want to enable scripting to modify other door colors? Have pressure plates that wake up evil eyes and put them back to sleep? I'm sure there are more giggles we could come up with. Am I just punchy from lack of sleep or is this going to be a thing?

____________________________
Gandalf? Yes... That's what they used to call me.
Gandalf the Grey. That was my name.
I am Gandalf the White.
And I come back to you now at the turn of the tide.

---

[Last edited by mrimer at 10-17-2020 04:15 AM]

Dragon Fogel
Level: Smitemaster
Rank Points: 2561
Registered: 06-21-2014
IP: Logged

With all due respect, that seems like the worst option out of everything suggested so far.

As I said above, under these rules, if I attempt to make a combined door room for some reason and I have several doors and orbs involved, it will be very hard to tweak it if I decide partway through that I want the final door to do something different. The suggested script command is the one thing making that issue a minor point in the discussion. Without the script command it becomes central and I think this is an even worse idea than I already do.

mrimer
Level: Legendary Smitemaster

Rank Points: 5195
Registered: 02-04-2003
IP: Logged

Dragon Fogel wrote:
With all due respect, that seems like the worst option out of everything suggested so far.

As I said above, under these rules, if I attempt to make a combined door room for some reason and I have several doors and orbs involved, it will be very hard to tweak it if I decide partway through that I want the final door to do something different. The suggested script command is the one thing making that issue a minor point in the discussion. Without the script command it becomes central and I think this is an even worse idea than I already do.

It's fine to disagree and have different opinions. I'm open to continuing the conversation.

What I'm saying is that we should make a logic fix in 5.1.1, but there won't be any new scripting until 5.2 at least. So, how are we going to fix the current odd logic in 5.1.1 so that it would be sensible, either with or without scripting?

However, isn't skell right that this isn't even a big deal? Which holds have issues with this? How many architects are wanting to build holds that combine door behaviors? I thought it was none, but I'm probably wrong.

May I request you restate what you think makes this option the worst one?

It would help me understand if you could describe what else you would want combined doors with conflicting orders to do differently (without scripting, for 5.1.1) than this proposal offers?

Was it that you'd prefer some type of positional determination? To be clear, I'm completely against position-based resolution because it sounds so fiddly, messy, and opaque. Like adding more snake movement rules for no reason. That's my perspective.

____________________________
Gandalf? Yes... That's what they used to call me.
Gandalf the Grey. That was my name.
I am Gandalf the White.
And I come back to you now at the turn of the tide.

---

[Last edited by mrimer at 10-17-2020 04:37 AM]

Dragon Fogel
Level: Smitemaster
Rank Points: 2561
Registered: 06-21-2014
IP: Logged

mrimer wrote:
Edit: ...and...um...do we *really* want connection scripting? Do we want to enable scripting to modify other door colors? Have pressure plates that wake up evil eyes and put them back to sleep? I'm sure there are more giggles we could come up with. Am I just punchy from lack of sleep or is this going to be a thing?

It's already possible to make a script that wakes up every evil eye in the room (although probably with weird side effects, since you'd be doing something like summoning decoys in their lines of sight... and I guess it wouldn't work if they were directly against a room edge or something that couldn't be removed with building) and one that destroys every eye in a room and replaces them with newly generated ones (although that messes with their move order). So a hypothetical script command to do this would just let it be done in a cleaner way.

I guess you couldn't feasibly link plates to specific eyes, rather than basing it on the positions of the eyes, but you could probably do something similar with custom monsters that move/stop moving based on pressure plates.

And with Build commands you can replace colored doors with other colored doors. You could even set up an orb that changed a closed colored door to an open one or vice versa, although the interface wouldn't indicate it does that.

mrimer
Level: Legendary Smitemaster

Rank Points: 5195
Registered: 02-04-2003
IP: Logged

Sure, I'm aware we can do these things via scripting.

I'm asking are we interested in doing these kinds of things with a New Type of Scripting?

Reminds me of what happens in fun houses.

____________________________
Gandalf? Yes... That's what they used to call me.
Gandalf the Grey. That was my name.
I am Gandalf the White.
And I come back to you now at the turn of the tide.

Dragon Fogel
Level: Smitemaster
Rank Points: 2561
Registered: 06-21-2014
IP: Logged

mrimer wrote:
Was it that you'd prefer some type of positional determination? To be clear, I'm completely against position-based resolution because it sounds so fiddly, messy, and opaque. Like adding more snake movement rules for no reason. That's my perspective.

I'm not going to defend it at this point, mostly because it's apparently difficult to implement so it's definitely not on the table. To be clear on one thing, I consider the important part of the concept to be door dominance - the position-based resolution is just the least-bad way I can see to make door dominance work.

I am opposed to the proposed concept because it sounds complicated to work through. I would find it a headache in any situation where I had to think about it, and without a script command that would include "trying to use it in a room I'm building".

At this stage I think it would be best to use the destroy-all-connections approach. Whatever else you can say about it, it's not complicated.

mrimer
Level: Legendary Smitemaster

Rank Points: 5195
Registered: 02-04-2003
IP: Logged

My apologies if I made you feel defensive. I'm not asking for a defense; just trying to understand what you'd want in this scenario. I appreciate the response.

Dragon Fogel wrote:
At this stage I think it would be best to use the destroy-all-connections approach. Whatever else you can say about it, it's not complicated.

I agree "conflict -> none" is no more complex than "conflict -> toggle".

My preference tends to the latter because doors would still operate in this case, whereas in the former they simply stop working, and I'm not seeing this as a common preference, and I'd prefer to err on the side of what is likely to be the least problematic most of the time.

I can't envision cases where the architect would want to combine doors with conflicting orders in order to make them stop working. What's a good puzzle around that?

Am I understanding correctly that you are wanting to build puzzles based around door combining?

____________________________
Gandalf? Yes... That's what they used to call me.
Gandalf the Grey. That was my name.
I am Gandalf the White.
And I come back to you now at the turn of the tide.

---

[Last edited by mrimer at 10-17-2020 03:16 PM]

Dragon Fogel
Level: Smitemaster
Rank Points: 2561
Registered: 06-21-2014
IP: Logged

Actually I was referring to skell's suggestion of "stop working, period". I realized later that "conflict -> delete" is just as complicated to sort through if the resulting door doesn't do what you want, which is the main problem.

Without the script command, it's not feasible to adjust such issues once the room passes a certain level of complexity. Of course, it's not possible at all if you make the door stop working, but that also means you can realize that sooner so you don't spend an hour trying to make it work before giving up.

Edit: I don't actually want to make puzzles around this. But I dread the idea of solving puzzles based around it, and this doesn't seem very friendly to the hypothetical architect who wants to make them either.

The only situation this seems to have any use for is the room where you just plop down a bunch of doors and do a bunch of building and see what happens.

---

[Last edited by Dragon Fogel at 10-17-2020 05:06 AM]

mauvebutterfly
Level: Smitemaster

Rank Points: 776
Registered: 05-03-2015
IP: Logged

Regarding concerns that architects might abuse whatever system we ultimately decide on, I think that's a moot point. Architects can already design truly wretched rooms if they want to.

I think it's better to err on the side of simplifying the rules for the sake of the player than to try and prevent architects from making terrible play experiences.

[conflict --> toggle] seems like a relatively straightforward rule that wouldn't be any more prone to abuse than stuff you could already do with orbs/plates/doors as it is. The reality is that no matter what rule we settle on there will be ways for architects to make miserable rooms around it. Having a relatively simple rule underpinning everything at least makes it somewhat more reasonable from the player's perspective, so I'm in favour of using a [conflict --> toggle] rule. I think that this would be more intuitive than a [conflict --> erase connections] rule, even if once you know the rules they are roughly equivalent in complexity.

____________________________
106th Skywatcher

Dragon Fogel
Level: Smitemaster
Rank Points: 2561
Registered: 06-21-2014
IP: Logged

Here's the root of my issue with it.

[conflict -> toggle] sounds like a simple rule... but it only is in one direction.

If you try to work backwards, you immediately get [toggle -> conflict] and there are multiple possibilities for conflict. If you are trying to create some toggles and prevent others, the possibility tree quickly becomes unwieldy.

This is also true for [conflict -> delete].

Door dominance does not explode in possibilities as readily, because adding one more door only adds one more possibility. And nullifying all connections simply means that it doesn't matter what the original connections were, so working backwards is completely unnecessary.

So basically my preference is for a system that's simple in both directions. This tends to favor systems that toss most of the information out indiscriminately.

Xindaris
Level: Smitemaster

Rank Points: 1605
Registered: 06-13-2015
IP: Logged

Well, as for me...I don't actually care about the original bug. I only jumped into this discussion at all because the possibility of adding script commands to add/remove connections was brought up. I very much want that, and in fact I already have a custom element which would be easier for other people (and for me) to put into rooms with that scripting, and which doesn't do anything convoluted or weird.

Just in general, scripting that can set up door (or force arrow) connections for the architect, dynamically, allows for the creation of custom elements which incorporate doors/force arrows and orbs into their design. Or just a script that toggle/open/closes arrows or doors would be workable, but also less visible to the player. I see this as extremely helpful and valuable, again, because I already made one thing that would benefit from it greatly, and which doesn't invoke any Bad Architecture.

____________________________
109th Skywatcher

Here are some links to Things!

---

[Last edited by Xindaris at 02-10-2021 05:48 PM]

mauvebutterfly
Level: Smitemaster

Rank Points: 776
Registered: 05-03-2015
IP: Logged

In one direction we'd go [conflict --> toggle]. Reversing that to go in the other direction we'd get [toggle --> toggle]. Basically, the way I'm seeing this, is that toggle would overwrite all other behaviour. Once the connection is a toggle, it can no longer change.

Maybe I'm not understanding what you mean when you say that [conflict --> toggle] only works in one direction.

Two doors are joined together and the orb previously opened one and closed the other; it now toggles the entire bigger door. What exactly is the other direction? The door is split into two smaller doors? The orb would now toggle both of them, even if it used to open one and close the other at the start of the room.

____________________________
106th Skywatcher

skell
Level: Legendary Smitemaster

Rank Points: 3775
Registered: 12-28-2004
IP: Logged

I wanted to note I wasn't planning to fix the merging issues for 5.1.1, but I guess if you guys can decide on something I'll get it done.

For what it's worth, I don't understand complaints about conflict -> toggle rule being complex or confusing, Also I don't understand what toggle -> conflict means, because the idea is that any conflict resolves to a toggle, no edge cases here that I can think of, and no dependency on anything other than the door's comnections themselves regardless of order, as no matter how you expand, shrink or modify the doors before merging they'll end up the same.

Either way it doesn't matter much how we decide to do it. O wouldn't even mind keeping it as-is and depend on the architect to decide how to resolve it, if not for the fact that it's easy to not know this rule and not know you need to clean it up.

____________________________
My website

Dragon Fogel
Level: Smitemaster
Rank Points: 2561
Registered: 06-21-2014
IP: Logged

What I mean is trying to reason back from a desired state of the final door and figure out what produces it, if you also have desired properties for the initial doors. This quickly turns into an unpleasant mess.

I started from "this sounds horrible to try to solve puzzles in" and then when I thought about trying to actually use these rules to deliberately put a room together - not even a puzzle, just something where I want to set up a door to do something specific after the building resolves - it didn't sound any better.

mrimer
Level: Legendary Smitemaster

Rank Points: 5195
Registered: 02-04-2003
IP: Logged

Thank you for the additional discussion and input. I appreciate the considerations for what will work out best for both architects and players.

There appears to be a general leaning toward "conflict -> toggle" being the preferred option, with the understanding that, without what I'm calling "association scripting" (in whatever form it ultimately takes), there may be situations that aren't ideal.

Given this, I'd like to move forward with the decision that for 5.1.1, we'll modify the current logic to be as follows:

When multiple doors receiving conflicting orders from a single agent are merged, these associations are set to a single "toggle" command.

If the merged door is subsequently divided, each sub-door still receives that toggle command. (I don't believe any change is logic is required to provide this outcome, but please correct me if I'm wrong.)

This clears up the ambiguity in the current behavior and paves the way for implementing new scripting for 5.2, which it looks like we may soon be ready to start working on, as skell has been excellent at squashing bugs with prejudice.

____________________________
Gandalf? Yes... That's what they used to call me.
Gandalf the Grey. That was my name.
I am Gandalf the White.
And I come back to you now at the turn of the tide.

---

[Last edited by mrimer at 10-17-2020 03:32 PM]

TFMurphy
Level: Smitemaster
Rank Points: 3118
Registered: 06-11-2007
IP: Logged

mrimer wrote:
Given this, I'd like to move forward with the decision that for 5.1.1, we'll modify the current logic to be as follows:

When multiple doors receiving conflicting orders from a single agent are merged, these associations are set to a single "toggle" command.

Just as a point of clarification, this isn't quite the full change, since it misses the desired result for Case 2: multiple doors receiving multiple non-conflicting orders from a single agent. So the necessary logic change would probably be described as such:

When multiple doors receiving multiple orders from a single agent are merged, these associations are reduced to a single command. If the merged orders conflict, then the remaining association will become a "toggle".


There's nothing in the proposal that dictates which exact connection should remain, but I can't think of any other process that cares what order or to what precise square in a door the connections were made, other than the possible alternative merges and the current TCB (non-)method. So might just be best to go with whatever's easiest to program in that case. EDIT: On second thought, it's probably best to try and preserve one of the connections and edit that one rather than delete all the merged connections and create a new one, just for safety's sake. Preserving and editing data was probably the easiest way anyways, but thought it bears clarifying.

(If one does present itself, then it may be worth thinking about how to make whatever emergent behaviour we discover to be position/order independent... but I'm fairly sure most order shenanigans with doors are due to 'turn order' and 'orb hit order' rather than 'connection position/order', and that's obviously not going to change.)

---

[Last edited by TFMurphy at 10-17-2020 04:24 PM]

skell
Level: Legendary Smitemaster

Rank Points: 3775
Registered: 12-28-2004
IP: Logged

Since this will be a bit more complex than most building, let me write down the process of how it will work, both for my benefit to write down my thoughts and for your benefit so you can point out any problems

1. Building doors:

 * Do the building as normal (be it one tile or a whole rectangle)
 * After that, check every door in the affected area: 
   a) Get all door tiles
   b) Inspect every orb/PP connection, and consolidate multiple links to the same orb/PP into the first link. Different actions are converted to one toggle.

2. Removing doors:

 * Each time a yellow door is attempted to remove
   a) Store door's connections
   b) Replace the door tile
   c) (if no connections were found at #A then skip the rest) Check orthogonally adjacent tiles for being doors
   d) For each orthogonally adjacent door, replace its connections with the ones retrieved at #A

____________________________
My website

mrimer
Level: Legendary Smitemaster

Rank Points: 5195
Registered: 02-04-2003
IP: Logged

Thanks, TFMurphy. Agreed.

Skell, #1 sounds right.
For #2, if I'm understanding correctly, the code already functions this way so nothing need be changed. If my understanding is incorrect, then what you describe sounds right.

____________________________
Gandalf? Yes... That's what they used to call me.
Gandalf the Grey. That was my name.
I am Gandalf the White.
And I come back to you now at the turn of the tide.

skell
Level: Legendary Smitemaster

Rank Points: 3775
Registered: 12-28-2004
IP: Logged

I am so not ready to implement this but let's try!

____________________________
My website

mrimer
Level: Legendary Smitemaster

Rank Points: 5195
Registered: 02-04-2003
IP: Logged

skell wrote:
I am so not ready to implement this but let's try!

I'll swap you for this one if you'd like.

____________________________
Gandalf? Yes... That's what they used to call me.
Gandalf the Grey. That was my name.
I am Gandalf the White.
And I come back to you now at the turn of the tide.