Ornamentions

[Ld7783]

I was just wondering if anyone got the ornaments/ornamentions up and working? If so a little help on making them work would be great.

Thanks!

[trevius]

Ornamentations are not implemented into EQEmu yet, so they won't work for anyone. They don't look like they would be overly hard to implement, but I am not sure of the best way to do it yet. I think we would probably need an extra 2 fields added to the inventory table for ornament icon and model number. Then we would just send that info in place of the ones that are loaded from the items table.

The implementation of the actual combine for ornamentations might be a bit harder to do. There is nothing in the ornament that tells us what model it is supposed to make the combined item look like. There is an icon for it, IIRC, just no model. I don't think there is anything on it that tells it what slots to restrict it to either. IIRC, there is a script file number filled out on the items, so I assume they may have called a script that had a list of what ornamentations use which models and what their slot restrictions are. I am not exactly sure on the best way to handle the actual combine part.

[Uleat]

Ornamentations may be possible...

http://imagebin.org/303486


The items images shown are based on a preliminary attempt to activate ornaments.

At this point, I'm not sure if every model will show up based on the information in the database.

I do know that every client will not be able to display every ornament..that's dependent on whether a given client supports a given model id.

[Kingly_Krab]

NatedogEZ has tested ornament-like code on Underfoot, it doesn't work, as the packets aren't sent like Rain of Fear so you can only do your primary weapon. When you attack it resets your secondary to its actual graphic. I don't believe he tested ranged weapons.

EDIT: I posted this to say that Rain of Fear will be the required client for all ornamentations to work correctly.

[NatedogEZ]

If you change the way the item is sent to the player it would be do-able I think :p

I didn't mess with that though.. I just tried to remove the "update" packet that happens when you attack.. because it is SPAMMED like mad if the item look doesnt match what the client thinks it should look like

[Uleat]

I'm still playing with it..but, yeah, I have GetEquipment() checking the item for bagOrnament, augOrnament, then base.

During the initial spawn, I can get the models to show up..but, switching always reverts to the base item.

I'm afraid that some models may be EliteMaterial and I currently don't have access to the attributes that I need to check that.

[Uleat]

I think I figured out why my testing was so sporadic...

Part of the problem is model id#. Not all models show up in all clients.

The other part is a partial implementation of the virtualized Mob::GetEquipment() series of methods.


I'll finish those up tonight and do some more testing to see where I stand.

[Uleat]

I am going to have to figure out how to handle differences in clients. It would be nice to have a list or range of IDFile #'s for each
supported client.

Otherwise..character select, initial spawn and item swapping currently work. It's most likely not how live does it..but, it's acceptable.
There is a small delay in switching to the ornamented graphic when swapping items. The base item is shown first..but, the ornament
is shown after the SendWearChange() packet is received. I attempted combat and saw no discrepancies using this method.

Now..I need to update: lua/perl api's, other inheritance classes (of Mob), and activate all of the augmentation/ornamentation op's.


(With a list of client 'ceilings,' I could send two textures to SendWearChange(); first for valid clients; second for earlier ones. That way,
all clients would at least display a weapon of some sort.)

[Kingly_Krab]

I can't help you with the IDs, but this plugin has a lot of them (up to 11169): http://perl.pastebin.mozilla.org/4759046

[Uleat]

Kewl, thanks for that!


Given the way that is done, I may be able to grab what I need from the db and lucy for the rest of the clients..then, just test the clients to see where
the supported line ends.

I'll just create a create a fallback array with one model per class and substitute that either in the handler or in the client patch files.

Could do the same for armor when the time comes.

[moofta]

This might be a totally ignorant question (I apologise if it is)...

Why can't we just overwrite the IDFile of the item with the one from the ornamentation when we serialize the item in SerializeItem, so when the item data is sent to the client it is just "there", then switch it back if they remove the augmentation?

[Uleat]

I considered that...

But, we would need each item to have a pointer to the const item library as well as a locally managed instance. There would be
more code than the way I'm currently doing it, just for the owning client's benefit.

The bulk of the work is done in sending OP_WearChange's (Mob::SendWearChange). I just added accessors to ItemInst to pull the
'visible' IDFile. And since we already translate all client's OP_WearChange's, I can add a small reference array there to compensate
for invalid client models.


Not an ignorant question and I appreciate feedback like that. Even if I have a set understanding of something, having to explain
myself makes me re-examine my process as I type it out.

[Akkadius]

Making it more complicated than it needs to be. You shouldn't leave it to the code to check a list of valid IT graphics before loading them. If an older client can't load the file that is up to the server operator to make that decision and or maintain client files necessary to do so. It just won't load anything if the client doesn't have the model and that shouldn't be something for the source to try and compensate for

[Uleat]

moofta, I'd like to use your method as it would make certain things easier...

Unfortunately, I don't know exactly what the client does and does not do in regards to generating a WearChange OP.


Looking at the criteria for Inventory::SwapItem()'s SendWearChange() call, everything but Helm, Primary and Secondary are generated server-side.

I'm assuming that Helm is done client-side because of the show/~show feature and weapons the same due to ornaments/augments.

I had to change the criteria to include weapons for item swapping to work..but, I suspect that the client is still sending the base item's
material and that is being re-broadcast to everyone. This will probably lead to issues with a weapon changing to ornamentation, then back to base
after the re-broadcast.

I can nix the re-broadcast to only include the helm..but, I'm not making much progress otherwise...


Any opinions? (anyone?)

[Drajor]

Bumping with some news. Whilst getting evolving item data sent correctly to the client the location of ornamentation icon / idfile has been discovered! The bad news is that it only works for evolving items for now.