Page 6 of 18 FirstFirst ... 234567891016 ... LastLast
Results 101 to 120 of 345
  1. #101
    Legendary Founder Ron's Avatar
    Join Date
    Feb 2006
    Posts
    2,832

    Default

    Quote Originally Posted by EllisDee37 View Post
    All my points go to a single class tree. Level 1 spends one on the first core, three in tier 1. Level 2 spends one (5th spent) in tier 1 then one in tier 2. Right now, those two enhancements taken on level 2 cannot swap spots due to "points in tree" prereqs, so the drag n drop interface will need to check that kind of thing.
    Yes, we'd have to check prereqs. My thought is, when the user grabs a particular enhancement, to check the prereqs on it and grey out any slots where it would be illegal to put it, due to either prereqs on that enhancement, or prereqs on enhancements that rely on that enhancement.

    I'm not too concerned with the save file, actually. And even the printout is not such a big deal (in one case, it's a snapshot of a particular level, so there are actually no concerns about changing enhancements, and in the second case it's a step-by-step leveling guide, and for that we can simply list when to reset the trees and what new enhancements to take). The one that concerns me the most is the forum export, and how we'd represent multiple enhancement sets at various levels without it becoming completely incomprehensible to anyone reading it.

    EDIT: One thing to keep in mind regarding a secondary interface to set the order is screen space. For us poor souls running 1024x768 there isn't a whole lot of room left over when the tree is on the screen:
    Yeah, good point, I'll keep that in mind. We will keep the default size of the screens to 1024x768. We will just have to work within that limitation.
    The locus of my identity is totally exterior to me.
    "On my business card, I am a corporate president. In my mind, I am a game developer. But in my heart, I am a gamer." - Satoru Iwata

  2. #102

    Default

    Quote Originally Posted by Ron View Post
    Yes, we'd have to check prereqs. My thought is, when the user grabs a particular enhancement, to check the prereqs on it and grey out any slots where it would be illegal to put it, due to either prereqs on that enhancement, or prereqs on enhancements that rely on that enhancement.
    That's nice and elegant. I like it.

    I'm not too concerned with the save file [..] And [..] printout [...] The one that concerns me the most is the forum export, and how we'd represent multiple enhancement sets at various levels without it becoming completely incomprehensible to anyone reading it.
    I'm not sure I follow this. I don't see multiple enhancement sets, but rather one single unified set. Many of the builds I've posted to the forums include a tree reset, and it doesn't seem overly cluttered to me. For examples in the builds linked in my signature:

    Evasion Paladin level 18
    Pale Trapper level 15
    Epic Challenge Farmer level 13

    EDIT: My guess is that for enhancements, internally you're saving a static array populated with all possible enhancements the build could ever take, filling in the level each is taken as they get taken. This is essentially a snapshot of all enhancements taken by the build. And this structure would indeed require multiple separate snapshots to support tree resets.

    I would go a different way with how the enhancements are stored internally. I would switch to a dynamic array, and grow it as each enhancement is taken. Think of it like a series of instructions, sort of like a clipboard buffer. As each enhancement is taken, you add a new entry to the dynamic array. A tree reset is simply another instruction to add to the end of the list, and then the subsequent re-selections get added after that. And so on. One single unified list of enhancements for the entire build regardless how many tree resets there are.

  3. #103
    Legendary Founder Ron's Avatar
    Join Date
    Feb 2006
    Posts
    2,832

    Default

    Quote Originally Posted by EllisDee37 View Post
    EDIT: My guess is that for enhancements, internally you're saving a static array populated with all possible enhancements the build could ever take, filling in the level each is taken as they get taken.
    Your guess is incorrect

    I would go a different way with how the enhancements are stored internally. I would switch to a dynamic array, and grow it as each enhancement is taken.
    This is already how we handle it.
    The locus of my identity is totally exterior to me.
    "On my business card, I am a corporate president. In my mind, I am a game developer. But in my heart, I am a gamer." - Satoru Iwata

  4. #104
    Legendary Founder Ron's Avatar
    Join Date
    Feb 2006
    Posts
    2,832

    Default

    Another change we are seriously considering. Right now, it takes quite a while to load in the data files. We've done about all we can to speed that up using the flat file system we have (i.e. text files). And the thing is it's just going to continually get worse as we add more and more data to the files. So we are considering converting the whole thing over to a sql style database. I'm looking into the technical specifics right now.

    The advantage is there would be no more loading. We would pull entries out of the database on the fly, when they are needed. Also, this would drastically cut down on syntax bugs in the files (no more missing semi-colons or misspelled keywords, and the like).

    The disadvantage is you guys would no longer be able to (easily) edit the files yourselves (it wouldn't be impossible, but you'd probably need a database editor, such as sql-lite, to do it). And I think there are still a few programs out there that rely on the text files we create to work. Those programs would have to be modified by their creators to use the new database system (or they'd have to start maintaining their own flat files).

    The caveat is I want to make sure there are no extra requirements for you guys to load entries out of the database tables. In other words, no special programs required to be installed by the end users. I THINK that is the case, but in all honesty, I don't have a ton of experience with databases (it just doesn't come up in my normal day to day programming, the sort of stuff I do doesn't usually deal with large amounts of data that need to be randomly accessed). But I'm looking into it.

    So what do you guys think? Any thoughts one way or the other?
    The locus of my identity is totally exterior to me.
    "On my business card, I am a corporate president. In my mind, I am a game developer. But in my heart, I am a gamer." - Satoru Iwata

  5. #105

    Default

    Quote Originally Posted by Ron View Post
    This is already how we handle it.
    Then I don't understand this:
    Quote Originally Posted by Ron View Post
    The one that concerns me the most is the forum export, and how we'd represent multiple enhancement sets at various levels without it becoming completely incomprehensible to anyone reading it.
    In what sense are there multiple enhancement sets?



    Quote Originally Posted by Ron View Post
    Another change we are seriously considering. Right now, it takes quite a while to load in the data files. We've done about all we can to speed that up using the flat file system we have (i.e. text files).
    I'd bet money that the text files load almost instantaneously; it's loading all the graphics that slows things down. As for a no-dependency SQL engine where the user never has to install anything, I'd bet money you won't find one.

    I could be out money twice on those bets, but that's my initial reaction.

    For the graphics, is it possible to roll them all into a single resource file so you don't have to distribute the bitmap files themselves? I count almost 2800 bitmaps.

    For online hobbyist applications like this -- as opposed to professional development environments -- I generally go for the no-install approach as well. Typically I'll use UDT arrays as a poor man's database engine since no install is required. Sorting and searching is pretty easy to implement, as are relationships. (Actually, you can build the relationships into the core structure, which in some ways is superior to a SQL database engine. In many ways worse, of course. heh.)

  6. #106
    Scholar of Treasure Dragon.Star's Avatar
    Join Date
    May 2006
    Location
    Fernia / Mornlands
    Posts
    898

    Default

    Quote Originally Posted by EllisDee37 View Post
    Then I don't understand this:
    In what sense are there multiple enhancement sets?
    In the current planner there isn't, but with version 5.0, we have had talks about allowing the planner to have multiple sets of enhancements. It is something we have been discussing but not coded yet.
    Guild: Ghallanda Rerolled
    Artamax - Cleandeath - Cleanup - Dragonbound - Draykon - Gully - Magestic - Tinbucket
    DDO Character Planner (Stable: Version 04.20.02) , Version 04.23.1 - Planner 5.0 Interface Discussion

  7. #107
    Legendary Founder Ron's Avatar
    Join Date
    Feb 2006
    Posts
    2,832

    Default

    Quote Originally Posted by EllisDee37 View Post
    I'd bet money that the text files load almost instantaneously; it's loading all the graphics that slows things down. As for a no-dependency SQL engine where the user never has to install anything, I'd bet money you won't find one.
    Well, last time I profiled it (and granted it's been a while) reading through and parsing all that data did take a good amount of time. Remember, we're not just loading those files, we're loading and parsing them, pulling all the data therein and converting it and storing it into the internal data structures of the program. And it's tens of thousands of lines of text we're talking about (the enhancement file alone is 27,000 lines of text). So yeah, it takes a while.

    Having said that, yes, loading the icons is also not a quick process. We are going to (in the 5.0 version) change the code to load icons on the fly (or at least we are going to experiment with it). That might cause us issues with the enhancement screen, where you have to load about 100 icons (or so) to display three trees, so we will just have to see how it works out. So yeah, we are both going to be eliminating the text parsing AND eliminating the up-front icon loads, which means the planner should start up pretty instantly. At least, that's the hope.

    As for the database, .NET has some built in sql table access functions (http://msdn.microsoft.com/en-us/libr...vs.110%29.aspx) that might help us out with that. In fact, we are going to build a data editor right into the planner itself at some point, so we will need both read and write functionality. Reading through those functions, I don't see why we would need anything external (besides .NET of course). But I could be wrong, as I said, my experience with databases are pretty limited.

    For the graphics, is it possible to roll them all into a single resource file so you don't have to distribute the bitmap files themselves? I count almost 2800 bitmaps.
    Probably not worth the trouble. We're switching over to .png files rather than bmps for the next version, which will reduce the download size considerably. Rolling them into a resource file would mean we'd have to come up with some kind of indexing system, and probably our own compression scheme. Using .pngs seems a lot easier to me

    Quote Originally Posted by Dragon.Star View Post
    In the current planner there isn't, but with version 5.0, we have had talks about allowing the planner to have multiple sets of enhancements. It is something we have been discussing but not coded yet.
    Yep. All this talk of multiple enhancements is all theoretical at this point. Right now the planner only supports a single enhancement set.
    The locus of my identity is totally exterior to me.
    "On my business card, I am a corporate president. In my mind, I am a game developer. But in my heart, I am a gamer." - Satoru Iwata

  8. #108

    Default

    Quote Originally Posted by Ron View Post
    Yep. All this talk of multiple enhancements is all theoretical at this point. Right now the planner only supports a single enhancement set.
    May I ask what the idea is behind multiple enhancement sets? I'm not sure I even understand the concept.

    Regardling the .NET SQL engine, yeah that should work fine. It might cause headaches for XP users, but they lose Microsoft support in a few weeks anyway, so XP is officially obsolete and not your problem. hehheh. (I switched from XP to 7 about 3 months ago solely because XP support is going away.)

  9. #109
    Legendary Founder Ron's Avatar
    Join Date
    Feb 2006
    Posts
    2,832

    Default

    Quote Originally Posted by EllisDee37 View Post
    May I ask what the idea is behind multiple enhancement sets? I'm not sure I even understand the concept.
    See post 96 (https://www.ddo.com/forums/showthrea...=1#post5251295)
    and 97 (https://www.ddo.com/forums/showthrea...=1#post5253122)

    By "multiple" I mean, having the ability to take enhancements, reset a tree, and take different enhancements, saving the old data, so that the planner is aware that the player may want to change their enhancement sets at various points throughout their life. Which as you correctly pointed out, a lot of people do.

    I make no guarantees that we are going to support it at this point, I'm just throwing around ideas for it. It would be nice to have, but it does present some difficulties.

    Regardling the .NET SQL engine, yeah that should work fine. It might cause headaches for XP users, but they lose Microsoft support in a few weeks anyway, so XP is officially obsolete and not your problem. hehheh. (I switched from XP to 7 about 3 months ago solely because XP support is going away.)
    We are going to be using .NET 4.0, which, if I am not mistaken, supports XP. I'm not going to use 4.5 (or 4.5.1). I know MS is giving up on XP, but I'm not there quite yet
    The locus of my identity is totally exterior to me.
    "On my business card, I am a corporate president. In my mind, I am a game developer. But in my heart, I am a gamer." - Satoru Iwata

  10. #110
    Hero DemonStorm333's Avatar
    Join Date
    Oct 2009
    Location
    Half way to hell
    Posts
    420

    Default

    Quote Originally Posted by Ron View Post
    See post 96 (https://www.ddo.com/forums/showthrea...=1#post5251295)
    and 97 (https://www.ddo.com/forums/showthrea...=1#post5253122)

    By "multiple" I mean, having the ability to take enhancements, reset a tree, and take different enhancements, saving the old data, so that the planner is aware that the player may want to change their enhancement sets at various points throughout their life. Which as you correctly pointed out, a lot of people do.

    I make no guarantees that we are going to support it at this point, I'm just throwing around ideas for it. It would be nice to have, but it does present some difficulties.


    We are going to be using .NET 4.0, which, if I am not mistaken, supports XP. I'm not going to use 4.5 (or 4.5.1). I know MS is giving up on XP, but I'm not there quite yet
    jw is there and eta on the new planner??
    Demons run when a good man goes to war

  11. #111

    Default

    Quote Originally Posted by Ron View Post
    As for the database, .NET has some built in sql table access functions (http://msdn.microsoft.com/en-us/libr...vs.110%29.aspx) that might help us out with that. In fact, we are going to build a data editor right into the planner itself at some point, so we will need both read and write functionality. Reading through those functions, I don't see why we would need anything external (besides .NET of course). But I could be wrong, as I said, my experience with databases are pretty limited.
    Hey Ron,

    A full-blow SQL engine is probably overkill. You might want to investigate using XML persisted DataSets or just XML with Schema as your main data storage. You can load either of those very quickly and access them like an in-memory DB using Lambda or LINQ queries, provided your schema are correct. I'd still recommend a rudimentary ORM layer to isolate your object and data models, but I'm picky.

    I really looking forward to what you guys come up with.
    The newest computer can merely compound, at speed, the oldest problem in the relations between human beings, and in the end the communicator will be confronted with the old problem, of what to say and how to say it. - Edward R. Murrow (1964)

  12. #112
    Legendary Founder Ron's Avatar
    Join Date
    Feb 2006
    Posts
    2,832

    Default

    Well, I thought about XML, but to me, that's just a flat file with a lot of tags Our 27,000 line file would hit 100K in XML, I'm sure And if it is just a flat file, would we gain anything over our current system by using it? Can you random access an XML file with any degree of performance? Probably not.

    And at what point does a database become not overkill? I think right now we are somewhere between 50 and 60K lines of text for the data. And once we redo the equipment files, I wouldn't be surprised if we hit 100K. Isn't that enough to say a database table is needed?

    I'd say not only is it not overkill, we are probably long overdue for it, hehe. And I'm not suggesting we are going to implement a full on SQL database engine into the planner. We are just going to use SQL tables and the built in .NET functions to access them.
    The locus of my identity is totally exterior to me.
    "On my business card, I am a corporate president. In my mind, I am a game developer. But in my heart, I am a gamer." - Satoru Iwata

  13. #113

    Default

    Quote Originally Posted by Ron View Post
    Well, I thought about XML, but to me, that's just a flat file with a lot of tags Our 27,000 line file would hit 100K in XML, I'm sure And if it is just a flat file, would we gain anything over our current system by using it? Can you random access an XML file with any degree of performance? Probably not.
    You are correct in that XML is just text, but it can be segmented hierarchically with schema - Kind of like a database. Once the ADO engine loads any file-based, persistable data source, it's all in memory. There's no waiting on data queries, reads or writes until the data are persisted again. Additionally, if there's a problem with the data the only tool required to fix it is a text editor.

    Quote Originally Posted by Ron View Post
    And at what point does a database become not overkill? I think right now we are somewhere between 50 and 60K lines of text for the data. And once we redo the equipment files, I wouldn't be surprised if we hit 100K. Isn't that enough to say a database table is needed?
    I can tell you are an old-school bit twiddler par excellence.

    Quote Originally Posted by Ron View Post
    I'd say not only is it not overkill, we are probably long overdue for it, hehe. And I'm not suggesting we are going to implement a full on SQL database engine into the planner. We are just going to use SQL tables and the built in .NET functions to access them.
    OK. I think we have a basic misunderstanding of terminologies. ADO and all its constituent components (like those SQL table objects) knows absolutely nothing about the underlying engine. If the data provider is MS-SQL, Oracle, XML or CSV text, ADO don't know and don't care. ADO is an abstraction layer which allows you to treat any data provider the same way (although MS has a few "special" extensions for SQL).

    My suggestion for using XML was based on two stated desires; that the data are easy to edit without specific tools and can be used with ADO. ADO will treat an XML source in the same ACID manner as any other data source and you can modify XML with a text editor. It's a win-win combination using nothing more than .Net which provides everything you want.
    The newest computer can merely compound, at speed, the oldest problem in the relations between human beings, and in the end the communicator will be confronted with the old problem, of what to say and how to say it. - Edward R. Murrow (1964)

  14. #114
    Legendary Founder Ron's Avatar
    Join Date
    Feb 2006
    Posts
    2,832

    Default

    Quote Originally Posted by sebastianosmith View Post
    OK. I think we have a basic misunderstanding of terminologies. ADO and all its constituent components (like those SQL table objects) knows absolutely nothing about the underlying engine. If the data provider is MS-SQL, Oracle, XML or CSV text, ADO don't know and don't care. ADO is an abstraction layer which allows you to treat any data provider the same way (although MS has a few "special" extensions for SQL).

    My suggestion for using XML was based on two stated desires; that the data are easy to edit without specific tools and can be used with ADO. ADO will treat an XML source in the same ACID manner as any other data source and you can modify XML with a text editor. It's a win-win combination using nothing more than .Net which provides everything you want.
    Ah, okay, I see. I'll google and see what I can learn. This is a very new area for me

    I'll take a look at it. I do think we need to get away from straight flat files with sequential access. I think we've about done all we can with that kind of system.
    The locus of my identity is totally exterior to me.
    "On my business card, I am a corporate president. In my mind, I am a game developer. But in my heart, I am a gamer." - Satoru Iwata

  15. #115

    Thumbs up

    I've recently worked on projects at the office using both xml and a mysql database on what started out as small projects.

    Going the xml route is nice and is definitely faster than plain text. And it does have that advantage of being editable by notepad.

    That said, the results we got from using mysql were just spectacular. It really doesn't even compare if you are at all concerned about performance. But as far as being easily editable/customizable by users, it would definitely lack the simplicity of plain text.

    I would say that's not really a bad thing, though. You could for instance just quickly whip-up a form with a grid and have the data be editable that way, from right within the planner. You could display only the data that should be editable, and even have rules and validation on the data entry.

    Both approaches would work for the planner. Personally, I'd pick whichever sounds more interesting to put together or would let you mess with something you've not done before.
    "The sword itself has no moral stature, since it has no will of its own. Naturally, it may be used by evil men for evil purposes, but there are more good men than evil, and while the latter cannot be persuaded to the path of righteousness by propaganda, they can certainly be corrected by good men with swords."



  16. #116

    Default

    Quote Originally Posted by Ron View Post
    By "multiple" I mean, having the ability to take enhancements, reset a tree, and take different enhancements, saving the old data, so that the planner is aware that the player may want to change their enhancement sets at various points throughout their life. Which as you correctly pointed out, a lot of people do.
    That's where I was confused. My suggested implementation results in a single, unified set of enhancements that happen to support the ability to reset trees mid-build. It is distinctly not multiple sets, but rather one single list. At any point in the build, there is exactly one list of enhancements taken to that point. The core change is that instead of the enhancement name being the primary key, the order becomes the primary key. The same enhancement can be in the single list any number of times. The sample data file I posted on the previous page shows an example of this unified structure. Note that saving the order the enhancements are taken is required in this setup. (It's the primary key.)

    I thought of another "standard" example of tree resets mid-build: Sorcerers who go fire savant for the first half of heroic leveling then switch to water savant.

    Quote Originally Posted by Ron View Post
    Well, I thought about XML, but to me, that's just a flat file with a lot of tags Our 27,000 line file would hit 100K in XML, I'm sure And if it is just a flat file, would we gain anything over our current system by using it? Can you random access an XML file with any degree of performance? Probably not.

    And at what point does a database become not overkill? I think right now we are somewhere between 50 and 60K lines of text for the data. And once we redo the equipment files, I wouldn't be surprised if we hit 100K. Isn't that enough to say a database table is needed?

    I'd say not only is it not overkill, we are probably long overdue for it, hehe. And I'm not suggesting we are going to implement a full on SQL database engine into the planner. We are just going to use SQL tables and the built in .NET functions to access them.
    I'm a database programmer for small businesses, specializing in legacy code. I do way more work in VB6 than is healthy, heh. The amount of data involved in the planner is tiny. A database engine would be fine, but is not particularly required.

    When I design hobbyist apps similar to the planner I typically use binary data files, but occasionally I'll use text-based data. My experience is that you can load in several megabytes of text data into a string variable in a fraction of a second, and then parse that millions-bytes-long string variable into whatever arbitrary structure you like in maybe 1 or 2 seconds.

    It is very easy to get poor performance when parsing strings in VB, to be sure, but VB has the ability to parse text data extremely fast if you know the right techniques.

    My feeling is that a database is not needed because you can comfortably load all the data for the entire planner into memory and keep it there for the duration the program runs.

  17. #117
    Legendary Founder Ron's Avatar
    Join Date
    Feb 2006
    Posts
    2,832

    Default

    Well, I guess I suck then, because ours definitely takes longer than 1 or 2 seconds to load in the data, even without the icons loading.

    Anyway, we will figure it out. I kinda like the idea of a database simply because it eliminates all those errors we get from wrong keywords and missing delimiters and weirdness from having commas in the names of spells and whatnot. That has always been a big source of bugs for us that would instantly be banished.

    I tell you though, I AM going to write a small utility to convert our current flat files into whatever we end up using. No WAY am I going to re-input all that stuff, lol.
    The locus of my identity is totally exterior to me.
    "On my business card, I am a corporate president. In my mind, I am a game developer. But in my heart, I am a gamer." - Satoru Iwata

  18. #118

    Default

    Quote Originally Posted by Ron View Post
    Well, I guess I suck then, because ours definitely takes longer than 1 or 2 seconds to load in the data, even without the icons loading.
    No you don't and stop saying that you do.

    Quote Originally Posted by Ron View Post
    Anyway, we will figure it out. I kinda like the idea of a database simply because it eliminates all those errors we get from wrong keywords and missing delimiters and weirdness from having commas in the names of spells and whatnot. That has always been a big source of bugs for us that would instantly be banished.
    If you are going to use an external DB engine, I can highly recommend SQLite. There are binaries available for every version of .Net from 2.0 to 4.5.1. It's very easy to use and install (basically put the binaries in the same directory as your app), has a tiny memory footprint, is frequently maintained and 100% open-source. Also, as DagazUlf suggested, MySQL is also a good choice is you want a more robust option.

    Quote Originally Posted by Ron View Post
    I tell you though, I AM going to write a small utility to convert our current flat files into whatever we end up using. No WAY am I going to re-input all that stuff, lol.
    That is going to be more of a challenge than you think. There's a good deal of business logic embedded in the existing data files. RDBs frequently don't like that sort of thing. I think you'll be heavily refactoring your schema before any migration path can be finalized. But, a fresh start is not always a bad thing.

    Although I've been mostly retired for a while, I still know a thing or two about this sort of thing. Please feel free to call upon me as a resource if you so desire.
    The newest computer can merely compound, at speed, the oldest problem in the relations between human beings, and in the end the communicator will be confronted with the old problem, of what to say and how to say it. - Edward R. Murrow (1964)

  19. #119

    Default

    Quote Originally Posted by Ron View Post
    I tell you though, I AM going to write a small utility to convert our current flat files into whatever we end up using. No WAY am I going to re-input all that stuff, lol.
    I wrote most of one back in 2011, it likely still works well enough. I'd need to take a closer look at it to verify, but it would be easy enough to adapt it to create tab delimited text files. (ie: csv, but tabs instead of commas.) Those csv files could then be imported directly into tables, to be massaged into their final structure.

  20. #120
    Community Member Theolin's Avatar
    Join Date
    Oct 2006
    Posts
    1,023

    Default

    Quote Originally Posted by Ron View Post
    I tell you though, I AM going to write a small utility to convert our current flat files into whatever we end up using. No WAY am I going to re-input all that stuff, lol.
    Excel is your friend, there is a great little thing called text to columns, I use it all the time for DB data conversions, well along with some of the other ways of splitting up the 'row' that excel offers.

Page 6 of 18 FirstFirst ... 234567891016 ... LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

This form's session has expired. You need to reload the page.

Reload