Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[BlazingDav]

One thing that interested me is the quantifying of traps force components. (I remember a thread discussing something like this in the form of ticks or something, honestly don't remember though)

With moving walls and the like, theoretically it should be quite possible to squish all your enemies with ease, naturally this would easily be deemed an exploit. Though like atom-smashers solvable via coding, though personally I don't like that approach, feels a bit harsh, though quite understandable.

Saw on the previous previous page (I read all of this today sort of) someone else also wanting to quantify all this into speed and force (sorry don't read names so much, read posts pretty much), to avoid getting too indepth into gearing (for the sake of sanity and CPU maybe) maybe power sources would just produce so many energy units per step(s).

Naturally this whole thread revolves around mechanics and traps, the sudoku defense of DF if you will, I wouldn't mind a more in depth system that was harder to get to grips with, if you aren't willing to learn it you would probably enjoy the military approach more anyway.

We have power sources -> transfer -> result

We got batteries suggested of gravitational energy and coils seem to be agreed on for the most part, I'd like to suggest thermal batteries on that note (magma/stones kept in fire or magma) I know steam isn't entirely approved, but steam itself ought to be a viable trap (scolding your enemies with large quantities of steam I mean). Though in the event steam power is added being able to throw in a large piles of scolding stones into a cistern for a quick power fix would be neat.

On that note being able to build a cistern that occupies one tile and can be given special properties and workings by a mechanic would be quite handy I imagine.

Also a 'lock' mechanism, so that once a pressure plate is triggered it toggles its target and keeps it like that until it is unlocked by a trigger or a mechanic coming along to untrigger it. Naturally this means in sieges that if enemies brought a mechanic with them they should be allowed to sabotage your traps and disable them and merrily proceed along their way (I know this is more siege stuff, but just saying)

I've suggested this before, but I like the idea an alternate means of transfering power, such as displacment of water (applying pressure on a tube at one end and getting a slightly lower amount out the other), if gearing systems allowing power to push, pull and rotate facing horizontals or verticals were available it'd be quite handy and interesting and kinder on wood stockpiles =P

I would suggest the focusing of light using the archimedes mirror business to focus beams of light across long distances then creating mechanical energy via a simple steam engine, or creating currents of air and powering underground windmills, but I have to admit it would probably require greater manipulation of glass than dwarven glassmakers could do (I know they have greater skill with such things, but would this apply to glassmaking?)

Actually I'll use this to say my piece on the steam power now (I know it finished about 2 to 3 pages ago, but I do find this debate interesting considering how dwarven society could or should develop, given their different mental capacities and living style, then there is possible implementation of magic later which I'd expect to hold some development back in areas such as these, though admittedly if its an init option to turn on or off debate could be brought up), we don't have to have steam engines to have power, we could just use a heat source to boil water creating steam that rises, then putting it through a turbine.

In enclosed underground spaces dwarves could probably notice that escaping steam could push things and then maybe fashion turbines to convert it into mechanical energy, naturally the steam would need to be able to disperse in some fashion to make this possible and effective, so vents to the surface (encouraging possible danger) would have to be implemented. Which actually is how it is done now in power plants I think, they just stick large magnets on the turbine and such for electromagnetic induction, (with coal and such). Quite possible for an Einstein dwarf to come up with that lived in enclosed spaces where air flow is an important consideration (ironically nuclear power plants also use something like this if I recall correctly).

Even if we don't use turbines as a power source, using them for goblin salami or fans would be fun. Which would be a fun example of a input and output, most mechanics should be able to work in reverse if they are powered instead of powering something else (artifical water currents anybody?). Technically you could go steam punk with this and create clock-work golems and such spewing steam etc. though we could easily argue that magic would have an easier time creating golems and so put such stuff out of business, but dwarves probably wouldn't even need them, or find them useful especially in cramped caves where lots of steam everywhere would be quite unpleasant to live with (though depending on how magic finally works out in the end)

Though on that note I'd say that civs should probably be able to be assigned technologies that are natural to them since the start (so maybe some have steam turbines like dwarves and others don't), though during gen and such they can nick technologies off of each other (Imagine humans that could work adamantium), then you could get genius civs with stranger techs like the primitive gunpowders. Generally I find it amazing how all this stuff can cross over at times.

I like the umkh-ing of pressure plates, maybe doing it to all such traps in general? Applying some lump sum saving on the mechanism costs like you get with horizontal axles and logs? Good ideas if you ask me for reducing work on what can be quite a frustrating business (not challenging, but just alot of work), maybe even the option to link all manner of traps together and create a 'trap corridor' where all traps simply are joined together and can be triggered in one fell swoop, which can have its good and bad points whilst each individual tile still abides by its individual build requirements, actually like a room assignment or something I guess.

[The Architect]

~Let's exaggerate the difficulties~

We've had technical discussions ad nauseum, and the truth is that the mechanical difficulty of precise delays is quite minimum. I don't feel the need to go into further detail, but consider these possible elements (which could simply be assumed, not directly implemented).

Fluid pressure mechanics.
On-site potential energy storage.
Counterweights maximizing conservation of power and minimizing necessary dwarven input (In other words, near-instant results over just about any distance).

In fact the only practical difficulties which distance would be likely to present to an engineer are:
1) the need for a potentially complex system of distributing potential energy from counterweights to assure continued repetitive function without the need for frequent power input (you could supply said input with an automated system using a waterwheel and water pressure if a self-reliant system were necessary).
2) installing such a pile of mechanical mess and lubricating it
3) material wear; chains would increase inertia so ropes would be better over long-distance, but would need to have short lengths and would be subject to damage. gear wear as well, of course.

Basically you need 4 days in a room with a slide-rule, a slate/light-colored-stone/paper and chalk/pencil, then weeks or months of labor depending on manpower and availability of materials.

[Starver]

~Let's exaggerate the difficulties~

Just to say that I don't recognise that summary as summarising what I was trying to say.  I'm not always the best at concise communication, so it's not an unknown phenomenon.

I was just really responding that, while player-adjusted timing delay (within a mechanism-pair transmission) is a possibility, I tend to think of a mechanism as an atomic unit[1], and a mechanism pair having a rigidly fixed interaction capability.  (With the possibility that different materials and quality levels could effect the intrinsic reaction times, inclusive of the nature of the originating lever/pressure-plate/whatever, but that's beyond the scope of player-influence on the speed of reaction, apart from pick'n'choosing the ones you want from your mixed stockpile.)

As such, my philosophy tends towards additional/adjustable delays being engineered through combination of mechanisms and related mechanics.  i.e. mechanism-actuated changes to the world (e.g. water levels through floodgates) and change-detecting mechanisms (e.g. of water levels, via pressure/depth detection), with other mechanics where applicable (e.g. other floodgates adjusting the nature of the reservoir area to fine tune matters).  Which can be done right now, in that basic form, though things like rotation-sensing 'switches' and the like could give a neater solution that wouldn't go beyond my philosophy (though maybe beyond the creator's wished DF-era tech level).

The whole thing of changing the mechanics to act at a distance with an additional delay-per-distance factor, as is currently not the case, was an offshoot of that.  And of course would be rather world-changing[2], but was not intended to be a difficulty exagerator (either in playing or coding, and besides the coding should be trivial and playing styles adjustable to the new norm).  But it was just an 'out there' idea, and not an actual wishlist proposal/seconding from myself, merely a reaction to the post to which I was replying.


[1] Indivisible and unadjustable, rather than something radioactive...

[2] For a start, hydraulic computing designs that currently work well with either local or dispersed 'computational elements' may act sufficiently differently.  And if the distance delay is significant then the "lever control room" idea might need refining into a multiple-nexus philosophy to prevent the fatal delays that the dislocation of lever from defensive barriers (to guarantee the availability of unalarmed dwarfpower) is currently implemented to prevent, for many players.  Personally, I like to put the levers somewhere close by (i.e. in a tunnel pointing towards the drawbridge's actual location), if only for easy management, and accept the unpredictability of available labour as a consequence, but I don't begrudge the centralisation idea for others.  And you could still do what you want with a delayed-action-at-a-distance, if you account for its effects.  Especially if you cut down on the intrinsic distance-irrelevent delay constant.

[The Architect]

The purpose of the proposal for player-set delays is to give us finer and more realistic control over mechanisms, not to complicate or further randomize the effects. As an engineering student I can tell you that what you've proposed (making the effects and time some sort of sum of its components) is not realistic on any level of actual engineering consideration.

I think that an actual player interface to install all of these things would be unnecessary and difficult to program. We can easily make the same assumption as now: the engineer takes care of all of the particulars about connecting switches and events. Nothing is really added by programming all of the details except a headache for the players and a steep handicap with those not familiar with the principles at work. At the most you might require a skilled, intelligent engineer to do certain things. Attributes are updated in the next version to include intelligence among others.

"liquid computing" is slow and ineffective. It's just a way of having fun with what we have at the moment. At most it stands as a benchmark of what this community might do given more utility.

[Starver]

I must admit I'm lost.  "Intrinsic to the universe" delays are only complex without understanding (same as with RL itself), and certainly don't randomise except through shear uncertainty about the nature of things.  A higher quality of mechanism (or better material for the job) reacting quicker (within the 'black box' of the mechanism's innards, however they be so configured) to manual input or connected-mechanism prompting is more or less how real-world devices work (though the variance may not be so noticable, compared with the liklihood of just breaking when inferior/insufficiently strong materials are used).

And exploiting that involves no player interface at all (beyond the ever-required placement), unlike defining a player-mandated delay upon construction (or reconfiguration?[1]) that's what we already do when assigning the job queue in advance the Dwarf engineer wandering along to do the job.

I agree that liquid computing is slow an ineffective.  But it's a constraint that the (current) DF world gives us, without rotation-detection linkages.  (Of course, there's related methods invoving the passage of dwarfs, pets and even hostiles through labyrinthine tunnels, and in my experience they're even more awkward to deal with.   Player-defined delays only marginally help (reducing the need to design certain types of repeaters/delay loops) and don't help with creating logic gates and the like.  Delay-by-distance needn't (if you don't go silly with decentralisation and fragmentation of your mechanics and mechanically-changed landscape feature) cause any problems either.

I can't help thinking the above looks more argumentative than I mean it to be.  Summarising, I just can't match your apparrent objections to the alternative method, and I'm probably spending more effort trying to explain my confusion than is merited.  All power to your suggestion, etc, and I wouldn't be upset if that was implemented, even though it doesn't chine with my own views.  There's really only one authority on which way (if either) is correct, and that's The Creator.  I'm sure that my frank response hasn't ruined your chance to petition.


[1] If player-defined delays are implemented, then the ability to add "adjust delay" jobs would be logical as well as possibly ones to adjust the particularly responsivenesses of pressure-plates.  Unless you're forced to deconstruct/reconstruct like you currently do.

[BlazingDav]

What about an alternate approach to setting a delay that doesn't require in depth understanding yet has some complexity to it?

Like allow the mechanics workshop to create a delay box.

This would be a simple series of mechanisms that when triggered wind up and then cause the desired action to occur after the delay.

The delay of the delay box would be specified on the making of the delay box and be inscripted in its name (to avoid building hassle).

To build a delay box with a more precise delay you would need a more skilled mechanic. Or better materials to work with. I won't say what it would require to make, but I figure mechanisms is a good start and maybe smithed metal springs or something (I guess those will end up in the game at some stage). Naturally if you dont have sufficient skill or quality in your resources the job cancels.

My reasoning for just needing mechanisms and say a legendary mechanic, is that the mechanic could easily chip the mechanisms into a better state, probably many levels of quality as the job is done, it would just take longer. The same being true for artifact mechanisms and a complete novice, the standard is there, the novice will just spend more time experimenting to get it right.

Also by a more precise delay I mean going down from 100s to 50s to 25s to 10s to 5s to 1s of steps. One problem I find though with steps is that what it means in seconds for us distorts immeadiately when your FPS shifts.

Also maybe in the rigging of these delay boxes requiring one or more mechanisms to link them into the system would make sense I guess.

You could even allow the design to be a building so that every number of steps it transfers power long enough to get one item or work done (e.g. a pump pumping one tile of liquid). Admittedly it would be the basis for a constructable repeater that way, but then it would be simpler to enable it to send a toggle signal after a certain delay when powered.

Though in a repeater capacity you would almost have to designate a minimum charge up time, just so we dont have spikes alternating from in and out every step

[The Architect]

Spoiler (click to show/hide)

What about an alternate approach to setting a delay that doesn't require in depth understanding yet has some complexity to it?

Like allow the mechanics workshop to create a delay box.

This would be a simple series of mechanisms that when triggered wind up and then cause the desired action to occur after the delay.

The delay of the delay box would be specified on the making of the delay box and be inscripted in its name (to avoid building hassle).

To build a delay box with a more precise delay you would need a more skilled mechanic. Or better materials to work with. I won't say what it would require to make, but I figure mechanisms is a good start and maybe smithed metal springs or something (I guess those will end up in the game at some stage). Naturally if you dont have sufficient skill or quality in your resources the job cancels.

My reasoning for just needing mechanisms and say a legendary mechanic, is that the mechanic could easily chip the mechanisms into a better state, probably many levels of quality as the job is done, it would just take longer. The same being true for artifact mechanisms and a complete novice, the standard is there, the novice will just spend more time experimenting to get it right.

Also by a more precise delay I mean going down from 100s to 50s to 25s to 10s to 5s to 1s of steps. One problem I find though with steps is that what it means in seconds for us distorts immeadiately when your FPS shifts.

Also maybe in the rigging of these delay boxes requiring one or more mechanisms to link them into the system would make sense I guess.

You could even allow the design to be a building so that every number of steps it transfers power long enough to get one item or work done (e.g. a pump pumping one tile of liquid). Admittedly it would be the basis for a constructable repeater that way, but then it would be simpler to enable it to send a toggle signal after a certain delay when powered.

Though in a repeater capacity you would almost have to designate a minimum charge up time, just so we dont have spikes alternating from in and out every step
[/quote]

What about an alternate approach to setting a delay that doesn't require in depth understanding yet has some complexity to it?

Like allow the mechanics workshop to create a delay box.

This would be a simple series of mechanisms that when triggered wind up and then cause the desired action to occur after the delay.

The delay of the delay box would be specified on the making of the delay box and be inscripted in its name (to avoid building hassle).

To build a delay box with a more precise delay you would need a more skilled mechanic. Or better materials to work with. I won't say what it would require to make, but I figure mechanisms is a good start and maybe smithed metal springs or something (I guess those will end up in the game at some stage). Naturally if you dont have sufficient skill or quality in your resources the job cancels.

My reasoning for just needing mechanisms and say a legendary mechanic, is that the mechanic could easily chip the mechanisms into a better state, probably many levels of quality as the job is done, it would just take longer. The same being true for artifact mechanisms and a complete novice, the standard is there, the novice will just spend more time experimenting to get it right.

Also by a more precise delay I mean going down from 100s to 50s to 25s to 10s to 5s to 1s of steps. One problem I find though with steps is that what it means in seconds for us distorts immeadiately when your FPS shifts.

Also maybe in the rigging of these delay boxes requiring one or more mechanisms to link them into the system would make sense I guess.

You could even allow the design to be a building so that every number of steps it transfers power long enough to get one item or work done (e.g. a pump pumping one tile of liquid). Admittedly it would be the basis for a constructable repeater that way, but then it would be simpler to enable it to send a toggle signal after a certain delay when powered.

Though in a repeater capacity you would almost have to designate a minimum charge up time, just so we dont have spikes alternating from in and out every step

First: I think Starver has missed the whole point, so I'm just going to ignore his comments. Sorry man.

BlazingDav: a gearbox such as you suggest is technology that was only well-known at the time of the Industrial Revolution (admittedly we have examples of human intelligence utilizing such technology for centuries, but only in ***extremely*** rare finds, such as some of the muskets owned by royalty in the medieval period). An actual mechanical delay is much more realistic, practical, and useful. To rephrase: it is what they actually had, and it worked better than a gearbox would. That said, in the sense of game balance and easy player understanding, your idea makes sense. The idea of player set delays is just what you've described. I don't see how in hell or heaven it can be objectionable. If you don't want realistic mechanics, just use the default delay! (100 frames)

As far as the quality of the mechanisms affecting what can be done: that is quite true in an advanced machine, such as a combustion engine. But we're talking about technology that is old as dirt, counterweights and cranks. You don't need skill or precise craftsmanship to do it. Only intelligence. That said, don't dwarves have all of those traits anyway?

[BlazingDav]

I'd almost relate the delay box thing to a bit like a clock, but I'll admit that I don't know when those would have been around to begin with. While advanced I'd admit (and opening doors to certain other themes) it would be a little more dwarvenly, though if it doesn't get in like this then some sort of repeating mechanism would be quite nice =P

Though technically for a delay trigger system if you simply added a paddle to the side of a mechanism, with proper gearing when a power source is connected to the system after so much time depending on said gearing (sorry I don't know any terms and by gearing I mean varying angular speed of gears etc. you know) the gear with the paddle eventually completes one rotation and the paddle essentially knocks a 'switch' toggling whatever it was supposed to trigger.

A system like that while not impossible for dwarves (I can imagine dwarves are supposed to be able to solve most mechanical that rise before them) would for realism's sake demand the trigger system be powered, not a problem at all, though when there are fluids to be concerned about in what would be future attempts of the forum engineers, when lava control and flood prevention is a desired goal, Fun would be had is power had to be provided to the final product end of the trigger.

So having it on the first half would make more sense, though quite possibly an inconvenience depending on how ambitious the design is. Though admittedly a half way point 'node' that is an intermediary point between the two implying a physical connection between the two points that can't be seen, would have its good points, one being that you could put it out the way and power the system apparently, could even use these as a way to imply you are transferring power across the mountain without having to dig half of it up. Could even allow such nodes to house more than one system. While potentially making things too easy it would reduce the hassle I guess once you're fairly seasoned with the stuff we do have.

One thing that would be said for quality is that it ought to imply the standard consistency of mechanisms, while an artifact mechanism can look nicer, its teeth and overall structure ought to be 100% consistent such that if it were put in a clock, it would keep time incredibly well. Maybe not an atomic clock, but nothing we ought to notice for thousands of years. My point being that while a mechanism might not degrade (I'd leave that more to if it was being overworked with not enough power or undergoing high friction anyway, though admittedly a slight amount of wear and tear would always be true), after continual use it would probably start stacking up an inconsistency, doesn't need to be big, but it would eventually be noticable, a slight imperfection such as a tooth being shaped differently would be enough for that, or even the mechanism not being quite that perfect circle.

On another note for the suggestions, mechanical stairs and floors that can pop out the ground would be fun with the whole moving wall business.

[RAM]

I would like to see a few very simple devices that would allow many different complex devices. At the moment I think that many mechanical operations are performed by water that should be purely mechanical. I suggest that there should be power transfers, power sensors, mechanical triggers(with delays). You could have the delay on a trigger based on the quality of the mechanism. A base quality mechanism has maybe a 200 step delay while an artefact mechanism has a 0 delay but high-quality mechanisms can mimic low quality mechanisms if they choose... For roleplaying purposes you could say that you are deliberately reducing the power(and therefore final speed) of the machine because the low quality components can't handle it. I would also require that the dwarf powered generator be separate from the screw pump, so that you can set up a slave-wheel or treadmill or pedals or chain-on-a-wheel or whatever and run power into a system for screw pumps or gates or whatever else without needing to put your dwarves in the lava or in the siege or in the refuse conveyor or whatever. Assuming that power transfer remains a part of the game...

[The Architect]

A wheel with gears and a paddle is indeed a well-known component of old windmills and watermills, and is thus very compatible with the technology of the era. I agree that repeating things need a power source, in particular spikes (and giant axe blades, which I think should be constructed like spikes and require an adjacent wall).

[BlazingDav]

One thing I just thought about is the compression of previous things forum mechanics currently do and maybe their efforts should be rewarded =/

I know it'd be strange to suggest unlockables and achievements for dwarf fortress, but unlocking new buildings that make your life simpler after you've proved to the game you know how it works and what you're doing seems strangely nice to me.

Like that repeater, once you've built a repeater and got it to work, being able to unlock a mechanical repeater building would be nice. Also the game recognising such structures how they work and what they are for would be a nice help in future versions where forts are supposed to be more impressive.

Then you'd have the way of creating a delay, namely fluid mechanics and floodgates, after doing that being able to naturally create a delay without all the work and lack of mental challenge (being more repetitive than challenging) would be strangely nice.

Upside of this? Every version as people on the forum do new and crazy things with the comforts in life they are given for their efforts. They then do new things, which are documented and transformed into smaller and convenient mechanical devices. Would be an interesting curve and testament to dwarven mechanics =P

Naturally you ought to be allowed to unlock such things manually for your use in fort mode immeadiately in the init menu so you don't have to unlock them all again every version XP

Sort of a mechanical suggestion, yet not, though it feels like it would be very interesting to see what would happen if it were implemented.

Admittedly I considering that logic gates have already been done I think (at least I've seen enough dwarf-puters to assume that) with this them being added with repeaters and such would help add fun to mechanics

[RAM]

Spore pretty much killed any desire I could ever have had to see any sort of unlockable in anything.

[Morrigi]

Same here. And this is DWARF FORTRESS. I think we should have said making-life-easier buildings in the beginning

[BlazingDav]

I know, just seemed an interesting way to document achievements of the community XP

Though who is to say you just unlock them straight away from the init control bit i suggested =P

Though really I would only be in favour of 'making life easier' stuff that doesnt quite fit in the tech or theme requirement of DF being put in if there was stuff the community wanted to achieve (In the realms of dwarven engineering), but to do what they want required a ridiculous amount of time. (though i guess what I suggested would be better described is a tech tree where you are doing the inventing)

Though otherwise I might have just about managed to kill off any respect i might have had before =P

[NW_Kohaku]

UGH! So many good ideas in this thread...  It's impossible to really read them all and comment on every one, but I was thinking about things I would like, and went searching for a thread like this to add them to.

While it's been said before on numerous occasions, here, I would like to mention conveyer belts again.  I've been thinking about the way that they might be implimented, and I think I have a good idea regarding that (apologies in advance if a repeat):

Conveyor belts can be run alongside (or possibly through) workshops, and set to dump or haul items automatically. 

Workshops, as they stand now, essentially rely upon a "dump" method of item sorting.  As far as I can tell, workers gather "input" materials, and dump them on the floor.  When they craft a new item, they dump the "output" on the floor, and go looking for a new input material for their next job, leaving it to the haulers to clean up after them. 

What if, instead, "inputs" were assigned to a single tile in the workshop, and there might be multiple "output" tiles.  Conveyors could run next to or through the "input" tiles, and if something that the production orders of that workshop would require, and was not already present in sufficient quantities for that workshop ran past the workshop, the workshop (if manned, if we want to be really realistic about it) would automatically pull that material off the belt, and into the input bin.  Outputs, meanwhile, if they were sorted into different categories (I'm thinking a slaughterhouse, for example, would want two seperate output lines, one for the meat and fat, the other for the chunks and bones) would have seperate tiles, so that seperate conveyors could carry off their products, either cycling past workshops (potentially forever), or just dumping them into a warehouse (potentially controlled by a switch that might go to a swinging gate, or just a single conveyor stretch that might be reversable. 

All this should also include some vertical "bucket" conveyors (dumwaiters / elevators), as well.  Such conveyors should probably just dump things at the top (potentially to other conveyors), since if we wanted things dropping down, you just need to convey them into a pit.


------


Other ideas for mechanical power-requiring workshops:

High-temperature furnace: The high-temp furnace would be capable of firing reactions normally out of reach of normal dwarven technology.  This idea is based upon the actual ancient chinese use of technology like this, so it should be well within the "flavor" of dwarven tech.  This furnace, instead of using the irregular billows, can use a screw fan to supply a constant flow of a larger amount of oxygen than a normal forge does, allowing for a hotter fire.  (As it stands, magma smelting is probably plenty hot, but we can just look the other way, and agree that a mechanically more complex system should drive greater benefits.)  This allows for burning more fuel more quickly, and burning a hotter fire. 

(This means that it would require rotational power, as well as a giant screw and probably a tube, just basically being an "air pump")

I was going to detail a "porcelain" craft, but you know what, I'm going to make this a seperate suggestion since it gets very long and detailed about how to make an entirely new kind of commodity.



Powered Looms: Real-life, when mechanization took off, mechanizing the textile industry was one of the easiest things to do... 

In any event, at its most basic, looms can be mechanically powered, so as to help make them, at the very least, work faster.  It would actually be best if it were combined with a seperate idea, however, to try to make dyes a little more versitile. 

Powered looms could, perhaps, be able to take in thread with multiple dying colors, and use them at the same time to make cloth that is multiple colors, or rather, patterned.  In much the same way that a reaction that takes in four ores would produce four metal bars, two threads used at the same time would produce two cloth units, both with the doubled dye pattern. 

This would also be able to potentially lend assistance to the poor, much maligned Hide Root, as every additional dye color improves the value of your clothing, even if they are not the most valuable dyes. 

-----

While I wanted to put a few more examples on this list, I have actually been so distracted by forum crawling while leaving this post open that I've actually kept it up for several hours, and I think that it's plenty long for today.    When I remember what the other ideas I had were, I'll post again.