SimCity 4 Open Access: Repository of modding tools

[rsc204 21,836]

8 hours ago, junspud said:

the T21 editor will crash if any texture TGIs are present in the T21 lotconfig. I found this out while attempting to review various T21 mods which people had released, a lot of them unfortunately contain leftover textures and so can't be opened.

Just delete the textures or create a patch with only the T21s before working. If anything this was likely an oversight since it rarely makes sense to bundle T21 mods with textures, I never personally noticed and have had the tool some time. 

[junspud 1,066]

18 hours ago, rsc204 said:

Just delete the textures or create a patch with only the T21s before working. If anything this was likely an oversight since it rarely makes sense to bundle T21 mods with textures, I never personally noticed and have had the tool some time. 

At first I thought it was a particular prop or something, pasted the lot configs onto a tile to look at in a lot editor, noticed all the ones that hang the program contained textures, deleted the textures and it loaded fine. 

Most of the T21's on this page contain textures;

https://community.simtropolis.com/profile/441245-958517907/content/?type=downloads_file

Along with some other older ones.

[Null 45 3,064]

On 5/15/2023 at 4:52 PM, junspud said:

I was wondering, is the FSH plugin for Photoshop supposed to work on x64 Photoshop CC 2019?

It should work on CC 2019, Adobe hasn't made any breaking changes to the plugin API in 25+ years.

On 5/15/2023 at 4:52 PM, junspud said:

Whenever I try to use it though, I get the error 'Could not complete the request because it is not the right kind of document'.

I suspect that error message may be Photoshop's generic 'cannot read' error code. That error is returned for 8-bit indexed FSH images and files that compressed with an unsupported format. IIRC SC4 uses 8-bit indexed images in a few places.

Could you make a post in the plugin support thread or file an issue on GitHub with one of the FSH files that causes this included as an attachment?

[Flann 1,709]

On 5/15/2023 at 5:52 PM, junspud said:

This might already be known but just a heads up, the T21 editor will crash if any texture TGIs are present in the T21 lotconfig. I found this out while attempting to review various T21 mods which people had released, a lot of them unfortunately contain leftover textures and so can't be opened. Maybe that falls outside the intended usage though but thought it was worth mentioning.

Can you post an example of a faulty exemplar that I can use to try and diagnose the problem?

Edit: Nevermind, I've made one.  I think I found the problem and should be able to fix it

Double edit: This bug has been fixed and a new release is available here https://github.com/memo33/jondor-t21-editor/releases/tag/0.6.1 @junspud @rsc204

  Edited May 17, 2023 by Flann  

[rsc204 21,836]

On 17/05/2023 at 12:34 AM, junspud said:

Most of the T21's on this page contain textures;

I’m seeing a bunch of MMPs, rather than T21s, again I can’t personally recall a T21 mod that includes textures. But the issue should be gone now just in case thanks to @Flann.

[junspud 1,066]

On 5/17/2023 at 11:45 PM, rsc204 said:

I’m seeing a bunch of MMPs, rather than T21s, again I can’t personally recall a T21 mod that includes textures. But the issue should be gone now just in case thanks to @Flann.

Apologies, should have been more specific, as you have to scroll down quite a bit to get to them. But he's done a few T21 mods including these ones;

This one also contains a texture;

It just so happened I was interested in taking a look at them in the program and they happened to contain a texture TGI. Not that it matters anymore as the new version won't crash now.

 

On 5/16/2023 at 8:42 PM, Null 45 said:

It should work on CC 2019, Adobe hasn't made any breaking changes to the plugin API in 25+ years.

I suspect that error message may be Photoshop's generic 'cannot read' error code. That error is returned for 8-bit indexed FSH images and files that compressed with an unsupported format. IIRC SC4 uses 8-bit indexed images in a few places.

Could you make a post in the plugin support thread or file an issue on GitHub with one of the FSH files that causes this included as an attachment?

Apologies for the delay, I intended to do that, but it looks like a new version has already been released which fixes the issue. I was unaware of the unsupported compression issue, most of the FSH files had been run through GoFSH with the 'compress FSH' enabled by default, so I was trying to mostly open compressed FSH files. I never came across one I was able to open previously.

I just tested one now though and Photoshop was able to open it with the plugin, which is awesome, I have been spending a lot of time converting single FSH files back and forth and now I can just edit them directly, so personally the update is much appreciated. 

[wouanagaine 83]

On 4/25/2023 at 12:52 AM, doug_wess said:

Hi nos.17

Really appreciate the reply, many thanks.

It was wouanagaine that i would have loved to have asked some questions about his SC4Mapper program.

What I would really like to know is there a file layout that for the region maps, and how he decide on the way of reconciling the grayscale colours to heights.

Cheers

 

Hey feel free to ask
I may reply or not, but better to ask me on sc4d discord as it is really depending on what I'm up to (Hasn't login for more then 8 years here) and my memories may need some refreshing on the code I wrote more then 10y ago

[junspud 1,066]

Came across interesting anomaly in iLives reader (both currently used iterations).

The 'TSC/OR Jubilee Church building exemplar, '56a6da7e',crashes both versions of Reader and LEProp if you attempt to click on it directly or open the navigator/exemplar analyser with it present. You can only drag a box around multiple exemplars in order to copy or delete it.

Tested on the original dat file (TSC_Or_JubileeChurch.dat), also tried copying the exemplar into it's own otherwise empty dat file but result is same.

Tried loading the dat in SC4DataNode, but the exemplar isn't reported as faulty/corrupt or any thing.

 

Seems to be present in a few different exemplars, encountered the issue while looking through some datpacked files, though the crash is exactly the same on the originally released .dat, previously on LEX but also available here;

https://www.toutsimcities.com/downloads/view/1420

Another example is a building with the instance GI '3EC1DB6A 88c32e51', FAR version of 'Mattb325 Modern Hospital'.

Quote

Problem signature:
  Problem Event Name:    BEX
  Application Name:    reader.exe
  Application Version:    1.4.0.0
  Application Timestamp:    5d8b3427
  Fault Module Name:    OR_DAT.dll
  Fault Module Version:    1.0.0.1
  Fault Module Timestamp:    5d8b3404
  Exception Offset:    00014c34
  Exception Code:    c0000409
  Exception Data:    00000000
  OS Version:    6.1.7601.2.1.0.768.3
  Locale ID:    1033
  Additional Information 1:    8ac2
  Additional Information 2:    8ac2e6e09724d4dc0f2e9c6be336ddbc
  Additional Information 3:    d733
  Additional Information 4:    d733daa3217216ff7ab489141ec1fa38
 

 

[rivit 3,391]

Did Datanode put anything in the its Log about it? I ask because I tried to make it resilient to data exceptions on reading and I will put a comment in the log if the data itself is faulty in some way. I'm thinking this exemplar may be slightly mangled at the property level in some way.

[junspud 1,066]

1 hour ago, rivit said:

Did Datanode put anything in the its Log about it? I ask because I tried to make it resilient to data exceptions on reading and I will put a comment in the log if the data itself is faulty in some way. I'm thinking this exemplar may be slightly mangled at the property level in some way.

Thanks, Just tried, loading the original dat packages as released into Node, but the logs didn't show anything for them, however loading the same dat files into Reader and clicking on them still crashed it.

So  I tried deleting deleting all exemplars in the .dat files (from the original zip files or installations) aside from the one causing Reader to crash., then merging those offending exemplars into a single dat file manually (using merge tool in Reader).

Then loading that consolidated .dat file into Node, which then did generate a log;

Quote

===> 7/31/2023 10:11:41 PM Start
Hello and Welcome to SC4DataNode

===> 7/31/2023 10:14:30 PM Warning
ArrayType used, 0 Reps expected
 in TGI File: 6534284A-4D353523-0D5CC72E
 in SC4 file: E:\sc4\Plugins\aadatapacked\crashes.dat

===> 7/31/2023 10:14:30 PM Warning
ArrayType used, 0 Reps expected
 in TGI File: 6534284A-4D353523-0D5CC72E
 in SC4 file: E:\sc4\Plugins\aadatapacked\crashes.dat

===> 7/31/2023 10:15:32 PM Stop
End Of Session

Reader Log in the debug menu is still empty though.

crashes.dat

[rivit 3,391]

That logged report is to catch float array problems for Transit costs that will crash the apple SC4s. thats in exemplar 0D5CC72E and needs to be fixed to NREPS=0

The others are not unusual except that the Mattb Hospital has a text description of 313 length, and the MBear one is 279 and then the Jubilee Building is 377 long. This could be why reader has apoplexy on trying read these. PIM-x presumably has no problem with this and there is no reason why this should be invalid, although its unusual.  If truncated to <256 length these will/should load in Reader.

[Null 45 3,064]

Adding some more DLL plugins in no particular order:

Spoiler

https://github.com/0xC0000054/sc4-city-date-sync

https://github.com/0xC0000054/sc4-humane-society-ordinance,

https://github.com/0xC0000054/sc4-legalize-gambling-ordinance-upgrade

https://github.com/0xC0000054/sc4-city-lottery-ordinance

https://github.com/0xC0000054/sc4-cpu-options

https://github.com/0xC0000054/sc4-graphics-options

https://github.com/0xC0000054/sc4-full-screen-32-bit

https://github.com/0xC0000054/sc4-no-kick-out

https://github.com/0xC0000054/sc4-disable-demolition-animation

https://github.com/0xC0000054/sc4-disable-lot-plop-smoke

https://github.com/0xC0000054/sc4-disable-network-construction-sounds

https://github.com/0xC0000054/sc4-growify

https://github.com/0xC0000054/sc4-more-building-styles

https://github.com/0xC0000054/sc4-more-demand-info

https://github.com/0xC0000054/sc4-query-ui-hooks

https://github.com/0xC0000054/sc4-resource-loading-hooks

https://github.com/0xC0000054/sc4-region-census

https://github.com/0xC0000054/sc4-dbpf-loading

A template that can be used as a starting point for creating new DLL plugins: https://github.com/0xC0000054/sc4-gzcom-dll-template

[junspud 1,066]

Some random observations.

Just a an observation on the two common versions of Reader. At least IME, a few of the 'sync with file' context options seem to be broken in the post-0.9.3 versions, for example trying to use it to sync from the Navigator window doesn't work. Could be my machine but haven't tested that.

Applying the 4GB patch to the Reader executable allows you to modify and save huge dat files (500+mb) without it producing a low memory error. I only found this useful to make minor adjustments to datpacked files after losing the original Plugins folder they came from.

I think this might be a quirk of my machine as I've never seen it mentioned anywhere despite searching, but to save 'groups' in the Pim-X lot editor requires me to toggle the 'always on top' button. Not being able to save groups had me stumped for a long time until I discovered this at random.

[Propfam 2,294]

2 hours ago, junspud said:

Some random observations.

Just a an observation on the two common versions of Reader. At least IME, a few of the 'sync with file' context options seem to be broken in the post-0.9.3 versions, for example trying to use it to sync from the Navigator window doesn't work. Could be my machine but haven't tested that.

Applying the 4GB patch to the Reader executable allows you to modify and save huge dat files (500+mb) without it crashing. I only found this useful to make minor adjustments to datpacked files after losing the original Plugins folder they came from.

I think this might be a quirk of my machine as I've never seen it mentioned anywhere despite searching, but to save 'groups' in the Pim-X lot editor requires me to toggle the 'always on top' button. Not being able to save groups had me stumped for a long time until I discovered this at random.

Yeah, post 0.9.3 is buggy as heck like the UI, despite @ilive's best effort, is pretty much trash. So many bugs within the UI itself. Tho to be fair, Reader 1.5.5 (yes, that exist) fixed the unicode problem. But it's pretty much experimental. Not to mention, I had huge dat corruption using the Reader (or LEProp, I forgot). You know, I was going to up the capacity of Tedasu's HSR station to a couple hundred and then I didn't get it in the menu. So, I PM'd rsc, if I'm not mistaken, and he eventually gave me the corrected file. Btw, thanks a lot to him for the fix.

For the last situation, you may have apps that conflicting with that. That's one of the reason why you can only save your group after pinning it to the top.

[Null 45 3,064]

2 hours ago, Jidan said:

Yeah, post 0.9.3 is buggy as heck

Agreed. Some things were improved in Reader 1.X, like the UI editor. But a lot of things are unstable, Reader 1.5.4 crashes most of the time when I open the exemplar editor. In my opinion, the Ribbon UI is a downgrade from 0.93. That conversion also appears to have resulted in a lot of the file filtering options being axed so that it could fit in the ribbon. If the filtering dialog dialog from 0.93 is still present, I have not found it. I tend to use 0.93 unless I need the features added in newer versions.

Also, the Reader's source code is on Source Forge (https://sourceforge.net/projects/ilive-reader/), but it looks like it only goes up to version 1.4. The links to the binaries and source code for 1.5.4 were posted in the SC4D Reader support thread, version 1.5.5 was also posted in that thread but it doesn't appear to include the source code.

[junspud 1,066]

Is it weird for Jdatpacker and SC4Datpacker 2008 to have very different sizes after packing? For example, one example, Jdatpacker resulted in a 31mb .dat, while 2008 resulted in a 16mb .dat, for the exact same files/folders.

[memo 1,460]

The difference is quite big, so it wouldn't hurt to check the files if anything's wrong. Generally though, this is not implausible. JDatPacker does not perform recompression (it's faster that way) and does not discard some files like XML or JIFF. So if you have many uncompressed or unnecessary files, you might see those results.