A few mining related bugs

[Xuri]

1) Resources such as ore (and presumably also logs, haven't checked) get depleted even if the player fails to extract any of it.

2) After mining 12 times as a player with 56 mining skill, I only got 2 iron ores, the rest of the time I got the message "You do not have enough skill to mine that ore!". The player should not be informed of ores he cannot mine, it should default to iron ore in those cases.

[stranf]

Interesting...

Is mining hard-coded or .js scripted?

If it's a script you could always use the older mining script. I never had a problem getting ore with 50 skill on the older UOx3 versions.

[giwo]

Lumberjacking is scripted, mining is still hardcoded, though it may be possible to put it out in JS now, not entirely sure quite yet....

[giwo]

Please test out mining in 0.98-3.5g, I have recently committed some changes jr made to the mining functionality, which will hopefully fix some issues.

[jr]

Please test out mining in 0.98-3.5g, I have recently committed some changes jr made to the mining functionality, which will hopefully fix some issues.

Sorting the orePreferences should fix the second problem. But note that if a region has an ore with minSkill <= miner's skill this miner will no longer find gems, because (s)he will always end up getting ore. Mining gems should probably be scripted as a special ore (with an itemlist attached) instead of being hardcoded in MakeOre().

RESOURCEMINECHECK types 1 and 2 could also be improved. While 2 is currently unimplemented 1 basically allows mining of static or land tiles named 'rock', 'mountain' or 'cave' at Z>=0. So it is possible to mine a single rock static, but not 'rocks' or 'boulder' AFAICS there also is no tile named 'mountain'.

If someone tells me how this should work from a player/configurator perspective I might be able to implement it, though it's probably better to move this to JS first (which is beyond my meagre hacking skills

[jr]

1) Resources such as ore (and presumably also logs, haven't checked) get depleted even if the player fails to extract any of it.

I've checked it. There is a 50-50 chance on a failed skill check to destroy one resource. IMO that seems ok. Should this chance be configurable?

[Maarc]

Hmmm, interesting question. I'd suggest that in general, it doesn't need to be too configurable. Given that skills such as this will end up moving to JS, you can argue that you could make it configurable that way. Have a standard 50/50, and if there is the presence of a custom tag (say, "OREFAILRATE") attached to the region (need to check if regions can have custom tags too), use that instead.

[jr]

Following is a reimplemented MakeOre (in skills.cpp) that makes mining of non ore items (e.g. gems) configurable (and also removes the requirement that a region's ore preferences be sorted as well as making GetOreChance superfluous).

Code: Select all

void MakeOre( CSocket& mSock, CChar *mChar, CTownRegion *targRegion )
{
	if( targRegion == NULL || !ValidateObject( mChar ) )
		return;

	const UI16 skill		= mChar->GetSkill( MINING );
	const size_t numOres	= targRegion->GetNumOrePreferences();
	const orePref *ore		= NULL;

	// first compute the chance sum for all ores minable with character's skill
	int accessibleOreChance	= 0;

	for( size_t i = 0; i < numOres; ++i )
	{
		ore = targRegion->GetOrePreference( i );

		if( (ore != NULL) && (ore->oreIndex != NULL) && (ore->oreIndex->minSkill <= skill) )
		{
			accessibleOreChance += ore->percentChance;
		}
	}

	// select from the accessible ores
	int oreChance = RandomNum( static_cast< SI32 >(0), static_cast< SI32 >(accessibleOreChance) );

	// find the selected ore
	int sumChance = 0;

	for( size_t i = 0; i < numOres; ++i )
	{
		ore = targRegion->GetOrePreference( i );

		if( (ore != NULL) && (ore->oreIndex != NULL) )
		{
			const miningData *oreData = ore->oreIndex;

			if (oreData->minSkill <= skill)
			{
				sumChance += ore->percentChance;

				if( sumChance >= oreChance )
				{
					if ( oreData->itemList.empty () )
					{
						UI08 amtToMake = 1;
						if( RandomNum( 0, 100 ) > targRegion->GetChanceBigOre() )
							amtToMake = 5;

						CItem *oreItem = Items->CreateItem( &mSock, mChar, 0x19B9, amtToMake, oreData->colour, OT_ITEM, true );
						if( ValidateObject( oreItem ) )
						{
							const std::string oreName = oreData->name + " ore";
							oreItem->SetName( oreName );
							mSock.sysmessage( 982, oreName.c_str() );
						}
					}
					else
					{
						Items->CreateRandomItem( &mSock, oreData->itemList );
						mSock.sysmessage( 983, oreData->name.c_str() );
					}

					// nothing more to do, since we already created the item
					return;
				}
			}
		}
	}

	mSock.sysmessage( 1772 );
}

To compile this you also need to add the new itemList member to struct miningData (in skills.h)

Code: Select all

struct miningData
{
	UI16 colour;		// colour of the ore, for colour of ingot
	UI16 minSkill;		// minimum skill needed to make the ingot
	std::string name;		// name of the ingot: no need to be fixed, as we're loading it dynamically
	bool foreign;		// if not iron, then it can print out that it's a stranger ore when failing
	int makemenu;		// the makemenu required for making with
	UI08 minAmount;		// min number of ingots to load anything
	std::string itemList;		// name of the item list if not normal ore

	miningData() : colour( 0 ), minSkill( 0 ), name( "" ), foreign( false ), makemenu( 0 ), minAmount( 0 ), itemList( "" )
	{
	}
};

and the following case to LoadMiningData (in cSkills.cpp)

Code: Select all

							case 'i':
							case 'I':
								if( UTag == "ITEMLIST" )
									toAdd.itemList = data;
								break;

In dictionary message 983 the word gem should also be replaced by a %s.

Configuration then just requires adding a new entry to the ORE_LIST section (in skills.dfn) and the description of the minable resources (also in skills.dfn)

Code: Select all

[Gem]
{
MINSKILL=850
NAME=gem
ITEMLIST=digginggems
}

This works quite well. Note that this will still produce the 'not enough skill' message if the region is (via OREPREF) configured to contain only ores that are beyond the characters mining skill. IMO that's a feature

[jr]

Hmmm, interesting question. I'd suggest that in general, it doesn't need to be too configurable. Given that skills such as this will end up moving to JS, you can argue that you could make it configurable that way. Have a standard 50/50, and if there is the presence of a custom tag (say, "OREFAILRATE") attached to the region (need to check if regions can have custom tags too), use that instead.

Souds like a good plan to me

[Kiff]

Do gems have makelists for them? Can you currently make gem armour?

[Xuri]

Kiff: No, and no. You can implement that yourself though by creating a new (or adding to an existing) dfn file in dfndata\create\, and adding gem armours to the dfns in dfndata\items\

[Xuri]

Have we implemented the changes jr posted in this thread yet? If not, any reasons why we shouldn't do it?

[Maarc]

Nope, and maybe. It's been a couple of months, and I'm guessing the JS engine's more flexible now. The question isn't whether it's useful (it is), but whether it needs to be done in code, or whether it should be done via JS these days. That'd be the harder question, tbh.