Feature Request: House Add-on multi type.

[Yukiko]

This is more of an update to UO Convert than a "feature request". At some point the powers that be at Origin Systems Incorporated/Electronic Arts/Broadsword, call it what you want, added to the myriad of multis the category "house add-ons". These include such things as forges, the chicken coop, and the garden shed. UO Convert should have this category added to its other two multi categories, house and boat. Currently it classifies all unknown multis as houses but house add-ons are not houses. I would be willing to assist in creating a list of the multi numbers of some of the house add-on multis. There are other multi categories as well. Some are for quests but for now just adding house add-ons would help.

One benefit of having an item or set of items, such as a large forge, placeable as a multi is they reduce the item count on a shard versus having them placed as dynamic items. Multis are treated similar to static items. Any GM with the moveany privilege enabled can see this in game by hovering their "finger" over a multi item. It does not change colour.

[Tomi]

This would actually require a bit bigger changes because there are only House/Boat classes in Pol and functions for those.

Im just wondering whats the problem of having these others as houses ?
For forges clicking you should anyway use the TargetCoordinates function because otherwise static forges doesnt work either so no problem there having it as a house

Or is the thing you really are looking for just something like multi_type or .isA class to recognize these ?

[Yukiko]

Thank you Tomi for responding. I didn't realise the extra work involved in "just" adding house add-ons to uoconvert. It might be useful to have them as an isA class but at the moment I cannot think of anything specific.You would know better than I how hard it is to add them as a new class.

My original thinking was more basic than that. When new users, and even some old users see uoconvert "spam" the console with the message that uoconvert is assuming it is a house they think it is an error.

[Tomi]

Checked how this is and it seems there are only Boats, Houses and Stairs in uoconvert.cfg

if ( elem.type_is( "MultiTypes" ) )
{
temp = elem.remove_string( "Boats" );
ISTRINGSTREAM is_boats( temp );
std::string graphicnum;
while ( is_boats >> graphicnum )
UoConvert::BoatTypes.insert( strtoul( graphicnum.c_str(), NULL, 0 ) );

temp = elem.remove_string( "Houses" );
ISTRINGSTREAM is_houses( temp );
while ( is_houses >> graphicnum )
UoConvert::HouseTypes.insert( strtoul( graphicnum.c_str(), NULL, 0 ) );

temp = elem.remove_string( "Stairs" );
ISTRINGSTREAM is_stairs( temp );
while ( is_stairs >> graphicnum )
UoConvert::StairTypes.insert( strtoul( graphicnum.c_str(), NULL, 0 ) );

Adding just a new elem for the config file would not require too much
Just that what posted on top add a new elem and then search for this and add a new else if and make sure the new type is "House" to not break the multi later on

if ( BoatTypes.count( id ) )
type = "Boat";
else if ( HouseTypes.count( id ) )
type = "House";
else if ( StairTypes.count( id ) )
type = "Stairs";
else
{
ERROR_PRINT << "Type 0x" << fmt::hexu( id )
<< " not found in uoconvert.cfg, assuming \"House\" type.\n";
type = "House";
}

and look on top of the file for

std::set<unsigned int> HouseTypes;
std::set<unsigned int> BoatTypes;
std::set<unsigned int> StairTypes;
std::set<unsigned int> MountTypes;

and add AddOnTypes or whatever you like to call it

I dont right now have accounts for github working or anything to test it with, but those changes should make you get rid of that spam if it was just uoconvert changes you were looking for

[Yukiko]

Thank you Tomi. After talking with my son we think, at some point, it could be useful to have the "house-add-ons" added as a class for isA checks but for now just getting rid of the spamming is a good start.

[DevGIB]

Just thinking along the lines of i assume the house addons are multi's that can be placed on top of other multis?

There might be some validity in creating an additional class which would allow scripters to place multi's on top of other multi's, otherwise maybe a new prop for "house" that would allow you to "override placement check" or if stairs were enabled to be placed on top of other multi's and the stairs class got changed to something else.

Just spit balling ideas.

[Tomi]

Placing a multi on top of another one is completely based on how its controlled by scripts
The only classes there are in pol are Boat and House for multis, stairs are still internally handled as house multis.

So just adding that Add-On in uoconvert stops the spam Yukiko is talking about, otherwise I still see no point in adding another class than the .isA( POLCLASS_ ) check for it because having another multi as house type doesnt change anything.

All multis need to be defined in itemdescs anyway so a scripter can add there an entry for different multis.
Only exception for that are the stairs used by custom housing tool that is client controlled mostly.

// CreateMulti flags
// only for house creation:
const CRMULTI_IGNORE_MULTIS := 0x0001; // ignore intersecting multis
const CRMULTI_IGNORE_OBJECTS := 0x0002; // ignore dynamic objects
const CRMULTI_IGNORE_WORLDZ := 0x0004; // ignore standability, relative Z, world height
const CRMULTI_IGNORE_ALL := 0x0007;

[Yukiko]

Yeah. I see your point Tomi and you are correct about placing a multi on top of a multi as long as the flags are set to ignore multis.

One interesting thing about the custom housing system is that, with it, you can remove things from a multi house. So you can remove an internal wall for example, to expand a room or completely clean off all parts of a house and build a different house. So it is kind of neat. I just wish we had control of the price of the different house components but that is for a different topic

[Tomi]

If I remember correctly that 500gp / 1 tile piece is hardcoded in the client, and even if you change it you only change the price for 1 tile so different prices for different materials are not possible with the built in system

[Yukiko]

Yes. I know it is a client issue unfortunately. I wonder why OSI chose to hardcode it in the client?

[Tomi]

Probably they finally understood that having something hardcoded instead of sending the data by packets is an easier way to stop abuse

[Yukiko]

Hehe. Yeah.