Combining Ztd's In Ztcc

[JohnRN1]

If I have a conflict... I am assuming now that conflicts would appear only when ID's conflict?

[Jay]

Why do you leave the animal files you care about by themselves?

If I can avoid it, I do not want to create files that are hundreds of megabytes in size. I want to be able to move files easily, including from one computer to another. Sometimes the best way of doing that is by email, and the email I'm using has its limits. Plus, if I am not hitting a ZT limit by leaving them on their own, then it does not make sense to take the time to combine them. Things like scenery are smaller and, therefore, take much less time to combine.

Or, What do you mean when saying: "the animal files I care about"? Does that last question just mean that those are files that don't need fixing and are just too big to deal with when combining them?

I feel some animals add variety to ZT and some do not. That could be concerning the animal graphics or the animal info or the plaque. Also, everyone will have their own preferences concerning animals. For me, I prefer real animals over dinosaurs or mythological creatures or made-up animals. I prefer animals that look different or are different species rather than subspecies.

if I have a conflict with a uci not showing up (that was put in a combined ztd fle), and there are no identical id#'s, what other factors would indicate a conflict? ... I am assuming now that conflicts would appear only when ID's conflict?

A true conflict is where two things are using the same file name in different ways. That file name could be the ".ztd" name itself or it could be a file inside a ".ztd". (There are two other types of conflicts some of us have to worry about: 2 different things using the same ".zip" name and 2 different things using the same message id inside ".dll" files. But neither of those conflicts would cause something not to show up inside ZT.) Here are some examples of conflicts:

• If 2 people create different animals using the same APE id, then a conflict will occur because both will be using the same file name. For example, if the APE id is 12345678, then both would have a file named animals/12345678.uca. That is a conflict because ZT can only load one of those files.</li>
• If 2 people create different objects (scenery, foliage, rocks) and the APE id is 12345678, then both would have a file named scenery/other/12345678.ucs, and ZT can only load one of them.</li>
• A conflict can happen even without APE ids. For example, sometimes 2 people create buildings and, by coincidence, they use the same ".cfg" file name. Again, ZT can only load one of those files.</li>
• Hacks always involve using the same file name as something else. For example, a working user made bench would use the same guests/guests.ai that is used by the ingame benches. So if 2 different people create a working bench without knowing about the other person's bench, that would be a conflict if someone tried to use both benches at the same time.</li>

But sometimes 2 different ".ztd" files contain the same file name and it is not a conflict. That is when the files are being used for the same thing. Here are examples:

• Different people have made barn shelters. Inside the ".ztd", there is a file that tells ZT when the barn shelters should appear in the game. They are using a freeform/unlock-barnshelter.scn to tell ZT that their barn shelter should be in the purchase menu at the start of a zoo. Since all of these barn shelters are using that file in the same way, it is not a conflict.</li>
• Sometimes 2 restaurants might sell the same food as 1 of their items. Those file names would also be the same, but it is not a conflict because they are being used the same way.</li>

When 2 things are in conflict, they are in conflict whether the ".ztd" files are combined or if the ".ztd" files are separate and in one of ZT's folders at the same time. So if 2 ".ztd" files both work when they are both put in the dlupdate folder at the same time, but they do not both work when combined, it is not because of a conflict; it is because they were combined incorrectly.

If something does not appear in ZT (whether combined or not), it could be other reasons besides a conflict. It might not have been configured correctly, or it was intentionally configured not to show until something happens first, such as researching it inside a zoo.

[JohnRN1]

Another Jay's text file saved as "Jay's conflict Explanation". Your synopsis of conflict was great!!! Which reminds me...

I believe Fern told me once that the rainbow benches and/or tables uci were not working ones but just scenery. I would like to hear from her on how difficult it would be to do them over as working. Or, is that intruding on the original designer's rights?

Regards,
John

[Jay]

I will answer, since this is a subject that designers have talked about ever since the start of ZT. All working benches and working picnic tables are hacks. That means they are overriding an ingame file. In this case, they are overriding a file concerning guests. There were 2 problems concerning hacks. One of them was that, every time BF came out with another expansion pack, BF would have to change that guests file to do other things. That meant the hacks had to be changed to account for the newer BF guests file. Meanwhile lots of Zoo Tycooners were using the older hacks and panicked when guests got stuck, not only on benches and picnic tables, but at some BF buildings as well, since those are also in the guests file. It was a nightmare for Zoo Tycooners, the designers, and technical support people. For me, it was not worth the hassle and I recommended that noone use working benches or working picnic tables made by users. Designers gave up trying to keep their guest related things up-to-date with the expansions. Since there will not be another expansion from BF, this would not be as much of a problem today. But, as far as I know, there is no user made bench or picnic table that was brought completely up-to-date for CC, at least not where most Zoo Tycooners could get them.

The second problem is true for any user made hack. If 2 people make hacks that affect the same file and they do not take into account the other person's hack, then one cannot have both of those hacks in ZT's folders at the same time, since ZT will only use one of the files. In the current situation, that means Zoo Tycooners would have to keep moving different working benches and picnic tables in and out of ZT's folders, depending on which they want to use at a given time. To many of us, that is inadequate. But there has been discussion about this at the Designer Guild. There are 2 solutions, each with their advantages and disadvantages. The Designer Guild has representatives from many of the ZT fan sites. So one approach is to have the hack of the guest file at the Guild. It would be kept up-to-date as new guest interactive things (such as benches and picnic tables, but includes other things as well) are created. That guest hack would be available for download at the Guild, but the interactive thing itself could be at any site that the designer wants it to be. There is a possibility that multiple guest hacks will be needed, for different ZT versions. The main disadvantage of this approach is that designers that are not part of the Guild might not want to work with their site representatives who are Guild members, which could cause confusion again if they decide to do things on their own. The second approach is for each guest interactive download to not be a hack. Instead, each of those downloads would give instructions on how the Zoo Tycooner can create and modify a guest file on their own. A main disadvantage of this approach is the extra work that a Zoo Tycooner has to do. Also, there is a risk they can make a mistake and their ZT would stop working. So there would also have to be instructions on how to get back to using the original guest file. At some point one of these approaches will be used, although it is impossible to say when.

[fern]

Instead, each of those downloads would give instructions on how the Zoo Tycooner can create and modify a guest file on their own. A main disadvantage of this approach is the extra work that a Zoo Tycooner has to do.

My thoughts on this way is there are people who have trouble combining ztd or even putting stuff ingame and taking it out again. For these people it would be unlikely they could/would be able to use this approach.

I believe Fern told me once that the rainbow benches and/or tables uci were not working ones but just scenery. I would like to hear from her on how difficult it would be to do them over as working. Or, is that intruding on the original designer's rights?

As for Ratbag's rainbow benches, I know she originally wanted them to work. She is probably contactable either by me or the ztuf staff as I know some keep in touch with her. How difficult......... Like anything there is a learning curve. They are different from doing buildings and scenery which is what I normally do. Probably as complicated as some buildings in some respects, if not more so, as get it wrong and you can cause ingame problems. Trouble is the amount of things I am trying to do.

[JohnRN1]

Well, Jay and Fern: "I'm sorry I asked" Just Kidding.

That was good reading and now in my files too. Perhaps when I get to work with scenery and objects, I can make a working bench/table that has solid colors and not infringe on other uci's. I know it would be hard to do, but I really hate those BF benches and tables.

Thanks much,

John

[fern]

Easier said than done. We cannot change where the guests sit (the graphics) so all things involving guests interacting have to be tailored to the ingame graphics. So your guests might end up half way through the new furniture, sitting above it or in front of it

[JohnRN1]

So Fern, What you're saying is they won't be ready until next week?

[fern]

Well....... you know how long it takes to learn things. So who knows.

[ztdoctor]

boy, I've enjoyed this thread and learned a lot - thanks for all the Qs and As!!