Suggestion - Allow plugins to access raw XML data about krelay HOT 17 CLOSED

Honestly the serializer needs to be entirely redone, and yeah I agree.
I may try to work on it, but you are welcome to as well!

from krelay.

I'll probably work on it over the weekend.

What features do you want for the serializer?

from krelay.

Preferable it should have classes that represent the XML structure that it returns, one for items, objects, tiles, etc

from krelay.

Alright I'll see what I can do.

from krelay.

@TheKronks Does this look good for tiles?

On second thought I probably should have just used xsd or something but this works for now.

from krelay.

Yeah that's what I meant, nice

from krelay.

Alright. I'll make a PR once I'm finished with it. I'll keep Serializer around for compatibility, but I'll mark it as obsolete.

from krelay.

The GameData class has fields for all of the XML files apart from complete gamedata.xml
The complete gamedata.xml needs to be implemented too.

from krelay.

The GameData class has fields for all of the XML files apart from complete gamedata.xml

@pixelzerg eh? I literally wrote the entire GameData system myself and it was merged just four days ago. At the time of writing this issue it didn't exist.

The complete gamedata.xml needs to be implemented too.

And the complete game data is just the combined data of the enemies, items, and objects, and doesn't need it's own data set. You can access the raw XML from Lib_K_Relay.GameData.RawGameData.CompleteGamedata if you really want it.

from krelay.

@apemanzilla The problem I had is that there are some enemies that are in the Complete game data.xml file but not in the Enemies.xml file such as the Undead Hobbit Mage, for example.

I fixed this issue myself for now by making a Dictionary<ushort, object> in the GameData class and parsed all of the stuff in the complete gamedata.xml file as either enemy data or item data, depending on if the element contained the item element or enemy element. The value of the dictionary will need to be casted to be made use of. The ushort input is the Type attribute.

If you want, I can pull request my changes, but I will need to do so later because I'm sleeping now.

By the way, great work on the GameData system, your code is quite good!

I have pretty much sorted out all of the problems I had myself so never mind.

from krelay.

I've been thinking about streamlining the game resources anyways, so I'll probably modify the GameData system manually a bit. Basically, all the data except tiles and packets can be found in the complete XML, so why not just parse that instead? It would also make it easier to update the XML, just extract the complete XML and that's all you need.

from krelay.

Yes, the complete gamedata.xml has everything apart from tiles, objects, packets and servers. Are you going to implement that now or do you want me to push my changes first? If you want me to push my changes then I'll push them by tomorrow probably.

from krelay.

I'm going to wait for my PR with Map Cacher first, then I'll probably write it myself. No offense, I just like writing stuff myself 😛

Also, the complete data does actually contain game objects too, it's just servers (can be fetched from a URL) and packets (must be manually ripped AFAIK) that are left out.

from krelay.

@apemanzilla No, please do. I'll use my thing for now and adapt my project to your implementation later. I'll be looking forward to it!
o(^▽^)o

from krelay.

Alright!

from krelay.

In my copy I have configured it to use objects.xml and groundtypes.xml (which can be easily obtained from http://drips.pw/)
I cannot commit though since I'm not home. I updated the projectile parsing and added a few missing fields here and there for the various structures.
Removed the unneeded XMLs from the resources and made all the structure parsers just grab from objects.xml

from krelay.

Ah alright, that's what I was planning to do 😛

Is http://static.drips.pw the official CDN or something?

from krelay.