Requirements needed!

Post your mods and custom content here

Re: Requirements needed!

Postby ericb1800 » Mon Aug 12, 2013 11:34 am

The only issues I had when putting the blueprint in the action as a move step instead of pick(since pick destroys the blueprint) is you can only have 1 Townie use the blueprint at a time and a blueprint can not be used from inside a container... Otherwise it worked flawlessly...
ericb1800
 
Posts: 815
Joined: Sun Nov 25, 2012 7:17 pm

Re: Requirements needed!

Postby Haggy » Mon Aug 12, 2013 4:37 pm

First I thought of "move-replace".
Thus, the existing with the same object is created.
But the "move" command is sufficient for this.
And yes, it can always use just one the blueprint. But after he has looked on it, can you solve the lock and the next one can use it.
And, if necessary, leads to a copy of the blueprint. However, what an original is required.
Thus one can introduce the ITE caravan without major problems. Because this is not essential for progress. My next step is but first again on paper.
My English is bad. Sorry, but this will not Change.

Schreib einfach in deutsch zurück ;)

Haggys Mod Comp.
User avatar
Haggy
 
Posts: 528
Joined: Sun Apr 21, 2013 3:34 am

Re: Requirements needed!

Postby Niranufoti » Mon Aug 12, 2013 6:10 pm

I'd suggest really using an upgrade system once v14 comes out: You upgrade your itesmithy to an itesmithy2 using a simple blueprint, then to an itesmithy3 using a more advenced one etc. And in order to make stuff, you first need to upgrade the Crafting stations.
Also, you could make an "Advanced Smithing Station" with the various ITEs, Gold and Silver and the blueprints, which is then used by the really end-game recipes(like Gold and Silver stuff) the same way that more advanced wooden things use the Wood Detailer.
Niranufoti
 
Posts: 551
Joined: Sun Apr 28, 2013 3:20 pm

Re: Requirements needed!

Postby YetiChow » Wed Aug 14, 2013 4:59 am

ericb1800 wrote:The only issues I had when putting the blueprint in the action as a move step instead of pick(since pick destroys the blueprint) is you can only have 1 Townie use the blueprint at a time and a blueprint can not be used from inside a container... Otherwise it worked flawlessly...


You can use <pick> and then <drop> to have the townies pick up and, well... drop the blueprint, unless you want it to be a "blueprint table" or something like that. The advantage is that you can have the blueprints be stored to save space, but really there's no huge difference in which way you do it.

If you want to get really sneaky and you're "upgrading" the util rather than making a separate one, you can use a bit of voodoo which Smithforge came up with: <pick> the blueprint and </destroy> it, then have the regular <pick> and </destroy> actions for collecting the materials for the upgrade. Use <replaceCellItem> to change the util into the upgraded one, and then <createItem> to get the blueprints "back" now that the townie is finished with them. It's not really an improvement, but it looks cool (and you can change the order of the <pick>, <move> and </destroy> tasks to ahve <move in between picking up and destroying, so that the townies "carry" the materials over to the workbench as it's being upgraded :)).
What's that you're eating? A nice, juicy apple? You weren't supposed to eat that you fool, you were supposed to make it into a pie! - last words recorded words of Francis D'Avre before he went looking for snowcherries, but found a hungry Yeti instead.
User avatar
YetiChow
 
Posts: 3149
Joined: Wed Apr 25, 2012 9:26 am
Location: Cramped between a Yeti's small intestine and its stomach... trying not to dissolve!

Re: Requirements needed!

Postby ericb1800 » Wed Aug 14, 2013 10:34 pm

YetiChow wrote:
ericb1800 wrote:The only issues I had when putting the blueprint in the action as a move step instead of pick(since pick destroys the blueprint) is you can only have 1 Townie use the blueprint at a time and a blueprint can not be used from inside a container... Otherwise it worked flawlessly...


You can use <pick> and then <drop> to have the townies pick up and, well... drop the blueprint, unless you want it to be a "blueprint table" or something like that. The advantage is that you can have the blueprints be stored to save space, but really there's no huge difference in which way you do it.

If you want to get really sneaky and you're "upgrading" the util rather than making a separate one, you can use a bit of voodoo which Smithforge came up with: <pick> the blueprint and </destroy> it, then have the regular <pick> and </destroy> actions for collecting the materials for the upgrade. Use <replaceCellItem> to change the util into the upgraded one, and then <createItem> to get the blueprints "back" now that the townie is finished with them. It's not really an improvement, but it looks cool (and you can change the order of the <pick>, <move> and </destroy> tasks to ahve <move in between picking up and destroying, so that the townies "carry" the materials over to the workbench as it's being upgraded :)).



I did not know <drop> worked...


EDIT:
After testing this out I get the same error for all of the variations...[Error reading queue [Unknown type [drop]]]
<drop />
<dropItem />
<drop></drop>
ericb1800
 
Posts: 815
Joined: Sun Nov 25, 2012 7:17 pm

Re: Requirements needed!

Postby YetiChow » Thu Aug 15, 2013 4:48 am

ericb1800 wrote:
YetiChow wrote:
ericb1800 wrote:The only issues I had when putting the blueprint in the action as a move step instead of pick(since pick destroys the blueprint) is you can only have 1 Townie use the blueprint at a time and a blueprint can not be used from inside a container... Otherwise it worked flawlessly...


You can use <pick> and then <drop> to have the townies pick up and, well... drop the blueprint, unless you want it to be a "blueprint table" or something like that. The advantage is that you can have the blueprints be stored to save space, but really there's no huge difference in which way you do it.

If you want to get really sneaky and you're "upgrading" the util rather than making a separate one, you can use a bit of voodoo which Smithforge came up with: <pick> the blueprint and </destroy> it, then have the regular <pick> and </destroy> actions for collecting the materials for the upgrade. Use <replaceCellItem> to change the util into the upgraded one, and then <createItem> to get the blueprints "back" now that the townie is finished with them. It's not really an improvement, but it looks cool (and you can change the order of the <pick>, <move> and </destroy> tasks to ahve <move in between picking up and destroying, so that the townies "carry" the materials over to the workbench as it's being upgraded :)).



I did not know <drop> worked...


EDIT:
After testing this out I get the same error for all of the variations...[Error reading queue [Unknown type [drop]]]
<drop />
<dropItem />
<drop></drop>


I really should start checking that I'm typing out tags correctly... :roll: :lol: It's actually </drop>

for future reference, any of the tags which reference existing arguments (I think I said that right... anything where you're using an existing variable at least - I don't really know coding or how this works, don't judge me :lol: ) use the format </tagword> - </destroy>, </drop> and </unlock> are the only ones I can think of at the moment, and each of them references a "held" or "claimed" item... the forwardslash is probably operative (like recalling the held string or something), but it's quite possibly just a quirk of Xavi's formatting style...

However it works, that's the basic rule when it comes to doing things which the townies are already using. It was one of the things which took me ages to make sense of, but it opens up a whole new world of voodoo when it comes to carried items.

It's amazing how many of these "rules" of Towns' formatting are incredibly simple when you sit down and figure out what they do - as a good general rule, any tag sitting on its own is probably VERY important to the way the action is completed. Try chucking a couple of extra </unlock> tags into long actions for example - it makes the difference between townies starving or surviving in many cases.
What's that you're eating? A nice, juicy apple? You weren't supposed to eat that you fool, you were supposed to make it into a pie! - last words recorded words of Francis D'Avre before he went looking for snowcherries, but found a hungry Yeti instead.
User avatar
YetiChow
 
Posts: 3149
Joined: Wed Apr 25, 2012 9:26 am
Location: Cramped between a Yeti's small intestine and its stomach... trying not to dissolve!

Re: Requirements needed!

Postby JackPS9 » Thu Aug 15, 2013 1:08 pm

I have thought of one way to do the different tiers of equipment, which I am thinking of using to allow the creation of special items in my mod.
It is blueprint based, its just like Anvil (Lv.1-X) where X is the number of tiers you have and you cant make Tier 2 items with a Anvil(Lv.1) then just upgrade the anvil with blueprints.
JackPS9
 
Posts: 1088
Joined: Mon Sep 03, 2012 4:15 pm

Re: Requirements needed!

Postby ericb1800 » Thu Aug 15, 2013 2:17 pm

JackPS9 wrote:I have thought of one way to do the different tiers of equipment, which I am thinking of using to allow the creation of special items in my mod.
It is blueprint based, its just like Anvil (Lv.1-X) where X is the number of tiers you have and you cant make Tier 2 items with a Anvil(Lv.1) then just upgrade the anvil with blueprints.



I have been thinking the same thing with the kitchen table for Food Ext(which is coming along nicely)...

As for the </drop> command... that dont work either...lol
ericb1800
 
Posts: 815
Joined: Sun Nov 25, 2012 7:17 pm

Re: Requirements needed!

Postby YetiChow » Sat Aug 17, 2013 5:11 am

It seems that tag has been deprecated.... sorry about that, I know it used to be part of some actions but I guess that the Devs have found a better system now with <generatedItem> or something...

On the idea of upgrading items: it's probably a better idea to preference the basic util as the first choice in the action for making low-level products - that is, make it the <move>(basic),(next upgrade),(next upgrade etc.),(ultimate)</move>. A lot of times where people have tried this idea, they've put the ultimate version of the util as the first preference for all of the actions; which can lead to townies clogging up your expensive uber-utils with low-level tasks and thus prevent the important new tasks happening. It's especially apparent when you're dealing with a single upgraded util and a heap of yet-to-be-upgraded ones, you'll have a couple of unused basic utils and the high-end task never gets completed.

It's a simple consideration, but one that often gets overlooked and which can prevent a heap of frustation. Sometimes, we do need to be reminded of the obvious when we're working on the cutting edge of 'new technology' :lol:
What's that you're eating? A nice, juicy apple? You weren't supposed to eat that you fool, you were supposed to make it into a pie! - last words recorded words of Francis D'Avre before he went looking for snowcherries, but found a hungry Yeti instead.
User avatar
YetiChow
 
Posts: 3149
Joined: Wed Apr 25, 2012 9:26 am
Location: Cramped between a Yeti's small intestine and its stomach... trying not to dissolve!

Previous

Return to Modding

Who is online

Users browsing this forum: No registered users and 3 guests

cron