|Category||Farming Simulator 19|
|Bio Medical Extetion (Unknown)||20.08.2019 07:26|
I need a complete FillTypes list to use in my script , mainly the exactly MIXED RATION filltype name.
Thank you to everyone.
|Lorenzos (lorenzoita)||20.08.2019 10:34|
|Hi, here it is:
FORAGE_MIXING (Mixed ration) <-
|Bilbo Beutlin (BBeutlin)||20.08.2019 15:16|
|Since the fillTypes might change depending on map, you should use a script which reads the actually existing fillTypes:
----- code -----
for _,fillType in pairs(g_currentMission.fillTypeManager.fillTypes) do
local ftName = fillType.name --> WHEAT, BARLEY, etc.
local ftDisplayName = fillType.title --> localized/translated name
local ftMass = fillType.massPerLiter
local ftPrice = fillType.pricePerLiter
|Bio Medical Extetion (Unknown)||28.08.2019 14:22|
But I need the tipTriggers prices (marketplace), and in FS19 there isnt anymore the tipTrigger Object
Where can I find those Prices?
|Brian Thompson (tommert)||25.12.2019 17:23|
|Is this the right table entry to edit to set bale prices (barley square bale in this example)?
I've made a mod that will set the price so that I get €25 when I sell a bale of straw, but it is always selling for approx €115. The mod makes the table updates in the loadMap() function, and it sets the prices correctly for other fill types such as wheat, barley, milk. It won't do ti for bales. Any ideas on how to set it?
if fillName == "SQUAREBALE_BARLEY" then
pricePerLitre = self.sellPriceStraw / self.balevolume;
g_currentMission.fillTypeManager.fillTypes[fillType].pricePerLiter = pricePerLitre;
Edit: FIgured it out. Somehow the bales are converted back to fillType STRAW at sale time. So
g_currentMission.fillTypeManager.fillTypes[STRAW].pricePerLiter = pricePerLitre;
|Gtx | Andy (GtX_Andy)||26.12.2019 01:16|
|Just a couple notes.
There is no need to use 'g_currentMission' to access FillTypeManager. You can access this directly using 'g_fillTypeManager'.
Also it would be better practice to use one of the manager functions to get the fillType, in this case you know it will exist but if you work with other mod fillTypes they may not on one occasion and 'g_currentMission.fillTypeManager.fillTypes[MOD_FILLTYPE].pricePerLiter' would leave you with an error.
Would be best to do something like this in most cases.
local fillType = g_fillTypeManager::getFillTypeByName("STRAW")
if fillType ~= nil then
-- Your Code Here
Keep in mind also 'pricePerLiter' is a raw value used for the economy calculation not the price at each trigger.
|Bilbo Beutlin (BBeutlin)||26.12.2019 02:03|
|Shouldn't matter. The 'fillTypeManager' is referenced multiple, beneath
also for example in
The '.fillTypeManager' appears also in many other global tables.
These all adresses to the same, always identical table pointer.
So if a mod fillType gives an error anywhere, it is not implemented properly.
|Gtx | Andy (GtX_Andy)||26.12.2019 04:41|
|I never said it matters from a working perspective but using 'g_fillTypeManager' was a suggestion as it is shorter, the original pointer are created like this for a reason. It is good coding practice to always write in a way that is easy to follow by someone just picking up the code for the first time. ;-)
So why use longer pointers when you can use a single word. The other examples are only available because direct pointers have been added to each of the classes you mention for fast easy access when working from inside that class. i.e 'self.fillTypeManager'
And depending what your doing it could matter as 'g_currentMission' may not have been created yet or may not be complete.
My main point was it is best to use the function 'getFillTypeByName' as this then handles the request without needing to write the fillType name in caps or check it already exists because it will be nil if it does not.
This however 'g_currentMission.fillTypeManager.fillTypes[STRAW].pricePerLite' would give an error if `STRAW` does not exist so again bad practice ;-)
All I do here is pass on clear easy to follow information using years of FS and other Programming experience and sometimes when I have time pass on a script to help a nice person instead of flaming them or telling them to learn. I do not come looking for a debate or to argue about who's suggestion is better, the info I give can be used or not. :-)
|Brian Thompson (tommert)||26.12.2019 20:20|
|Andy and Bilbo - thanks very much for your inputs here. It's great to get help when needed. And not only that, to get many different approaches and ideas. So thank you to both. I'll mess around with my little script and make some changes. Happy New Year!
|Brian Thompson (tommert)||26.12.2019 20:33|
Note: Log in to post. Create a new account here.