separation of multiplayer and single player characters

[vladtepesch]

What is the reason for separation of multiplayer and single player characters?

Would stand anything against the possibility to unify this (maybe as an game option)?
The separation seems to be artificial as also the single player saves a hero file allthough its ignored on the load and the player state from the game is used.

It seems to be quite easy to also use the hero file in single player. With this one could switch between multiplayer and single player mode with the same character.

[AJenbo]

The items are different, at best you could strip all items when transferring a hero from single player to multiplayer, but that would probably not be desired /expected

[ChaosMarc]

But isn't it one of the long goals to completely rewrite the savegame structure (to json), so that items are stored in full and morphing items can no longer occur? Are there still differences in the item generation between SP and MP with this change? Of course all quests would have to be MP compatible by then, too.

[AJenbo]

Net code sends the item generation code and not the full data.

[vladtepesch]

what does this mean - are there just other items that are disabled in the one or other realm or does the same id refer to different actual items? Sure in single player some items does not make sense (heal other, resurect, ... ), but also would not harm.

I hacked in a proof of concept and loading/storing back and forth between single/multiplayer seems to work - but of course no extenssive testing took place. I loaded the single player character to slot 3 and read the hero file character into slot 0 and copied some info from the game char over to the actual player (like position, pmode, ...)

[AJenbo]

Mainly some items are removed and that shifts the meaning of all other values.

[julealgon]

I tend to agree it should be unified at some point. Conceptually, it makes no sense to have the characters split: it's not intuitive at all.

I think it was done purely for technical limitations, and as a way to (attempt to) minimize hacking. Both concerns should not be a problem anymore at some point for us.

[vladtepesch]

ahh - now I understand - thank you. so at the end each item would require to have the information if it was multiplayer created or single player created to correctly recreate it from seed.
So if there would be a bit spare to store this then may be this could be handled without breaking save games. initially the type could be determined by the type of savegame and from this further on by the flag

[julealgon]

each item would require to have the information if it was multiplayer created or single player created to correctly recreate it from seed.

Oof, that sounds like a terrible hacky approach.

[AJenbo]

Correct

[vladtepesch]

each item would require to have the information if it was multiplayer created or single player created to correctly recreate it from seed.

Oof, that sounds like a terrible hacky approach.

yes - but the only way without rendering save games incompatible ;-( - it seems that the buff member has some spare bits ;)

Best thing would be to remove this dependency from the item generation. this could be done by storing the item type separately and only using the seed for the values. As far as i've seen so far, difference comes from the allowed item types and that type is sometimes rerolled or overwritten in single or multiplayer. (maybe use 8bit of the seed for the type and the rest for the generation)
@AJenbo : that is the overall devilution pretension? would such breaking changes be forbidden? are the current save games compatible with hellfire or diablo? does have savegames to be forward AND backlward-compatible?

[AJenbo]

For 1.2.1 the are fully forwards and backwards compatible, for 1.3.0 they are gracefully backwards-compatible with single player saves may have a bit of incorrect animation frames right after loading until the current animation finishes. Breaking changes are not acceptable, it's unexpected for the user and it prevents us from properly testing things.