Hey so I’m currently working on developing a replacement for Dragon Manager. I’ll be open sourcing all the code for the app on a GitHub repository, and I’d like to know what would people like to see on a replacement?
Several people are working on the same thing. May the best site win.
You might find Kate’s thread to have useful info.
I don’t think anyone is just going to start breaking it down for you but if you understand what a relational database is, think of each file as a table. There are a few files which have shorter names which also reference the other files you need.
If you are struggling with something you should just ask about a specific thing.
I understand that much, was more seeing if there was anyone who knew exactly where everything was located so I don’t have to spend a while looking for where everything is
Again you need to be more specific. “Everything” is too broad and and best you will get a broad response.
You likely only care about csv files located in the assets folder. (Broad answer)
I’m aware that the breeding pairs are in deck.csv and breeding.csv but I’m unsure how they correlate to the breeding pairs cost and % chance to breed a drag.
Also noticed a tierBasedDiscounting.csv are the discounts not already in the files or do the files only contain the full cost and the discounted ones have to be derived from that file
You want to start with breeding based stuff?
That I can help you with.
Or are you looking for a table of context answer beyond breeding?
To know breeding stuff you need dragon.csv (to get the real name for the dragon), dragonegg.csv (to map patents to a deck), deck.csv will contain your weighting and possible children.
Some older dragons used to not have entries In deck, but instead have their weighting and offspring listed in the place where the deck would have been. Notice that the deck reference has a weighting too. If any of these are not 1, it will impact the contents of the deck weighting.
You may also want to use properties in dragon.csv to for example filter out dragons which aren’t enabled or breedable or whatever. (They list even the summon type dragons)
The biggest challenge will be in getting the multi-value column and parsing it, and then converting all internal names to real names and doing basic math to change weighting with total fragments into tokens.
Not super hard but 5 min of work unless you live and breath as a coder.
Several people are working on the same thing. May the best site win.
I think we are going to fall into the same dilemma when the next site operator calls it quits and deletes all the data and takes down the site.
It helps that several people are now figuring these things out. And @ConfusedKate for one is doing her work in google sheets that you can backup for personal use, so no risk of them vanishing on you. Worst thing that can happen is no more updates.
I can guarantee that I won’t take mine down once it’s finished, or if I end up quitting I’ll hand over the site to someone else who can work on it
I agree. I like a little diversity and competition.
Honestly what we need is a code repository that’s public… might even get more people from the community to help make cooler things.
So far everyone has taken their work with them. I will probably make something and depending on what everyone else does maybe not make it public unless it goes missing… but I’ll publish my code in sourceforge or something. (Maybe add gpl licensing if that’s not prohibited)
That’s how I think we avoid more people forcing the community to start over.
That would do it.
Had sandberg or amoeba done this we would never have needed to go through this fire drill.
I mean the most difficult thing right now is just parsing the data into a format that can easily be handled and queried. The way the files are spread out everywhere makes it kind of a pain to start finding every file related to a dragon or towers especially with some inconsistencies in naming. If anything, if someone had released the parsed data previously it would be much better and easier for everyone working on it
Yeah I am going to just import the contents of the csv into relational tables and create views (table joins) for things I want and then use the views in the web app.
I have some bigger ideas though. So the overkill framework sets up for those future ideas.
I’ll use Twitters bootstrap to make the UI easier and optimized better for most things.
Haven’t decided on DB, Web server, language, but considering MariaDB with Apache and python. Might go C sharp with IIS.
Yeah the problem with doing that is each dragon has their own seperate files for levels and such so I imagine creating a seperate table for each dragon would be a bit excessive. I’m trying to think of the best way of getting that data into a database that makes the most sense. Unfortunately since the stats differ per dragon/tier sometimes it’s hard to just sort them and it’s impractical to go through every file and check what’s the same and what’s not.
Personally I’ll probably be setting it up using a NodeJS backend, with a Mongo Database and a ngnix server, utilizing something like MaterialUI React for a view or something.
I feel like this is something we could probably work on together if you’re interested @Eidolon , as I’d like to extend the functionality beyond what Sandberg and Ameoba did as well. Would probably be more efficient than working on things seperately
Yeah I’d just dump them all into a dragon details table… similarly a buildingdetails table
I’d have a separate table for keeping track of imports and use the key value there to stamp all new dragon details. Create a maintenance job to archive or purge and/or rollup old data.
It’s pretty easy, both Python and C sharp can import csv easily into objects you could create rows from. Would need to do a little work to catch row changes.
You could read directly from flatfiles but it likely would be a lot slower (with a decent load) and less powerful with searching, and you would want to basically pre-create your own layout.
Creating the join statements will be the hardest part.
Using NOSQL because it’s what you know or do you have a design choice driving that?
Nothing wrong with nodeJS. I have bittersweet experiences. Not really familiar with your UI.
Absolutely. I’m not with tons of available time but this kind of project is fun for me. I definitely have a lot of ideas. I actually might enjoy more of a brainstorming/engineering talk than implementation due to limited time and already having ideas I wished sandberg and amoeba had done
I am using Angular to diectly parse the data into Arrays which can simply be handled, this brings the benefit that for every normal game update the only thing I need to do is to upload the csv files into the /asset folder, which makes it easy to maintain.
I will push my code to GitHub, once I have implemented all the basic stuff, as currently to have a fast solution some of the code needs to be refactored anyhow.
I am wondering if combined forces aren’t more effective and efficient to get the best results.
Basically it’s what I’m familiar with and it also allowed me to embed the level data into each dragon itself as I spent a bit of time yesterday parsing the data and formatting it into some nicer JSON files that I could manipulate.
Implementation is the easier parts of doing everything, coming up with the ideas the more difficult part. It’d be great if we could have some sort of chat going on about ideas, engineering and such. Do you have line, or what would be your preferred source of communication
I thought about that but I was concerned about potential performance issues so I just spent about two days writing code to parse the csvs into json to insert into a database.
Would probably be the best thing for the community imo
Hmm, you know what they say about coding projects… With twice the people you can build the code in twice the time!
Anyway, I’m faffing around a bit with the files too. I don’t think it’s bad a lot of people are working on this but it’s good to exchange info on where stuff is located.