Server pack works on linux, fails on PC

[Talonos]

The server pack for my modpack works on my ubuntu server but doesn't work on windows.

The pack is located here: http://www.technicpack.net/modpack/blightfall.592618/about

When I run it, it displayed a lot of unhelpful junk, but *did* say that there was a class format error, claiming there was a duplicate "world" class: http://pastebin.com/PRp9jS5K

Can anybody suggest what might be the problem?

Thanks a ton.

[plowmanplow]

Server Pack:

• You have two copies of CoFHCore (one with (1) in the title). Duplicates are always bad, and I've already mentioned the (1) issue in a previous post to you.
• You still have CoFHLib in the /mods/ folder. As I previously mentioned, this does not belong. (It's still in your client pack as well... are you not heeding my advice?)
• Your Thaumcraft and ThaumicTinkerer still don't match.
• You really want to be using AE2rv2 and Chisel 2.
• Your BigReactors is out of date.
• Your Waila version is still woefully of date and doesn't match your other mods.

None of the recommendations I made for your client pack have been fixed. Why are you asking for help again when you haven't addressed the previously noted issues?

[Talonos]

Short answer: Because it was a different issue, and the first issue (that I originally asked for help on) was resolved without making those changes.

As for why I didn't make those changes as well...

I've been reluctant to update my modpack because it comes packaged with an adventure map. My understanding is that if I update the client pack, anything in the user's directory that is named identically to anything in my modpack zip folder will be overwritten with what I push. I'm frightened that if I update, any users "updating" to the new version of the modpack will have their worlds overwritten and be upset. Because of that, I have intentionally been trying to update as little as possible. I hotfixed the Mac issue in a way that left both versions compatible with each other and wouldn't trigger an update, but replacing mods is too great a change. The breach of trust that comes from accidentally deleting a user's world is of greater concern to me than a woefully outdated WAILA version. Here's my question to you: If I push an update, will my users' worlds be safe? If so, the reason I've been reluctant to update is invalid, and I will probably update the mods you mention tomorrow, if not tonight.

As for the server pack, I don't mind fixing those issues because there has, by definition, been no successful downloaded server worlds yet. But I feel I can only fix them insofar as they remain compatible with the client.

It's obviously the duplicate mod causing the issue. I verified it works upon removal of the CoFHCore-[1.7.10]3.0.0B9-40 (1) jar. I'm kinda ticked at myself, because that's actually glaringly obvious in retrospect. I'm just confused as to how that duplicate got in there when I thought I just pulled it directly from my (functional) linux box. :/

Not ignoring feedback, just clueless in other ways. Thanks for pointing the extra CoFH-Core out.

Edited February 18, 2015 by Talonos

[plowmanplow]

I applaud your efforts to provide a consistent, uninterrupted game play experience to your users. That desire will serve you well over time.

 

As for the updates, as long as you stay within the same version of MC (1.7.10) you'll almost never have an issue. All of the mods I mentioned will update without any impact on world saves which players have created. For things like Thaumcraft and ThaumicTinkerer not matching, this WILL cause your world to crash eventually. The version of TT you have has implemented features that don't work with the version of Thaum you have. If someone attempts to make certain TT items and gets them into their inventory, the client will crash. Same issue with any mods with provide Waila integration. There was a significant API change in Waila after the version you are using which most other mods have included. This will cause issues if you don't update.

[Talonos]

Thank you. When you said "Why are you asking for help again when you haven't addressed the previously noted issues?" I first assumed it was a rhetorical question meant to berate me for failure to implement your suggestions. Then, I said "Nah, this guy is blunt, but genuine. If I treat it as an honest question and explain my reasoning, things will be okay." Seems I was right. Thank you for you unique brand of helpfulness and patience.

I also appreciate knowing that there is nothing world-breaking about the mod upgrades. While world-breaking mod updates are rare and almost always explicitly mentioned in changelogs, It's nice to have outside assurance. I also appreciate knowing that the TT and Thaumcraft mismatch is a bigger problem than it appears to be on the surface. That will be a high priority fix.

I feel you have missed my main concern, however. My modpack contains a pre-packaged adventure map in the "saves" folder. When the users play my modpack, they change that map in their local version of the saves folder. If I update my modpack, then what happens to the user's saved map? Will the map in my zip file "clobber" the user's version?

Or, more generally, when a user is prompted to update his modpack and presses "yes", what files specifically are replaced, which ones are deleted, and which ones are ignored? Are there specifications I could see that show me the "Update algorithm"?

Perhaps such a question merits it's own thread... Want to hop threads again, seeing as though you solved my original issue regarding the server?

[plowmanplow]

Ahh, yes. If you include the world save in your modpack archive it will most definitely "clobber" the local user's save and anything they have changed. There are a few ways you could distribute the world save in a non-destructive way:

• Zip up the "starting" world into an archive in the /saves/ folder. Clients can extract that ZIP to the /saves/ folder the first time they want to start the world and then if you change the ZIP file later it won't overwrite their active save. This would be a close second to the last option if you don't want users to have to download extra files.
• Instruct users to change the folder name of the world save before they launch the pack for the first time. This is likely to cause issues/frustration for the "less informed" among your user-base.
• Distribute the world save as an additional download. This would be my first choice.

Edited February 18, 2015 by plowmanplow

[Talonos]

Perfect. Thanks for the info. I'll see what I can do with that, then, starting tomorrow.