Build 14 Beta 1

[Pieter Boelen]

I had a quick check between my current Sulan-based file and Black Bart's original file, but both use the same picture index numbers for the weapons you've mentioned.
As such, I don't know where the problem came from. Should be a fairly simple change in initItems.c though. :wacko:

 

[Black Bart]

Keep in mind i had started to use Sulans new file also, so the file i currently have is a version of Sulans file, i've just been re-editing mine for the current new item+weapons stats that i'd been testing. You'd need to go back to the pre Sulan format, where we had two tables of weapons(one after the other) to not get the weapon icon issue. I'm guessing that initItems.c file would have been the one in patch 6 maybe?

 

[Pieter Boelen]

It's a weapons/picture mismatch. For instance the papenheimer rapier is shown as a machete or something. This was mentioned some time ago but must have fallen through the cracks.

Should be fixed with attached file. Seems that in the old two-table system, the "Weaponsmod OFF" table had some different (read: WRONG) interface pictures set up that ended up being used in ALL cases now.
I double-checked all mismatches between the two tables and used the GM Viewer with the TX Converter to ensure that the correct pictures are now being used for the correct weapons.
Even the original table had an error, because bladeC6 and bladeC10 used the same interface picture, so that is now corrected too.

Was there a problem with guns also or are they good? I didn't check those yet.

 

[Pieter Boelen]

Black Bart, do you have an initItems.c file containing your latest work that is based on Sulan's latest file? If so, I could include that in Patch 7 as well for testing.

 

[Hylie Pistof]

All weapons so far seen have the correct pictures again.


The guys who come up to you and say "Psssst! I have something you might like." still show blanks except for the golden cuirass. :hmm



The fighting seems very haphazard at first, with one guy going down with little damage to me then the next one cutting me down in 2 strokes.

Now at level 8 combat is very difficult to impossible. The poisoned throwing knife works but the ether bottle now does not. It also takes 2-6 grenades to kill anyone. The long pistol is ineffective.

 

[Pieter Boelen]

The interface pictures are the only thing I touched in that file.

The guys who come up to you and say "Psssst! I have something you might like." still show blanks except for the golden cuirass. :hmm

I suspect that is because there are no longer any high-level weapons for them to have.
Maybe if I could find the code that sets the criteria for items appearing at these guys, we could loosen them up so they'd still show stuff.
What are supposed to now be the high-level weapons that are NOT unique/quest items?

 

[Pieter Boelen]

Did we ever find out the best fix for the "ship turning to port in a storm" issue? This is the one I've got for inclusion at the moment:

			if(!CheckAttribute(arCharShip,"stormimp"))
{
switch(rand(9))
{
case 0: arCharShip.stormimp = fRotate; fRotate -= 0.02; break;
case 1: arCharShip.stormimp = fRotate; fRotate += 0.02; break; // PB: Not just to port
}
arCharShip.Impulse.Rotate.y = fRotate;
}

 

[Hylie Pistof]

I have forgotten where that code is located, but what I have works well except for the occasional instance of the ship going into a hard spin to the left when the storm ends.

 

[Sulan]

I'm back for some time at least - but may be off again soon because of rl work. I noticed that I erroneously "killed" some textures. Sorry for that. I'll use the corrected file Pieter provided and merge it with my Historic weapons modification.

 

[Pieter Boelen]

That's PROGRAM\SEA_AI\AIShip.c . We don't want crazy spins once the storms are over, do we?
What if we do this?

		/*float fRotate = stf(arCharShip.Impulse.Rotate.y) + (frnd() * 0.08 - 0.04);
if (fRotate > 0.07) { fRotate = 0.07; }
if (fRotate < -0.07) { fRotate = -0.07; }*/
float fRotate = stf(arCharShip.Impulse.Rotate.y);
if(frnd() < 0.5)
{
if(CheckAttribute(arCharShip,"stormimp"))
{
arCharShip.Impulse.Rotate.y = arCharShip.stormimp;
DeleteAttribute(arCharShip,"stormimp");
}
}
else
{
if(!CheckAttribute(arCharShip,"stormimp"))
{
switch(rand(9))
{
case 0: arCharShip.stormimp = fRotate; fRotate -= 0.02; break;
case 1: arCharShip.stormimp = fRotate; fRotate += 0.02; break; // PB: Not just to port
}
arCharShip.Impulse.Rotate.y = fRotate;
}
}
// NK <--
}
else
{
if(CheckAttribute(arCharShip,"stormimp"))
{
arCharShip.Impulse.Rotate.y = 0;
DeleteAttribute(arCharShip,"stormimp");
}
}

It seems that once the storm is over, it could be that the turning impulse remains. This additional else{} case should remove any turning impulse once the storm is over, hopefully stopping the spins after the storms.

 

[Hylie Pistof]

No we don't want that spinning ever. It clicks in at the moment the storm stops. I found the part and hope I got it in there ok.

 

[Pieter Boelen]

Use attached file if you're not sure. I think what might be happening is that you got a turn impulse just before the storm ended and that impulse is not being removed. Hopefully the code I added will do that.

Alternatively, maybe I should just rewrite that entire section of code until I actually understand what it does.
Right now, I'm guessing because I can't quite follow the logic that went into writing it.

 

[Hylie Pistof]

I will compare this one to mine. One thing. You are still showing a force of +- .02. I have been using +- .01 for some time. .02 gives a wild ride.


OK, I just did a Winmerge of the 2 AIship files and here is the total differences.

 

[Pieter Boelen]

Your copy is correct, mine is not.

 

[Baste]

I think I have fixed the problem. It seems there really isn't any correlation between my critical hit changes and the pierce calculation, but I found another error I also missed earlier and after it was fixed it seems the "instant death" problem is gone. I have posted about it here: http://forum.piratesahoy.net/index.php/topic/15312-some-questions/page__view__findpost__p__410419

They have no correlation, but it seems this fixed both problems. Strange.

I'm uploading the updated Patch 7 WIP 2 LAi_fightparams file. Please try it and see if the "instant death" problem is gone for you too. Note that the pistol change is also included.

switch(rand(9))
{
case 0: arCharShip.stormimp = fRotate; fRotate -= 0.02; break;
case 1: arCharShip.stormimp = fRotate; fRotate += 0.02; break; // PB: Not just to port
}

Choose between ten (0-9) outcomes but only two (0-1) are possible? :wacko:

 

[Hylie Pistof]

Your copy is correct, mine is not.

My copy may be correct, but I got an Instacrash with it. :764: I'm using yours now, and before and after testing says that +-.02 is too much for me. A 4 masted caravel with lateens was not controllable by me and tossed cargo and crew while spinning this way and that. I'm going back to +-.01.



Baste, I will try that ASAP. :2up

 

[Pieter Boelen]

Thanks a lot! I'm adding your latest file to my game and see what happens when I release Patch 7.
Personally I never encountered instant death, but that's because I never played it to find out. ops2

switch(rand(9))
{
case 0: arCharShip.stormimp = fRotate; fRotate -= 0.02; break;
case 1: arCharShip.stormimp = fRotate; fRotate += 0.02; break; // PB: Not just to port
}

Choose between ten (0-9) outcomes but only two (0-1) are possible? :wacko:

I know it looks weird, but I suspect that the idea is that there is a 2-in-9 chance of being rotated.

 

[Pieter Boelen]

My copy may be correct, but I got an Instacrash with it. :764: I'm using yours now, and before and after testing says that +-.02 is too much for me. A 4 masted caravel with lateens was not controllable by me and tossed cargo and crew while spinning this way and that. I'm going back to +-.01.

Attached works for me. Ignore any code related to Steam Ships; I'm messing around with those at the moment.

 

[Pieter Boelen]

The steamship sound code led me to rewrite the "speed up time" keys [R] and [G] a bit. With my new code, [R] will speed up time in steps from 1x to 3x, 10x and 30x and [G] slows things down again from 30x to 10x, 3x and back to 1x.
Does that make more sense to you? I always did think the R/G stuff was a bit more complex than it should be, especially the coding behind it which was confusing the crap out of me just now.
Here's what I did:

		case "BOAL_Control":
if(dialogRun || dialogSelf || CheckAttribute(PChar,"paused")) break;//MAXIMUS
// NK basetime 05-04-25 -->
if(CheckAttribute(PChar,"basetime")) basetime = stf(PChar.basetime);

if(!CheckAttribute(PChar,"timescale")) PChar.timescale = 1;
AddPerkToActiveList("TimeSpeed");
switch(sti(PChar.timescale))
{
case  1: PChar.timescale =  3; break;
case  3: PChar.timescale = 10; break;
case 10: PChar.timescale = 30; break;
}
SetTimeScale(basetime*sti(PChar.timescale));
LogIt(XI_ConvertString("Time") + " x" + PChar.timescale);
//Log_SetStringToLog("Test R");
/*	if(IsPerkIntoList("TimeSpeed"))
{
SetTimeScale(basetime);
DelPerkFromActiveList("TimeSpeed");
Log_SetStringToLog(XI_ConvertString("Time") + " " + "x1");
PChar.timeaccel1030 = "30";
}
else
{
SetTimeScale(3.0 * basetime);
Log_SetStringToLog(XI_ConvertString("Time") + " " + "x3");
AddPerkToActiveList("TimeSpeed");
PChar.timeaccel1030 = "30";
}*/
break;

case "BOAL_Control0":
if(dialogRun || dialogSelf || CheckAttribute(PChar,"paused")) break;//MAXIMUS
if(CheckAttribute(PChar,"basetime")) basetime = stf(PChar.basetime);

if(!CheckAttribute(PChar,"timescale")) PChar.timescale = 1;
switch(sti(PChar.timescale))
{
case 30: PChar.timescale = 10; break;
case 10: PChar.timescale =  3; break;
case  3: PChar.timescale =  1;
DelPerkFromActiveList("TimeSpeed"); break;
}
SetTimeScale(basetime*sti(PChar.timescale));
LogIt(XI_ConvertString("Time") + " x" + PChar.timescale);
//Log_SetStringToLog("Test G");
// NK Fixed 04-09-08 to actually toggle.
/*	if(!IsPerkIntoList("TimeSpeed")) { AddPerkToActiveList("TimeSpeed"); }
if(!CheckAttribute(PChar, "timeaccel1030")) PChar.timeaccel1030 = "30";
if(PChar.timeaccel1030 != "30")
{
PChar.timeaccel1030 = "30";
SetTimeScale(30.0 * basetime0);
Log_SetStringToLog(XI_ConvertString("Time") + " " + "x30");
}
else
{
PChar.timeaccel1030 = "10";
SetTimeScale(10.0 * basetime0);
Log_SetStringToLog(XI_ConvertString("Time") + " " + "x10");
}*/
// NK basetime <--
break;

In PROGRAM\seadogs.c

 

[Black Bart]

Thanks a lot! I'm adding your latest file to my game and see what happens when I release Patch 7.
Personally I never encountered instant death, but that's because I never played it to find out. ops2

switch(rand(9))
{
case 0: arCharShip.stormimp = fRotate; fRotate -= 0.02; break;
case 1: arCharShip.stormimp = fRotate; fRotate += 0.02; break; // PB: Not just to port
}

Choose between ten (0-9) outcomes but only two (0-1) are possible? :wacko:

I know it looks weird, but I suspect that the idea is that there is a 2-in-9 chance of being rotated.

Yeah it's just a small chance within the rand function, you don't want to spin out of control all the time! My code for that section mirrors the commented out code above(line 4534 and 4535) so is = 0.02 for the positive and = -0.02 for the negative. After a number of test runs between that and the code you posted above it just seemed to work more reasonably(less likely to get a stuck in spin situation after the storm), but i haven't tested it recently to comment on it more.

As for my initItems.c file, it keeps some of the old format(so the second table(just commented out for now) and was a real pain to compile(took over a week as Sulan was doing his changes). The values are nice though for trade goods etc, BUT i also have 'stealth' items available as buyable in shpos etc. I'll post it anyway but it is not a simple winmerge effort to get the numbers across, it will have to be done manually! Also it still has the icon mix ups you fixed and i havent ported those across yet. So erm, you might not want it really!

@Baste i've downloaded your latest LAI_fightparams.c file and hope to give it a test run next week sometime, glad your still working on it