|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Development::Bug Reports Post detailed bug reports and what you would like to see next in the emu here. |
02-22-2009, 08:17 AM
|
AX Classic Developer
|
|
Join Date: May 2006
Location: filler
Posts: 2,049
|
|
Trevius Edit: Note that I moved these posts out of the SoF Development thread. This is related to a bug that has existed in Titanium and not connected to SoF development.
I don't know if this is related or not, but this morning I was doing some tests, and went to right-click loot a fireflow stone (augument) off a mob in Omens, and the item went straight to an empty neck slot on my character. It appears to only happen with Augs, I tried with a few other items and it wouldn't.
Last edited by trevius; 02-23-2009 at 04:17 AM..
|
|
|
|
02-22-2009, 06:27 PM
|
|
Developer
|
|
Join Date: Aug 2006
Location: USA
Posts: 5,946
|
|
That only happens on the SoF client, right? Just making sure you didn't see this issue on Titanium, because that would be bad lol. I just don't know who all has SoF so far and who doesn't yet.
I will have to check on it a bit, but it sounds like the item struct is probably still off by some for augments. Maybe there is a new flag for augments similar to the itemtype field for normal items, bags and books.
BTW, I got doors almost working now. It looks like there are a few more fields in the doors struct and 2 of them have to be set to 1 for the door to be clickable. Now, I am getting the clickdoor opcode when clicking them and also getting the too far away message when clicking at a door from out of range. So, the client is seeing the doors as clickable now at least. I also changed the clickdoor struct slightly, because it seems like doorid is now int8 instead of int32. I haven't tried it yet, but I bet a Titanium client would now actually see a door open when a SoF client clicks on them, even though the SoF client doesn't see them open just yet.
I am pretty sure that the only thing left to do for doors is to adjust the movedoor struct and get the opcode and then they should be fully functional. I imagine that click portals like in PoK probably work already, since they don't need the movedoor packet, but I haven't tested that yet. I will test it out tonight and try to finish doors too so that they work. I haven't updated anything onto the SVN yet, but I will get this added tonight if I can get it working. I will also be adding some more opcodes that one of my players has been helping to find/identify.
Once doors are done, that will leave AAs as the last really major issue that needs to be take care of. Most of the rest of the issues should just be things that need minor adjustments here and there. I have been working on getting AAs to work, but still have had no luck yet. I am 99% sure that the opcodes are correct, because they are really easy to verify in IDA. Also, I know that if you change the AATable packet structure, that it will crash the client if it is too wrong. So, it has to be the right opcode and probably the right structure too. I think we are just missing some new packet that needs to be sent to allow the AAs to list. As far as I can tell, the client isn't even making use of any AAs (no stat bonuses, etc), so it isn't that it is just not listing them in the window, it is more like it is just ignoring them completely.
I went through and re-aligned the player-profile as best as I could and I think it is pretty accurate now. There are only a couple of sections that I am not very sure about. But, since almost everything I can verify already seems to line up, it really narrows down areas that might be a bit wrong. One of those unsure areas is where the AA Array is loaded. From looking at Live, it looks like the AA Array struct is now 12 bytes instead of 8 bytes. I adjusted for that, but it didn't seem to make a difference.
I can't stress enough how nice it would be to have a single packet collect of a character logging into live on 9/7/07 lol. Almost everything is fairly well worked out, but it would be nice to have info to make everything perfectly aligned. Ahh well, we will get it eventually either way I am sure lol.
|
|
|
|
02-22-2009, 08:00 PM
|
Demi-God
|
|
Join Date: May 2007
Posts: 1,032
|
|
Quote:
Originally Posted by Angelox
I don't know if this is related or not, but this morning I was doing some tests, and went to right-click loot a fireflow stone (augument) off a mob in Omens, and the item went straight to an empty neck slot on my character. It appears to only happen with Augs, I tried with a few other items and it wouldn't.
|
the AUG auto-equping istelf into empty invnetory slot has been going on since last 2 years =P
and still does as of 302 build
|
|
|
|
02-22-2009, 08:02 PM
|
|
Developer
|
|
Join Date: Aug 2006
Location: USA
Posts: 5,946
|
|
They are still available brand new from Newegg for $5.99 with free shipping:
http://www.newegg.com/Product/Produc...20of%20faydwer
But yeah, people should get them now while they are still in stock. I am sure their stock is limited, though it would be nice if they gave some kind of stock count so we would know exactly how limited it is. I am sure once SoF is done and more servers start using it, there will be a big jump in purchases from newegg. I know there are already quite a few people who have bought it from there already.
I am not sure why Titanium would let you equip an augment into an actual inventory slot. We haven't messed with any structures for Titanium. Are you sure that the aug wasn't modified in some way to be equipable somehow? The client itself makes the first decision on whether to allow an item to be equiped. After that, the server decides if the client should actually gain stats from that item. I imagine that even if they can equip an aug in a slot, that they don't gain any stats from it from #showstats. If the client can equip it, then something on the augment is probably set incorrectly. I would have to see this happen to have an idea of why it would happen.
|
|
|
|
02-22-2009, 08:09 PM
|
Demi-God
|
|
Join Date: May 2007
Posts: 1,032
|
|
well Trev the AUG have "Equipable" slot on them just like a regular item.
ANy item with such setting will be atempted to be auto-equiped, unless you SPECIFICLY put into server code to check if item is an AUGment.
Personaly I don't have much problem with it - if people want to run around wearign augs - let them =)
|
02-22-2009, 08:13 PM
|
|
Developer
|
|
Join Date: Aug 2006
Location: USA
Posts: 5,946
|
|
As I said, it doesn't matter what the server thinks is equipable or not. The only thing that matters for is what the client will gain actual stats from on the server side. The client makes the decision to equip an item based on the settings on the item. I imagine we are probably missing a setting to tell the client that it is looking at an augment which shouldn't be equipable. As I mentioned before, my guess is that there is probably a specific itemtype setting that should be used for augments. Either that, or maybe it is the augment restriction setting or something.
But yeah, it isn't a huge deal. Just something to think about. Also, it isn't related to SoF development. I think I will move these posts out of this thread and into their own bug thread.
|
02-22-2009, 09:35 PM
|
AX Classic Developer
|
|
Join Date: May 2006
Location: filler
Posts: 2,049
|
|
Actually, I just call them as I see them - I never noticed this before, so I reported it. Not that it matters, just thought it would be of use to someone working in this area. I was testing something with the bots and went to loot an Aug, happened to noticed this for the frst time
I also noticed that when I right-clicked it, the item went into an empty neck-slot. But when I left-clicked and removed it, I couldn't left-click set it back again, so it does seem to partially work.
Last edited by Angelox; 02-23-2009 at 05:38 AM..
|
Thread Tools |
|
Display Modes |
Linear Mode
|
Posting Rules
|
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
HTML code is Off
|
|
|
All times are GMT -4. The time now is 07:50 PM.
|
|
|
|
|
|
|
|
|
|
|
|
|