Please? There's no way to get this information at the moment.

 

-----signature-----

>> There's no way to get this information at the moment.


NetEcho? If it's simply a different property it should be pretty easy to pull it out of the packet manually...

 

-----signature-----

This would of course, require me to rewrite the plugin to use NetEcho and parse things manually, which of course defeats the purpose of having all those nice enumerations to begin with.

 

-----signature-----

you don't have to re-write it. simply add a handler for the NetEcho, then use that to either call a different event or do something else within that. It *shouldn't* require a rewrite.

Lets say, for example, that I use WorldFilter_ChangeObject, then on that event handler, I loop through each enumeration(long, bool, string, etc.) in order to serialize the object. I also use these for detecting specific attributes of the items I want. This means the plugin needs no changes to support any possible property past or future. It *does* however mean that Decal needs to recognize these properties. Isn't the whole point of having the Adapter/enumeration stuff so that plugin authors DONT have to go in and manually parse this stuff and make code changes every time something new is added?


Seriously, I do not believe the suggested approach is the correct one. I *can* go and do all this manually(it'll be real ugly, though, unless there's an easy way serialize an entire object on receipt of an ID packet), but my understanding is that we were supposed to be getting away from that with the Adapter. If the Voice of Decal says "Plugin authors should stop using WOs or Adapter and everyone should decipher using NetEcho and parse manually, so be prepared to have to change your plugins every time a new property is added or the structure changes", then so be it. Otherwise I stick with the assumption that the framework is intended to handle this and the correct solution is to update Decal.


Its been a long time since we've had any fixes or updates to Decal. I'm sure there are pending fixes sitting in the codebase waiting to be published. Now is as good a time as any.

 

-----signature-----

the point of the Decal Filters is to take care of the most-used properties and features to prevent duplication. In some cases however, things are out before we can make changes to Decal. Therefore, if you want to take advantage of that, you need to add it yourself for now.


There is nothing saying you can't use NetEcho for now for yourself, then switch to WorldFilter in the future. If you are worried about repeating code, then simply pull the repeated code into a function and use it from both places.


The idea is that eventually it will become part of the core filters, but until that happens, if you want to use it yourself, then you'll need to use what is available to you.. this means using NetEcho.





There is a reason for that. It is the same reason we can't just push some new filters either. Suffice it to say, it'll be ready when it is ready. Until then, you'll need to work with what you have.


Also... I'm not saying to not use WorldFilter or Adapter at all. I'm simply saying, for this SPECIFIC instance, jusdt append the property to your serialized object, and add to it with NetEcho. The whole point behind serializasation is that you can re-use the objects and add to them as needed. If it isn't flexible enough to be able to append attributes, or utilize the object in more than one location, perhaps that is something that would requre more changing.


The idea is to to use WorldFilter as much as possible, but tack on NetEcho for the pieces that aren't supported yet. That's why I said it shouldn't require a re-write. It shouldn't take much more than changing how your objects are serialized, and adding a NetEcho handler to add the additional properties as needed.

I know you do not know my code, but trust me, its a lot more than you think.


void WorldFilter_ChangeObject(object sender, Decal.Adapter.Wrappers.ChangeObjectEventArgs e)

{

// Check for ID receipt and send data

if (e.Change == WorldChangeType.IdentReceived)

{

int ItemIndex = PendingItems.BinarySearch(e.Changed.Id);

if (ItemIndex >= 0)

{

PendingItems.RemoveAt(ItemIndex);

ScannedItems.Add(e.Changed.Id);

SendToServer(e.Changed.Serialize());

}

}

}


The SendToServer line is actually a call to a procedure that enumerates every property and sends the resulting string to the server. The net effect of this identical to what the line above would be IF the WO had a Serializer(Hint Hint). Very clean, very simple. (Before you ask, items that are not ID'd are sent in the Create in a similar manner, and the server does the deduplication)


To work NetEcho into this will require some significant structure changes, because the object is currently sent immediately (via UDP) and its not held onto. I'll have to store the objects and update them, etc. which makes the solution a lot more fragmented and ugly. (Which comes first, the NetEcho or the Changed event?, Is this always the case? etc.)


None of this is really relevant, though. *I* know what needs to be done to support NetEcho in this scenario and its not a 4 line change.


All I asked for in this topic is a Decal release that supports sets. I don't need to dance around the issue and talk about what I can and can't do. I only need an honest answer from YOU. Is there going to be a Decal release before the end of the year that supports these attributes as enumerations or isn't there? I don't care what the answer is; I just need to know so I can focus MY time on either network decoding or features. From your post edit above, it looks like the former.


Thank you.

 

-----signature-----

If memory serves, the current decal already does. All you have to do is identify the correct value for the set and cast it to the enum type when you query WF. It stores everything whether it has a 'name' for it or not.

That is certainly worth a shot, I'll try that!

 

-----signature-----