WIP New Passenger Transfer Interface

[Mere_Mortal]

I have absolutely, completely and utterly mutilated transfer_characters.c.

Actually, what I’ve done is enabled access to companion passenger lists, which by the way were already functioning, and the transferring of people between their ships. I’ve tweaked a few miscellaneous things, such as creating a toggle for individual skills and the summary.

I might have a think about implementing some way to access another ship’s passengers at sea, but as it stands the player’s own passenger list is displayed when carrying out transfers; it can very easily be switched the other way around and I think this could be more than a decent idea if ships were to be carrying random passengers, or even officers.

Instead of using the original, I have renamed the file to transfer_officers.c and left the original intact.

In order to load this new interface, I have placed the following code into the first function of transfer_main.c...

Interfaces[INTERFACE_TRANSFER_CHARACTER].SectionName = "interface\transfer_officers.c"
Interfaces[INTERFACE_TRANSFER_CHARACTER].IniFile = "RESOURCE\INI\"+GetCurrentInterfacePath()+"\transfer_officers.ini"

In order to prevent the interface from being used during boarding, this has also been set in ransack_main.c...

Interfaces[INTERFACE_TRANSFER_CHARACTER].SectionName = "interface\transfer_characters.c"
Interfaces[INTERFACE_TRANSFER_CHARACTER].IniFile = "RESOURCE\INI\"+GetCurrentInterfacePath()+"\transfer_characters.ini"

I won’t include the files, I’ll leave these changes to discretion.

Captains are not transferring properly. The interface will deliberately exit immediately afterwards to the ship screen, although the transfer will have taken place. Whatever the problem is, it means the screen has to be completely reloaded and this is being forced. In order to mitigate any chance of the player accidentally closing the window the captain must be transferred using the remove button, which actually works remarkably well and I personally prefer it this way.

To-do or ideas list...

• Upon electing to replace the captain, switch the skills area to a prompt message. Done.
• Consider allowing a current officer to remain at their post while also commanding a ship.

16:00 3rd May

 

[Pieter Boelen]

Do you need someone to check the code or the functionality?
For code, you may need some patience because I can't make any guarantees when I'll find the chance.

Hopefully somebody can test it for you in the meantime though.

 

[Mere_Mortal]

The functionality is actually pretty good, what I have intended to implement works well in its own right, it’s just these bugs. I think there is something I’m overlooking with the code, maybe one or two things causing most of the problems. Sometimes it’s a routine error, something like using GetOfficersIndex instead of SetOfficersIndex or vice-versa, or for the companion.

Do you have any links where I can learn a bit more about the language itself and the game’s own code? I’ve done a fair bit of work with PHP so I can grasp it quite well, but clearly there are some differences which are crucial to understand.

I mean, stuff like this is causing me problems...

RUNTIME ERROR - file: interface\transfer_characters.c; line: 228
missed attribute: officertype

RUNTIME ERROR - file: interface\utilite.c; line: 463
missed attribute: faceid

It’s as if a value either is in the first place or is being reset to null.

Or I just do stupid things like copy SetCompanionIndex, notice it’s supposed to be GetCompanionIndex and change it without bothering to remove the third argument form it. That’s just me being stupid, I imagine it’s stuff like this causing most of the problems.

 

[Pieter Boelen]

With missed attributes, I would do a DumpAttributes on whatever is supposed to have those attributes.
Then at least you can see a bit more clearly what is going on.

Other than that, you can have a look at the PDFs we added to the Documentation folder in the game.
There is some old but potentially useful stuff there.

 

[Mere_Mortal]

Ooh, I will get around to that but right now I have nothing to open a PDF with. I could probably get my browser to do it.

The first line was because it was looking for info on blank passenger slots, but obviously couldn’t find anything. I could see the error appearing just by clicking a blank tile so that was a huge give-away, and I’ve fixed it now. I can only assume that DumpAttributes would have either returned nothing or thrown another error.

This appears as soon as the interface loads...

RUNTIME ERROR - file: interface\utilite.c; line: 463
missed attribute: faceid

In itself this doesn’t tell me where the problem is. Since the error shows when I have passengers and four officers listed, and still does so if I remove the blank slots from the passenger list, I’m not sure why it’s doing it. Actually, it still does it if I completely remove the faces.

 

[Mere_Mortal]

I got it. Sometimes I reference something without pointing to its index.
The stupid thing is that the relevant code does nothing, so I deleted it.

Now I have no error log at all.

 

[Pieter Boelen]

Progress!

Adobe Acrobat Reader is free.

 

[Mere_Mortal]

Can somebody explain this to me?

trace ( sti(myCh.InterfaceParam.i1) )

RUNTIME ERROR - file: interface\transfer_characters.c; line: 48
missed attribute: interfaceparam
RUNTIME ERROR - file: interface\transfer_characters.c; line: 48
null ap
RUNTIME ERROR - file: interface\transfer_characters.c; line: 48
no rAP data

If I do a transfer with a berthed ship, it is sunk by the “Hand of God” (presumably because the code thinks it has no captain). I think it’s because of a check it does against the InterfaceParam.

What good is this anyway, surely we know if the main ship in a transfer is the player or a companion simply by looking at its index?

 

[Pieter Boelen]

Is looking at the index not what that code is supposed to be doing?

 

[Mere_Mortal]

Oh, of course it is. I just don’t understand stuff like this...

if(CheckAttribute(xi_refCharacter,"InterfaceParam.i1"))
{
  nMyCharacterCompanionPlace = sti(xi_refCharacter.InterfaceParam.i1);
  nCompanionIndex = GetCompanionIndex(xi_refCharacter,nMyCharacterCompanionPlace);
}

if(GetCompanionIndex(myCh,i) == sti(enemyCh.index))
{
  myCh.InterfaceParam.i1 = i;
  break;
}

Maybe I’m misunderstanding, but it seems like an awfully long route to checking if the first ship in a transfer scenario belongs to the player or a companion, and/or for setting the index to a shorter variable. Any of these will grab their indexes...

myCh.index
enemyCh.index
GetCompanionIndex(myCh,0)
GetCompanionIndex(enemyCh,0)​

... and so on. We can also deduce that the ship is a companion if its index is not zero.

And all this seems to be good for is SetCompanionIndex, at least so far as I’ve had to work with it. So why is there all this fiddly code lying around? Is there something I should better understand? I mean, this is example logic which I would use to this purpose...

if (myCh.index == 0) {
  isPlayer = 1
}
else {
  isPlayer = 0
}

SetCompanionIndex(myCh,isPlayer,i)

 

[Mere_Mortal]

Wait, hold on. Do I have this right?

GetCompanionIndex(myCh,0) -- player’s ship or the primary in a transfer
GetCompanionIndex(myCh,1) -- next ship owned by the player
GetCompanionIndex(myCh,2) -- next ship, and so on​

GetCompanionIndex(enemyCh,0) -- secondary ship in a transfer
GetCompanionIndex(enemyCh,1) -- first berthed ship
GetCompanionIndex(enemyCh,2) -- next berthed ships​

That’s actually really cool.

 

[Pieter Boelen]

I haven't a clue how that works with berthing.
But the reason for storing a number as character attribute is because that needs to be set in another interface.
Otherwise Transfer Characters wouldn't know where the new ship should go (which slot).

As for the difference between using myCh and enemyCh, do a DumpAttributes on them both to see who they are.
Probably one of the two is the player and the other a companion.

 

[Mere_Mortal]

As for the difference between using myCh and enemyCh, do a DumpAttributes on them both to see who they are.
Probably one of the two is the player and the other a companion.

Or indeed two companions. Besides, I’ve replaced passengers’ names with a string of variables, so now I just need to select them and without having to use a trace I can see the index, place and companion number for both ships.

I’m not entirely sure either why it affects it. However, seemingly berthed ships have no companion number. Since just looking at the passenger transfer screen and then leaving, that is without even taking an action, is enough to cause a berthed ship to be sunk - either a permanent status is set on the ship, such a its captain being removed, or no permanent changes are made but a value is passed along when the interface closes.

I don’t think this is usual behaviour. I have reinstated the original transfer_main.c and transfer_characters.c files but it still happens. I should probably start a fresh game to see if anything changes, who knows what I’ve been saving to file.

I have temporarily removed the code in transfer_main.c which deletes a ship under certain conditions and berthed ships are no longer being sunk. I can now see that there are no problems transferring passengers between two berthed ships, the game is more than obliged to comply.

 

[Mere_Mortal]

I have a working prototype.

Still got a few things I want to do, like getting the skills summary to toggle with the captain’s own skills. There’s also one idiotic bug I can’t seem to fix but I’ve been able to improvise on that, everything else I was having problems with are dust in the wind now.

 

[Pieter Boelen]

Congratulations!

 

[Mere_Mortal]

I’ve updated the files, but to be honest I’ll be working on it again later because a few things are still off.

Anyway, without regard as to the state of my own work, the fact that companions can transfer stuff between one another I feel could lead to new possibilities in the mod. For example, ships could have a whole bunch of passengers for the player to capture. To be fair, this is probably possible anyway with the existing set-up because a player can easily remove an officer from the 4 slots into their own passenger list, but at the same time it could be done the other way around as well - taking people from the other ship’s passenger list into their own officer slots. Maybe ships could have a chance to create some decent officers.

Have you ever thought about changing the skill values? Not the skills themselves, but increasing the numbers. The trouble is that once a player has 3 officers with near straight-tens, they’d probably never bother to look at other officers again. What about setting the value to 100? This would require some scaling to balance it, but it could make officers much more dynamic and the player might have to think more carefully about their expertise.

 

[Pieter Boelen]

Have you ever thought about changing the skill values? Not the skills themselves, but increasing the numbers. The trouble is that once a player has 3 officers with near straight-tens, they’d probably never bother to look at other officers again. What about setting the value to 100? This would require some scaling to balance it, but it could make officers much more dynamic and the player might have to think more carefully about their expertise.

Thought about, yes. And I like that idea very much, because getting up to 10 goes basically far too quick by my liking.
Nobody ever did it though and it sounds like a lot of work to me. But I'd definitely welcome it!

 

[Grey Roger]

What is the purpose of this? To make it take 10 times as long for the officer, and presumably the player as well, to reach maximum skill? Or to take the same time to reach maximum skill but it's measured on a finer scale?

The former is fine if you're playing Free Play and want to take 10 times as long doing so, and really bad news if you're playing storylines. The latter is of limited use, especially since the current system already shows percentage towards the next skill level.

You're unlikely to get officers with straight 10's due to the current levelling system which gives officers a boost in skills related to their post and nothing (or limited increase if you have the "Shared Experience" perk) in other skills. Slowing down their skill increase won't make anything more dynamic, it means you'll need to keep your three officers in their posts permanently if they're ever to gain higher skills.

 

[Pieter Boelen]

For starters I'd imagine something similar like @Mere_Mortal has been doing regarding companion and officer numbers,
so to use the SKILL_MAX #define so that people who want to increase it could do that.
Whether the final effect is to slow things down or not depends on the balancing.

As long as skills range between 1-10, for there to be any notable progression in the game, progression has to be by necessity rather quick.
That is what we've had in PotC ever since the game was originally made and there's nothing particularly wrong with that.

If skills can range between 1-100, then there could be progression for much longer, which can extend the gameplay.
And there can be a greater range of differences between different officers.

One way I imagine it could work out is that the larger range means you may have to hire low-level officers
and eventually fire them to hire higher level ones as you get to the point that you can actually afford them.

Whether people would want any of that is up to those people, of course. There is potential in it.
But it is also not particularly important. Especially since we've already had some rather large changes to Levelling lately anyway.

 

[Mere_Mortal]

I didn’t think about the effect it could have on story-lines, but it’s something I might think about. Maybe I’ll make a thread about it if I drum up any decent ideas. Right now though I’m going to see about getting the skills summary to properly display on the transfer screen.

Oh, I’ve just noticed this in globals.c...

//bool transferCaptain = false; // eliminated - no longer in use anywhere

It is now.