Config option to not need structures

[CmdrDats]

Only need signs for setting up memory stones

[ryantheleach]

What makes this different then sign warps then? but yeah I mean it seems simple enough to add, and I'm guessing someone requested it...

The main issues I see, is how do you differentiate between types of stones just using signs? there would need to be some sort of tagging system and if we do that we may as well do custom per stone pricing as well on the signs, this draws it away from the simplicity i love about memory stones however so should be completely optional when making a sign, Needs careful consideration on how to implement it with the current code also.

[CmdrDats]

Hmm, good point about the sign types - Yes, it is requested because they want to be able to attach it to any arbitrary structure (to make each unique). I agree, it should be optional and off by default though since it's a little off what this plugin was meant to be :)

It's a bit of a tough cookie to implement though because structures are so ingrained in the project. Will be a good refactoring exercise though.

I rate we could add a sign tagline in the structuretypes.yml, so you can setup what each stone would be.. ie:

structuretypes:
 - name: Memory Stone
   sign: [MemoryStone]
 - name: Global Stone
   sign: [GlobalStone]
 - name: Crossworld Stone
   sign: [Crossworld]

and if the sign: is found on the first line, it'll setup a memory stone as if there was a valid structure behind it (if enabled)

[ryantheleach]

The way we have worked around that on our test server www.taamc.com its currently going thru a re-factor into a PvP + build server for when MC release comes out, reset the website and everything, we just used a "core" of bedrock obsidian obsidian and glowstone, the bedrock is never visible, and we just make ornamental additions around that.

[ryantheleach]

But a good way to handle this is to have a memorystone that extends memorystone to be a structure-less stone, when this stone needs to fetch config stuff it refers to the structure files according to type of stone, then you could use the sign as:
[type]
[name]

Does this seem a good method? Note I think you are a better java programmer then me, so you may see flaws that I don't.

[CmdrDats]

Ye, that would be a good way, but the code will need to be refactored so that the MemoryStoneManager asks the MemoryStone itself to check whether the stone is valid, instead of using the StructureManager so closely.

What I'd like is for only the MemoryStone class to use the StructureManager directly and nothing else. What I think that will imply is a bit of an overhaul of how saving and loading currently works - it currently relies on the structuremanager saving, where I think each memory stone should just be able to save itself, each stone in its own file instead of having one file for all stones. This should also speed up loading and saving changes to stones..

On Thursday 20 October 2011 at 9:27 AM, Ryan Leach wrote:

But a good way to handle this is to have a memorystone that extends memorystone to be a structure-less stone, when this stone needs to fetch config stuff it refers to the structure files according to type of stone, then you could use the sign as:
[type]
[name]

Does this seem a good method? Note I think you are a better java programmer then me, so you may see flaws that I don't.

Reply to this email directly or view it on GitHub:
#13 (comment)

[ryantheleach]

I notice your addicted to public methods, are they public for a reason or should they only be available to this package?