|
Most frameworks don't have farming implemented quite right, so I though I'd post some of the stuff I've found out about the actual farming system from various sources. Hopefully it will help those who are developing farming systems. This is based off ids from RS3, though many will still apply for older revisions.
Variables
Each farming patch is associated with two different varbits: one which tracks the current status of the patch, the other which tracks whether compost has been applied (and which sort of compost). These two variables are the only things that need to be stored between farming interactions, and they are also stored along with the player save data. They are as follows:
Spoiler for Patch Information:
Farming ticks
This process is best explained by this thread on the RuneScape forums, but I will leave a brief explaination here and advice on how to implement it.
About every 5 minutes following the player's login, a farming tick is run. This is where each patch is investigated by the server and it's status is changed, if need be. Most crops have a regular 5 minute window in which growth is processed. This window is attatched to the current server time so, for example, growth for potatoes will only run if the farming tick occurs between 12:00-12:05, 12:10-12:15, 12:20-12:25, etc. You can check whether the farming tick can be run using the calcuation:
Where "tickType" is the type of farming tick for the crop (1=flower, 2=allotment, 4=herb, and so on).Code:canRun = ((getCurrentTimeInSeconds()/5*60) % tickType == 0);
When a player logs in, the total amount of time since their last login is calculated. All the missed ticks are simulated using this, based on one every 5 minutes after their logout until they logged back in.
Patch statuses
This is mostly well understood already, but I'm including it for good measure.
In almost all farming patches, statuses 0-3 are used for weeds, with 0 being fully grown and 3 being empty. The remaining statuses vary between patch types, but in general, there are 7 types of statuses used.
For example, these are the statuses for potato crops:
Upon planting, the patch is set to the plantStage. If watered, it is changed to the "wateredSeedling" stage. From either of these stages, the crop grows into the first growth stage (it cannot become diseased until the second growth cycle). If watered again, the crop shifts to the "wateredStage" with the same index as it's current state. When growing in any of the growthStages, the crop either falls into the diseasedStage with the matching index, moves to the next index in the growthStages, or moves to the first harvestStage (if it was in the final growthStage). If cured while diseased, the crop moves back to the growthStage with the same index as the diseasedStage (thus, if the crop becomes diseased, it will miss a growth cycle even if cured). If the crop is not cured, it will go to the deadStage of the same index.Code:plantStage : 6, wateredSeedling : 70, growthStages : [7, 8, 9], wateredStages : [71, 72, 73], diseaseStages : [135, 136, 137], deadStages : [199, 200, 201], harvestStages : [10, 11, 12]
Herbs do not have watered stages, and while each herb type shares the same locations, they have different status codes for plant, growth, diseased, and harvest stages (they share the same dead stages, since there's no need to track the herb type if it's dead).
Compost
Applying compost is fairly simple. In the "Variables" section above, I mentioned that each patch has a varbit linked to it which tracks the compost status. When compost is applied, you should set this variable to 1 for normal compost or 2 for supercompost.
Harvesting
This is one area which most implementations don't seem to have quite right. Basically, when harvesting allotments, herbs, and hops, there are 3-5 "rolls" (3 if no compost has been applied, 4 with normal compost, and 5 with supercompost). Each time a player harvests an item from the patch, there is a chance that a "roll" will be used up (the exact chance depends on farming level, crop type, whether boosts are used, and possibly some other factors). When a roll is used up, the farming patch moves to the next harvestStage, and the status should be updated accordingly. If compost was applied, the compost variable should be decremented by one when a roll is used before changing the harvest stages. Once the last roll is used up (when the patch is on its last harvestStage), the patch is set as empty (status 3) and the player stops harvesting.
If implemented this way, the player is guarenteed to get at least 3-5 items from the patch. Also, since using up rolls is tracked via the variable, players can safely click away and even log out without resetting the harvest counters (which is a possible issue if a temporary variable is used to track harvest progress).
Where has all this information about the random stuff in the varbits come from? The IDs an object (e.g. a farming patch) can transform into are in it's definition data.
Example:
Tree patch in Lumbridge, object ID 8391.
Initially looks like:
Let's convert it to a willow tree
Spoiler for morphable IDs:
Looking at this list we can see index 22 will change it to a willow tree (object id 8488)
So send the varbit message with ID 703 and value 22, and this happens:
The above definition for 317:
Code:ObjectDefinition { Name=farming_tree_patch_4, Morphism Set { bit variable=703, parameter variable=65535, morphisms=[ 8395, 8394, 8393, 8392, 8395, 8395, 8395, 8395, 8462, 8463, 8464, 8465, 8466, 8467, 8468, 8481, 8482, 8483, 8484, 8485, 8486, 8487, 8488, 8489, 8435, 8436, 8437, 8438, 8439, 8440, 8441, 8442, 8443, 8444, 8445, 8502, 8503, 8504, 8505, 8506, 8507, 8508, 8509, 8510, 8511, 8512, 8513, 8514, 8396, 8397, 8398, 8399, 8400, 8401, 8402, 8403, 8404, 8405, 8406, 8407, 8408, 8409, 8410, 8395, 8395, 8395, 8395, 8395, 8395, 8395, 8395, 8395, 8395, 8473, 8474, 8475, 65535, 8476, 8395, 8395, 8490, 8491, 8492, 8493, 8494, 65535, 8495, 8395, 8395, 8446, 8447, 8448, 8449, 8450, 8451, 8452, 65535, 8453, 8395, 8395, 8515, 8516, 8517, 8518, 8519, 8520, 8521, 8522, 8523, 65535, 8524, 8395, 8395, 8411, 8412, 8413, 8414, 8415, 8416, 8417, 8418, 8419, 8420, 8421, 65535, 8422, 8395, 8395, 8395, 8395, 8395, 8395, 8395, 8395, 8395, 8395, 8395, 8477, 8478, 8479, 65535, 8480, 8395, 8395, 8496, 8497, 8498, 8499, 8500, 65535, 8501, 8395, 8395, 8454, 8455, 8456, 8457, 8458, 8459, 8460, 65535, 8461, 8395, 8395, 8525, 8526, 8527, 8528, 8529, 8530, 8531, 8532, 8533, 65535, 8534, 8395, 8395, 8423, 8424, 8425, 8426, 8427, 8428, 8429, 8430, 8431, 8432, 8433, 65535, 8434, 8314, 8395, 8488, 8488, 8488, 8488, 8488, 8488, 8395, 8395, 8395, 8395, 8395, 8395, 8395, 8395, 8395, 8395, 8395, 8395, 8395, 8395, 8395, 8395, 8395, 8395, 8395, 8395, 8395, 8395, 8395, 8395, 8395, 8395, 8395, 8395, 8395, 8395, 8395, 8395, 8395, 8395, 8395, 8395, 8395, 8395, 8395, 8395, 8395, 8395, 8395, 8395, 8395, 8395, 8395, 8395, 8395, 8395, 8395, 8395, 8395, 8395, 8395, 8395, 8395, 8395] }, Width=3, Length=3, Interactive=true, Contour Ground=true, }
Last edited by Major; 05-03-2015 at 12:48 PM.
What I've referred to as "statuses" the client uses to transform the location into different variations, as you've specified. So by setting the varbit associated with an allotment to 6 (plant stage of a potato), the client will transform the location into a potato seeding. In the example given, the stuff in square brackets are the statuses I identify. So, if you want to identify the statuses for patches, you'll need to either use trial-and-error in setting variables or lookup the location configuration.
From what I can tell, the value stored in varps (and hence varbits, since they alter parts of varps) are supposed to be stored on the server side and saved along with the player file, as well as sent to the client whenever their value changes so that the client knows to change (or morph) the locations they represent.
Not sure if that answers your question, but I hope it helps.
PS. When I refer to "locations", I mean what's been traditionally referred to as "objects".
i don't see why you'd use the former when you have the list of morphables in the object's 'configuration'.
yes, varps and varbits represent variables that may or may not be saved to the player's save file. other examples include prayer points and life pointsFrom what I can tell, the value stored in varps (and hence varbits, since they alter parts of varps) are supposed to be stored on the server side and saved along with the player file, as well as sent to the client whenever their value changes so that the client knows to change (or morph) the locations they represent.
the 'trial and error' thing answers where you got the random formula from, but doesnt answer my question as to why you arent using the actual list of morphable object ids that are in the objects definition, seems to make a ton more sense than 'trial and error'?Not sure if that answers your question, but I hope it helps.
Sorry, sounds like I haven't been all that clear. By "lookup the location configuration" I mean checking the morphs/transforms/whatever they're called to find out the right values, which is certainly the preferred way. There are some cases where the transform list isn't quite enough (such as when there are multiple versions with the same name and the order isn't all that clear, which is the case with the new crops Jagex added), in which case trial-and-error is needed to find out which version is which.
So what is all this about plant stage and seed stage? Are you sayin that there are varbit values that are consistent throughout every patch, for example to transform it into the state where it's just been composted?
That leads me to believe this "transform list" of presuming that the states are consistent for each patch is not the correct way of doing it.transform list isn't quite enough (such as when there are multiple versions with the same name and the order isn't all that clear, which is the case with the new crops Jagex added)
« Previous Thread | Next Thread » |
Thread Information |
Users Browsing this ThreadThere are currently 1 users browsing this thread. (0 members and 1 guests) |