SC4 Devotion Forum Archives

Hi all,

Lately I was thinking of a simple tool to help me reorder the items in the menus.
Actually every lot creator assings a value to "item order" and "occupant group" at its free will, and the the menus are becoming heavily scattered and "unreadable".

• 1st step would be a tool that extracts the menu-icon and name from all the lots and display them in a list together with the files from which they were extracted. This way I (and everyone else here) would have a good help to find the needed files for iLive reader to reassign a new value to "item order".
• In 2nd step this tool will be expanded so it can reodorder the items. This tool could look like a windows explorer: on the left side the menu-tree, on the right side the list with icon, name, filename of the lots in the menu-branch. The items in the list can be moved up and down (maybe also moved to another menu-branch).
  With a click on a special <Go>-button the tool writes new values to "item order" (and maybe also "occupant group") of all the lots depending on their new position in the list.

I was thinking of doing this tool myself, but with my limited knowledge in Delphi 7, it would take me a few weeks (if not months) to perform this task. But I'm sure for one of the programming-guru it wouldn't take more than 2-3 days to do this, so if one is willing to sacrifice his free time I would be grateful.
My problems in programming it myself would be on how to embed the picture in the list and program the drag-n-drop functionality (haven't done this so far). And somebody would have to provide me the knowledge to read the SC4-files or something like an SDK to read them.

Thanks
-andy33b-

A good idea indeed, especially the 2nd step with drag&drop features

Watch this space.... Wou has spoken...  :P

A program to change the item order could be very helpful, but changing the occupant group for a lot isn't enough to actually change the lot to a different RCI type, and would probably just cause more confusion than it's worth I think.
Though a program that could easily and properly change the RCI type of a lot... that could be interesting.

Quote from: Diggis
Watch this space.... Wou has spoken...  :P

Watching  ;D

also watching ::) ::)

mauricio.

/me bookmarks thread

If only I could program...

Joe

I don't think the idea is to change the RCI type of the lot, but rather what menu it shows up in.

I am not sure how to read the values of the SC4 files, or I could do this in short order.

Wish I could help you with that Becca, but maybe wou would share the info with you.

Joe

[size=0]hmmm, looks like my 700th post[/size]

I'll send a PM then.

Quote from: xxdita on February 11, 2008, 02:14:30 AM
A program to change the item order could be very helpful, but changing the occupant group for a lot isn't enough to actually change the lot to a different RCI type, and would probably just cause more confusion than it's worth I think.
Though a program that could easily and properly change the RCI type of a lot... that could be interesting.

Watching  ;D

Stupid question: does it have to be done in Delphi 7?? Or could it be done in any language (say C#, VB8, etc..)?

I guess it could be done in any language, just the OP could program in Delphi 7.

It all depends on the reading of/writing to SC4 files

Another thread for this kinda stuff:

http://sc4devotion.com/forums/index.php?topic=2198.0

Joe

Mathe Man from the SFBT once drafted a tool like this, but due to the ubiquitous RL, it never exceeded the first planning stages. But obviously, there is no need to reinvent the wheel once again, so I suppose wouanagaine could re-use quite a bit of his code for such a tool. So expect "some" suggestions once you have posted the first beta (one of them will be to make it multilingual  ;D ).

I understand the basic desire is to simplify changing the menu orders, but andy33b had also requested changing Occupant Groups, one of the steps in Creating a functional landmark. Unless the purpose is only to move the building to a different menu perhaps? Not sure that this is such a good idea though.
I would however like this program to function on more than just the landmarks menu. Hopefully it would work on all plop menus, to make organizing everything less tedious than it currently is. This would seriously help those of us that run with a way too full plugins folder.
I have absolutely no coding knowledge though, so no clue what language you'd need to use HandsOn.

Too full a plugins menus? hehe *looks around innocently"

Just one point about any language issues... be aware that the end user normally needs a "support library" and environment of some sort. This needs to be considered. That is one advantage of using whatever Wou uses (Microsoft C and DirectX I think )

I'd estimate that 70% of the support issues on Wou's tools is that people don't have the support in place (they just don't bother to read/follow the readme's).

Presuming that it would not be possible to add menu categories (otherwise someone like Wou would have already done it), the only function could be the organising according to a "most used" type of arbitrary sort. Which would definitly be helpful because SC4 seems to arrange the menus as according to the local weather everytime you add a plug-in. Which explains it in my case - the weather here mostly sucks!

Thus I premptively surmise:
Since this would not be done in-game (would not work, I think) but in a fashion similar to any of the other tools, no graphic interaction is required; all that is needed is the knowledge of how SC4 does it. Where is that information ultimately stored? In what form? I can pretty much program most things (except, alas, the girlfriend), but I don't know what I am looking at and where.

What might make sense is to create the program also as an installer: thus you assign where in a given sub-menu branch the latest jeronjii creation goes.

SO, someone tell me what's wrong with my ass-u-me rehearsal thus far?

if I recall correctly, SC4 arrange items based on item menu order, lot size and price, and someone ( Andreas ? ) need to refresh us in which order thoses 3 keys are used
As the only things that can be change is item menu order, it may lead to some impossible setup

The Order overrides everything.  I would guess price is next, and then lot size but only at a guess.

Quote from: wouanagaine on February 12, 2008, 07:28:08 AM
if I recall correctly, SC4 arrange items based on item menu order, lot size and price, and someone ( Andreas ? ) need to refresh us in which order thoses 3 keys are used
As the only things that can be change is item menu order, it may lead to some impossible setup

Mais, since plug-ins insert items into the menu, it should be possible to determine where these are inserted. I've seen park items show up in the power menu, and a recent installation of sunken highway walls rearranged the park menu in a dismal, very interupted manner.

After having changed many many lots in my menus, I have something to say about this ...  ;D

The most important value is the Item Order value. It determines the position from the lot in the menu. The valid values are from -32768 to 32768 (hexadecimal values). To second important value is the item cost, and I wasnt aware of the lot size, but never had problems about that, so I guess it is the third value.

The problem comes when you want to change the occupant group. You can change order in the same menu, and between some menus without problems, for instance, you can move lots from the parks menu to the landmarks menu without problems, and without having to change nothing but the occupant group, but in some cases you cant do this. For some menus, the lots need to have specific properties, and if they are not present, they wont show up. For instance, you can't simply move a park lot to the airport or seaport menus... you have to tweak them and add some properties for this to work. I cant be more precise, because I adapted to this situation, and I moved to where it was simple and easy, but serious experimenting about this issue should be done, prior to release any tool which may do this task.

Other that this, I fully support this idea  :thumbsup: ,specially after having manually changed several hundreds of lots  ::)

QuoteThe valid values are from -32768 to 32768 (hexadecimal values).

May I correct you? The Unit32 field tag allows for 8 hex digits (32Bits), or a number between 0 and 42949672955₁₀ or FFFFFFFF₁₆ which means that it could go between -2147483648 and 2147483648. But I may be wrong, its not like I am a computing student or anything  $%Grinno$%

Joe

I don't think that "Lot Size" will affect the menu order. As said before, the most important property is "Item Order", followed by "Plop Cost". I believe that the third one is either the lot or building exemplar ID.

Quote from: star.torturer on February 12, 2008, 09:35:01 AM
May I correct you? The Unit32 field tag allows for 8 hex digits (32Bits), or a number between 0 and 42949672955₁₀ or FFFFFFFF₁₆ which means that it could go between -2147483648 and 2147483648. But I may be wrong, its not like I am a computing student or anything  $%Grinno$%

Joe

I should have said "The valid values are from -32768 to 32768 (hexadecimal values) if I recall correctly"  ::)

Anyway, my experience says that these are the valid values  ;)

Quote from: jeronij on February 12, 2008, 09:04:36 AM...  ;D
The problem comes when you want to change the occupant group. You can change order in the same menu, and between some menus without problems, for instance, you can move lots from the parks menu to the landmarks menu without problems, and without having to change nothing but the occupant group, but in some cases you cant do this. For some menus, the lots need to have specific properties, and if they are not present, they wont show up. For instance, you can't simply move a park lot to the airport or seaport menus... you have to tweak them and add some properties for this to work.

I've always been lazy - especially when it comes to anything around computers. Thus I go for simplicity first -complexity, if it must, can come later. I still maintain that first task is to import some order. And now that we know this can be done, can someone tell me where I have to look if I want to do it - manually or programmatically? Changing the occupant group seems a - remote - secondary issue.. ()what()

Every building exemplar has a property called Item Order. Iy may be present or not. If it is not present, you can add it by rigth clicking on the exemplar properties list (rigth side of the Reader screen) and selecting Add property. If you double click on the property you will open it and you can modify the value there. If you use the bottom field of the Exemplar Edit screen, you can introduce the decimal value, and when you hit Apply, the Reader will change it to the appropriated Hex value.

Programatically speaking.... no clue at all  $%Grinno$%

DONT BELIEVE THIS WITHOUT CONFIRMATION FROM SOMEONE ELSE:

The "record" in the sc4 file is referenced by its own ID called Instance, and the "record" type that you want is compound by Type: 0x6534284A and Group: 0xAD4BA465. The Property in that record has a Name of Item Order and a NameValue of 0x8A2602B9 where the DataType of this record is Unit32 (with range of -32768_hex to 32768_hex, according to JeroniJ) Rep of 0 (??) and 1 Value of the order wanted.

Hope this is right, and hope it helps

Joe

Based on my lots I am working on right now, plop cost has no baring at all, on the order. In fact, other than Item order, I have not been able to find out what factors are effecting it.

Edit: Further testing reveals I was wrong (Brain fart, I forgot I had already changed the item order in a few of my lots as an experiment)

For those confused about why Occupant Groups *should* be included in such a program.   This has nothing to do with changing the type of the lot, OGs (Occupant Groups), deal with much more beyond the type of lot and the building style.  The BSC has OGs for the BSC tracking mods, there are OGs for which Building Style you want the building to grow in, OGs for which type of lot it is (R, C, I), OGs for which menu the ploppable lot is to be placed in.

So, each menu has its own OG.  What if you have a set of landmarks you that you have and want them placed in the parks menu?  Then you will have to change the OG from the Landmark Menu and change it to the Parks Menu.  Now, the problem with changing the OG list, is every lot has a custom OG list and you only want to change one of them.  Im sure this is avoidable, but.. its a problem that must be dealt with.
___________________________________________________________

As stated already, there is 3 determining factors on how the game orders something in the menus:

1. Item Order Property

The lower the number the higher the position on the menu.  So, if one lot has a 1 and another lot has a 4 the lots with the 1 will be placed first.

2. Lot Size

When a lot has the same Item Order Property value, it will then place the lots in order of thier size.  Like so,

1x1
1x2
1x3
2x2
2x3
3x2
3x3
4x4
etc.

3.  Item Cost

Finally, if the Item Order and the Lot Size are the same the game will order the lots by cost.  Like so:

2x2, $100
2x2, $150
2x2, $175
_____________________________________________________________________

Hopefully, this makes a bit more sense.  I think the original poster has a very good idea and it can be implemented quite well.  It is widely known, that your menus are a mess and this can only help you finding stuff if you setup the Item Orders yourself.  Good luck on this program and I hope someone will actually do it.  ::)

QuoteIt is widely known, that your menus are a mess and this can only help you finding stuff if you setup the Item Orders yourself

LOL, how true, I just spent all day sorting out my Item Orders, and they still appear all over the place, there is still no real structure, except a very rough grouping

Quote2. Lot Size

When a lot has the same Item Order Property value, it will then place the lots in order of thier size.  Like so,

1x1
1x2
1x3
2x2
2x3
3x2
3x3
4x4
etc.

I am contemplating that this is more on the Area of the lot, than the Lot Size. Just a contemplation, but maybe not

Joe

I will be more than happy to write the program, as soon as I find out how to read and write to and from sc4 files.

Quote from: RebaLynnTS on February 12, 2008, 12:56:25 PM
I will be more than happy to write the program, as soon as I find out how to read and write to and from sc4 files.

That, ladies & gentle men, is the crux of the matter: thus, lest I repeat myself: where can that data be found. Is it the DAT file? But then, not every plug-in seems to have one (I maybe talking through my hat here).

The info in question is in the building exemplar of the lot, or the buildings desc file. How to read it programatically is the only problem I have.

Quote from: RebaLynnTS on February 12, 2008, 03:35:23 PM
The info in question is in the building exemplar of the lot, or the buildings desc file. How to read it programatically is the only problem I have.

Havent looked (it's late, too late here in the land of beer), but what lingo is it written in? I doubt it would be something as simple as ASCII text. But then thos brilliant folks who wrote the Reader and similar tools do read the exemplar, thus can they not tell us?

i'm watching this space.....

Quote from: HandsOn on February 12, 2008, 03:32:46 PM
That, ladies & gentle men, is the crux of the matter: thus, lest I repeat myself: where can that data be found. Is it the DAT file? But then, not every plug-in seems to have one (I maybe talking through my hat here).

Well, and that's exactly why I said it wouldn't be feasible to re-invent the wheel once again. ;) ilive wrote the Reader that is able to read and write SC4 files, then DarkMatter wrote DatGen, simrolle wrote SC4Tool, and wouanagaine wrote the X-Tool. Unfortunately, every program was written in another language, and the wheel (reading and writing DBPF files) was reinvented four times...

Fortunately, I can program in 38 languages, so if I get the info, all I have to do is use it.

Quote from: jplumbley on February 12, 2008, 12:10:45 PM
For those confused about why Occupant Groups *should* be included in such a program.   This has nothing to do with changing the type of the lot, OGs (Occupant Groups), deal with much more beyond the type of lot and the building style.  The BSC has OGs for the BSC tracking mods, there are OGs for which Building Style you want the building to grow in, OGs for which type of lot it is (R, C, I), OGs for which menu the ploppable lot is to be placed in.

The same argument could be applied to why it shouldn't be included in this program, but instead to something else already in development. Adding OG's is something that needs to be done to every building that is to be used in the game in order for it to function correctly. So to me, this sounds like a job for XTool.

Quote from: xxdita on February 12, 2008, 07:06:18 PM
The same argument could be applied to why it shouldn't be included in this program, but instead to something else already in development. Adding OG's is something that needs to be done to every building that is to be used in the game in order for it to function correctly. So to me, this sounds like a job for XTool.

Well, I am not saying this should or shouldnt be made... just pointing out what needs to be taken into consideration and it seems as though in this thread some people have bad information and I was just trying to sort out that information with some good info.  ::)

We can always use more of that good info stuff :)

After a quick search on teh internetz, I found this (from Sims2Wiki) (http://www.sims2wiki.info/wiki.php?title=DBPF) which continues to List of Formats by Name (http://www.sims2wiki.info/wiki.php?title=List_of_Formats_by_Name)

FOUND ST RESOURCE: http://www.simtropolis.com/forum/messageview.cfm?catid=40&threadid=84838&enterthread=y

Looks like thats the business...

Joe

Quote from: HandsOn on February 11, 2008, 08:08:43 AM
Stupid question: does it have to be done in Delphi 7?? Or could it be done in any language (say C#, VB8, etc..)?

It's the language I am "more-or-less" able to program. The other option I have is LabVIEW, but I don't think it would be appropriate  ;). Delphi (at least in version 7) doesn't need any runtime library, just take the exe and run it.

Quote from: HandsOn on February 12, 2008, 07:38:28 AM
Mais, since plug-ins insert items into the menu, it should be possible to determine where these are inserted. I've seen park items show up in the power menu, and a recent installation of sunken highway walls rearranged the park menu in a dismal, very interupted manner.

That's why I'd like to be able to change the menu where the icon shows up...

Quote from: jplumbley on February 12, 2008, 12:10:45 PM
For those confused about why Occupant Groups *should* be included in such a program.   This has nothing to do with changing the type of the lot, OGs (Occupant Groups), deal with much more beyond the type of lot and the building style.  The BSC has OGs for the BSC tracking mods, there are OGs for which Building Style you want the building to grow in, OGs for which type of lot it is (R, C, I), OGs for which menu the ploppable lot is to be placed in.

To complete your posting: this thing holds several numbers, at least one for each menu. Eg. one for "transportation tools" (top menu), one for "misc transportation" (submenu) and maybe a few more. So if you'd like to change the place of an icon from "misc transportation" to "education", be sure to filter out and replace more than one number, or your occupant group ends with "transportation tools" & "education" and you won't find your icon anymore, since "education" isn't part of "transportation tools" but "civic tools".

...oh, I haven't said. The base of my Idea was a tool from ST that is named "RudeBoy's menu divider". It implements:

• different "fake"-lots (just an Icon in the menu) to "divide" the menus (eg. misc transportation or parks) into various sections... That's not the part I'm refering to  :P, it's next...
• a huge excel-sheet with order-values 0...0xFF??? for each game-menu. One put the filename, instance-number, and description of a lot at the wanted place in the excel-sheet and transfers the according order-value in the Reader into "item order". This way the menu-icons gets the order you like.
  Problem with this method is, you need "a few" night-shifts of handwork  :-[ if your plugin folder has 1GB or more. I'd like to have this process a bit automated and shortened.

-andy33b-

My 0.02€ here  as I clearly don't want to program that tool, it is time I start playing at a 100% scale again  ::)

-don't rush for coding, make sure you understand all in&out of menu and OG ( does not seem everyone get to this point )
-There is no such thing as just getting the info from the examplar, you'll have to write back to the file and don't screw the users files ( remember on SC4TF days how many times I've thought I had the writing file code correct but was proven wrong ? ), or the V.08a of SC4DatPacker where some users experiments brown boxes ?
-To make the tool effective, you'll have to load all the maxis files & plugins, so think about RAM ( python which is the language I'm using is not effective on that subject, so it was a bad choice ), any language with a Garbage collector and out of coder memory management will suxs ( look at all my tools but the latest SC4DatPacker, they all use way much too RAM but I can't control it, the language control me ), and do lazy code ( XTools testers can attest how "funny" it is to have to wait for loading ), and handle the correct file loading order
-Remember that the info for the menu is in the building examplar, but you'll have to search if such a building examplar is used in a lot ( no need to order it if it does not show up in SC4 )
-Remember that there is a awfull big number of totally screwed modded files out there. some that are not readable, some that will have menu information, but proved to be growable lot, some that are plopable but don't have menu information or missing some of the needed properties
-Remember that there is not only english/us lot makers, so support unicode from the start ( see how many problem I have with unicode with my tools ? )
-Test, test and test, have a quite large testers group with different plugins, OS and languages
-Be prepared to handle the support thread !

Wish you luck  :thumbsup:

Trying to scare me? lol

Quote from: wouanagaine on February 13, 2008, 12:10:36 AM
-There is no such thing as just getting the info from the examplar, you'll have to write back to the file and don't screw the users files ( remember on SC4TF days how many times I've thought I had the writing file code correct but was proven wrong ? ), or the V.08a of SC4DatPacker where some users experiments brown boxes ?

That's why I suggested a two step approach. While the first step is done it becomes evident which are the problematic files.

Quote from: wouanagaine on February 13, 2008, 12:10:36 AM
-To make the tool effective, you'll have to load all the maxis files & plugins, so think about RAM ( python which is the language I'm using is not effective on that subject, so it was a bad choice ), any language with a Garbage collector and out of coder memory management will suxs ( look at all my tools but the latest SC4DatPacker, they all use way much too RAM but I can't control it, the language control me ), and do lazy code ( XTools testers can attest how "funny" it is to have to wait for loading ), and handle the correct file loading order

you don't have to keep all the files open in the RAM. As long as you keep the filename with the menu-icon & instance-number it is simple to reopen the file. Most probably you'll have to do it so anyway, since mods can "overwrite" an exemplar.
What was the correct order? First files then subfolders, and everything in assending order (or was it the other way round)? ()what()
<Scan a directory tree (recursive task), build a list of the desired items (and dismiss unwanted and maybe problematic items), while building up scan for duplicate list-items and replace their content> is not that difficult (If your programing language has a good support for lists), but needs time to be programmed and will in the compiled app consume quite some time.

Quote from: wouanagaine on February 13, 2008, 12:10:36 AM
-Remember that there is a awfull big number of totally screwed modded files out there. some that are not readable, some that will have menu information, but proved to be growable lot, some that are plopable but don't have menu information or missing some of the needed properties

I don't expect a program that does everyting (in german "Eierlegende Woll-Milch-Sau"), but rather a tool that does 80% of the job. I'm happy if I can reduce the handwork from "several" night-shifts to only 1.
While writing new values to "item order" don't use an increment of 1 but rather of 100 or more. This way there is enough room for additional handwork (-> the remaining 20%) after the automated process.

Quote from: wouanagaine on February 13, 2008, 12:10:36 AM
-Remember that there is not only english/us lot makers, so support unicode from the start ( see how many problem I have with unicode with my tools ? )

&mmm Would be a big problem for myself. But if I understand it right not that much for RebaLynnTS.

-andy33b-

Correct loading order is the following =>

-Parse files in folder in alphabetical order ( ASCII ordering, case insensitive, differ from what windows explorer shows  )
-then parse subfolders in alphabetical order

if one file has duplicates within itself, use the first version
if one file has duplicates with previous files, use the new version

Maybe I'm just being too simple here, but the main problem that would warrant the program is the disorder of plug-in placement in the menu. Now, I would first want to go to the source. That is, as NAM and creators of similar ilk have shown, it is possible to "bundle" parts of a plug-in into a single icon, asking the user to use the TAB key to select which lot to plop. If, and I am really dreaming here, I guess, everyone who made lots that go together - such as trails or parkways, etc., used that single-icon approach, half the problem would be solved. I know there's MML (or some such) but I for one never seem to get that right. And in some instances, there are "construction lots" for the same items appearing in different menus (an underground plaza - great stuff - that shows up under parks, misc. transport, and landmarks is a good example).

The loading of my "parks" menu alone has me twiddling my thumbs for quite a while, and my guess is that its the number of icons SC4 generates on the fly. Of course, all of this could be hogwash..?!

Hands on, unfortunatly, as has been stated many a time, the TAB ring is restricted to transit networks only.  It can't be used for lots.

With the MML's they all have to be in the Landmark menu, as well as where you look for them.  I can't explain why one would show up in more than 1 menu (+ the landmarks) unless the lots they replaced do.

Quote from: HandsOn on February 13, 2008, 08:27:36 AM
That is, as NAM and creators of similar ilk have shown, it is possible to "bundle" parts of a plug-in into a single icon, asking the user to use the TAB key to select which lot to plop. If, and I am really dreaming here, I guess, everyone who made lots that go together - such as trails or parkways, etc., used that single-icon approach, half the problem would be solved.

Unfortunately what you have just isolated is a function that is only available to Network Puzzle Pieces...  It is not possible to put lots into such a menu icon.  The menu icon for the TAB-rings are defined in the Transit RULS and cannot reference Lot Exemplars or anything other than Puzzle Piece Models.

MML is the closest thing we can get to a TAB-ring icon.  Unfortunately, it takes alot of modding to create an MML and a complete update of the set of lots the MML is dealing with.  It would be much nicer if we could use this, but it just isnt possible.

Quote from: jplumbley on February 13, 2008, 10:17:46 AM
MML is the closest thing we can get to a TAB-ring icon.  Unfortunately, it takes alot of modding to create an MML and a complete update of the set of lots the MML is dealing with.  It would be much nicer if we could use this, but it just isnt possible.

Actually they aren't too bad to Mod.  Depending on the size.  It's more an issue of tedium and that you have to wait till a set is finished before doing the MML as they can't be added serparatly.

Quote from: jplumbley on February 13, 2008, 10:17:46 AM
Unfortunately what you have just isolated is a function that is only available to Network Puzzle Pieces...  It is not possible to put lots into such a menu icon.  The menu icon for the TAB-rings are defined in the Transit RULS and cannot reference Lot Exemplars or anything other than Puzzle Piece Models.

MML is the closest thing we can get to a TAB-ring icon.  Unfortunately, it takes alot of modding to create an MML and a complete update of the set of lots the MML is dealing with.  It would be much nicer if we could use this, but it just isnt possible.

Maybe the reason they do show up in more than one menu lies with me. There's always a good chance I did something wrong. But in the case of (I forgot whose) a set of embankment walls and with the underground malls, the MML icon's with the bulldozer show up in different menus. And only the one in the landmark menu proclaims when it has already been placed.

Shame about the Tab restriction. That would have simply been to good to be true.

If the custom submenu thing ever gets off the ground, that would solve a lot of problems. Also, I designed a small app that can quickly create MMLs, but I still have to figure out how to read and write to the sc4 files (working on that now).