Jump to content

Group Park 3


Broxzier

Recommended Posts

55 minutes ago, Broxzier said:

^ I don't think that's nice to do.

In the console it says it can't load: ITMZLINE

If you added anything custom ride related, make sure all files are there.

What's not nice?  The challenge, or something else?

 

Huh, that's odd.  Let me check that when I get home.

Link to comment

Allowing Incorrect Checksums when the console clearly says an entire DAT file (I'm assuming) is missing is not nice to do, @Broxzier meant.

You should upload ITMZLINE.DAT so the ride does not require one to use "Allowing loading files with incorrect checksums" in the first place.:)

Link to comment
Just now, Broxzier said:

You're just playing without the required file then.

No you're not. "Allow incorrect checksums" forces the file to load despite the incorrect checksum, so you will still have the object. The difference is that if you install the object manually, the object in your ObjData file has a valid checksum, and then it gets corrupted during the export process. If you use "Allow incorrect checksums" to force the object to load, the object in your ObjData folder will be the object post-export version so it has an invalid checksum to start off with. That means it throws a checksum mismatch on load that you don't get if you installed the object manually, but that error doesn't actually prevent the object loading, so I'm not sure if there are any actual consequences of doing it this way, and it's certainly easier than manually copying the files.

I agree that this is an ugly way to solve the problem though - the correct way is to fix the broken object before using it in a park IMO.

Link to comment
1 hour ago, X7123M3-256 said:

No you're not. "Allow incorrect checksums" forces the file to load despite the incorrect checksum, so you will still have the object. The difference is that if you install the object manually, the object in your ObjData file has a valid checksum, and then it gets corrupted during the export process. If you use "Allow incorrect checksums" to force the object to load, the object in your ObjData folder will be the object post-export version so it has an invalid checksum to start off with. That means it throws a checksum mismatch on load that you don't get if you installed the object manually, but that error doesn't actually prevent the object loading, so I'm not sure if there are any actual consequences of doing it this way, and it's certainly easier than manually copying the files.

I agree that this is an ugly way to solve the problem though - the correct way is to fix the broken object before using it in a park IMO.

How come manually placing them in your ObjData folder works, and having them in the save (if they are) doesn't, does it make their checksum different? I was assuming they don't exist on the ones downloading it, because it couldn't get exported with the saved game or something. And why does this only apply to certain .DAT files?

Link to comment

This bug applies to tracked rides created with Buggy's ridemaker. The problem originates from that tool, not from OpenRCT2 or the vanilla game, but there's enough of these broken DAT files that I doubt they'll ever all be fixed.

Several fields in the ride entry structure are reserved to be populated during load time. When a ride is exported, all these reserved fields are zeroed out. They should not contain any data, so this normally doesn't change anything. The problem is that some of these fields serve a different purpose for tracked rides than do flat rides. Buggy's ridemaker writes three of these bytes as 0xFF, which apparently has something to do with the animation - but only for flat rides. For tracked rides those fields are expected to be zero, and because they aren't, the file gets changed during the export process. The checksum is not updated accordingly, so the file ends up exported with a mismatched checksum. It's still in the savegame, and only the checksum is wrong, which is why you can load it if you allow incorrect checksums.

 

I tried to implement a workaround for this by having the game recalculate checksums after exporting an object so that this issue would not cause a problem (because fixing the original tool is unlikely at this point, it's old and I doubt it's still being maintained). However, the number of DAT files still causing problems indicates to me that my attempted fix was severely broken - I have been meaning to have another look at it but haven't got round to it.

Edited by X7123M3-256
  • Like 1
Link to comment

It looks like the DAT file may not be responsible at all, because saving and then loading parks without that DAT file still crashes the game.  Could someone please try starting a new game, saving, and reloading the park to see if it still produces that error?

Link to comment
1 hour ago, jensj12 said:

If there is a second 3.57a version, it should have been named 3.57b, please fix that or I might download the wrong one.

I know that; just recognized it too late to fix since I have erratic access to my computer right now.  Follow imlegos post and you should be fine. ;)

Link to comment

Will do, and I'll fix The Deep Forest (it somehow just misses a track piece). Since I haven't built one last turn, it will include a coaster. The design is almost done so I can just put it in and build a box around it.

Claimed: jensj12
Queue:  Wuis, Yimmy, RedScope53, Dan, Philmon11, Broxzier, ziscor
Missed: imlegos, WobblyRails , Wilburg22

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...