Forum :: Client Editing :: Shields/Wings Graphics Limitations

I tried replying to my previous topic, but the system doesn't allow me to double post.

I found another massive limitation with the graphics system. This time with sheilds/wings. It seems like any new resource bitmaps that are added to gfx019.egf and gfx020.egf, are hard-coded as "shields". If I create a set of wings graphics with the usual 5 frames, it will have a graphical glitch and desync the walking with the server. If I add the remainder 11 frames (16 total) to simulate a shield, there is no glitch/desync, but the graphic is offset below the characters feet and is clipped. I also assume, since it's handled as a shield, it will constantly be overlayed ontop of the character sprite.

I don't understand how anyone can deal with all these limitations with the client. They might be small (which I would disagree), but they add up very quickly. I know I can simply replace wing graphics, but that defeats the purpose of adding new graphics if I am simply replacing old ones.

Can someone confirm my findings? Is there any workaround/hack? I know this could be fixed with an open-source client, but I don't have time to take on such a huge project and Ethan's client isn't complete enough to where I feel like id have time to do the finishing touches on it.

Hope there's some good news for this disheartened soul! I don't want to sound ungrateful, I appreciate everything this community does. :)

Edit:

There seems to be only 3 Wings + 1 back item (Bag) in the original EO graphics, does the system really only support 4 sets of back graphics in the entire game?

- 408: Bag

- 384: Good Wings

- 445: Good Force Wings

- 446: Fire Force Wings

---
Just your friendly neighborhood Programmer-Man!

As far as I know you could only replace the current back items as they are hard coded. There's also the arrows normal/ frost/fire 

That being said and this is off topic, wings do look awful in game, players walking around with them just doesn't work in eo really.

Late to the party :p all these problems have been gone over many many times years ago :( need to make a new client to bybass these kind of isssues

It's not possible to add even new shields? Will it all just appear on the feet?

Ya you can but idk about wings or bags never added those in

I took a shield I had, and since I had all arrow gfx added in, but not in game, I switched the shield gfx to arrow gfx and it all appeared fine, fully functional. 

Should just be a pub thing? But I know sausage has code for determining what items are bows. Maybe just add a few lines of code similar to sausage's that determine what's wings etc.

---
Whitewolf v19
Endless Origins and Z

Paranoid posted: (16th Mar 2017, 06:34 pm)

Should just be a pub thing? But I know sausage has code for determining what items are bows. Maybe just add a few lines of code similar to sausage's that determine what's wings etc.

I don't understand what you mean or how any server-side code would allow more shields/wings, but I'm interested to know more. I haven't actually looked out how bows are used, but I assume they are handled similarly (layer/position-wise) as shields.

---
Just your friendly neighborhood Programmer-Man!

More shields can be added just fine Ive added like 4 new ones

I never claimed that shields were an issue. I only mentioned shields in my title because wing/back items are in the shield category.

---
Just your friendly neighborhood Programmer-Man!

Paranoid posted: (16th Mar 2017, 06:34 pm)

Should just be a pub thing? But I know sausage has code for determining what items are bows. Maybe just add a few lines of code similar to sausage's that determine what's wings etc.

I am pretty sure wings/arrows are hard coded in the client. Ive seen Shayne doing some pretty tricky stuff with the client lately maybe he can figure out how to add some more wing/arrow's "not to sure"?  The ranged wep hack is in eodata.cpp

// Ranged gun hack
 if (newdata.id == 365 && newdata.name == "Gun")
{
       newdata.subtype = EIF::Ranged;
 }

That reads the server side eif file and even if the subtype is not ranged it is hacked in at that point.Maybe you could try something like this just to see what happens allthough I don't think it will work but it is worth a shot.
 if (newdata.id == new id && newdata.name == "New Item")
{
       newdata.subtype = EIF::Arrows;
 }

To avoid creating a new topic. I'll post here:

Is it possible to add/append custom spell graphics to gfx024.egf?

From what I've seen, there's no pattern on how the resource numbers are ordered. So I assume every single spell graphic is hard-coded into the client. I looked at Fallen Evolution and Endless Edge, and I didn't see any new resource IDs, they seem to just replace the original IDs/bitmaps (although I didn't check to see if Endless Edge had custom graphics).

Id like to create new custom graphics for spell effect #34+ (the current spell count goes to 33). It would also be nice if the spell effect also allowed multiple bitmaps to do a layer behind the character and a layer in front of the character, like the first spell effect. But I assume if the client did allow new spell effects, it would just be a single layer.

Also, if I do have to replace graphics, do you know of which effects are not used in the original game content? Not sure what should be the spell effect I replace that is the least or never used.

---
Just your friendly neighborhood Programmer-Man!

It took me enough attempts of messing around.., but I finally figured it out.

Vult hardcoded the gfx ids for wings and arrows. They are both the exact same limitation.
The client will reject any 'shield'/gfx id not matching the existing hardcoded ones, and invoke the graphical/alignment issues if the shield type is 2(ammo) or 3(wings).

By limitation, only an item with the gfx id 10(Good Wings), 11(Bag), 14(Normal arrows), 15(Frost Arrows), 16(Fire Arrows), 18(Good Force Wings), or 19(Fire Force Wings) could be used for arrows or wings.

I'll get to releasing the bypass eventually, but I'm working on some other limits/stuff before that point.

---
EO Resources/Guides: â—„ eobud.boards.net â–º

shayne posted: (29th Sep 2017, 07:20 am)

It took me enough attempts of messing around.., but I finally figured it out.

Vult hardcoded the gfx ids for wings and arrows. They are both the exact same limitation.
The client will reject any 'shield'/gfx id not matching the existing hardcoded ones, and invoke the graphical/alignment issues if the shield type is 2(ammo) or 3(wings).

By limitation, only an item with the gfx id 10(Good Wings), 11(Bag), 14(Normal arrows), 15(Frost Arrows), 16(Fire Arrows), 18(Good Force Wings), or 19(Fire Force Wings) could be used for arrows or wings.

I'll get to releasing the bypass eventually, but I'm working on some other limits/stuff before that point.

If you found a bypass for this problem I'd be pretty ecstatic. I can't currently release any new arrows/wings because of the hardcoded GFX IDs.

---
Want to learn to pixel?
Pixelsource.org

shayne posted: (29th Sep 2017, 07:20 am)

It took me enough attempts of messing around.., but I finally figured it out.

Vult hardcoded the gfx ids for wings and arrows. They are both the exact same limitation.
The client will reject any 'shield'/gfx id not matching the existing hardcoded ones, and invoke the graphical/alignment issues if the shield type is 2(ammo) or 3(wings).

By limitation, only an item with the gfx id 10(Good Wings), 11(Bag), 14(Normal arrows), 15(Frost Arrows), 16(Fire Arrows), 18(Good Force Wings), or 19(Fire Force Wings) could be used for arrows or wings.

I'll get to releasing the bypass eventually, but I'm working on some other limits/stuff before that point.

Glad I thought of you when I seen this topic you do good work :D. If you figured out how to bypass these limitations is it possible you may be able to bypass the the egf file name/id limit which I think is 9999? I know in my client I set a temp hardcoded limit 10000 "which I know no egf files surpass at this time" to speed up loadtime I'm guessing Vult-R did this for the same reason. I think setting the value to unsigned short/65535 instead of a weird number would make more sense.