Let me tell you, it ain't as easy as anyone may think. I've been working on my own CB for a while, and the modeling of all the data is a pain in the ass, even when you know what you're doing. Let alone letting the lay person who knows jack about data modeling come up with their own stuff without tools to shoe horn what they want to do into what you can do.
CB's biggest failing by far: No custom content possible
- Thread starter DNH
- Start date
Dr_Ruminahui
First Post
Depending on what kind of modifications you wish to make, this tool may be very helpful: https://power2ool.com/login/
It, for example, allows you to modify (if you have a DDI account) existing equipment, or (no DID account needed) create your own. Any cards resulting look just like the CB ones.
It does not do the math for you, or intigrate any bonuses from the card into the character itself, but is none the less quite a handy tool. Personally, I love it - for nothing else, it has a much better search interface than CB or the Compendium (for most searches, anyway).
It, for example, allows you to modify (if you have a DDI account) existing equipment, or (no DID account needed) create your own. Any cards resulting look just like the CB ones.
It does not do the math for you, or intigrate any bonuses from the card into the character itself, but is none the less quite a handy tool. Personally, I love it - for nothing else, it has a much better search interface than CB or the Compendium (for most searches, anyway).
I'd just like to barge in at this point like a bull in a china shop...
I'm a lead developer in a corporate environment and we use web technologies for our projects, as well as database technologies to store customer details and the like.
Having a free text field for such as Religion and Language breaks nothing. As far as I am aware neither of these properties of a character relate to anything else (with the possible exception of Religion - to determine Challenge Divinity feat availability - but as that is a "does this character worship Pelor? Yes. Then show this feat" algorithm, it doesn't break anything).
Some things can easily be implemented and are quick wins. I'm amazed that such a simple thing - that used to exist! - is now not available. Someone, somewhere, made a conscious decision to exclude it. If it never existed in the offline one then I would completely agree that it's been overlooked, or is at the bottom of the pile - but it did exist, and has therefore been excluded.
Such a simple change would give a lot of benefits - so why not do it?
I'm a lead developer in a corporate environment and we use web technologies for our projects, as well as database technologies to store customer details and the like.
Having a free text field for such as Religion and Language breaks nothing. As far as I am aware neither of these properties of a character relate to anything else (with the possible exception of Religion - to determine Challenge Divinity feat availability - but as that is a "does this character worship Pelor? Yes. Then show this feat" algorithm, it doesn't break anything).
Some things can easily be implemented and are quick wins. I'm amazed that such a simple thing - that used to exist! - is now not available. Someone, somewhere, made a conscious decision to exclude it. If it never existed in the offline one then I would completely agree that it's been overlooked, or is at the bottom of the pile - but it did exist, and has therefore been excluded.
Such a simple change would give a lot of benefits - so why not do it?
Ryujin
Legend
I should think that the two top priorities would be:
1) Adding the new content to builder
2) Getting Builder up to, at the very least, the standard at which it performed before the offline rug got pulled out
Thanks, Babbage. Your post serves to reaffirm what my problem is, which is two-fold. One is that certain functionality that used to be available is now no longer available, which makes little to no sense. But the main one is that the custom content I am talking about is minor, so why not implement its inclusion? People posting on this thread have started using the term "house rules" and that is not really what I am talking about. Okay, I have a small handful of custom feats and Channel Divinity powers but I can live without including them if that is so problematic to achieve. But surely, *surely*, a free text field option for religion and languages ... I mean, you can already type in the character and player names.
You would think (and I realise I may be a little naive or over-optimistic here) that the software developers would have built the application to be future-proof, inasmuch as they will be able to add to the data without breaking anything. So I would like to think that your two priorities can be addressed concurrently.
Shall I also bring up now the inability to use custom character portraits?
The problem lies in character storage. If they've built the system with relegion selected stored via it's integer key, then typing into a field to override by itself simply wont work, mismatched datatypes. So lets say you create another table to hold religion overrides, that one more piece that sure, you could slap on in the UI and backend, but what else is going to want that kind of override ability? Then you have to think "is this the most optimial long term solution, or a quick fix that is going to make life a PITA later?". It's not an easy solution (nor a very good one).
Last edited:
Two words: Datatype Storage.
Any intelligently designed system (and i'll give the benefit of the doubt that CB is 'intelligently' designed, even tho that may be stretching it quite some distance) will store it's data in the smallest and most easily comparable datatype possible. What this means is you have a table of religions, each has an associated integer that represents that religion. When you store the character, you store it's religion as 2 instead of 'Bahamut', because it saves space, and it's significatly faster to compare 2 == 2 than 'Bahamut' == 'Bahamut' when looking other things up. Since you are storing an integer, you can't simply just store the value of a text field in it's place. Sure you can add a religion to the religion table, but there is going to be more information that the system expects (and usually requires) to know about a single religion entry. Add on top of that, you need to come up with a way to denote that this religion is classified as a 'house rule' tied to some player (think of it as a source identifier, like MM3 or Dra400). Now, you need to add a subsystem and UI to allow the player to search and 'subscribe' or 'inculde' that source as part of the campaign so you don't have an ungodly huge list of deities from every joe blow that inputs a religion all displayed at once. Then, you might also want a table that allows the creator to associate custom religions with major campaign religions for the purpose of 'filing off the numbers' for feat/power/etc support with the custom religion.
When it was the old CB, information was stored in very loosely coupled xml, which allowed all kinds of junk data to be strewn anywhere because there wasn't a good schema (data model) to keep it all straight. When you start dealing with databases, you have to be significatly more strict, and you have to enforce data type integrity. Take a car, you put gas in the tank. Just because diesel, bio diesel, wood, coal, plutonium, and heavy water are all types of fuel, you don't just stick them in your tank and expect to go driving down the road. If you want good performance with thousands of users, as opposed to a single user on his own desktop that can devote 100% computing resources to just that user, you have to design based on using integer keys and other such things.
It's not to say that it's impossible, but good developers have to take their time and actually plan things out. The difference between using a POJO for a webservice and actually sitting down and creating a strongly typed schema for in/outputs.
Last edited:
I apologize to anyone I may appear to be talking down to, but I honestly affirm that is not what I am doing here. I don't know the technical level of anyone here, so I'm just going for the lowest common denominator! 
It's certainly true that comparing integers to other integers is quicker than comparing one set of letters to another set of letters. It's also true that storing an integer in a database takes up a lot less space that storing all those letters.
(Incidentally, I'm using the word 'integer' and not 'number' specifically - using any 'number', such as 13.5674201, would be just as problematic. Using a neat integer with no decimal places is a lot easier to compare.)
But the problem described above is not insurmountable, and here's why...
In a database you would have a table listing all the languages in the core rules and against each one there would be a unique number. No two languages would have the same number. This means that each character "User A" creates stores those numbers (for speed and storage reasons) - but when you look at the character, the software goes "hey, Albion the Dwarf knows languages 1 and 3; which according to this list is Common and Dwarven" (albeit a lot quicker than you or I can read).
So how do you allow "User A" to have other languages that aren't in the core list? Simple. You have another table, which adds in any language that doesn't already exist - but is only visible to "User A" and all the characters he cares to create. How is this stored? Using numbers - no different to the way the core list is stored.
It's so simple any reasonably experienced developer would know how to design it. I've done it several times on several projects - each with many users. But let's number crunch a little...
How many DDi subscribers are there? Any idea? I don't. Let's pick a completely arbitrary and ridiculous 1 million! How many languages are there in 4e? I know this one! Well, I don't - but I'd be surprised if it was more than 20.
Out of those 1 million subscribers how many do you think use languages not in the core list? Let's be equally arbitrary and say *all* of them. And not just one additional language, let's have another 20 languages for *each* subscriber!
How big would this table be? 20,000,000 lines. Yes, but in terms of storage? Sorry to go all technical but let's assume 4 bytes for the number (well, I say *assume*, it *is* 4 bytes for an integer) and 100 bytes for a 50 letter language (err, wow! That's probably a language in itself) - this means each new language takes up 104 bytes. Multiply that by 20,000,000 we get just under 2Gb. 2Gb!? That's less than a memory stick nowadays.
In the examples above I've show a simple way of implementing it, then blown it apart with over the top numbers. It's peanuts, it really is.
It's certainly true that comparing integers to other integers is quicker than comparing one set of letters to another set of letters. It's also true that storing an integer in a database takes up a lot less space that storing all those letters.
(Incidentally, I'm using the word 'integer' and not 'number' specifically - using any 'number', such as 13.5674201, would be just as problematic. Using a neat integer with no decimal places is a lot easier to compare.)
But the problem described above is not insurmountable, and here's why...
In a database you would have a table listing all the languages in the core rules and against each one there would be a unique number. No two languages would have the same number. This means that each character "User A" creates stores those numbers (for speed and storage reasons) - but when you look at the character, the software goes "hey, Albion the Dwarf knows languages 1 and 3; which according to this list is Common and Dwarven" (albeit a lot quicker than you or I can read).
So how do you allow "User A" to have other languages that aren't in the core list? Simple. You have another table, which adds in any language that doesn't already exist - but is only visible to "User A" and all the characters he cares to create. How is this stored? Using numbers - no different to the way the core list is stored.
It's so simple any reasonably experienced developer would know how to design it. I've done it several times on several projects - each with many users. But let's number crunch a little...
How many DDi subscribers are there? Any idea? I don't. Let's pick a completely arbitrary and ridiculous 1 million! How many languages are there in 4e? I know this one! Well, I don't - but I'd be surprised if it was more than 20.
Out of those 1 million subscribers how many do you think use languages not in the core list? Let's be equally arbitrary and say *all* of them. And not just one additional language, let's have another 20 languages for *each* subscriber!
How big would this table be? 20,000,000 lines. Yes, but in terms of storage? Sorry to go all technical but let's assume 4 bytes for the number (well, I say *assume*, it *is* 4 bytes for an integer) and 100 bytes for a 50 letter language (err, wow! That's probably a language in itself) - this means each new language takes up 104 bytes. Multiply that by 20,000,000 we get just under 2Gb. 2Gb!? That's less than a memory stick nowadays.
In the examples above I've show a simple way of implementing it, then blown it apart with over the top numbers. It's peanuts, it really is.
