Included in Build Post 28th July fixes

[LarryHookins]

The 16Nov16 fixes can be found in this post:

Hook's fixes | Page 6 | PiratesAhoy!

Hook

 

[Grey Roger]

From that page:

These changes have been made to the Build 14 Beta 4 WIP: 2 Apr 2016 version of the code, which is noted in LDH Notes.txt.

Can you create a version based on Build 13 Beta 4.1 from 28th July with the existing post-28th July fixes already in place?

Is this all fixes for existing bugs, or are there alterations to the basic gameplay or changes to the basic game mechanism?

 

[pedrwyth]

Does anyone have anything else to go into this?

@pedrwyth you have anything to include?

I am still working on the revised store interface to completely match normal (now all non-linear) transactions and active multipliers with sell all/auto buy, nearly nailed it but each time I check through I find slight differences in behaviour and go round the loop again. I have also tweaked the shipyard interface so any goods sales there will also be in line once done.

Given the changes I want to undertake more exhaustive checking before releasing anything

My proposed amendment of startstoryline.c allocation of starting cargo will require extensive changes (for reasons I need not go into here - but will recount in the appropriate thread in due course) so I don't think that one will be a fix anyway but more revised/new content..

So long story short - No - not at the moment

 

[LarryHookins]

The version I posted was the last known stable version I have. A week later I started getting CTDs in sea_ai.dll that I can't track down. Because I can't be certain that my code since then isn't either causing them or making them worse, the newer code is not intended for release. What you have should be fine.

Most of the work since then was the intermediate scale map, refinements to the navigator's log (and directsail debug traces), and trying to determine the cause of the CTDs.

At the bottom of the included text file is a list of all files that I changed and what I did there. This is the best place to get the info you asked for.

Directsail is a restructure, almost a rewrite. Changes to the worldmap were to add points to make transitions smoother on the normal map... they're already good enough on the open sea map. There are some changes in a couple of files that make your ship appear in the right place on the map, and to prevent odd teleports when returning from the world map. The HUD scalar enlarges the battle interface for high resolution screens. The NORMAL_TIME setting is to adjust for the game running too slow because of the need for the frame rate limiter and differences in people's computers. The intermediate scale map is a way to avoid the problems in the normal map, but I wasn't able to figure out how to swap between the normal map and the intermediate scale, so it's not implemented.

There will be people who don't know about the problems with the normal map, which generally only show up under directsail, but have an occasional effect on the world map.

For people who never use directsail, who can read the HUD text on any size monitor, and who don't care that the character runs slightly slow, these changes are unnecessary and can be discarded. As for the ship position on the map, it's updated properly the first time the directsail code runs.

I'll be here for a consulting role, but at this moment I'm concentrating on the stock COAS game. You won't be able to winmerge changes to directsail, but the others should be quite simple, and you've already got the version you want them winmerged to, which I do not.

Hook

 

[Jack Rackham]

I have uploaded on the ftp "JRH files 1955 & Baker 16-12-19".

It contains WoodesRogers update, 80 files.
Baker rifle mod, 11 files.
Bugfix Tartane50 mast had a basket in the top, 1 file.

This pack is merged to the latest zip 16-11-26 status.

 

[Pieter Boelen]

The version I posted was the last known stable version I have. A week later I started getting CTDs in sea_ai.dll that I can't track down. Because I can't be certain that my code since then isn't either causing them or making them worse, the newer code is not intended for release. What you have should be fine.

I think @Grey Roger was just wondering if you could merge it with the Beta 4.1 WIP base.

The intermediate scale map is a way to avoid the problems in the normal map, but I wasn't able to figure out how to swap between the normal map and the intermediate scale, so it's not implemented.

Maybe after the Christmas holidays, I can have a look at it and see if anything can be done there.
I'd expect that should not be all that difficult, but of course figuring it out can be tricky.

 

[Grey Roger]

Directsail is a restructure, almost a rewrite.

That puts it out of the remit of this fixes collection; it would go better into the next experimental update.

I have uploaded on the ftp "JRH files 1955 & Baker 16-12-19".

It contains WoodesRogers update, 80 files.
Baker rifle mod, 11 files.
Bugfix Tartane50 mast had a basket in the top, 1 file.

This pack is merged to the latest zip 16-11-26 status.

Can I have a pack without the Baker rifle mod, please?

Are those "Woodes Rogers" files later than what already went into the 30th November collection?

 

[Jack Rackham]

Now @Grey Roger what's the problem with the Baker rifle?

Are those "Woodes Rogers" files later than what already went into the 30th November collection?

Yes these are really new files, the ones I have been working on up util tonight.

 

[LarryHookins]

@Grey Roger Good deal. I doubt there's much in there that's a pure bug fix, and the new stuff would be better off stress tested a bit.

Hook

 

[Pieter Boelen]

In this case, I'm inclined to say @Jack Rackham's Baker's Rifle mod seems to me a VERY low-risk inclusion.
And for the DirectSail update, at least @LarryHookins is currently around for any potential troubleshooting if necessary.
So I'd be inclined to recommend INcluding them both.

@Grey Roger Good deal. I doubt there's much in there that's a pure bug fix, and the new stuff would be better off stress tested a bit.

I wonder who's ever going to test it though? Unless new stuff is "forced" onto players, new stuff generally doesn't get tested.

EDIT: And to be clear, I am of course NOT saying all experimental stuff should always be included. Obviously.
All I'm saying is that these particular two examples might be worth the risk in this case.

 

[Grey Roger]

As stated in post #1:

No experimental new mods are included. What's in:

• Bug fixes, as reported in "Build Mod Bug Tracker" and the fix reported in "New Content: Post Build 14 Beta 4.0 Public Release"
• A few other bug fixes found elsewhere
• Cosmetic changes which do not affect general gameplay
• Storyline and sidequest changes which do not affect gameplay outside their specific stories/quests

I've tried to keep out anything related to brainstorms and overhauls featured in the later ZIP updates, though something may have got in if I mistakenly included a bugfix which held code from such an update, or worse, was actually a fix for a bug in said updates.

Neither the Baker Rifle nor the DirectSail update fit in with that, and the DirectSail update goes right against the whole point.

The version of "initItems.c" included in the "JRH files 1955 & Baker 16-12-19" set also appears to have some other weapon prices changed, which is not to happen in the "Post 28th July Fixes" set. And the rifle itself appears to have an absurdly long reload time compared to other rifles.

 

[Jack Rackham]

The details you notice can always be changed. They're just merging mistakes I guess from my side.

The Baker Rifle has been out since september and no bugs have been reported.
It's NOT an experimental mod .

When is a mod meant to be accepted if not at this point?

 

[Pieter Boelen]

Neither the Baker Rifle nor the DirectSail update fit in with that

What's the problem with the Baker Rifle mod anyway? I seem to be missing something here....

From what I understand, it is a single added item with slightly different stats that is used exclusively for the Hornblower storyline.
It should only be a single line of code added to initItems.c and any other changes in that file can therefore be ignored,

Adding the item without using it cannot possibly cause any problems whatsoever; it'll just be available for use.
That makes it even less risky than ordinary "Cosmetic changes which do not affect general gameplay".

If it is also used where it is meant tobe used, then it becomes "Storyline and sidequest changes which do not affect gameplay outside their specific stories/quests".
And if it is just the stats of the item that concern you, then I'd suggest changing those numbers in such a way that they do seem OK with you.
Once an item is added, changing the numbers is not exactly difficult nor risky.

and the DirectSail update goes right against the whole point

Perhaps. But it should also serve to fix this long-standing and very annoying bug:
Fix in Progress - DirectSail and WorldMap island transfer inconsistencies | PiratesAhoy!
And if nobody except @LarryHookins makes any use of this update while he is actually around, we'll never know if it's stable and ready for inclusion or if it really requires more work.
Which means that either:
1. We never find out and are forced to forever exclude what might be a very good update
2. We add it to an experimental archive later (because nobody is making nor testing any right now), at such a time that @LarryHookins is no longer around to provide support

On the other hand, what's the worst that could happen if it is included in a new ZIP right now?
Worst case scenario is that it does introduce problems. That'll be annoying, but if you keep the current ZIP, it'll be extremely easy to revert back with no lasting harm done.
And least then we'd know for sure that it needs further work and @LarryHookins would hopefully still be around to do something about it.

----------------------------------------------------------------------------------------------------------

While I'm really very glad to see any progress still happening despite my own lack of time to do much of anything,
it seems it is still extremely difficult to maintain forward momentum in a way that works well.

Less than half a year ago, we had a ridiculous amount of experimental work being done at the same time, with nothing being properly finished and tested.
The result was a lot of new bugs without any easy way of establishing what was the cause of those bugs.
Of course the reason for that was doing too much at the same time, which I cautioned against already back then.
Unfortunately Levis and Tingyun clearly got carried away, before one did his usual vanishing act and the other one apparently decided to throw a temper tantrum or something.
So eventually that led nowhere.

As far as I can tell, there aren't a lot of players around anymore these days;
most likely because they were first chased away by TOO MUCH (unstable!) progress and then never invited back because all fell down to virtually no progress at all.
But no support to make new stuff happen and test that unfortunately also doesn't lead much of anywhere.

Because not a lot of things are being worked on at the same time right now,
that makes this an ideal time to add new stuff one by one so that any new issues can easily be traced to what was included last.
And maybe over the Christmas holidays, we might actually be able to attract some people to try that out so that early next year, we'll know the additions to either be OK or not!

 

[Grey Roger]

It may indeed make sense to add new, experimental mods, one by one so that if something then breaks, we know what did it.

The whole purpose of this collection is to be free of any such mods. Partly so that we can release a new version of Beta 4.1 for general use, as stable as possible. And partly to become the fall-back position for if things go horribly wrong as a result of an extensive mod.

As for the Baker Rifle, what has swung me in favour of including it is that it has a significant price whereas the "LongRifle_C" has a price of 1, which means if you capture a Baker Rifle then you can sell it, or you may even be able to buy it. The same is not true of the "LongRifle_C".

 

[Grey Roger]

Warning: in "JRH files 1955 & Baker 16-12-19", "PROGRAM\INTERFACE\itemsbox.c" has a massive "if... else... else... else..." chain. (So does the previous version; this one adds another "else" to it.)

 

[Pieter Boelen]

The whole purpose of this collection is to be free of any such mods. Partly so that we can release a new version of Beta 4.1 for general use, as stable as possible. And partly to become the fall-back position for if things go horribly wrong as a result of an extensive mod.

I suppose that puts some pressure on me to actually release a Beta 4.1 very, VERY soon as I doubt we can afford to remain stuck in a lull for very much longer.
With a bit of luck, I can look at some stuff finally again in the first week of January....

As for the Baker Rifle, what has swung me in favour of including it is that it has a significant price whereas the "LongRifle_C" has a price of 1, which means if you capture a Baker Rifle then you can sell it, or you may even be able to buy it. The same is not true of the "LongRifle_C".

Wasn't that the whole reason for adding it?
If I recall, Hornblower made heavy use of a custom quest rifle, which was deliberately set up a bit "weird" because of its original "only one exists" situation.
So the "Baker Rifle" was thought up to make for a more "normal" item for the Hornblower storyline and potential regular game use so that the "custom quest rifle" would no longer be necessary.

Warning: in "JRH files 1955 & Baker 16-12-19", "PROGRAM\INTERFACE\itemsbox.c" has a massive "if... else... else... else..." chain. (So does the previous version; this one adds another "else" to it.)

@Jack Rackham: Like before, if you see the chance to replace that section with some less scary code, please do....

 

[Grey Roger]

Wasn't that the whole reason for adding it?
If I recall, Hornblower made heavy use of a custom quest rifle, which was deliberately set up a bit "weird" because of its original "only one exists" situation.
So the "Baker Rifle" was thought up to make for a more "normal" item for the Hornblower storyline and potential regular game use so that the "custom quest rifle" would no longer be necessary.

No, the reason was that "Longrifle_C" was the general purpose rifle (as opposed to a couple of other quest-specific type), but someone had the idea to turn that standard, general purpose rifle into an unrealistic short-barrelled version of a Kentucky rifle, a weapon which in reality owed its potency to its long barrel. "Hornblower" needed a more realistic rifle than that, so the "Baker" was introduced. With "initItems.c" restored to its original version, the standard rifle wasn't the oddball type any more, removing the need for the new one for "Hornblower".

 

[Pieter Boelen]

No, the reason was that "Longrifle_C" was the general purpose rifle (as opposed to a couple of other quest-specific type), but someone had the idea to turn that standard, general purpose rifle into an unrealistic short-barrelled version of a Kentucky rifle, a weapon which in reality owed its potency to its long barrel.

The "Longrifle_C" was originally intended for exactly one purpose: To be found by the player in the Maltese Knight Abbey.
I think its stats were always somewhat unrealistic for that very reason.
This was the very first rifle we added to the game, with its equippable scope linked to the "first person aiming" mode.

It was later given to the Riflemen in the Hornblower storyline.
Unless I'm very much mistaken, that was the reason for giving Hornblower a different rifle.
That rifle then COULD be fully realistic, independent of its original "single quest use" in the Maltese Knight Abbey.

 

[ANSEL]

@Pieter Boelen says: "As far as I can tell, there aren't a lot of players around anymore these days;"
I am still here, active player,even I have written here for a time. I play the 28 July version.
I willing to do some test for you, just tell me what you want me to look into and I will do it.

 

[Pieter Boelen]

Thanks a lot, @ANSEL!

I think the one main thing that needs testing is @LarryHookins' fixes posted here: Hook's fixes | Page 6 | PiratesAhoy!
Unfortunately that is compatible with the 2 Apr 2016 version of the code, which is of course quite old by now.

It should be made compatible with a more recent version first, either the 28 July 2016 version OR @Grey Roger's "Post 28 July 2016 Fixes" archive.
Which of those would you prefer to test with?

I do reckon it'd be quite valuable to know if Hook's work is indeed safe for inclusion in a future stable update.