Community Forum

Custom bateType Paths and Custom Placeables still NOT working in update 1.3

Category	Scripting
Created	19.03.2019 12:16

Derek Squire (dezza069)	19.03.2019 12:16
Hello Giants, "BALETYPES" NOT BATETYPES!!!!!!!!! As advised the day after you released the 1.2beta, which was long before you dropped the latest 1.3 update out: customBaleTypes.xml STILL require a full typed path for the custom i3d file (this was advised to by fixed by Jos "in the next update", which at the time was 1.2). Custom placeables do NOT initialise/run their custom scripts after being sold from the in-game store. The ONLY way to get it to work (that I can find, without any guidance) is to buy/place from the store and then change the className in the saved items.xml, or start with the className correctly set in the defaultItems.xml. Thanks for looking into this. D.

Derek Squire (dezza069)

19.03.2019 12:16

Hello Giants,

"BALETYPES" NOT BATETYPES!!!!!!!!!

As advised the day after you released the 1.2beta, which was long before you dropped the latest 1.3 update out:

customBaleTypes.xml STILL require a full typed path for the custom i3d file (this was advised to by fixed by Jos "in the next update", which at the time was 1.2).

Custom placeables do NOT initialise/run their custom scripts after being sold from the in-game store. The ONLY way to get it to work (that I can find, without any guidance) is to buy/place from the store and then change the className in the saved items.xml, or start with the className correctly set in the defaultItems.xml.

Thanks for looking into this.

D.

Andrei Sprinseana (xsenio)	19.03.2019 16:55
Yes, I am also very upset by this.

Andrei Sprinseana (xsenio)	19.03.2019 19:30
Yes, it is a pity that you have to give up their bales. Disappointment.

Andrei Sprinseana (xsenio)	19.03.2019 20:56
If you set the full path, then this works fine in a single player game, but it does not work on a dedicated server.

Derek Squire (dezza069)	19.03.2019 23:03
TBH - I’m really, really annoyed over this. Dunno if I can be bothered modding FS19 anymore, these little frustrations and constantly waiting patiently for others (who provide no or misleading feedback) to implement rather simple fixes is taking away any enjoyment, and means all the stuff I’ve spent months working on still will not work correctly IF I choose to release them. Not good enough Giants.

Derek Squire (dezza069)

19.03.2019 23:03

TBH - I’m really, really annoyed over this.

Dunno if I can be bothered modding FS19 anymore, these little frustrations and constantly waiting patiently for others (who provide no or misleading feedback) to implement rather simple fixes is taking away any enjoyment, and means all the stuff I’ve spent months working on still will not work correctly IF I choose to release them.

Not good enough Giants.

Kevin K. (kevink98)	21.03.2019 15:38
Customs placeables: When you use your own script, then can you also register this placeabletype in this script. Where is the problem?

Derek Squire (dezza069)	22.03.2019 01:05
I have no problem registering the custom placeable type/class using a separate loading script during the initial mod loading stage: g_placeableTypeManager:addPlaceableType("mySpecialClass", "Placeable", Utils.getFilename("scripts/mySpecialClass.lua", g_currentModDirectory), nill); The log shows: Register placeable type: mySpecialMod.mySpecialClass The problem is: The custom placeable does NOT fire its custom script - a separate script containing the special functioning of the custom placeable, not the registration script - when initially sold via the in-game shop. The only way to get the custom script to work is to buy and place the placeable, save the game and then manually modify the savegame to adjust the class type. Will try and explain it further: Eg: when purchased from the in-game shop, the custom placeables' class/script is not accessed - the game uses the default "Placeable" class and the savegame is saved like this: <item className="Placeable" id="1" modName="mySpecialMod" ….. where it needs to (should) save it as: <item className="mySpecialMod.mySpecialClass" id="1" modName="mySpecialMod" …. OR(????) <item className="mySpecialClass" id="1" modName="mySpecialMod" …. I can tell the custom script is not being utilised during the initial purchase, because I've got debug messages throughout it indicating where it's functioning which simply don't appear in the log. Log messages only appear when the manual className setting process above is used, or if a "default_items.xml" file is used with the correct className set initially/manually. Weird thing is, if I use the wrong (for eg) placeableType="mySpecialClassWronglySpelt" in the placeables "mySpecialMod.xml", or set the className in the savegame incorrectly, the object fails to load and a log message error is produced. I'm hoping I'm just making a stupid mistake(s), and I'm thinking it's with the subclassing of the placeable class. Apologies for the excuses, but I'm getting older and find that multiple computer languages known are blurring and I'm confusing myself whilst learning another one (LUA)!!! ---- This is how I'm subclassing: mySpecialClass= {}; mySpecialClass_mt = Class(mySpecialClass, Placeable); which gets used in function mySpecialClass:new(isServer, isClient, customMt) local self = Placeable:new(isServer, isClient, customMt or mySpecialClass_mt); registerObjectClassName(self, "mySpecialClass"); ….. (stuff) end; As mentioned, this all works fine except if the placeable is purchased/placed via the in-game store. Thanks for your considerations. Regards.

Derek Squire (dezza069)

22.03.2019 01:05

I have no problem registering the custom placeable type/class using a separate loading script during the initial mod loading stage:
g_placeableTypeManager:addPlaceableType("mySpecialClass", "Placeable", Utils.getFilename("scripts/mySpecialClass.lua", g_currentModDirectory), nill);

The log shows:
Register placeable type: mySpecialMod.mySpecialClass

The problem is:
The custom placeable does NOT fire its custom script - a separate script containing the special functioning of the custom placeable, not the registration script - when initially sold via the in-game shop.

The only way to get the custom script to work is to buy and place the placeable, save the game and then manually modify the savegame to adjust the class type.

Will try and explain it further:

Eg:
when purchased from the in-game shop, the custom placeables' class/script is not accessed - the game uses the default "Placeable" class and the savegame is saved like this:
<item className="Placeable" id="1" modName="mySpecialMod" …..

where it needs to (should) save it as:
<item className="mySpecialMod.mySpecialClass" id="1" modName="mySpecialMod" ….
OR(????)
<item className="mySpecialClass" id="1" modName="mySpecialMod" ….

I can tell the custom script is not being utilised during the initial purchase, because I've got debug messages throughout it indicating where it's functioning which simply don't appear in the log. Log messages only appear when the manual className setting process above is used, or if a "default_items.xml" file is used with the correct className set initially/manually. Weird thing is, if I use the wrong (for eg) placeableType="mySpecialClassWronglySpelt" in the placeables "mySpecialMod.xml", or set the className in the savegame incorrectly, the object fails to load and a log message error is produced.

I'm hoping I'm just making a stupid mistake(s), and I'm thinking it's with the subclassing of the placeable class. Apologies for the excuses, but I'm getting older and find that multiple computer languages known are blurring and I'm confusing myself whilst learning another one (LUA)!!!

----
This is how I'm subclassing:

mySpecialClass= {};
mySpecialClass_mt = Class(mySpecialClass, Placeable);

which gets used in

function mySpecialClass:new(isServer, isClient, customMt)
local self = Placeable:new(isServer, isClient, customMt or mySpecialClass_mt);

registerObjectClassName(self, "mySpecialClass");

….. (stuff)
end;

As mentioned, this all works fine except if the placeable is purchased/placed via the in-game store.

Thanks for your considerations.

Regards.

PinchTheFarmer	22.03.2019 22:54
Hi o/ apparently what you want to do is to re-define the placeable class for 1 item ? I got a problem like that with husbandryFilename. With custom maps they completly replace the directory and put the one of the map in front of your path (it's really not nice & disturbing, they re-write into). You probably have the same problem, did you tried on 1 of the 2 stock maps ?? I didnt got troubles with full path & stock maps. One solution is maybe to go write the file where its needed BUT big problem is that we can't delete them after :/ it can cause troubles on custom maps / dedicated server. Also ! : in LUA in fact your script file is already a class ! Of the name of the file , and if you want to do something all the time you have to put the "update(dt)" or "draw" function (dont forget boolean for 1 time loop). You make function with your classname in front too normally (for class func, you can without to do global) : file "myClass.lua" : function myClass:myFunction( arg1, arg2) --Static call with " : " end; and if you use this class and create instances into variables, you can put : function myClass.functionInstance( arg1 ) end; This is for manipulating class variables in theses functions. Also you have maybe a last way too : find where your item is in the g_ variables and modify the path but i tried and there must be multiple places to modify :/ Me i use the copy of file into a directory created with the map name and copy files where he will read and warn player to delete this directory after playing (because multiplayer need ZIP and game believe mod is into a dir). If you want to look this kind of code, it is into Animal Species - Savage Pig Pack. Also you may find theses website very useful to know engine classes & functions : https://github.com/scfmod/fs19_lua https://github.com/scfmod/fs19_LuaRefAutoGen (v1.2)

PinchTheFarmer

22.03.2019 22:54

Hi o/ apparently what you want to do is to re-define the placeable class for 1 item ? I got a problem like that with husbandryFilename. With custom maps they completly replace the directory and put the one of the map in front of your path (it's really not nice & disturbing, they re-write into).

You probably have the same problem, did you tried on 1 of the 2 stock maps ?? I didnt got troubles with full path & stock maps.

One solution is maybe to go write the file where its needed BUT big problem is that we can't delete them after :/ it can cause troubles on custom maps / dedicated server.

Also ! : in LUA in fact your script file is already a class ! Of the name of the file , and if you want to do something all the time you have to put the "update(dt)" or "draw" function (dont forget boolean for 1 time loop). You make function with your classname in front too normally (for class func, you can without to do global) :

file "myClass.lua" :

function myClass:myFunction( arg1, arg2) --Static call with " : "
end;

and if you use this class and create instances into variables, you can put :

function myClass.functionInstance( arg1 )
end;

This is for manipulating class variables in theses functions.

Also you have maybe a last way too : find where your item is in the g_ variables and modify the path but i tried and there must be multiple places to modify :/
Me i use the copy of file into a directory created with the map name and copy files where he will read and warn player to delete this directory after playing (because multiplayer need ZIP and game believe mod is into a dir).

If you want to look this kind of code, it is into Animal Species - Savage Pig Pack.
Also you may find theses website very useful to know engine classes & functions :
https://github.com/scfmod/fs19_lua
https://github.com/scfmod/fs19_LuaRefAutoGen (v1.2)

Derek Squire (dezza069)	23.03.2019 00:43
PinchTheFarmer - thanks. The problem exists regardless of the map used. It's possible you've mis-understood the problem. For anyone reading this, I have noticed that after instigating the new placeable type in a loading script using: g_placeableTypeManager:addPlaceableType("mySpecialClass", "Placeable", Utils.getFilename("scripts/mySpecialClass.lua", g_currentModDirectory), nil); The log shows: Register placeable type: mySpecialMod.mySpecialClass BUT consistently a few lines after in the log appears this message: Error: spec type name 'incomePerHour' is already in use! This one line message appears consistently for each/any of the registered custom placeables. If one custom placeable is initialised during map load, this one line error will appear once. If three (different) custom placeables are initialised during map load, this one line message will repeat three times a little bit further down in the log. This happens regardless of having no other mods loaded or any/all other mods loaded. None of my scripts are loading any additional spec types. Thanks in advance.

Derek Squire (dezza069)

23.03.2019 00:43

PinchTheFarmer - thanks. The problem exists regardless of the map used. It's possible you've mis-understood the problem.

For anyone reading this, I have noticed that after instigating the new placeable type in a loading script using:
g_placeableTypeManager:addPlaceableType("mySpecialClass", "Placeable", Utils.getFilename("scripts/mySpecialClass.lua", g_currentModDirectory), nil);

The log shows:
Register placeable type: mySpecialMod.mySpecialClass

BUT consistently a few lines after in the log appears this message:
Error: spec type name 'incomePerHour' is already in use!

This one line message appears consistently for each/any of the registered custom placeables. If one custom placeable is initialised during map load, this one line error will appear once. If three (different) custom placeables are initialised during map load, this one line message will repeat three times a little bit further down in the log. This happens regardless of having no other mods loaded or any/all other mods loaded.

None of my scripts are loading any additional spec types.

Thanks in advance.

Jos Kuijpers (Unknown)	25.03.2019 15:00
Don't register the incomePerHour spec type again. I've successfully registered and used 5 new placeable types in a mod. They also load when the map is loaded. It is VERY important to use your class name as the second argument, not Placeable. g_placeableTypeManager:addPlaceableType("mySpecialClass", "MySpecialClass", Utils.getFilename("scripts/mySpecialClass.lua", g_currentModDirectory), nil);

Derek Squire (dezza069)	27.03.2019 12:45
Thank you Jos, that simple fix of using the command correctly solved the problem. I'd taken the line from another forum post from you, now that I've had it pointed out to me specifically and, re-read that other post for the 100th time I finally noticed how I'd obviously misinterpreted the function definition you'd provided in your other post. My apologies, my brain is failing!! That also fixed the spec type error. Thanks again. Also, I was under the impression the baleTypes path issue was fixed in the 1.2 update, I'm wondering if you may have any idea when that may be getting looked at? Kind regards

Derek Squire (dezza069)

27.03.2019 12:45

Thank you Jos, that simple fix of using the command correctly solved the problem.

I'd taken the line from another forum post from you, now that I've had it pointed out to me specifically and, re-read that other post for the 100th time I finally noticed how I'd obviously misinterpreted the function definition you'd provided in your other post. My apologies, my brain is failing!!

That also fixed the spec type error. Thanks again.

Also, I was under the impression the baleTypes path issue was fixed in the 1.2 update, I'm wondering if you may have any idea when that may be getting looked at?

Kind regards

Brian Smith (bs98765432123)	01.04.2019 16:25
great, now what about Custom baleType Paths, is giants ignoring this?

Anthony Roark (iwasthere83)	01.04.2019 18:11
This worked for me in the moddesc. Also worked the same way for round cotton bales. <baleTypes> <baleType filename="bales/roundbaleHay_w120_d180.i3d" fillType="DRYGRASS_WINDROW" isRoundbale="true" width="1.2" diameter="1.8" /> <baleType filename="bales/roundbaleGrass_w120_d180.i3d" fillType="GRASS_WINDROW" isRoundbale="true" width="1.2" diameter="1.8" /> <baleType filename="bales/roundbaleStraw_w120_d180.i3d" fillType="STRAW" isRoundbale="true" width="1.2" diameter="1.8" /> </baleTypes>

Anthony Roark (iwasthere83)

01.04.2019 18:11

This worked for me in the moddesc. Also worked the same way for round cotton bales.

<baleTypes>
<baleType filename="bales/roundbaleHay_w120_d180.i3d" fillType="DRYGRASS_WINDROW" isRoundbale="true" width="1.2" diameter="1.8" />
<baleType filename="bales/roundbaleGrass_w120_d180.i3d" fillType="GRASS_WINDROW" isRoundbale="true" width="1.2" diameter="1.8" />
<baleType filename="bales/roundbaleStraw_w120_d180.i3d" fillType="STRAW" isRoundbale="true" width="1.2" diameter="1.8" />
</baleTypes>

Derek Squire (dezza069)	02.04.2019 07:55
Thanks Anthony. The process is supposed to be (unless there's some undocumented specifics I'm not aware of) simply a baleTypes.xml document declaring the paths to the various custom bale types which gets linked in the "mapXXX.xml" document, eg: <baleTypes filename="mapXX_baleTypes.xml" /> Glad you've found a hack that works for you - just to confirm you're using custom i3d's for your custom bales which are located in a "bales" folder located inside the mod-map folder, correct?? Tried your method (on the Mac), placing the <baleTypes> entries in both the moddesc.xml and also directly in the mapXX.xml and for me neither worked, or would appear to allow the use of custom bales that are located in a folder located inside the custom map folder. Wondering if there's any updates on this from Giants please? Thanks.

Derek Squire (dezza069)

02.04.2019 07:55

Thanks Anthony.

The process is supposed to be (unless there's some undocumented specifics I'm not aware of) simply a baleTypes.xml document declaring the paths to the various custom bale types which gets linked in the "mapXXX.xml" document,

eg:

<baleTypes filename="mapXX_baleTypes.xml" />

Glad you've found a hack that works for you - just to confirm you're using custom i3d's for your custom bales which are located in a "bales" folder located inside the mod-map folder, correct??

Tried your method (on the Mac), placing the <baleTypes> entries in both the moddesc.xml and also directly in the mapXX.xml and for me neither worked, or would appear to allow the use of custom bales that are located in a folder located inside the custom map folder.

Wondering if there's any updates on this from Giants please?

Thanks.

Anthony Roark (iwasthere83)	10.04.2019 04:26
The i3d are in the baler mod, allowing me to load different size bales with custom textures on any map.

Derek Squire (dezza069)	10.04.2019 09:02
Hi Anthony - What/where is "the baler mod"??? Thanks, sorry for my ignorance.

Note: Log in to post. Create a new account here.

GDN

Community Forum

Custom bateType Paths and Custom Placeables still NOT working in update 1.3

Latest Products

Latest Downloads

Newsletter

GDN

Community Forum

Custom bateType Paths and Custom Placeables still NOT working in update 1.3

Login

Latest Products

Latest Downloads

Newsletter