Slitherine

I am wanting to limit what units the player can purchase to a small amount of units for a historical scenario I'm working on.

As far as I can tell...
Edit > Scenario Params > Players > Advanced Options
at the bottom of advanced options there is an empty field for "Custom purchase list". Hovering over the help icon says "references a row in TypeLists.csv"

I opened up TypeLists.csv in OpenOffice (forgot I even had something to open spreadsheets tbh) and I see 13 rows dealing with Romania1, Russia1, TestList, the 6 Tutorials and also the Crete and Bohemia (poland) scenarios.

I'm assuming I make a new list with proper unit names and put it on a line I desire in TypeLists.csv. Then I go back to the editor and reference the line simply as 13 or 99 or whatever... but this raises a few more thoughts & questions...

What if two scenario designers use the same row in TypeLists? Will people just always be overwriting the TypeLists.csv all the time and dealing with conflicts? Ie "breaking" one scenario because you "installed" a new scenario which required the over writing of TypeLists?

Additionally, while I'm viewing the unit list in OpenOffice the format appears to be (unitname, unitname) on some of the scenarios rows while others are (unitname,unitname,unitname). This leads me to believe the comma is what is important and not the space. However, this might be an issue with OpenOffice so I'm not sure. another thing I notice is the unitnamesneverhavespaces. If I'm wrong with any of these observations please tell me. I might need to play with OpenOffice more or use a different program.

Thanks for any help. I can't wait to get some scenarios out for the community.

Well I just tried a few different things while editing TypeLists.csv. It just breaks the game and no units show up in the buy section. Of course I backed up the file before I gave it a go. ...standing by to stand by.

I should state that the conflict issue isn't a conflict. The reference to the "row" is not the number in the TypeList but the TITLE to the far left of the column. Figured this out by opening Crete scenario. Anyways, still not working with the word I used after I added my row and such, following the exact same format as what I can see... so I have the feeling this "openoffice" software isn't reading or writing properly.

Try making new scenario and use one of the existing custom lists to see is it working for you.
As you figured it out by looking at existing scenarios in Global Parameters > Purchasable Units set it to Custom list.
Under Players > Custom purchase list write the name of the custom list as you see it in TypeLists.csv.

Names of units in the list are actually Unit IDs and they can be different from names you see in the game UI.
Modify the existing custom list with new units and make sure Unit IDs are copied correctly from other files. They are under name if you are using Units.csv or PzC2 ID if you are using equipment.pzeqp file. This way you will eliminate the problem is not in using incorrect IDs.

If this doesn't work than it is safe to guess the problem is with saving file format.

Thanks. I will check the unit ID's proper and get a new program to work with .csv's tmro.

EDIT: I was using the proper ID's actually. I did the test by using the "crete1" and "bohemia" unit lists and they worked properly, so OpenOffice has some formatting issue.

I have a new program and everything is going ok. At some point my TypeLists started crashing the game. I pin-pointed this fairly quickly. It is the 2cmFlaK38AA and 2cmFlaK38AT. I understand the unit has two distinct game state modes. However it is unclear which should be used in TypeLists. I tried them both together and separately, and the game always crashes. When I remove it from the list the game is fine and the rest of my list functions as it should.

Almost there...

NETSCAPE wrote: ↑Sat Apr 18, 2020 1:27 am At some point my TypeLists started crashing the game. I pin-pointed this fairly quickly. It is the 2cmFlaK38AA and 2cmFlaK38AT. I understand the unit has two distinct game state modes. However it is unclear which should be used in TypeLists. I tried them both together and separately, and the game always crashes. When I remove it from the list the game is fine and the rest of my list functions as it should.

I tested it myself and cannot confirm the crash. Scenario loads properly for me. When switcher units (like AA to AT) are in the game by default only the primary model will be available for purchase. When you use the custom list any of them will appear in purchase screen. If you use both, both will appear in the purchase screen in their respective class.

uran21 wrote: ↑Sat Apr 18, 2020 6:19 am When switcher units (like AA to AT) are in the game by default only the primary model will be available for purchase. When you use the custom list any of them will appear in purchase screen. If you use both, both will appear in the purchase screen in their respective class.

Interesting. If this is so, shouldn't the non-primary models of switchable units be removed from "Romania1" and "Russia1" in TypeLists.csv (for the "Maresal at War" MP scenario)? Like the AT modes of Romanian AA guns? Or is this WAD?

I should state that I put 2cmFlaK38AA at the end of my rather short unit type list and for some reason it doesn't crash the game. So everything is working properly now.

Cortilein wrote: ↑Sat Apr 18, 2020 11:04 am

uran21 wrote: ↑Sat Apr 18, 2020 6:19 am When switcher units (like AA to AT) are in the game by default only the primary model will be available for purchase. When you use the custom list any of them will appear in purchase screen. If you use both, both will appear in the purchase screen in their respective class.

Interesting. If this is so, shouldn't the non-primary models of switchable units be removed from "Romania1" and "Russia1" in TypeLists.csv (for the "Maresal at War" MP scenario)? Like the AT modes of Romanian AA guns? Or is this WAD?

I don't know is this WAD but technically there is no need for non-primary models to be in purchase list since switching can be done before unit deployment. The only advantage is stats comparison with units of the same class if non-primary model is of high interest to the player.

Was this issue ever resolved? i'm creating a new TypeList.csv, do i save it in the campaign folder? or do i save it in the Original /Content/Data folder

also i'm getting a blank shop, im 90% certain im using the correct IDs because i copied them from the Equipment file

is OpenOffice the issue when it comes to saving the format?

WookieeDavidson wrote: ↑Wed May 06, 2020 10:39 am Was this issue ever resolved? i'm creating a new TypeList.csv, do i save it in the campaign folder? or do i save it in the Original /Content/Data folder

also i'm getting a blank shop, im 90% certain im using the correct IDs because i copied them from the Equipment file

is OpenOffice the issue when it comes to saving the format?

Hi Wookie, you would have to replace the file in the /Content/Data folder (while keeping a backup of the original file, of course). It's working for me, I am using Notepad++ for editing. The character encoding should be left alone (which is Unicode UTF-16, I suppose).

The problem here is that - at least AFAIK - that modders cannot "append" additional lines to the file without editing the original. Take the Cholm scenario created by user NETSCAPE, for example: He has added a dedicated new entry/line to TypeLists.csv for that particular scenario in order to restrict available unit types. Unless you kind of "collect" all those custom lines in the TypeList.csv, they might get overwritten/deleted by the next official patch/update. That would be a particular problem if you use the Steam version of the game (like I do), as you cannot really prevent updates overwriting files for good, if they are officially replaced by newer versions. So you should always keep multiple backups.

Once we (hopefully) get some extended modding capability and/or tools, that procedure would be less finicky. In your case, it might be a problem that arises from the character encoding – or even a simple character too much or too few.

The game, in its current state, is rather "unforgiving" with respect to debugging capabilities. Take the Units.csv, for example: If you have a unit with a single trait [e.g. (Overrun)], and you feel like adding a second trait [e.g. (Overrun,MachineGun)] the game would crash on loading the scenario list unless you enclose the whole trait entry in parentheses [e.g. "(Overrun,MachineGun)"]. The same is true if you want to grant a particular unit to additional faction(s), like changing (DE) to (DE,CL). Here, you would have to remember adding the parentheses as well, so that it reads "(DE,CL)" - otherwise, the game would crash just because of those two missing characters. A possible workaround would be to ALWAYS include those parentheses at those particular entries, even if they are not needed.

So - some kind of automatic, internal debugging functionality for modded text/csv files included in the game's engine would indeed be highly desirable...

Cortilein wrote: ↑Wed May 06, 2020 2:57 pm So - some kind of automatic, internal debugging functionality for modded text/csv files included in the game's engine would indeed be highly desirable...

Uran21 the Dev who handles the Unit list uses equipment.pzeqp not Units.csv to edit unit parameters.

In PzC1 modded files would be included in the Data folder of the mod [or DLC].
This allowed the GC to have different Hero thresholds from the standalone campaigns.
I assume it will be the similar for PzC2.

In an early Beta on the 'Start New Game' splash screen there was a 'Mod' option to go with 'Campaign' and 'Scenario'.
I believe they dropped it to concentrate on the main game and campaign.
The next big issue is multiplayer, once that is resolved modding[ ].

I expect end of May or start of June for shifting to the modding issues.

dalfrede wrote: ↑Wed May 06, 2020 4:07 pm Uran21 the Dev who handles the Unit list uses equipment.pzeqp not Units.csv to edit unit parameters.

Yeah, thanks for the heads-up, dalfrede. I have run into some issues yet by editing the Unis.csv file straight away and leaving the equipment.pzeqp alone already. I should have done it the other way round... On second thought, it would be nice if the "sequence" didn't matter, if we someday got kind of a ("grep"-based?) converter tool that would handle changes on one file being implemented to the other, and vice--versa. Just dreamin'...

Cortilein wrote: ↑Wed May 06, 2020 2:57 pm So - some kind of automatic, internal debugging functionality for modded text/csv files included in the game's engine would indeed be highly desirable...

There is one, sort of . . .

dalfrede wrote: Two files are used:
Local Disk > Program Files(x86) > Slitherine > PanzerCorps2 > PanzerCorps2 > Content > Editor > Data > equipment.pzeqp
Local Disk > Program Files(x86) > Slitherine > PanzerCorps2 > PanzerCorps2 > Content > Data > Units.csv

The game uses Unit.csv, the Devs use equipment.pzeqp.

equipment.pzeqp is a TSV file, tab separated data. This is a modification of the same file used in PzC.
It allow comments to allow you the keep track of revisions.

In the editor: Edit > Unit Tools , this opens the ‘Unit Tools’ window.
Pushing the ‘Export to Game’ creates a new Unit.csv file.

-----------
To edit equip file
1) make a safety version.
2) Add .csv to file name - equipment.pzeqp.csv
3) Open equipment.pzeqp.csv in spreadsheet. I use LibreOffice.
Charactoer set: Unicode (UTF-16) , be just Unicode, NOT UTF-7 or UTF-8
Separator Options: Tab
4) Save in spreadsheet format of your choice. [.xls, .ods]
5) Tweak page for easy reading.

Mod away.

-----
To transfer to game.
File > Save as > Text CSV; Click on Edit filter setting
Charactoer set: Unicode (UTF-16) , be just Unicode, NOT UTF-7 or UTF-8
Field Delimiter: Tab
String Delimiter: null

Move to Editor > Data ;
remove .csv at end of name
Use editor to export to your game directory.

Note: I do all my equip file editing on my Mac Air.
You should come up with a method keeping track of your mods vs the original game set up.
EquipFile.jpg

uran21 wrote: ↑Sun Apr 19, 2020 4:16 am I don't know is this WAD but technically there is no need for non-primary models to be in purchase list since switching can be done before unit deployment. The only advantage is stats comparison with units of the same class if non-primary model is of high interest to the player.

In single scenarios that might be true, but in the campaign I disagree. Suppose you have captured a Soviet Zveroboy and want to field it as part of your artillery corps. The problem is that the Zveroboy is an AT unit, so to upgrade one of your artillery units to it you'll have to sacrifice 1000 experience. If it were available for requisition as both AT and artillery this wouldn't happen.

Dual mode units should be available as either, or the experience cost of switching class should be removed for them.

Edit: Come to think of it, captured units are available as the class you captured them as and nothing else. This doesn't make much sense either as you can still switch them while deployed.