#2031 Hero slices are associated with caterpillar ranks rather than heroes

[TeeEmCee]

Hero slices act rather weird. Slices are assigned to heroes based on their rank. If their rank changes (due to add, delete or swap of heroes) then their slices get reassigned, and the sprites and positions updated to match the hero. But any other slices you've parented to the hero slice will suddenly be parented to a different hero.

Closely related, there are always 4 hero slices regardless of the number of heroes in the active party. I know this has tripped people up, for example, it's very unexpected for "find slice at point" to find a hero that doesn't exist. I intend to mark these slices as template slices to reduce those problems. But it would be better to get rid of them.

Both changes would need a backcompat bit. (It would be the same one)

Also, I think it would be good if hero slices were preserved even when a hero is in the reserve party, so that you don't need to re-stepup slices when the party changes (in future I expect they will be preserved in saved games like other slice) and so that they can be used in future in the Party special screen or other uses.
It's perfectly legal to have slices disconnected from the slice tree, but that creates so many possible edgecases. A safer solution is probably to have a special hidden toplevel slice in the slice tree for storing "disconnected" slices.

[Bob the Hamster]

Closely related, there are always 4 hero slices regardless of the number of heroes in the active party.

This part is not a bug, definitely intentional. I have plenty of scripts that manipulate all four members of the caterpillar without checking if they exist yet or not. (Like Inn scripts, for example)

I do understand what you mean about it being potentially confusing, but I would rather just document this better. Making them into template slices is an interesting idea.

Hero slices act rather weird

Agree, that needs to be fixed.

Also, I think it would be good if hero slices were preserved even when a hero is in the reserve party

That is interesting!
It would be cool to be able to fetch a handle to reserve hero slices. It would be nice to be able to set up any slice modifications for the whole part, both active and reserve, in one script.

I like the idea of keeping a hidden toplevel for disconnected slices

[TeeEmCee]

I typed up a long reply, but SF ate it. This has happened to me before. Just when I was noticing some improvements to their bugtracker and website... no, I massively prefer bugzilla with Web 1.0 technology where pressing the back button actually works. Or github or bitbucket. Oh, and now this text input field has broken on me too.

Anyway, I think it's contradictory for each hero to have its own slice, and also for there to be slices for non-existent heroes. It would require that those extra slices are created and destroyed as heroes get added/removed from the active party, so would not actually have any use. The only purpose of having those slices would then be that you can use slice commands on the result of "get hero slice" without getting an error. But you wouldn't get one in release mode anyway. Is it much of a burden to have to check whether the slice exists?
Well, there is another potential use, which is to setup some additional placeholder slices just once in newgame/loadgame scripts (like 'hat' or 'name' child slices), since it turns out that those get kept even as the sprite gets reset to the hero's. This would be covered by the backcompat bit.

Also, notice after giving each hero its own slice, games which do something like the following will break:

global variable(1, leader slice)
plotscript, newgame, begin
  leader slice := get hero slice(0)
 end

[Bob the Hamster]

I was thinking about this more, and I mis-spoke. havign slices exist for empty caterpillar slots isn't neccisarily intended, and it isn't behavior that needs to be preserved if it causes other problems.

What definitely is intended behavior is being able to set the X, Y, Z and direction of empty hero slots. That data is currently stored in the cats() array of CaterpillarHistory objects, and it just gets copied into the hero slices.

So if removing the unused hero slices is the best thing to do, I retract my objection.

...Is it much of a burden to have to check whether the slice exists?

No, I don't think it is a burden

...Or github or bitbucket. Oh, and now this text input field has broken on me too...

How about we abandon sourceforge, and use the github issue tracker? I already have one here:
https://github.com/bob-the-hamster/ohrrpgce/issues

Since we only have 16 open bugs here, it would not be that big a deal to copy-paste them over there.

[TeeEmCee]

Maybe we should create an 'ohrrpgce' organisation on GH. Then the URL would be https://github.com/ohrrpgce/ohrrpgce/
This could become the official mirror of the svn repo, or the official repo if we ever switch from svn to git. That way you can continue having your own repo on github. Although the svn-mirroring script could push into a repo with additional non-svn branches.

GH has an API for their issue tracker, although it's pretty primitive, so you can't import a lot of stuff... like authors of comments :/ so people have of course written conversion tools. There are a bunch of alternatives. I would really like to import all our old bugzilla bugs, because there's a heap of important information there (which I can thankfully still access in my email archives)

sourceforge to gh: https://github.com/cmungall/gosf2github
bugzilla to gh: https://www.theozimmermann.net/2017/10/bugzilla-to-github
https://stackoverflow.com/questions/7281304/migrate-bugzilla-issues-to-github-issue-tracker

Example of an issue converted from bugzilla: https://github.com/coq/coq/issues/2000
It's not very pretty. I suspect this is something bitbucket does better (because Atlassian are also the authors of JIRA)

We can make sure that issue numbers on GH and Bugzilla are identical. It doesn't seem to be possible to skip over numbers, unlike SF, unless we were to add a thousand dummy issues. But because we have so few bugs on SF it doesn't matter if we renumber those.
Also, I believe there's no way to delete an issue and reassign the number, so any attempt to import had better be correct on the first try! Better test on a dummy repo.

I would be willing to figure out the scripts to migrate from SF and Bugzilla.

[TeeEmCee]

What definitely is intended behavior is being able to set the X, Y, Z and direction of empty hero slots.

I assume that you mean that this is actually what you're depending on in your scripts, not the non-existent slices existing. I figured that was probably the case. I don't have any hopes or intentions of changing that.

[TeeEmCee]

This bug has been migrated to our new issue tracker on Github: https://github.com/ohrrpgce/ohrrpgce/issues/1090