| Category | Editor |
| Created | 27.11.2018 09:29 |
| Ander Ss (anderrios) | 27.11.2018 09:29 |
|---|---|
| Hello, I have been doing tests to add a type of filler, the problem is the textures of the heaps. I explain what I have done; 1.- mapName.xml uncomment <fillTypes filename = "maps / maps_fillTypes.xml" /> <densityMapHeightTypes filename = "maps / maps_densityMapHeightTypes.xml" /> add: <additionalFile filename = "maps / fillPlanes / fillPlane_materialHolder.i3d" /> 2. copy the original fillPlane_materialHolder.i3d and edit. Just leave the new fillType with the new textures configured 4.- edit maps_fillTypes.xml. Copy an entry and replace it with the new FillType name and add the routes to the icons. At the bottom, add the fillType to the category type (BULK, AUGERWAGON, TRAINWAGON, FARMSILO) 3.- edit maps_densityMapHeightTypes.xml. Copy an entry and set name and routes ... Here comes my problem, I am unable to solve these routes and heaps dont have texture... I have tried with: · $moddir$FS19_MapName/maps/fillPlanes / · /maps/fillPlanes/ · /FillPlanes/texturename.png · Texturename.png https://i.imgur.com/rHSzX35.jpg I've tried with absolute paths (D: / ...... maps / fillPlanes ....) and it works fine, the problem is the routes to the mods from that file |
|
| Bilbo Beutlin (BBeutlin) | 27.11.2018 14:25 |
|---|---|
| $moddir$ is case-sensitive. Try with "$moddir$FS19_mapname/.." Anyway - ALWAYS look into the log of game and editor for errors, espec. for missing/unloadable files. |
|
| Ander Ss (anderrios) | 27.11.2018 16:38 |
|---|---|
| XD When I get home I try it, but I find it odd that I put it with capital letters because I copied it from one that worked. I think it was the translator who put the capital letter ... The log would throw a load error in textures, so try absolute paths, to really see if it was a problem with dds or xml files. With absolute paths they load perfectly the textures of the heaps, so I think it must be some type of bug, that from this .xml we can not point to folders of the mod Note that when using "$moddir$FS19_mapname/" in the log the string exited as is, the system does not replace this with the path to the folder MODS |
|
| Bilbo Beutlin (BBeutlin) | 27.11.2018 19:12 |
|---|---|
| Could be the same bug when evaluating the "defaultItems.xml" and "defaultVehicles.xml". The xml-parser somewhere cannot handle "$data/..", takes "data/.." instead. At the mom I don't know a solution for your problem apart from using absolute pathes. |
|
| William Rowe (Bonger76) | 27.11.2018 21:13 |
|---|---|
| $ moddir $ FS19_mapname remove the space between $, $moddir$ FS19_mapname might help |
|
| Ander Ss (anderrios) | 27.11.2018 21:24 |
|---|---|
| xD I put a photo so you can see how it is and the error it gives. the capitals and spaces put the translator sorry https://image.giants-software.com/index.php?hash=5EVa8Pgc&codes=true As you can see it does not replace $moddir$ with the path to the MODS folder |
|
| William Rowe (Bonger76) | 28.11.2018 02:29 |
|---|---|
| you might try removing the $moddir$ that might just be for the placeables because they are a mod |
|
| Ander Ss (anderrios) | 28.11.2018 12:36 |
|---|---|
| I've tried with relative paths from the root of the mod, from the file itself. I think that the relative paths do not work, only the absolute paths and this is a error |
|
| Sergiy Fors (Sergiy) | 28.11.2018 13:03 |
|---|---|
| how to register sale trigger fs19? |
|
| William Rowe (Bonger76) | 28.11.2018 18:41 |
|---|---|
| Ander,you might try loading all the fillTypes from your map so that thier is no call for data/ just load them all from map,and it might be a .lua thing on giants end like the trains and sky in FS17 when first release the paths where all in the right order but thier was something in thier .lua that called for a data/ and it stop the trains and sky from being loaded from map. the error is called on the tarpDistance_diffuse.png chnage to a gravelDistance_diffuse.png |
|
| Ander Ss (anderrios) | 28.11.2018 19:55 |
|---|---|
| I was testing with the original textures of the game in case it was a problem of this, but with the absolute paths the textures that I prepared for gravel work perfectly ... I have left to check leaving only in the file the filltype that I want to add or as I thought I understood you, do you copy all the filltypes to the folder of the map ???? |
|
| Ander Ss (anderrios) | 28.11.2018 21:04 |
|---|---|
| I tried to leave only the entry of the new pile in the file, but neither, I guess we'll have to wait for it to be solved |
|
| William Rowe (Bonger76) | 29.11.2018 00:17 |
|---|---|
| All fruitTypes from map look at mutiFruit map from FS17. The error is coming from your tip to ground or the densityMapHeightTypes.xml it shown in your trailer,thier might be a limit on how many types are in the map you could try removeing oneofthe types that would never be tip on the ground like wheat barley oats.This might be why the only way you can harvest cotton is to bale it in the game lots of harvesters don't bale. |
|
| Bilbo Beutlin (BBeutlin) | 29.11.2018 01:45 |
|---|---|
| No - the error is caused definitely by buggy filename resolving. When Ander is using absolute file path, all works fine. Quite obviously the evaluating function of "modDesc.xml" and "map.xml" points to the game's install (root) folder as 'cd' (current directory). And that's wrong, they should 'cd' to the mod's root folder (as in FS17). I've found, that in certain files not even $data is evaluated, $moddir$ not at all. That's also the reason why the GE generated files "defaultVehicles.xml" and "defaultItems.xml" don't work. They contain the filepath $data and this isn't resolved as usual. When replacing "$data" by "data" it works. I think, the whole "map.xml" evaluation is a 'building site'. I tried replacing "maps_fruitTypes.xml" and "maps_fillTypes.xml". That confused the whole game, since these files are read twice. First in the $data/maps folder and second in the defined mod folder. One can assume, it's the same with the other "..Types" files. |
|
| Ander Ss (anderrios) | 08.12.2018 11:59 |
|---|---|
| I try again relative path with and without the variable $moddir$FS19_name/ With the beta version of patch 1.2 IT IS NOT SOLVING THIS PROBLEM |
|
| Derek Squire (dezza069) | 07.01.2019 09:33 |
|---|---|
| I'm having the same problem with a "map_densityMapHeightTypes.xml" file - the paths are not working correctly, exactly as per above. |
|
| Jos Kuijpers (Unknown) | 07.01.2019 10:16 |
|---|---|
| I've tested the xml block for the densityMapHeightTypes.xml and it works fine. It grabbed the file from my mod folder. I had my mod folder map/, it contained map.xml and densityMapHeightTypes.xml My map.xml has <densityMapHeightTypes filename="densityMapHeightTypes.xml" />. Note that the default height types are always loaded. When you want to add a new height type, put just that new type into your XML. If you want to change properties of an existing height type, put just that height type into the xml with the changes. The filltype bound to the height type can't be changed but all other properties including textures can be. The same is true for the fruitTypes.xml. You can't update the name but the rest should be overwritten. Now I'll take a look at the texture paths. There is probably a bug there. Yes the paths in densityMapHeightTypes did not get resolved to the mod, so I've added that for the next patch. The filenames for filltypes are already resolved. Bilbo is correct in saying that things are 'loaded twice'. We force the loading of our own files at all times. Then map specific ones can be added on top as I described above. So you can't remove filltypes (for example) with just XML (would likely break the game anyway) Regarding $moddir$: this is only used for the items.xml and vehicles.xml because of internal networking related code. You can also use $moddir$$mapdir$/placeables/x.xml for example so your xml is not bound to the name of the folder/zip. |
|
| Bilbo Beutlin (BBeutlin) | 07.01.2019 16:25 |
|---|---|
| That the default "*Types.xml" are read in any case first from $data is no good idea. For mod maps it should be possible to disable certain fillTypes or fruitTypes and adapt type properties. Was quite simple if the "*Types.xml" would contain only absolute necessary datas and the 'real types' are defined in a map specific types definition, according map.xml <*Types .. /> |
|
| Derek Squire (dezza069) | 07.01.2019 22:21 |
|---|---|
| Thank you for looking/fixing (in the next patch) the paths issue Jos, much appreciated. - I flick between PC for editing and Mac to play, the file path issue was tiring.... Also agree with Bilbo that there needs to be a way to disable certain fillTypes or fruitTypes, perhaps by a "disable='true'" tag in the additional fillType or fruitType xml would suffice. Eg, in a colder region no sugarcane? Noticed the "*baleTypes.xml" file suffers from the same path issue as noted above - is it possible to have that resolved too please?? Again, thank you :) |
|
| Jos Kuijpers (Unknown) | 08.01.2019 11:57 |
|---|---|
| @Bilbo it is possible to change the type properties. Just not to remove them. This can of course still be done with scripts as before FS19. We just don't support it with XML. Please note that we had to change a lot to even make this possible with XML files, and we are allowing to add (+ change!) fruits now with just XML so it is also available on consoles or generally without scripts. Allowing removal of fruits and fills has far reaching concequences however. Filltypes are used in a lot of places (e.g. the bale types, filltype converters, and some hardcoded. They are also inside every vehicle with a fillunit). If a wrong filltype was removed it would break the game. This is fine if you are scripting, not fine if you're just editing XML files. I hope you understand the reasoning. @Derek I will look at the bale types EDIT: fixed for next version too |
|
| Derek Squire (dezza069) | 09.01.2019 02:46 |
|---|---|
| Hey Jos, Thanks for your updates and information - which all makes sense. BTW, I'm appreciating how much easier this version is to customise (once you "get it"). Great game. |
|
| Ander Ss (anderrios) | 09.01.2019 12:27 |
|---|---|
| Thanks for fix, ETA for 1.3? |
|
| Jos Kuijpers (Unknown) | 09.01.2019 13:15 |
|---|---|
| This winter |
|
| Derek Squire (dezza069) | 09.01.2019 13:30 |
|---|---|
| Hi, I'm finding whilst adding new fruit(s) and fill types the GE8.1.0 is not correctly saving the shapes file. For eg in the "effects_materialHolder.i3d" - after importing new items and saving, the existing entries all have their associated shapes changed - "wheat0_05_materialHolderShape" and all the other unloading shapes are now tagged with "barley0_05_materialHolderShape" , and the shapes file size decreases from 300k to about 3k. This is regardless of how things are imported (individually, or in a transform group) or how the file is saved or exported - with or without the i3d set to be binary. Is this a problem with me or the editor?? :) :) :) :) Thanks. |
|
| Derek Squire (dezza069) | 09.01.2019 22:57 |
|---|---|
| Attempting to add to an existing/entire "effects_materialHolder.i3d" - with an existing external shapes file - I've even tried editing the .i3d code manually, adding the materials, nodes, attributes, etc, carefully ensuring there are no clashes with nodeId's, materialId's, etc. It loads into GE8.1.0 (with the expected "Warning: i3d contains non-binary indexed triangle sets: C:/Data/fs19_maps/FS19_EstanciaLapacho/particleSystems/effect_materialHolder.i3d" ), but every time it is saved the external shapes file goes from 309k to (now, with 3 new shapes added) 16k and all the associated shapes get wrongly assigned. Even the three new shapes (created in Blender 2.79) are now wrongly assigned - with them all referencing the one shape (name) instead of the individual shapes they were originally inserted with. Seems the shapes files is being overridden and not added to. What am I doing wrong? EDIT: Just loading in and saving "effect_materialHolder.i3d" without edits is enough to wipe the shapes file and mess all the shape assignments up. Surely this is not how it's supposed to work? |
|
| Jos Kuijpers (Unknown) | 10.01.2019 10:33 |
|---|---|
| You should not save material holders in GiantsEditor. On our side they are directly exported from Maya and we never touch them in the editor. Do everything in the xml directly. |
|
| Derek Squire (dezza069) | 10.01.2019 15:38 |
|---|---|
| Thank you Jos, After a bit of trial and error and thinking about it, I worked out that was how it must have been (your using of Maya for exporting the shapes) and editing the xml was the way to do it... Appreciate your reply :) |
|
| Andrei Sprinseana (xsenio) | 08.02.2019 19:37 |
|---|---|
| Everything is now in versions 1.3.0 works registration of their own crops in the densityMapHeightTypes. But to do and registration of their own bales, did not, sorry. |
|
| Derek Squire (dezza069) | 08.02.2019 22:38 |
|---|---|
| Where did you get the 1.3.0 version from? Both my Mac and PC have 1.2.0.1. |
|
| Andrei Sprinseana (xsenio) | 09.02.2019 09:58 |
|---|---|
| Steam beta v. 1.3.0 |
|
| Derek Squire (dezza069) | 09.02.2019 12:48 |
|---|---|
| Thanks Andrei, I'd missed the announcement. The registration of bale types still requires the full file path to be written in V1.3.0 |
|
| Andrei Sprinseana (xsenio) | 10.02.2019 00:28 |
|---|---|
| Yes Derek that's right, unfortunately with bales did not do anything. |
|
| Ander Ss (anderrios) | 16.02.2019 12:16 |
|---|---|
| hello, someone has managed to translate the names of the new "filltypes" records? I suppose that the file "maps_fillTypes.xml" the attribute "title ="$l10n_carrot"" but I get the same error, can not find the translation in ($l10n_es.xml) |
|
| Ander Ss (anderrios) | 19.03.2019 17:01 |
|---|---|
| Hello, I still have problems translating the names of the fruits with the patch 1.3 Does anyone have new fruits installed and translated correctly with title="$l10n_hops"? |
|
Note: Log in to post. Create a new account here.