Hi everyone, long time no post. I am currently working on an ODF editor (I know there are already some around but I just wanted a project to do that might be of use to someone rather than rotting on my hard drive). Anyway, there will be a built in help system which tells the user what each property is for and what values it accepts. I was just wondering if anyone knows the maximum values for properties like dilithiumCost, officerCost, maxHealth, etc which I could put in and stop anyone from entering any value above this. I am trying to make the editor as fool proof as possible so I need to build in as many safeguards as I can. ATM I have protected against people missing inverted commas and they cannot enter duplicate values or properties. Also, if anyone has a list of valid properties for ODF files (ones which are not there by default), that would also be extremely helpful!
thankyou all in advance talyn2k5
13th November 2004
Hmmm, for dilithium and metal, the max value is 999999, crew is 99999 and so is latinum. There is no limit for health and shields and special enrgy including their respective recharge rates. Officer the max is technically 999. Hope that helps, it not, do you need anything else?
thats great joelteon, thanks. Only other thing I need for now is maybe the aforementioned list of properties that are not always in ODF files by default (scaleSOD, etc).
ooh, just thought! What is the maximum number of builditems in an ODF? and is there a limit on shipnames?
think thats about it for now!
I want to be like the Admins
10th April 2004
Max on builditems is 13. No limit on ship names in a odf file as far as I know.
13th November 2004
KaBoom is right on both accounts, but I wouldn't want 300 different names. An extreme, true, but something to bear in mind if you want to limit that number.
Ok, what would you say is a reasonable amount of shipnames to allow? (assuming I ever get that part of the program working!) 30-50 maybe?
Have added limits for dilithium, metal, biomatter, crew, and officers. Still trying to figure out how to add the limit for buildItems (not as easy as you`d think).
Does anyone think it would be a good idea to add a maximum to health, shields, etc? Something like a ridiculous level that no one is ever likely to want to use but just to set a roof, or do you think this would be too restrictive?
And finally is const.odf the only #include that will allow a ship to build? I want to add a check so that buildItems cannot be put in a file without this include. Are there any other abilities/functions that require specific ODFs to be included?
Also, if anyone has experience in VB.net, I am having trouble with a few aspects of the program. If you think you can help, please PM me.
The Carbon Comrade
14th July 2004
I usually have 32 names per class of ship. Thats a fleet X2 (16 ships per fleet)!
13th November 2004
If you can fit this in, you'd want more names for the smaller classes, ie the Akira more than specific others, such as the Nebula or Aegian as people use less of them. You won't need SO many for battleships, but people who use masses of fleets wouldn't really mind about having duplicate names.
I didn't make it!
good luck on that editor. looking forward to seeing it in action.
SupaStarAshI usually have 32 names per class of ship. Thats a fleet X2 (16 ships per fleet)!
What i`ll do then is put in a limit of 50 shipnames (again,once I get that part of the program working. Nearly there!)
Does anyone have an opinion on limits for health, shields, etc? I want to make it foolproof but not SO foolproof that you can't crank a ship upto ridiculous shields strength whenever the feeling takes you to 0wn 7 AI-Hard players! (so much fun watching 4 ships destroying an entire race, but gets old pretty quickly.) The 'As You Go Help' as I`ve dubbed it is now ready for action. All that is there for each property is a description of its use and its max value (the user is still prevented from entering anything over this value). Is there anything else you think I should put in the AYGHelp for any particular properties?
Til next time.