|
|
#1 | |
|
User
Join Date: Aug 2008
Posts: 14
|
NOTE: You have been redirected in order for our attachments to be made available to you. This will only last two minutes; these measures where taken to avoid hotlinking and bandwidth theft. To avoid these restrictions Log in or Register Yes, it's true. Yet another one.
RecipeSYS v0.6d RecipeSYS is a system that allows you to have recipes that combine two or more (up to six) items into one item. The code has a rather good documentation on how to use it, and the map also contains an example trigger of usage in GUI. All you need to do is add one line of Jass for each recipe you want, and the system will do the rest. The system can even be used for stacking charged items (not the easiest way of doing that, though, as you would need one line for every item that can stack). Features Requirements A vJass compiler (NewGen includes one). Table by Vexorian. The Code C++:Example of Usage Trigger: T
![]() Conditions
![]() Actions
![]() ![]() Custom script: local recipe re = AddRecipe('rde2', 'rde2', 0, 0, 0, 0, 'belv')
![]() ![]() Custom script: call AddRecipe('rde1', 'rde2', 0, 0, 0, 0, 'belv')
![]() ![]() Custom script: call AddRecipeWithCharges('fgdg', 'fgdg', 0, 0, 0, 0, 'fgdg', 0)
![]() ![]() Set Item = Boots of Quel'Thalas +6 0028 <gen>
![]() ![]() Custom script: call DisassembleItemByRecipe(udg_Item, null, re)
![]() ![]() Custom script: call EnableRecipeByResult('belv', false)
![]() ![]() Wait 10.00 seconds
![]() ![]() Game - Display to (All players) the text: Enabling.
![]() ![]() Custom script: call EnableRecipeByResult('belv', true)
![]() ![]() Wait 10.00 seconds
![]() ![]() Game - Display to (All players) the text: Destroying.
![]() ![]() Custom script: call RemoveRecipeByResult('belv')Importing Copy the trigger called RecipeSYS from the attached map or create a trigger named RecipeSYS, convert it to custom text, and replace everything inside it with the code above. Q&A Q: There are lots of recipe systems already. Why on earth did you make another one?! A: I felt like it. Duh... Q: How is this different from the other systems? ![]() A: Well, I didn't make the other ones (although you might think I did (even though you've never heard of me before)). You could also take a look at the feature list, it might have some differences. Q: The 'Features' list is like exactly the same as the 'Strengths' list in the comments! ![]() A: No shit, Sherlock. Q: Does the system have any weaknesses? ![]() A: Besides the ones mentioned at the end of the comment block, I don't know. You tell me. Q: Can I leave suggestions, questions, and/or comments? A: If they are somehow intelligent. Q: How many recipes can I have at once? A: Up to 1365. Q: I seriously think no more recipe systems are needed. A: Ok. Q: How do I use this system? A: Didn't you look at the code at all? The 4th row with text is 'How To Use RecipeSYS'. Could there be instructions for usage under that title? I doupt. :) Changelog
Last edited by Artificial : 08-30-2008 at 01:49 PM. Reason: Update to v0.6d |
|
|
|
|
| Sponsored Links - Login to hide this ad! |
|
|
|
|
#2 |
|
Free Software Terrorist
Technical Director
|
You could have made it much faster, right now, you need to loop through every single recipe in the game when a unit acquires an item, think about it, with only 6 items in a unit's inventory, there got to be a better way...
__________________ |
|
|
|
|
|
#3 |
|
User
Join Date: Aug 2008
Posts: 14
|
I'm still rather new with Jass (excuses), and I'm having a hard time figuring out how to make it faster, although I know it probably could be done better.
__________________The only thing I can think of would be linking the recipes to the item types, which I don't know how to do. I guess the only way of doing that would be using gamecache. That should be faster, right? Maybe I'll need to learn to use gamecache, then. ![]() |
|
|
|
|
|
#5 |
|
Dread Lord of the Cookies
Content Director
|
gc is pretty fast as a two key hash table. Big arrays are faster, if they'll do what you need.
__________________ |
|
|
|
|
|
#6 |
|
User
Join Date: Aug 2008
Posts: 14
|
> gc is slow
__________________I know it's somehow slow, but I guess it's faster than looping through every single recipe. And I know who you are, don't worry. ^_^ > Big arrays are faster, if they'll do what you need. I thought about arrays, but I can't figure out a way to transform the item's rawcode into a form that could be used as an array pointer. They are like WAY too big and vary too much. ![]() |
|
|
|
|
|
#7 |
|
Corkscrew Chainsaw!!!
|
Why do item systems need to be fast anyway? They aren't being called by periodic timers or anything. Items should be, to quote TC, 'powerful'.
__________________Last edited by Here-b-Trollz : 08-24-2008 at 07:23 PM. |
|
|
|
|
|
#8 |
|
Free Software Terrorist
Technical Director
|
Item systems don't need to be fast but this thing is a recipe system which will trigger everytime you pick up an item, anyway. Artificial: Yes, something like that would be good, another thing would be that in the case of a pickup event you only need to consider the recipes that use the item.
__________________GC is ok for this in terms of speed since it is O(1) instead of O(n) it would be faster, you could make your own hash table, but I think Griffen got a good idea with big arrays, it still though requires a way to convert the item type to an array index. The problem is how to implement this stuff without adding weight to the requirements, making it use its whole gamecache file would be a little too much. Also you'd have to be careful not to make this cause an item type limit. -you could use one of many libraries out there that do hashing- it wouldn't scale well with things like 50 recipes in the whole system, it seems like a big value but there isn't too much reason to use one of these systems if you don't plan having plenty of recipes in your map. -- The optimization would not be a requirement for approval, Something I don't like too much is how it forces the guy to use plain integers for the recipes thus losing some type safety and convenience around, you could actually make recipes creatable as just recipe.create() and what not, you can also make the functions return a recipe and make the recipe struct public and have some read only fields that could be helpful for the guy using your system. Even if you don't add these things, make the functions take and return recipe, it will make life easier when jasshelper gets type safety and that stuff. |
|
|
|
|
|
#9 |
|
For External Use Only
Join Date: Jun 2007
Posts: 672
![]() ![]()
|
indent much?
__________________and what is 'cre8', i dont think i speak your language. Please speak english |
|
|
|
|
|
#11 |
|
User
Join Date: Aug 2008
Posts: 14
|
Ok, I made some improvements. First of all, I made the functions take and return recipes instead of integers, and the recipe struct no longer is private.
__________________Second of all, I made 2 versions of it; one using GC and one a hash table I found (this one). Now I'm wondering if you guys could tell me which one should be better, or if there is a way for me to test their speeds (which I would like to do even though you would be able to say which one is better) and how to do it. Here are the codes in case you wanna see them. Gamecache: Hash table:![]() Last edited by Artificial : 08-27-2008 at 10:49 AM. |
|
|
|
|
|
#12 |
|
Procrastination Incarnate
Development Director
|
I really don't know what you're doing in the GetItemTypeRecipes function. Why work with strings when you could easily have stored integers to GC? Speaking of GC, you shouldn't be creating your own cache for this, you should use an external gamecache library like Table.
__________________ |
|
|
|
|
|
#13 |
|
User
Join Date: Aug 2008
Posts: 14
|
Why I'm working with strings is that I couldn't figure out a way to use integers without limiting an item-type to only be cabable of being used in one recipe.
__________________GetItemTypeRecipes just separates the integers (=recipes) stored to the string, sets them to the array and returns the array. And I'll look to that Table. :) |
|
|
|
|
|
#14 |
|
Procrastination Incarnate
Development Director
|
Couldn't you just create a dynamic array for each item that stores all the recipies that item is involved in, and then link that array (which is just an integer when vJass compiles to Jass) to the item type via GC? Seems like the only sane way to do this.
__________________ |
|
|
|
|
|
#15 | ||
|
User
Join Date: Aug 2008
Posts: 14
|
At some point I came up with an idea of using dynamic arrays, but I abandoned that idea as I thought it'd restrict the system too much (if you increase the amount of recipes an item can be in, the amount of different item-types that can be used goes down), and I didn't know a way to store them well when in dynamic arrays. Didn't know they are that much like structs. So thanks for Anitarf, Vexorian, and everyone else who has left suggestions/comments.
__________________So I think it's about the time to release the version 0.6 after tweaking the code kinda much, now using Table and dynamic arrays and stuff. And it even worked in my tests.
Quote:
![]() Edit: Heh, maybe I shouldn't do this just before getting to bed. I noted I've been using strings to store the data, even though I could've just used integers. Will be fixed for the next version, don't worry. Last edited by Artificial : 08-28-2008 at 06:12 AM. |
||
|
|
|
![]() |
| Thread Tools | Search this Thread |
|
|
|
Donate |