DAMN-NAM v.5 9/09/13
I have replaced this first post as I am now posting the revisions on the STEX. I have included a link to the download here instead of maintaining this post as well as the STEX file.
http://community.simtropolis.com/files/file/28943-damn-nam/
What's New in Version .5 (See full changelog)
## V.5
-- Added root menu's for use with new damncontrol.dat. See the readme for install location. (Only works with SSP Tool and DAMN Manager)
-- Added images and descriptions for the following menus
FLUPs
Draggable GLR
Draggable GLR Alternate Texture
El-Rail Dual Network
High El-Rail
GLR
Tram Tunnel under various Pieces
Tram-in-Street
Tram-in-Avenue
Tram-in-Road
Tram-on-Road and Texture variations
GHSR (Ground High Speed Rail)
HSR (High Speed Rail)
Monorail Curves
Monorail - High Monorail
Ped Mall
Street Diagonal Helpers
SAM (Street Addon Mod)
Basic TuLEPs
Triple-Tile NWM TuLEPs
-- Renamed all dual network tram items to Tram-In-[Network]
-- Renamed Wide Radius Curves in many menus to simply curves
-- Rearranged curves menus for avenues, roads and streets so the correct curves appear first in the list
-- Renamed L2 Curves in the Rail menu to simply curves because they are not elevated
-- Removed Diagonal Bridge enabler menu since its only active when the mod is enabled and in these cases use the menu
-- Removed Hole Digger Lots from the DAMN menu as it feels better fit in the game menu's.
-- Maybe some other stuff I forgot? There were a lot of additions.
Welcome to SC4D :)
I think that the DAMN system works for buildings and lots, not for transit puzzles pieces.
As long as a given NAM piece has a 4-digit HID in its RUL0 RotationRing entry (which most do), it is actually possible to DAMN it. The IID you'd reference would be 0x6A47####, where #### is the 4-digit HID.
We've known about this since the DAMN came out (daeley was very active on the NAM Team back then), and it's been discussed on numerous occasions, but the reason it's never happened is because of the sheer magnitude--there would be literally thousands of pieces we'd have to catalog. It'd be especially prohibitive if we were to make icons for each piece, as tends to be the case for the existing DAMN sets.
-Alex
Well I started working on this tonight and am working on rewriting the RUL file for sectioning to be split into seperate files using a powershell script. Next passing the individual .RUL files to DAMM Manager imported into numericly ordered folder's for organization. Then I can easily go through in game and screenshot each piece as they will follow a logical order (possibly automating the screenshot naming and folder placement). After that I can begin to rename some DAMN menu entries and possibly remove descriptions or add a category description for the DAMN section (tab rings). It doesn't seem like this should take too long i'll let you know my progress.
Sounds very promising! As for splitting the RUL file, you can also find a copy of the controller [here] (https://github.com/BluelightningSC4/Network-Addon-Mod/tree/master/Controller/RUL0) which has been split up into logical chunks and also happens to be most up-to-date.
Update:
I currently have the script created to be functional to create seperate .RUL files for each tabring. I am working on finding a way to automate the rendering of the .3DS files to create the thumbnails for the DAMN menu's for easier navigation. The basic functionality is already working fine and I have a set of DAMN menu's (minus PNG images) for each tabring. Hopefully I can release some menu's for preview before the end of the day today if I have enough time to work on this at work ;)
Is there a batch S3D to 3DS converter? I am trying to think of an efficient way to generate the thumbnails for the DAMN menu items. I envision converting all the 3SD files the 3DS then using renderscript or such to render individual images of each model for the thumbnails. I am not sure if this is feasible and I may be wasting more time trying to find a way to automate this then actually just taking in game screenshots of each puzzle piece...
I don't know of any way to do that. Maybe you can get the PIMX to generate the thumbnails, if you add prop exemplars for all the preview models first.
So it's possible? I feel like an idiot...
&ops &ops
I'll follow this topic, looks promising :)
As a person who works in IT I have learned nearly everything is possible it just might be a PITA to do it. :)
I have started taking some screenshots to extract thumbnails with photoshop as that seems the most functional way to do it since I can drop all the pieces from one menu on the map, screenshot and then pull out images to put into the menu's.
I have started the process of screenshotting all the pieces and have created the necessary batch scripts to automate the creation of the required PNG file for each entry in the DAMN. I have a question though. Is it possible to reference the RUL0 hex number to like a description file or the sorts? I just don't know where to find the description file as I know one must exist since the pieces have logical names in game. I would like to modify each of my RUL files to append the ; section with the actual name so when I reimport all the pieces they will have proper names and images to go with them as well!
Spanks in advance!
Also not sure if maybe this topic could be moved to a more appropriate location as this is no longer really a 'How-To or Tutorial' well maybe a bit of a tutorial.
Each RUL0 entry should have a line called "PlaceQueryID" referencing the IID of an LTEXT file which is the description displayed by the game. Otherwise, the PlaceQueryID is copied from another HID via the "CopyFrom". The LTEXT file is usually contained in the NAM locale file.
Ugh that does not seem like its even worth the time attempting to automate. I will just name each one individually in the RUL files I have created. Here is a quick preview of what I have the icons looking like so far. Let me know any opinions/suggestions on the thumbnails since I will be starting the majority of the rest of this late this week. Avenue's are about 100% complete, Real Highway is next up.
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FFIZhAaw.jpg&hash=c062d32b53182c6619f346151b2bb14fdc73724e)
Actually, I think it is quite easy to automate, if you want to stick with the name of the LText files. Though, if you are planning to change the description text here and there, it is easier to do it by hand.
Anyway, what you have so far looks very promising. I've once attempted it myself, but gave up before the part of creating the icons. I'm definitively looking forward to this. My only concern is that the HIDs in the RUL0 file are not set in stone and might change a bit from release to release. Fortunately though, all the HIDs have been rearranged prior to the NAM 31.1 release, so there won't be any big changes for the time being.
Quote from: memo on August 26, 2013, 07:38:19 AM
Actually, I think it is quite easy to automate, if you want to stick with the name of the LText files. Though, if you are planning to change the description text here and there, it is easier to do it by hand.
Anyway, what you have so far looks very promising. I've once attempted it myself, but gave up before the part of creating the icons. I'm definitively looking forward to this. My only concern is that the HIDs in the RUL0 file are not set in stone and might change a bit from release to release. Fortunately though, all the HIDs have been rearranged prior to the NAM 31.1 release, so there won't be any big changes for the time being.
Perhaps I will look into the naming again once I get off of work today. I plan on getting the RHW screenshots and possibly the thumbnails done today. Regarding the RUL0 changes are there typically a changelog from versions that would ease the process of converting my work for the new HID entries? I am currently using the 31.2 production RUL0 file and have all images named according to thier HID entry. For example a 44x176 PNG file named 6a47920C.PNG is for the L2 RHW over road. If there is a changelog or diff file it would be relatively easy to batch process each of these named images for reimporting for the next NAM version. The screenshots are the most time consuming process by far and splitting a RUL0 file and creating the menu's with my scripts I have created takes only a couple of hours. Avoiding having to redo images for everything would be optimal. If you can think of any process changes I may want to make please let me know so I don't get too far ahead with something that will not be scale-able.
Thanks Nemo
Quote from: droric on August 26, 2013, 08:42:45 AM
Regarding the RUL0 changes are there typically a changelog from versions that would ease the process of converting my work for the new HID entries? I am currently using the 31.2 production RUL0 file and have all images named according to thier HID entry. For example a 44x176 PNG file named 6a47920C.PNG is for the L2 RHW over road. If there is a changelog or diff file it would be relatively easy to batch process each of these named images for reimporting for the next NAM version. The screenshots are the most time consuming process by far and splitting a RUL0 file and creating the menu's with my scripts I have created takes only a couple of hours. Avoiding having to redo images for everything would be optimal. If you can think of any process changes I may want to make please let me know so I don't get too far ahead with something that will not be scale-able.
Usually, there isn't any changelog listing changes to the HIDs, as it's never been necessary. However, we maintain a copy of the latest controller at GitHub (https://github.com/bluelightningsc4/network-addon-mod). If you are familiar with git, it is easy to view the differences between the current version and the latest release of the controller which I have just tagged.
Anyway, don't worry too much about changes of HIDs. As I said, the big change is over, and I would not expect many modifications from now on. Redoing the images will never be necessary, but maybe adapting one or two names. Also, if you complete this project, it is a very good reason for the NAM team to consider not changing any HIDs anymore, at all, in my opinion.
As for new puzzle pieces, which are constantly added to the NAM with each release - those will be obvious using SSP tool.
Very well deserved Karma point!
For anyone who might be interested
Well I've found way to automate my entire image capture procedure. I simply need to plop all the pieces and then take a screenshot after that its into Photoshop to have batch actions ran against it. A selection is made then auctioned on with a batch action and it automatically resizes, changes canvas size, moves the image and saves a PNG file. Then onto the next piece.
I do have a question for the NAM team though... Although I think you might have already answered this question as not possible but figured id ask anyways. There are certain pieces that contain a 5 place hex HID instead of the normal 4 place HEX identifier. The pieces that have a 5 digit hex value cannot be selected within the DAMN in the game although they do display properly. I am going to go ahead and screenshot all of these pieces anyways in hopes that there may be a change that can be made to the RUL0 to make it compatible or a change to the DAMN LUA scripts if thats possible. Here is a section that i'm doing that has alot of 5 digit hex HIDs.
https://github.com/BluelightningSC4/Network-Addon-Mod/blob/master/Controller/RUL0/5000_RHW/5F00_FARHW/5F20_FARHW_Curves.txt
I think the solution for those pieces is going to be to change them to 4-digit HIDs. A few developers decided to use all 5+-digit HIDs for some pieces to save room, thinking that DAMN for NAM was unlikely to ever happen. But now it has--my metaphorical hat is definitely off to you for making this pipe dream become a reality. :thumbsup:
-Alex
So.... How long could a project like that take? Changing to 4-digit HID's ... ::)
It's definitely doable by some point in the NAM 32 development cycle.
-Alex
See there's this problem. When importing the menu's with no images attached 4-digit 5-digit make no difference, except the piece is unploppable.
Today I started importing RHW images. I ran into an issue where importing a RUL file with images results in only a portion of the actual entries due to entries with a 5-digit rul have a 0x00000000 network entry and won't import since there isn't an image associated with them. Actually I just solved part of my problem :D I can drop a placeholder 00000000.png dummy file. (imports without a dummy file were problematic since its missing 5-digit pieces).
Well anyways it's good to hear that 4-digit RUL's are a possibility for the next NAM. As long as the ordering of pieces doesn't change much in the RUL file I can account for the eventual renaming by keeping the raw numerically formatted entries. I am using a script to rename images from the split up RUL files based on the order they currently appear. New pieces can always be easily added individually down the line as they come in with new revisions.
Exhibit A
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FOAIVOUw.jpg&hash=18aa524707cb249e09d49f8ed42f3fabbc00533a)
Quote from: memo on August 26, 2013, 07:38:19 AM
Actually, I think it is quite easy to automate, if you want to stick with the name of the LText files. Though, if you are planning to change the description text here and there, it is easier to do it by hand.
Anyway, what you have so far looks very promising. I've once attempted it myself, but gave up before the part of creating the icons. I'm definitively looking forward to this. My only concern is that the HIDs in the RUL0 file are not set in stone and might change a bit from release to release. Fortunately though, all the HIDs have been rearranged prior to the NAM 31.1 release, so there won't be any big changes for the time being.
How would one go about doing something like that? Running into alot of cosmetic pieces that are not named in an easily readable way from the entry in the rul file.
Quote from: droric on August 26, 2013, 08:43:19 PM
Quote from: memo on August 26, 2013, 07:38:19 AM
Actually, I think it is quite easy to automate, if you want to stick with the name of the LText files. Though, if you are planning to change the description text here and there, it is easier to do it by hand.
Anyway, what you have so far looks very promising. I've once attempted it myself, but gave up before the part of creating the icons. I'm definitively looking forward to this. My only concern is that the HIDs in the RUL0 file are not set in stone and might change a bit from release to release. Fortunately though, all the HIDs have been rearranged prior to the NAM 31.1 release, so there won't be any big changes for the time being.
How would one go about doing something like that? Running into alot of cosmetic pieces that are not named in an easily readable way from the entry in the rul file.
Well, there wouldn't be any way around scanning the RUL0 file. In each HID section, you would look for the PlaceQueryID. There are several ways to obtain the LText-text from the IID. For one, you could use the Reader to export all the LTexts from the NAM Locale file to your file system and read those files to update your RUL0. Alternatively, you could use
CasperVG's [SC4LTEXTool] (http://sc4devotion.com/forums/index.php?topic=15680.msg454071#msg454071) to export the texts to XML, if it is easier to process.
If you are fond of Java, you could directly load the dat files using one of the Java libraries [one] (http://sourceforge.net/projects/sc4dbpf4j/) or [two] (https://github.com/memo33/jdbpfx). Though, I am biased. For instance, using the latter, you could initialize a DBPF file like this
File inputFile = new File("the path goes here");
DBPFFile dbpfFile = DBPFFile.Reader.read(inputFile);
and get the text from the placeQueryID, if it is contained in the file:
private final long queryGID = 0x2a592fd1L;
String getText(long queryIID) {
DBPFTGI tgi = new DBPFTGI(DBPFTGI.LTEXT.getType(), queryGID, queryIID);
DirectDBPFEntry entry = dbpfFile.getEntry(tgi);
if (entry != null) {
DBPFLText ltext = entry.createLTEXT();
return ltext == null ? null : ltext.getString();
} else {
return null;
}
}
Quote from: memo on August 27, 2013, 12:19:07 AM
Quote from: droric on August 26, 2013, 08:43:19 PM
Quote from: memo on August 26, 2013, 07:38:19 AM
Actually, I think it is quite easy to automate, if you want to stick with the name of the LText files. Though, if you are planning to change the description text here and there, it is easier to do it by hand.
Anyway, what you have so far looks very promising. I've once attempted it myself, but gave up before the part of creating the icons. I'm definitively looking forward to this. My only concern is that the HIDs in the RUL0 file are not set in stone and might change a bit from release to release. Fortunately though, all the HIDs have been rearranged prior to the NAM 31.1 release, so there won't be any big changes for the time being.
How would one go about doing something like that? Running into alot of cosmetic pieces that are not named in an easily readable way from the entry in the rul file.
Well, there wouldn't be any way around scanning the RUL0 file. In each HID section, you would look for the PlaceQueryID. There are several ways to obtain the LText-text from the IID. For one, you could use the Reader to export all the LTexts from the NAM Locale file to your file system and read those files to update your RUL0. Alternatively, you could use CasperVG's [SC4LTEXTool] (http://sc4devotion.com/forums/index.php?topic=15680.msg454071#msg454071) to export the texts to XML, if it is easier to process.
If you are fond of Java, you could directly load the dat files using one of the Java libraries [one] (http://sourceforge.net/projects/sc4dbpf4j/) or [two] (https://github.com/memo33/jdbpfx). Though, I am biased. For instance, using the latter, you could initialize a DBPF file like this
File inputFile = new File("the path goes here");
DBPFFile dbpfFile = DBPFFile.Reader.read(inputFile);
and get the text from the placeQueryID, if it is contained in the file:
private final long queryGID = 0x2a592fd1L;
String getText(long queryIID) {
DBPFTGI tgi = new DBPFTGI(DBPFTGI.LTEXT.getType(), queryGID, queryIID);
DirectDBPFEntry entry = dbpfFile.getEntry(tgi);
if (entry != null) {
DBPFLText ltext = entry.createLTEXT();
return ltext == null ? null : ltext.getString();
} else {
return null;
}
}
Unfortunately I do not know java or really any 'real' programming languages. I do all my file and text automation using powershell and regex. Now this isn't really an issue as I have identified a method to query the RUL and find the PlaceQueryID. The issue is that when using reader to export the ltext files they are in one of two formats.
file00000001.lng - Exported using save selected files (these are in binary and not decoded therefore not usable by a regex query)
file_dec00006327.lng - Exported using save decoded files (these files do not contain the instance ID as far as I can see.)
Any idea how I can identify the exported files? I may be exporting them incorrectly.
Actually there are LNG.TGI files that are exported as well that contain the necessary information so if there isn't an easy other way to export them I suppose I can rename the LNG file using the TGI files. One other question is there a reason for the invalid characters that display at the beginning of the LTEXT file (when saving a decoded file). Is this needed for the description to appear properly or should I just filter and only capture a-z characters?
Quote from: droric on August 27, 2013, 01:58:45 PM
One other question is there a reason for the invalid characters that display at the beginning of the LTEXT file (when saving a decoded file). Is this needed for the description to appear properly or should I just filter and only capture a-z characters?
The reason for this is that the Reader exports the LText raw byte data. The LText format defines a 4 byte header, the first two bytes of which determine the length of the following text. By chance, the length might represent a valid character, so instead of filtering for a-z, you would just skip the first 4 bytes.
Quote from: memo on August 25, 2013, 09:09:58 AM
Each RUL0 entry should have a line called "PlaceQueryID" referencing the IID of an LTEXT file which is the description displayed by the game. Otherwise, the PlaceQueryID is copied from another HID via the "CopyFrom". The LTEXT file is usually contained in the NAM locale file.
Is this an instance of a "CopyFrom" scenario? This and a few others are coming up as not found when running my scripts. I don't see this IID in the NAM_Locale_english.dat file.
[HighwayIntersectionInfo_0x00005FE4]
;Created by MandelSoft on 2013/05/21
;RHW-10S Ramp Type C3 - Exit Ramp
Piece = 0.0, 0.0, 0, 0, 0x5E192605
PreviewEffect = preview_rhw10s_ramp_c3_01
CellLayout =...........
CellLayout =.....AC....
CellLayout =.....XX...<
CellLayout =.....XX....
CellLayout =.....XX....
CellLayout =......X....
CellLayout =......X....
CellLayout =......D....
CellLayout =.....^.....
CheckType = A - dirtroad: 0x02000200 OneWayRoad: 0x03000003, 0xffffffff optional
CheckType = C - dirtroad: 0x02000200 Road: 0x01000001, 0xffffffff optional
CheckType = D - dirtroad: 0x02000200 Road: 0x01030003, 0xffffffff optional
CheckType = X - dirtroad: 0x02000200
ConsLayout =...........
ConsLayout =...........
ConsLayout =.....||...<
ConsLayout =.....||....
ConsLayout =.....||....
ConsLayout =......|....
ConsLayout =......|....
ConsLayout =...........
ConsLayout =.....^.....
AutoTileBase = 0x5E192600
PlaceQueryID = 0x5E192600
Costs = 400
Other than that I have all the relative stuff done, took me like 3 hours but im still learning scripting. I am hoping to complete the RHW section of the DAMN-NAM by the end of this week/weekend which will mark a large step forward in the project since most all automation aspects are now in place. For who might be interested here is the powershell code used to relate the file dumped from reader to the RUL entries. It relies on a HIDS.txt which is the 4-6 digit HID entry from the RUL file (I pulled these manually).
To harvest the names from the ltext files from reader.
$IIDs = (Get-Content *.lng.TGI)
$files = (Get-childitem *.lng)
$IIDfile = (Get-childitem *.lng.tgi)
$a = 4
$b = 0
$files | foreach-object {
ren $_ (($iidfile[$b] | get-content)[4] + ".txt")
del $IIDfile[$b]
$a += 5
$b += 1
}
$b = 0
$files = (dir *.txt)
$files | foreach {
$z = ((get-content $_ -raw -encoding unicode)).remove('0','2')
$z | out-file $_
$b += 1
}
Sleep 10
And to relate the HID entries to the names from the previous scripts output.
$file = (get-content hids.txt)
$rul = [io.file]::ReadAllText("D:\Desktop\SC4 Stuffs\NAM DAMN Menu Proj\V.1\SplitRUL.rul")
$file | foreach { $_.padleft('8','0') | foreach {
$rul | Select-String "(?smi)\[HighwayIntersectionInfo_0x$_\](.*?)\[HighwayIntersectionInfo_0x\w\w\w\w\w\w\w\w\]" -AllMatches | Foreach {$_.Matches} | Foreach {$_.Value}
}
} | Out-File matcher.txt
$file = (get-content matcher.txt)
$HIDS = ($file | select-string 'PlaceQueryID \= 0x\w\w\w\w\w\w\w\w').matches.value.replace('PlaceQueryID = 0x','')
$HIDS | Foreach {
(Get-Content "D:\Desktop\SC4 Stuffs\NAM DAMN Menu Proj\V.4\IIDs\$_.txt")
} | Out-File Names.txt
Sleep 10
Quote from: droric on August 27, 2013, 07:31:23 PM
Is this an instance of a "CopyFrom" scenario? This and a few others are coming up as not found when running my scripts. I don't see this IID in the NAM_Locale_english.dat file.
No, it is not. The PlaceQueryID is 0x5e192600. For whatever reason, it is contained in the "RealHighway_FractionalAngleNetworking.dat" and says "RHW-10S Exit Ramp Style C3". Those LTexts should be moved to the locale files, actually. The simplest thing to get around this for you is to datpack the entire NAM, then sort by GID and IID and copy the English LText files.
Quote from: memo on August 28, 2013, 12:04:29 AM
Quote from: droric on August 27, 2013, 07:31:23 PM
Is this an instance of a "CopyFrom" scenario? This and a few others are coming up as not found when running my scripts. I don't see this IID in the NAM_Locale_english.dat file.
No, it is not. The PlaceQueryID is 0x5e192600. For whatever reason, it is contained in the "RealHighway_FractionalAngleNetworking.dat" and says "RHW-10S Exit Ramp Style C3". Those LTexts should be moved to the locale files, actually. The simplest thing to get around this for you is to datpack the entire NAM, then sort by GID and IID and copy the English LText files.
Okay that part is solved I now have a proper names list for each entry. I did notice a few entries that show up in game as '## Invalid Intersection Placement ##' or such and I am accounting for them as "Description Missing". Here is one example.
[HighwayIntersectionInfo_0x00005FC0]
;Added by SA 02/18/2011
;RHW-6S Ramp Type E - Exit Ramp
Piece = 0.0, 0.0, 0, 0, 0x5e151005
PreviewEffect = preview_rhw6_ramptype_e_001
CellLayout =...........
CellLayout =.....Y.....
CellLayout =....+A....<
CellLayout =....+A.....
CellLayout =....+A.....
CellLayout =.....A.....
CellLayout =.....Y.....
CellLayout =.....^.....
CheckType = Y - dirtroad: 0x02000200 Road: 0x01030003, 0xffffffff optional
CheckType = A - dirtroad: 0x02000200
ConsLayout =...........
ConsLayout =...........
ConsLayout =....+|....<
ConsLayout =....+|.....
ConsLayout =....+|.....
ConsLayout =.....|.....
ConsLayout =...........
ConsLayout =.....^.....
AutoTileBase = 0x5e151000
ReplacementIntersection = 0, 0
PlaceQueryID = 0x5e151000
Costs = 410
Again much thanks to the NAM team for helping me understand all of the intricacies of the NAM structure!
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FrzArfNt.jpg&hash=0bc7ce9a01712ca7ea6dc793b52bb63d44c655d6)
Bonus question - Can anyone thing of a way to fill in the size information for puzzle pieces?
Also noticed that 0x00085066 appears twice in the RUL0 e-series RHD controller. Is this on purpose?
Oh yea... and the RHW section is now 100% finished. ;D
http://community.simtropolis.com/files/file/28943-damn-nam/
Hello
I was gonna try to implement adding NAM pieces in my DAMN Manager (without any user info about network IIDs and such) but parsing RUL file is more tedious than I anticipated :/
There is no real pattern by which automation can be done without human touch (ATM I didn't find one) :/
There are many inconsistencies like:
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; CANAL PUZZLE PIECES ;
; CANAL PUZZLE PIECES ;
; CANAL PUZZLE PIECES ;
; 0x01##
RotationRing=
and there are some entries like:
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;RAIL ADDON MOD (RAM) BUTTON SECTION
;RAIL ADDON MOD (RAM) BUTTON SECTION
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;RAIL ADDON MOD (RAM) BUTTON SECTION
;RAIL ADDON MOD (RAM) BUTTON SECTION
;RAM Set1 - Single Track Railroad (STR) button
RotationRing=
and now try to parse this :P
Quote from: Yild on April 13, 2014, 12:20:18 PM
Hello
I was gonna try to implement adding NAM pieces in my DAMN Manager (without any user info about network IIDs and such) but parsing RUL file is more tedious than I anticipated :/
There is no real pattern by which automation can be done without human touch (ATM I didn't find one) :/
There are many inconsistencies like:
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; CANAL PUZZLE PIECES ;
; CANAL PUZZLE PIECES ;
; CANAL PUZZLE PIECES ;
; 0x01##
RotationRing=
and there are some entries like:
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;RAIL ADDON MOD (RAM) BUTTON SECTION
;RAIL ADDON MOD (RAM) BUTTON SECTION
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;RAIL ADDON MOD (RAM) BUTTON SECTION
;RAIL ADDON MOD (RAM) BUTTON SECTION
;RAM Set1 - Single Track Railroad (STR) button
RotationRing=
and now try to parse this :P
I used powershell and regular expressions to parse the RUL files. I ended up adding section start and end flags to split the rul file up into sections to make it easier to categorize.
ok, I managed to parse this ***, gather ltext entries for corresponding puzzle pieces, an I have found something odd...
why there is no info for entries like 0x0504 -0x0516 (advenced tuleps) and many more (GLR-IN-ROAD bridge puzzle pieces, RAM -FARR-2-3 CROSSINGS BUTTON SECTION
and so on) ?
I searched for any instance of exemplar 0x6a47, AutoTileBase or by Piece value - it seams that those pieces ware 'abandoned'?
any info would be appreciated
The descriptions on the lines in the RUL file do not necessarily properly describe the piece. I used another script to pull all of the LTEXT data for the pieces and import them into my split RUL files to add descriptions. If the entry in the RUL file starts with a semicolon it means it is commented out and should be ignored.
Are you saying your RUL entry doesn't contain entries for 0x0504-0x0516? If your using the NAM 32 you may need to reinstall and ensure you install all of the components since with NAM 32 brought a compiled RUL file customized to the users needs.
This is what my Advanced Tuleps section looks like
AddTypes = 0517, 10517, 20517, 30517, 40517, 50517, 60517, 70517, 80517, 90517, A0517, B0517, C0517, D0517, E0517, F0517 ;Road Type 210/210 Blank Lane
AddTypes = 0518, 10518, 20518, 30518, 40518, 50518, 60518, 70518, 80518, 90518, A0518, B0518, C0518, D0518, E0518, F0518 ;Road Type 210 Transitions
AddTypes = 0519, 10519, 20519, 30519, 40519, 50519, 60519, 70519, 80519, 90519, A0519, B0519, C0519, D0519, E0519, F0519 ;Road Type 210/Avenue Type 120 +
AddTypes = 0515, 10515, 20515, 30515, 40515, 50515, 60515, 70515, 80515, 90515, A0515, B0515, C0515, D0515, E0515, F0515 ;OWR Base Intersection 1 (4 OWR +)
AddTypes = 0516, 10516, 20516, 30516, 40516, 50516, 60516, 70516, 80516, 90516, A0516, B0516, C0516, D0516, E0516, F0516 ;OWR Base Intersection 1 (2 OWR/2 Road +)
Quote from: Yild on April 17, 2014, 11:40:44 AM
ok, I managed to parse this ***, gather ltext entries for corresponding puzzle pieces, an I have found something odd...
why there is no info for entries like 0x0504 -0x0516 (advenced tuleps) and many more (GLR-IN-ROAD bridge puzzle pieces, RAM -FARR-2-3 CROSSINGS BUTTON SECTION
and so on) ?
That's because the file has a long history. There are a few button sections in there that are not currently in use. Some of them have been used before and others have never been publicly released. Nothing to worry about; just ignore the buttons that you've never seen in the game. ;)
sorry to say that but you are explaining basics - my nam is installed with full available options (nam 32), rul0 file is original
after retrieving info for 0x0500 i have (debug info):
0500 2 Road Type A-Transition Road TuLEP-Type A/Base Network Transition Road TuLEP-Type A/Base Network Transition (Rotate for T-End) | NO_DESC_ITEM_DESCRIPTION_KEY
0501 2 0 Road Type AX Road TuLEP-Type A1 Road TuLEP-Type A1 (Rotate for A2) | NO_DESC_ITEM_DESCRIPTION_KEY
0502 2 1 Road Type AT Road TuLEP-Type A2 Road TuLEP-Type A2 (Rotate for A1) | NO_DESC_ITEM_DESCRIPTION_KEY
0503 2 2 Road Type B-Transition Road TuLEP-Type A0 Road TuLEP-Type A-Blank (Rotate for Dashed) | NO_DESC_ITEM_DESCRIPTION_KEY
0504 2 3 Road Type BX |
...
0516 2 24 OWR Base Intersection 1 (2 OWR/2 Road +) |
second and third columns are my loop iterations counters, fourth - comment from rul0 file, fifth is exemplar name (from piece exemplar entry), sixth and seventh info from ltext files
in this example from 0504 to 0516 info are missing through not finding exemplars for those entries as mentioned in previous post, after checking your DAMN files there is no entries for 0500 branch either (or I couldn't find them in TULEPs folders)
I pulled the advanced tuleps from the DAMN-NAM release but can't seem to remember the exact reason why. I will try to remember to take a look at this later today.
Unfortunately I do not have a list of all the sections I pulled as documentation has never been a strong point. I pulled out certain entries if they were either redundant or did not work. This was all a manual process where I would complete a menu section then go in game to test everything. What do you look to implement in the DAMN Manager? I am not sure if you saw but I have released the DAMN-NAM V1.0 over at simtropolis which contains all the menu items with images and root menus except for Project Symphony, Hole Diggers, Maxis Highways and Canals.
eh... :P
I was missing hole diggers/risers in Your menus so i was gonna try to pull those info by myself and in addition all available items, atm I can make icons without ingame screenshots... just point me to 3DM file (that code was implemented in my unfinished project but it works just fine)
Your project is manual work ( respect ;) ) - if anything change in puzzles you will have to modify this manually... ;)
But in other hand if there's a mess like the one that I was pointing at... i don't have any chance to do all your work by code (there's to many unknown/nuances to code and be 100% sure the output is correct).
I plan on updating the whole thing once the HIDS have been changed to use all 4 digit identifiers since the 5 digit items will not work the DAMN. I burned myself out a bit when I did this so I am taking a break on this project until we can get the HIDS values taken care of. All of the 'placeholder' images you see I already have images for but due to the technical limitations currently with the HIDS I can't use them or even select that piece. I will probably add in all the missing pieces I excluded from the release when I do update it.
I probably wouldn't have been able to get all of this done without your app so im glad you are getting some use out of the menu's I made. The SSP Tool just isn't as reliable as the DAMN Manager is and it had issues handling so many pieces.