Go Back   EQEmulator Home > EQEmulator Forums > Development > Development::Feature Requests

Development::Feature Requests Post suggestions/feature requests here.

Reply
 
Thread Tools Display Modes
  #1  
Old 09-15-2011, 09:29 PM
Ld7783
Fire Beetle
 
Join Date: Jan 2007
Posts: 2
Default Ornamentions

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!
Reply With Quote
  #2  
Old 09-16-2011, 02:28 AM
trevius's Avatar
trevius
Developer
 
Join Date: Aug 2006
Location: USA
Posts: 5,946
Default

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.
__________________
Trevazar/Trevius Owner of: Storm Haven
Everquest Emulator FAQ (Frequently Asked Questions) - Read It!
Reply With Quote
  #3  
Old 04-02-2014, 09:45 AM
Uleat's Avatar
Uleat
Developer
 
Join Date: Apr 2012
Location: North Carolina
Posts: 2,815
Default

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.
__________________
Uleat of Bertoxxulous

Compilin' Dirty
Reply With Quote
  #4  
Old 04-02-2014, 04:10 PM
Kingly_Krab
Administrator
 
Join Date: May 2013
Location: United States
Posts: 1,589
Default

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.
Reply With Quote
  #5  
Old 04-02-2014, 04:25 PM
NatedogEZ's Avatar
NatedogEZ
Developer
 
Join Date: Dec 2012
Posts: 515
Default

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
Reply With Quote
  #6  
Old 04-02-2014, 08:37 PM
Uleat's Avatar
Uleat
Developer
 
Join Date: Apr 2012
Location: North Carolina
Posts: 2,815
Default

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 of Bertoxxulous

Compilin' Dirty
Reply With Quote
  #7  
Old 04-03-2014, 11:01 AM
Uleat's Avatar
Uleat
Developer
 
Join Date: Apr 2012
Location: North Carolina
Posts: 2,815
Default

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 of Bertoxxulous

Compilin' Dirty
Reply With Quote
  #8  
Old 04-04-2014, 05:19 AM
Uleat's Avatar
Uleat
Developer
 
Join Date: Apr 2012
Location: North Carolina
Posts: 2,815
Default

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.)
__________________
Uleat of Bertoxxulous

Compilin' Dirty
Reply With Quote
  #9  
Old 04-04-2014, 07:25 AM
Kingly_Krab
Administrator
 
Join Date: May 2013
Location: United States
Posts: 1,589
Default

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
Reply With Quote
  #10  
Old 04-04-2014, 09:41 AM
Uleat's Avatar
Uleat
Developer
 
Join Date: Apr 2012
Location: North Carolina
Posts: 2,815
Default

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.
__________________
Uleat of Bertoxxulous

Compilin' Dirty
Reply With Quote
  #11  
Old 04-04-2014, 10:26 AM
moofta
Sarnak
 
Join Date: Jan 2014
Location: United Kingdom
Posts: 53
Default

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?
Reply With Quote
  #12  
Old 04-04-2014, 06:52 PM
Uleat's Avatar
Uleat
Developer
 
Join Date: Apr 2012
Location: North Carolina
Posts: 2,815
Default

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.
__________________
Uleat of Bertoxxulous

Compilin' Dirty
Reply With Quote
  #13  
Old 04-04-2014, 09:03 PM
Akkadius's Avatar
Akkadius
Administrator
 
Join Date: Feb 2009
Location: MN
Posts: 2,071
Default

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
Reply With Quote
  #14  
Old 04-06-2014, 01:13 AM
Uleat's Avatar
Uleat
Developer
 
Join Date: Apr 2012
Location: North Carolina
Posts: 2,815
Default

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?)
__________________
Uleat of Bertoxxulous

Compilin' Dirty
Reply With Quote
  #15  
Old 11-07-2014, 08:42 AM
Drajor's Avatar
Drajor
Developer
 
Join Date: Nov 2012
Location: Halas
Posts: 355
Default

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.
__________________
Drajor regards you indifferently -- what would you like your tombstone to say?
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

   

All times are GMT -4. The time now is 01:55 PM.


 

Everquest is a registered trademark of Daybreak Game Company LLC.
EQEmulator is not associated or affiliated in any way with Daybreak Game Company LLC.
Except where otherwise noted, this site is licensed under a Creative Commons License.
       
Powered by vBulletin®, Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Template by Bluepearl Design and vBulletin Templates - Ver3.3