DaisyBox's SR4CharGen (SR4CG), Official Discussion thread Options

[dobbersp]

The latest Version can be found here:
http://www.dobberisms.com/sr4cg.php

This is Beta, it aint perfect.
Maybe not even pretty. I'm workin' on it.

Q) Does it work for MAC/Linux ?
A) I do not know. It is designed for Windows XP/Vista with .NET framework

If any MAC/Linux users can download the .zip and try it out with Mono, that would be swell.
Please submit your feedback in a courteous manner.

Be sure to check out the documentation for adding your own items to data files.
The "Legend.txt" file is located at ~\Data Files\Legend.txt
It details that information.

Enjoy
d:- D

[dobbersp]

Heres a screen grab from 0.2.3.0
Beta Screen Grab

enjoy
d:- D

[Dumori]

Have you though about making it work with The Standardised Character Format

[dobbersp]

The current save file is in a delimited text file that can be read by a human, though with great difficulty, and not without knowledge of what each field represents. for example:

0|0|True|{5,4,7|4,8,7|}

It isnt in binary or anything like that. I realize that this format is not the strongest choice for flexibility or for updating (and its very difficult to read), though creating an inter-operable file format would be nearly impossible for character generators, unless you specify that the generator must reconstruct the character from solely the information in the file. This would mean that no program specific information could be stored in the file. The program would need to extrapolate that information from the data.

My current goal is to simply offer a working program for windows (with .net framework installed...) and unfortunately, I have already written the file format.

However, I am interested in creating a file format that is better than the one i have now. It just isnt on the top of the "todo list."
It is my hope that In the future, something similar to what you have proposed will be adopted and implemented in my character generator.

I'll keep harping on this point, but I have created some fairly detailed documentation for my data files that will be released with beta when it rolls around, and I hope that it will lend itself to some rad community involvement in extending the capabilities of the program. Heck, it might even become a sort of standard for data files.

Thanks for your interest ^^

d:- D

[Bobson]

I realize that this format is not the strongest choice for flexibility or for updating (and its very difficult to read), though creating an inter-operable file format would be nearly impossible for character generators, unless you specify that the generator must reconstruct the character from solely the information in the file. This would mean that no program specific information could be stored in the file. The program would need to extrapolate that information from the data.

See 5a & 5c in the format goals. The idea is to provide at least a section where the character generator app can store app-specific data, and at best a way to leave a "comment" on any element in the entire thing. It's not there yet, but that is the goal.

Though, I wonder what you mean by "the generator must reconstruct the character from solely the information in the file" - isn't that the definition of loading a saved character, regardless of format?


That being said, it's always good to have multiple options in character generators, so welcome to the forums and I look forward to seeing it (IMG:style_emoticons/default/smile.gif)

[dobbersp]

Though, I wonder what you mean by "the generator must reconstruct the character from solely the information in the file" - isn't that the definition of loading a saved character, regardless of format?

I suppose i was pretty vague with that one. What I meant was:

You cant have program specific information in a standardized file format.

A character generator would need to figure out its own program specific information from the file. a tag like

<ProgramSpecificInfo>
<field1>my secret information stuff</field1>
<field2>my previous variable value</field2>
</ProgramSpecificInfo>

would be pretty useless. Because each program is going to have its own

unless each character generator does have its own tag (which would mean a revision to the standard would have to come out each time a new generator emerges. quite undesirable.)

<DaisyBoxInfo>
</DaisyBoxInfo>

The most important issue in my mind will be devising a way to make it extensible.

<Addon>
<superSpecialNewStuff>BBQ Module</superSpecialNewStuff>
</Addon>


Anyhow.

I will try to make an export option for the standardized format once i get everything else working.
Unfortunately, there are more pressing issues at hand.

happy weekend.
d:- )

[Muspellsheimr]

unless each character generator does have its own tag (which would mean a revision to the standard would have to come out each time a new generator emerges. quite undesirable.)

Granted, it has been a few years since I last did any coding, so I could be wrong, but this should not be the case. The standard would have a generalized program specific section, as follows:
<ProgramSpecificInfo>
</ProgramSpecificInfo>

Each program that the file is loaded into would first check to see if it has a program-specific code section. If yes, load. If no, write. So, it would look like this
<ProgramSpecificInfo>
<Sample1>
</Sample1>
</ProgramSpecificInfo>

When loaded into another new program, it would then be this
<ProgramSpecificInfo>
<Sample1>
</Sample1>
<Sample2>
</Sample2>
</ProgramSpecificInfo>

Thus, the revision will always be to a character file, not to the standardized format, & will be done by programs utilizing the format.

[Bobson]

Granted, it has been a few years since I last did any coding, so I could be wrong, but this should not be the case. The standard would have a generalized program specific section, as follows:
<ProgramSpecificInfo>
</ProgramSpecificInfo>

Each program that the file is loaded into would first check to see if it has a program-specific code section. If yes, load. If no, write. So, it would look like this
<ProgramSpecificInfo>
<Sample1>
</Sample1>
</ProgramSpecificInfo>

When loaded into another new program, it would then be this
<ProgramSpecificInfo>
<Sample1>
</Sample1>
<Sample2>
</Sample2>
</ProgramSpecificInfo>

Thus, the revision will always be to a character file, not to the standardized format, & will be done by programs utilizing the format.

Ooh, good format. I like it. Into the spec it goes.


Edit: Ok, I've added:

CODE

<xsd:element minOccurs="0" name="ApplicationInformation">
    <xsd:complexType><xsd:sequence>
        <xsd:element name="Application" minOccurs="0" maxOccurs="unbounded">
            <xsd:complexType><xsd:sequence>
                <xsd:element name="ApplicationName"></xsd:element>
                <xsd:element name="TextInformation" maxOccurs="unbounded" minOccurs="0"></xsd:element>
                <xsd:element name="BinaryInformation" minOccurs="0" maxOccurs="unbounded" type="xsd:hexBinary"></xsd:element>
            </xsd:sequence></xsd:complexType>
        </xsd:element>
    </xsd:sequence></xsd:complexType>
</xsd:element>

XML generated from this would look something like:

CODE

<ApplicationInformation>
    <Application>
        <ApplicationName>DaisyBox</ApplicatioName>
        <TextInformation>Entered by DaisyBox SR4 chargen v.1</TextInformation>
        <TextInformation>House rules implemented: Clout, free races</TextInformation>
        <BinaryInformation>8167a910b9828dd9100927ca92fe93</BinaryInformation>
    </Application>
</ApplicationInformation>

I'm working on adding some kind of identifier to all those fields, but the idea is that you'll be able to store any app-specific information you want in either text or binary (as hex, possibly) format. Images, checksums, pre-calculated values, etc.

[dobbersp]

That wont work.

The only reason you would want to put a program specific info section into the standard would be if the program needs that information to load the file. (otherwise its pointless)

to illustrate the problem, I'll use this example:

you have two programs:
program 1 and program 2


so, as I'm following the proposed standard, the tags will be roughly like this:

<programSpecificInfo>

<program1>stuffs</program1>

<program2>different stuffs</program2>

</programSpecificData>

lets say that you create a character with program 1:

the file will look like this:

<programSpecificInfo>

<program1>stuffs</program1>

</programSpecificData>

then, you want to open the file with program 2 (which is the reason for the standard...portability)
so when you get to the program specific section, it only has information for program1.

If program 2 needed the
<program2>
</program2
section of the specific information to open the file, it would not be able to open the file. because its not there.

the information is only there for program1.

if program 2 didnt need the program specific information to load the character, why would you put it in the file?

It doesnt make a whole lot of sense to me, but then again...i might be missing something you guys havent told me about yet...

d:- )

[Bobson]

It doesnt make a whole lot of sense to me, but then again...i might be missing something you guys havent told me about yet...

d:- )

Multiple <Application> keys (IMG:style_emoticons/default/wink.gif)

CODE

<ApplicationInfo>
    <Application>
        <TextInfo>
    </Application>
    <Application>
        <TextInfo>
        <BinaryInfo>
    </Application>
</ApplicationInfo>

Correct behavior, of course, would be to preserve any unrecognized application blocks, and as I said, I'm still not entirely sure how we're going to identify which <Application> tag goes to which app, but there will be a way to do so. Does that address it? If not, please let me know - I want this to be able to work for all apps, not just the one spreadsheet (IMG:style_emoticons/default/wink.gif)

[Muspellsheimr]

The character sheets are basically data entry. There should be nothing outside of the basic file type & format needed to load one of these files.

Thus, if the application needs specific info that does not exist in the file you are trying to load, it leaves those entries blank & writes the section in the file for that information - specifically, in the <ProgramSpecific> section. It will then save such information under this new tag, without compromising other <ProgramSpecific> data. If the data is already there when loaded, it loads normally.



As I said, this is not for data that is required to load, it is for data that is not included in the basic standard documentation. Anything required to load is file format & type, and any tool using the standardized format will be designed to load standard format files.

[dobbersp]

ok, so, lemme get this straight....

the program specific data is for nonessential data for the character sheet?

that makes sense....so i hope thats right, heh.

I understand the method you are proposing, I was just unclear as to what type of data would be listed under the tag.

So, under that presumption of how you guys have it set up, there will need to be some sort of master list of application tags that are taken,
so that each new application that wishes to implement this standard can ensure that it will not have a conflicting tag. <sr4cg> being the most likely candidate.

I dibs <DaisyBoxInfo>

I think it would be a lot better to use phrases rather than keys to maintain human readability. We can set up a maximum character length though...

Its funny how this discussion is pretty much about the file format, because i dont have time to do much work on the actual generator just yet ^^

but take heart, I shall continue work as I am able...now off to write that servlet for class.


d:- D

[Zormal]

Will it be possible to tweak the costs of skills and attributes? I'm a fan of some of the FrankTrollman houserules, and would like to have a character generator that can cope with me changing the price of skills.

Right now I'm using an old(ish) excel sheet that has Frank's rules.

[dobbersp]

It is not currently possible to change the costs of stats or skills.

however, that should not be entirely difficult to do, and i will consider adding that functionality to the program after i release beta.
This would be easier to implement than the standardized character export, and so i could foresee it coming out before i code up the standard.

[dobbersp]

so, I'm at a point in development where i have most of the core book stuff implemented in the chargen.
I'm not able to address many bugs and provide support at the moment, so i havent released it as a beta yet.
I also want to tweak my website which will be hosting the project a little bit before release.

The beta should be released in the near future, after finals finish (approximately 2-4 weeks)


I am admittedly a bit of a shadowrun noob, and dont know the extent of all of the extra rules, and additional materials
that are used for character generation, so I decided to put this question up:

what are the most desireable features for a character generator beyond the core rules?
where should i start if im going to implement more stuff?


on my tentative list so far are the following:
+make a vehicles page...similar to the spiffy spread sheet (you can add vehicles as gear right now....which is a sort of hack to get it to work.....)
+get some sort of import/export option for a character standard.
+finish adding arsenal gear items...

I need suggestions for where to go next. Of course, it will be easier for you guys to make suggestions after the release in a couple few weeks.
but imagine the original excel spreadsheet, and you will have a good idea of what the program currently does.


thanks in advance.

PS Bobson, how close is the standard to being finished? Is it finished? Do you have some helpful examples and stuff?

[Muspellsheimr]

I would suggest including checks for Tweaking the Rules & Optional Rules options from the Core books, as well as for some of the popular House Rules, such as FrankTrollman's Build Point generation/advancement & Matrix rules, and Serbitar's rules.

I should also be posting a full compiling of my House Rules soon (2-4 weeks), & would be interested in having you include those as well.

[dobbersp]

it would be helpful to get page numbers, or direct quotes of the rules ^^

d:- D

[Muspellsheimr]

Serbitar's Shadowrun Supplements
FrankTrollman's House Rules

[Bobson]

PS Bobson, how close is the standard to being finished? Is it finished? Do you have some helpful examples and stuff?

Work's been clobbering me lately. It's not finished, although it's getting pretty close, and what is done is unlikely to change at this point. I'll try and post an example tomorrow, if I get enough of a break. If not, I should have one up by next week.

[dobbersp]

I just put up the first beta build:
http://www.dobberisms.com/sr4cg.php

there's an .exe and a .zip up as the two most recent releases.
The .exe works on my Windows XP, and hopefully on yours as well ^^.

I have no idea what the dependencies are for MAC/Linux users, but it would be really tight if Mono worked for them.
Please someone DL the .zip and a mono distribution and let me know what happens.

Mono:
http://www.mono-project.com/Main_Page

I will be on a finals stint for the next couple few days, so i may not be able to provide the most extensive service,
Apologies.

d:- )

[Zormal]

Christmas!

Thank you. Looks really good.
I really appreciate keeping everything as open as possible (the options dialog looks great)!

[dobbersp]

Merry Christmas.

let me know what you think about the data files (you can just open them with notepad)

d:- )

[Deus Innomen]

Looks pretty good so far. Most of my nitpicks are UI things at this point, so I'm shushing unless you want a barrage of observations. I'm a senior developer by career and my code reviews aren't very forgiving, so I'm trying to behave myself. (IMG:style_emoticons/default/wink.gif) But I'm definitely interesting in helping you figure things out if you need any guidance when you have time to work on this again.

What kind of feedback are you looking for at this point?

Also, would you be interested in a chunk of code to allow your program to become self-updating? (IMG:style_emoticons/default/smile.gif) I've started working on a suite of tools for another game I play (Star Fleet Battles), and I've found having the application be able to find and grab updates automatically is very handy.

[dobbersp]

Also, would you be interested in a chunk of code to allow your program to become self-updating? (IMG:style_emoticons/default/smile.gif)

Yes! I also would like to know what i have to do on the website to respond to queries about updates as well...

And I just finished with finals so i can work on this now. This is actually my first VB program, so im a bit noob with the language (and i wont have my CS degree until spring, so im no pro).
Feel free to let me know what needs to be improved, as i'm open to suggestions and concerns.

As for the GUI, I'm doing this on a laptop, so it takes forever to change....mostly because i need more RAM.
I chose VB so i could do GUI WYSIWIG style and not worry about Layouts and Panels and listeners...
But i can occasionally go over to my friends house and use his super computer (in comparison to this laptop) to make changes.

please start with the most important issues for the functionality of the app, and then we can move on to issues of sleekness.

right now my top priority is going to be getting the standard implemented with an import/export feature.

EDIT: what do you know about Mono?

thanks for your interest.
d:- )

[Deus Innomen]

Yes! I also would like to know what i have to do on the website to respond to queries about updates as well...

And I just finished with finals so i can work on this now. This is actually my first VB program, so im a bit noob with the language (and i wont have my CS degree until spring, so im no pro).
Feel free to let me know what needs to be improved, as i'm open to suggestions and concerns.

As for the GUI, I'm doing this on a laptop, so it takes forever to change....mostly because i need more RAM.
I chose VB so i could do GUI WYSIWIG style and not worry about Layouts and Panels and listeners...
But i can occasionally go over to my friends house and use his super computer (in comparison to this laptop) to make changes.

please start with the most important issues for the functionality of the app, and then we can move on to issues of sleekness.

right now my top priority is going to be getting the standard implemented with an import/export feature.

Okay, I'll fire you a PM with my email address. We'll talk more in depth there since it'll be pretty detailed. (IMG:style_emoticons/default/smile.gif)

EDIT: what do you know about Mono?

What I do know about Mono is that it's targeting .NET 2.0, which means you're going to need to make this a .NET 2.0 application instead of .NET 3.5. (That means no LINQ and a few other things but you can easily live without them.) Other than that, as long as you stay targeted to 2.0 it should work just fine.