New XML Parser/Settings.xml structure

[toddw123]

I didnt know where to put this so im making this "issue" for now and will close it in like a week or so.

Basically i just wanted to go over the change i just pushed. I switched to the pugixml parser instead of the one that was currently in the project. I feel the pugixml parser has better features and is just as simple to use. I also like that it is also under the MIT license, not that the other parser's license had any conflicts with this projects license, but just liked the general idea.

I also went ahead and modified the settings.xml structure (view the sample to see how its laid out now). I decided to make this change now instead of down the road when this project is working with multiple clients. The idea is that eventually you will be able to make as many <Client> nodes inside the core <Config> node, and each one of those will be its own instance of the client class. Right now though, since the project only handles 1 client, it will only use the last <Client> node's details. Or you can just have 1 node in there to prevent any issues as well, the sample file is just to show how it will look when there are multiple nodes.

You will also notice the objects.xml file is in the resources folder now. Im not too sure how i want parse this yet, so i added it there so everyone can look over it and if anyone has an idea on a good way to parse it let me know. Im not sure if i should create a unique class for the different object classes (ie: character/equipment/projectile/etc) or just have that be an enum value sort of thing. Or if i should make classes like Object/Enemy/Item type of deal. Any input on this is welcomed.

Lastly, i changed the post-build event that copied the settings.xml file to the output directory to instead copy the entire resource directory to the output directory. This way it will copy whatever files that end up in there to the output directory when building. I also changed the code so it reads from "resource/settings.xml" instead of just "settings.xml" which means you dont have to have a copy in your root project folder if you want to use the visual studios debugger.

If anyone has questions/comments on these changes let me know.

[ebf34e12952930cf]

the client has Objects, Projectiles and Items separate, guess that'll work?

[toddw123]

well if you look in the client, it has all the <Class> values as: public static const TYPE_MAP:Object = { "ArenaGuard":ArenaGuard, "ArenaPortal":ArenaPortal, "CaveWall":CaveWall, "Character":Character, "CharacterChanger":CharacterChanger, "ClosedGiftChest":ClosedGiftChest, "ClosedVaultChest":ClosedVaultChest, "ConnectedWall":ConnectedWall, "Container":Container, "DoubleWall":DoubleWall, "FortuneGround":FortuneGround, "FortuneTeller":FortuneTeller, "GameObject":GameObject, "GuildBoard":GuildBoard, "GuildChronicle":GuildChronicle, "GuildHallPortal":GuildHallPortal, "GuildMerchant":GuildMerchant, "GuildRegister":GuildRegister, "Merchant":Merchant, "MoneyChanger":MoneyChanger, "MysteryBoxGround":MysteryBoxGround, "NameChanger":NameChanger, "ReskinVendor":ReskinVendor, "OneWayContainer":OneWayContainer, "Player":Player, "Portal":Portal, "Projectile":Projectile, "QuestRewards":QuestRewards, "Sign":Sign, "SpiderWeb":SpiderWeb, "Stalagmite":Stalagmite, "Wall":Wall, "Pet":Pet, "PetUpgrader":PetUpgrader, "YardUpgrader":YardUpgrader };

And there is literally a class for each one of those types.

k-relay went with just Objects, Items, and Projectiles.

My general idea, that doesnt look like it will work, was to have a base Objects class and it would hold all the attributes that are present across all the types. Then depending on what other classes we really want/need, make those classes (which would probably come down to just items and projectiles honestly). But if you pull up one of the <Class>Projectile</Class> objects you will see that they only have like 1 or 2 attributes. So the base object class would have like 1 attribute which would make that class pretty much useless. Which then goes into the next idea of not having a base class and all the classes are unique on their own (although the client has a BasicObject class that all the classes do inherit).

Idk, im still not too convinced one way or another on what the best way to store the information is yet. I almost want to just have the 1 class (Object), and that class will have a "type", and its on you to know what variables are filled in based on the type. Meh.

[ebf34e12952930cf]

look at the ObjectProperties and ProjectileProperties classes in the client. i think items use ObjectProperties too.

[toddw123]

Yeah that is similar to just having 1 class with all the properties (as ObjectProperties contains ProjectileProperties in the client). Im not too sure what other ways to do it then that really. It just seems weird that there are Objects like this: ``

Which is but isnt an object, its a projectile. It would be nice to break all the objects out by their <Class> value, but then we get into the list in my previous comment which is way more classes then i feel like creating for the objects.

Ill probably just end up copying the ObjectProperties class from the client for the most part though, as you pointed out.

[Zeroeh]

Object type map should be an enum and the main object properties (projectile, enemy, item, ect) should have a single object property class and derive the rest of the objects. Pretty sure I'm just rephrasing what's been said but w/e

[toddw123]

yeah thats what im thinking as well, just for simplicity reasons atleast.