Archived UOX3 Version (0.98-3.6 - Updated April 5th, 2006)

giwo · Post by **giwo** » Sat Mar 11, 2006 10:29 pm

Well remember, every new storage container we add to a character increases the memory consumption of UOX3 by an exponential amount.

Basically we should be striving to make UOX3 itself as basic as possible, allowing the JS to handle anything "custom". Since there is nothing in OSI's UO that allows for increased weight-carrying capacity, it's not something inherent to the UOX3 server.

Grimson · Post by **Grimson** » Sat Mar 11, 2006 11:07 pm

With your latest changes we don't add or subtract weight for items that have their layer definded as 0, meaning we can carry and indefinite amount of non-equipable items.

This is because CWeight::subtractItemWeight( CChar *mChar, CItem *item ) and CWeight::addItemWeight( CChar *mChar, CItem *item ) checks against the layer setting of the item, not the layer of the char where the item has been placed.

giwo · Post by **giwo** » Sat Mar 11, 2006 11:09 pm

Hmm, not really...

Firstly, IL_NONE is where we put the tradewindow. We should NEVER equip anything on a character at IL_NONE, but the tradewindow.

Secondly, those functions only apply to characters, items are only "in" the character container by their layer, so there will only be one item on layer IL_NONE, and it must have that layer to be on that layer of a character.

Grimson · Post by **Grimson** » Sat Mar 11, 2006 11:13 pm

giwo wrote:Hmm, not really...

Check it by yourself, put a book in your backpack, move it on the ground put it back in and your weight won't change a bit. Do the same without the check agains layer 0 and it will work.

giwo · Post by **giwo** » Sat Mar 11, 2006 11:23 pm

Ahh, I see what you're saying...

That's because it's recursive, so we simply need to change what it's checking the layer of, not make it add the weight of all items without a layer.

giwo · Post by **giwo** » Sat Mar 11, 2006 11:45 pm

Code: Select all

[color=yellow]3/11/2006 - giwo (0.98-3.5e [3.6 BETA])[/color]
	Fixed an issue causing items with no layer to not change the weight of a character.
	Fixed an issue causing spells that require a targeted location not to function.
	Fixed an issue allowing one to build a house or boat far from their location.
	Fixed an issue allowing one to build a multi directly on top of another multi.

Maarc · Post by **Maarc** » Sun Mar 12, 2006 5:44 am

I just had a look at the latest CVS updates, and while I think the concept of damage resistance and such is good, I think Grimson, you're reinventing the wheel, in some forms.

You've added a DamageType enum, for resistance and such. While that's fine that you want to do such things, part of the whole weather system when I originally created this was to tie in elemental damage already. If you look already, Items possess properties dictating what elemental type they belong to (based upon the WeatherType enum). So they can already be heat, cold, lightning (energy) sort of weapons already, and we already deal with combat damage through that (a race weak to that elemental type and a weapon of that type will deal double damage).

Fire, cold, energy and poison you're adding in. Granted, poison's not covered through the WeatherType enum (though it probably could be, poisonous fog anyone?). Fire, cold and energy you can already cover through the use of WeatherType, rather than having to invent the DamageType like you've already done. And there's already, as I've said, a precedent for using this through items.

I'd suggest (and you can shoot me down if you want), that rather than reinventing something, that you already use what is there. I think it's more flexible, gives you a wider range of types, and there's already partial hooks in for it already.

Maarc · Post by **Maarc** » Sun Mar 12, 2006 8:15 am

Code: Select all

[color=yellow]12th March, 2006 - Maarc[/color]
	Changed some id >= 0x4000 comparisons to CanBeObjType( OT_MULTI ), for clarity
	Fixed a bug with applying NPC sections where if you specified ALCHEMY values, it would fail to apply correctly

giwo · Post by **giwo** » Sun Mar 12, 2006 9:20 am

Code: Select all

[color=yellow]3/12/2006 - giwo (0.98-3.5f [3.6 BETA])[/color]
	Removed CMulHandler::AverageMapElevation() as it was superfluous.
	Removed CTileUni height in favor of top, to reduce calc_walk() calculations.
	Removed CTileUni id as its use was unnecesarry.
	Rewrote CMovement::calc_walk() to improve overall readability and speed.
	Merged CMovement::calc_WaterWalk() with calc_walk().
	Removed higher() as UOX_MAX() does the same thing.
	Removed CMovement::validNPCMove() as it was superfluous.
	Modified house placement to make it impossible to place a house on the ocean.

Grimson · Post by **Grimson** » Sun Mar 12, 2006 2:49 pm

Maarc wrote:You've added a DamageType enum, for resistance and such. While that's fine that you want to do such things, part of the whole weather system when I originally created this was to tie in elemental damage already. If you look already, Items possess properties dictating what elemental type they belong to (based upon the WeatherType enum). So they can already be heat, cold, lightning (energy) sort of weapons already, and we already deal with combat damage through that (a race weak to that elemental type and a weapon of that type will deal double damage).

I see, as you applied those propertys through "SetWeatherDamage()" I actually thought those items should take damage when exposed (by wearing them) to the specific weather type.

Maarc wrote:Fire, cold, energy and poison you're adding in. Granted, poison's not covered through the WeatherType enum (though it probably could be, poisonous fog anyone?). Fire, cold and energy you can already cover through the use of WeatherType, rather than having to invent the DamageType like you've already done. And there's already, as I've said, a precedent for using this through items.

I'd suggest (and you can shoot me down if you want), that rather than reinventing something, that you already use what is there. I think it's more flexible, gives you a wider range of types, and there's already partial hooks in for it already.

I'll have to overthink my plans for elemental resistance then.

Grimson · Post by **Grimson** » Sun Mar 12, 2006 7:32 pm

Code: Select all

[color=yellow]3/12/2006 - grimson[/color]
	Removed DamageTypes enum and added POISON to WeatherTypes.
	Renamed DamageResist functions into ElementResist and moved them to cBaseobject.cpp.
	Renamed DFN tag DAMAGERESIST to ELEMENTRESIST and use it also for items.
	Added DFN tag POISONDAMAGE to items so that they can also do poison damage on attacks.
	Added functions calcElementDef(), getElementDef() and checkElementDef() to combat.cpp
	to calculate the resistance against elements similiar to the def value of armor.
	Changed AdjustRaceDamage() to also take into account the elemental resistance of the target.
	Use calcElementDef() in MagicDamage() similiar to calcDef() in calcDamage() to take the
	elemental resistance into account.

I'm still working on poison, so that is not complete.

You can now give items and npcs elemental resistance against fire, cold, energy and poison. They are used the same way armor is used. Additionally chars can gain a basic resistance against those elements of up to 5%, when USECHARRESISTANCE is set to 1 in the ini.

Grimson · Post by **Grimson** » Sun Mar 12, 2006 10:31 pm

Code: Select all

[color=yellow]3/12/2006 - grimson[/color]
	Added element resistance calculation to weather damage.
	Fixed calcElementDef() and getElementDef() so that the chars basic element resistance
	is always added.
	Changed MagicDamage() so that we always do at least a little bit of damage.

Grimson · Post by **Grimson** » Sun Mar 12, 2006 11:33 pm

Code: Select all

[color=yellow]3/12/2006 - grimson[/color]
	Changed the z value for various LineOfSight() calls so that we actually check whether
	we can see the face of the targeted char instead of his feets.

Grimson · Post by **Grimson** » Mon Mar 13, 2006 1:04 am

Code: Select all

[color=yellow]3/13/2006 - grimson[/color]
	Changed CPICreateCharacter::newbieItems() so that the default items aren't placed inside
	the players backpack until they have their final ID, to prevent the adding of wrong weight
	values.

giwo · Post by **giwo** » Mon Mar 13, 2006 1:37 am

If ID is modifying weight (I'm guessing it's because we pull tile.weight() ) then on ID changes of items we should do something like if( GetCont() { subtractItemWeight(); } id = newID; if( GetCont() ) { addItemWeight(); }

Grimson · Post by **Grimson** » Mon Mar 13, 2006 1:58 am

giwo wrote:If ID is modifying weight (I'm guessing it's because we pull tile.weight() ) then on ID changes of items we should do something like if( GetCont() { subtractItemWeight(); } id = newID; if( GetCont() ) { addItemWeight(); }

Good point, and we should probably do the same in SetWeight().

Edit:
I have made those changes here, but currently can't commit them as CVS seems to be dead again.

Maarc · Post by **Maarc** » Mon Mar 13, 2006 7:45 am

CVS should be working again. Has been out for most of the day for me, but has started to work again.

Code: Select all

[color=yellow]13th March, 2006 - Maarc[/color]
	Altered the CBO resistances code to use an array rather than a number of variables
	Note that we're still only saving out a subset of these resistances, because only a subset ever get checked at the moment
	This could easily change in future, with people wanting to use other elemental stuff
	Adjusted CItem::CopyData() so that it copies all the WeatherDamage values instead of only a couple
	Upgraded the container size on weatherBools, as the number of weather entries has moved beyond a UI08 size

Grimson · Post by **Grimson** » Mon Mar 13, 2006 8:40 am

Code: Select all

[color=yellow]3/13/2006 - grimson[/color]
	Changed CBaseObject::SetWeight() and CBaseObject::SetID() so they also update the weight
	of the container the item is in, when it is an item and when it is within a container.

giwo · Post by **giwo** » Mon Mar 13, 2006 10:59 pm

Code: Select all

[color=yellow]3/13/2006 - giwo (0.98-3.5g [3.6 BETA])[/color]
	Converted Numeric DFN's to a Signed Long rather than unsigned by default for *nix compatability.
	Merged jr's fixes for cygwin compatability and fixing some minor gameplay issues.
	Modified ModelBoat() to automatically move you off the boat (if near land).
	Fixed a crash bug involving boats.
	Changed several calls checking against type IT_PLANK to CanBeObjType( OT_BOAT ).
	Fixed an issue causing boat holds to "explode" when opening them.
	Fixed an issue causing containers inside containers on the ground to be "too far away".

Grimson · Post by **Grimson** » Tue Mar 14, 2006 8:18 pm

Code: Select all

[color=yellow]3/14/2006 - grimson[/color]
	Fixed item IDs for human corpses in newCarveTarget().

Ultima Offline eXperiment 3 forums

[ARCHIVED] Archived UOX3 Version (0.98-3.6 - Updated April 5th, 2006)