Re: Building a map, start of a project, help will be needed

[52ndOx]

You don't need to extract the packages.dat to use the objects in Lstudio.
Need to add the whole library in Lstudio with Packages/Package Manager/Add Package

I don't think you can resize the actual models without loading them back into a 3D editor, but you can set the scale of an object when you add it with Properties/Orientation. These values are remembered during the Lstudio session, or if you select a model already added to the scene and duplicate.

Not possible to do anything with a spreadsheet here because the .dat are binary.

[RebBugler]

Need to add the whole library in Lstudio with Packages/Package Manager/Add Package

I'm doing this. I added them from their original file, I've copied them to the Map 1 file (the test file that got the terrain to show up in lstudio) and added them from there, to no avail, all I get is same terrain without objects, and the packageName can't be found errors.

Regardless, I'm screwing up somewhere, I'll just go back and start over. Thanks for the help

[52ndOx]

It should work.

LS map with no packages:




Add WL.dat via package manager and reload:

[RebBugler]

Did exactly what you said. It then appears here in the Packages Manager.

The attachment Packageserror2.jpg is no longer available

After 'reload' I get this error, and no objects.

The attachment Packageserror.jpg is no longer available

[RebBugler]

OK, found the problem, but not the solution. Went back and worked with a WL map. Followed your procedure and had no issues, package files were accepted, and I see and can move objects now. In fact, they showed up without going through the Package Manager procedure. So, it's a GB maps issue, or I should a procedural issue on my part. Davinci or another GB map maker will probably steer the correct GB route for fixing this issue.
Thanks for helping me load a WL map.

[Davinci]

"Reb" - What's New in the Great State of Arkansas "

The "Main" Problem that you are going to encounter is that the Packages are in a dozen different files, and a lot of them have duplicate objects in some of them.

There was never a Standard on loading them, so everyone did something different.

Now, the "Packages" have to be "Loaded" in "Two Separate" folders to work correctly.

There is a "Packages" Folder in the LStudio Directory \ NSDTools - I think is the name of yours.

There is also a Packages Folder in the Mod \ Maps \ Packages - folder, place the same Packages into both of those.

The LStudio - Will call on the Packages from it's directory.

The Game - Will call on the Packages from the Maps \ directory.

Once you have extracted the Packages in the "LibEdit Window" and copied them into another folder to view, there are usually 3 or 4 files that are associated with each item. ( item equal house, barn, fence, etc.)

There is a ( LS ) file that can be viewed with "NotePad" and Edited with "NotePad" - its a text file.

If you know the "Exact" Size that you want an item to be, this file can be altered manually, as long as it isn't already placed on the Map in question.

To put that another way, if the Map that you are going to edit already has a "House1" on it, it will do "No Good" to edit the ( LS ) file, since it will not override the existing house size on the map.

All of the current objects and their locations and current sizes are stored in the "Terrain.lvl" file that is located in the MapName.lsl file.

Now, if you are going to change the sizes of the fences, to best way to change ten thousand of them in two seconds is with a "Hex Editor", but it really only changes the height and not the length of them.

This is for your New Mod - So what size difference are you changing everything too?

Load All of the Packages in this Folder - and then use the Menu from LStudio in the Picture that you posted above to [ Add Packages] one at a time into the Map that you are currently working on!

The attachment 1_2019-08-07.png is no longer available

davinci

[RebBugler]

Thanks davinci,

Copying the packages .dat files into the NSDTools/Packages folder did the trick. This is why the WL map loaded without a hitch, as the .dat files for it were already there. Didn't need to mess with the LibEdit app, thank goodness, or the 320 object files would have had to be saved one at a time, if extracted to a folder.

Now I can see and edit map objects.

[Davinci]

Didn't need to mess with the LibEdit app, thank goodness, or the 320 object files would have had to be saved one at a time, if extracted to a folder.

Dropping the Packages.dat into the LibEdit Window - is only when you are going to "Change" something such as making another house with a different roof for the game, or changing the doors or windows.

This way is a lot better than starting from scratch, just rename a house, change the appearance, and add it back into the Packages.dat file.

You might want to load that "BoxScale" figure on the Map and adjust the height to the men on the field.

Open the LStudio - and place the Boxscale figure where you think that the men will show up in the game, and move some men over to his position to get the right scale.

Then go into the LStudio - and change his height, now when placing down houses and fences, you can use his scale to determine the correct size.

I usually place him near the doors of a structure to get the right size of a house or barn.

Also - it's a good idea to also start writing down what values you use on each house, barn, etc...it will make the conversions a lot easier, so you don't have to remember what values to use.

The attachment 1_2019-08-07-2.png is no longer available

davinci

[Crikey]

Reb....I believe the 3D box scale figure’s default scale properties is set at 1.6, 1.6, 1.6 - length, height, width etc. That may be right for SoWGB although worth checking, but far too big for SoWWL. The latter should probably be around 1.2 to reflect the smaller sprites used. The default settings for SoW buildings generally come out far too big....in terms of scale and in terms of collision radius. You can spend a lot of time manually adjusting.

On the latter i’m not even sure the AI recognises the size of the collision radius only that there is one. In TCM2 troops would recognise a 300 yard radius, in SOWWL they seem to recognise there is one but not it’s size, and just edge around the walls of the building. Perhaps this was a side effect of Norb’s bespoke PR variant.

Finally, fences. As D suggests make sure you get the scale right before laying. Also, you can turn 3D collisions completely off on these.

[r59]

In other words, what actually defines a road?

The Game does not know a road from a cornfield, the Programming is Programed to "Seek" out the fastest movement speeds.

A formula that is very Simple, and very Clever !

So, if the Roads are given a positive value ( 0.2, or 0.1 ) and all of the other values are lower than those two values, the Game will move the units on the fastest path.

So, the MapName.csv file can have multiple names that are the same, and also have multiple values assigned to some of them that are identical.

It just can't have the same "GrayScale Color" doing different things, as far as I know, but I have never tried it.

davinci

Hi Dav.
I'm 100% new to the game pathfinding's insights.
Please excuse my ignorance, first of all.
Just a question...
How could the game mark the (contiguous) road pixels as "SKD_ROAD" features for e.g. the AI's FindClosestFeature function?
It marks the ones with the best movement modifier values?
Or every table entry is considered as road below a defined grayscale value threshold (say 10)?
Or just the first N entries in the terrain table brush?
Thanks anybody for clarifying.

I'm under the impression the road pathing doesn't use A* at all.
Just seek for the closest road feature for start pos and goal pos.
And following the grayscale's road pixels, sample path locations (probably smoothing that a bit before) to connect both extremes.

I guess the grayscale_25 pixels should automatically trigger the same road pathing process, but only once a unit falls above any of them. That could explain why units set to move forward but on the opposite bank, tends to slide along both rivers edges, no?

I spotted a true A* algorithm inside CHex::BuildPath, on the other hand.
This is called every time you fire a move command, for example.
But I could not make a sense of the implementation so far.
Seems it can't pick the intermediate steps for the cheapest ai-hex-tiles path, returning in most of cases just goal and destination to the waypoints list instead.
The heuristics is defined as...
v.xy = abs(xy-goal.xy).
1) 141 * v.x;
2) 41 * v.x + 100 * v.y;
3) 41 * v.y + 100 * v.x;
Depending on comparison between v.x and x.y.
The added cost of visiting a tile also looks strangely fixed (141 or 100 if matching previous node's xy).
I see also some checks on collision objects there and probably something related to the unit "killbox" too (to avoid blocking lines of fires).
If only this piece of code could work upon effective ground moving costs and do not visit impassable tiles like water bodies at all...
Still a long way left for me to understand this system thoroughly, anyway.

Ciao.