|
3 people marked this as a favorite.
|
Before I start the thread, I didn't post this in the Community Use thread because I don't want to sign up to the program. I don't think it would actually help me, except that I could say the trademarked name that PFRPG is short for or the company that runs it. The only obstacle to me saying either now is the OGL, which I had to adopt due to how 3.x games work. Long story short, I think I can get around it, but it'll take a lot of extra engineering and I think my time could be better spent on other parts of the program.
This program (PFSB) makes statblocks for monsters based on user input. It only runs on *nixes as of now, but it shouldn't be too hard to change that. Also, the codebase is an absolute mess. v0.2 is mostly going to be me rearranging the codebase to be more maintainable.
Planned (farther in the future, mind you) is to have the output be a PDF instead of HTML. Also planned is a sort of internal DB that you can add files to for non-SRD (homebrew s@*@) creature types and classes. Oh, and probably a GUI at some point. That sounds possibly helpful.
Project is here. It should compile for Windows, but it won't output because it has *nix-specific things built into it. For example, fslash is the directory separator and the program has to read a template file from /usr/share. That second thing is defined in platform.hpp, and I don't think it's hardcoded anywhere else.
https://github.com/frozenMustelid/pfsb
Anyways, enjoy. I probably won't be able to work on it again for a week or several, so please tough out the issues until I can fix them.
What language are you using for this? If it helps, I'm proficient in C and C++.
This is C++ code, with HTML and CSS for the output. Due to the large changes due for next version, I'm not accepting submissions yet. Unless that submission is something like a Windows port. Or creature type/environment/climate icons.
I can program for Windows. I've got Visual Studio 2012 Ultimate. I've hand written a stand-alone database program to manage large collections of anime.
Just downloaded the source. I'll go over it later when I have time. I've got a busy Saturday ahead. No rest for the weary.
I just discovered that I have completely FUBARed the HP calculation. It's actually more likely to be wrong than to be right. This is scheduled to be fixed with v0.2. Until then, math it out by hand and correct the HTML output with a plain-text editor. I'm pretty sure I got the other calculations right, but I may have gotten those wrong too. Saves should be right more often than not, but AFAIK they're always calculated correctly. I try to test corner cases and edge cases, but obviously I can't test every possible value and some parts are tested better than others.
John Napier 698 wrote: I can program for Windows. I've got Visual Studio 2012 Ultimate. I've hand written a stand-alone database program to manage large collections of anime.
Just downloaded the source. I'll go over it later when I have time. I've got a busy Saturday ahead. No rest for the weary.
Killer. Fair warning, VS2012 won't compile the code unless you have an updated MSVC++. I use a few C++14 features, which (obviously) didn't exist until 2014.
I can still work on the Windows user interface. I'll have the buttons direct to stubs, which you can rename to the generator functions.
I remember my Visual Studio going through a serious upgrade earlier this year. I'll try to compile. If the source compiles, that's fine. If not, I can still work on the Windows User Interface.
Pathfinder Adventure, Adventure Path, Lost Omens, Maps, PF Special Edition, Starfinder Adventure Path, Starfinder Maps, Starfinder Roleplaying Game Subscriber
Dot. For OGL, you may find the bottom FAQ on this page useful.
For Windows compatibility, it would be best if you can transition from make to cmake. Visual Studio 2017 has native support for cmake, and would mean there are no issues with maintaining two build systems (Makefile and cxproj). std::filesystem should be used to generate paths, etc in an interoperable way instead of rolling your own (although in practice it doesn’t matter; Windows accepts forward slash as a directory separator as well).
@John: VS2017 Community is free and supports almost the same feature set as Professional. You may want to pick that up if you’re interested in working on this. It can be installed side-by-side VS2012.
Thanks, but I'm not sure my Windows 10 subversion is adequate enough. I tried downloading and installing last week and got nowhere. I might be better off just working on the UI for the Windows port.
skizzerz wrote: Dot. For OGL, you may find the bottom FAQ on this page useful.
For Windows compatibility, it would be best if you can transition from make to cmake. Visual Studio 2017 has native support for cmake, and would mean there are no issues with maintaining two build systems (Makefile and cxproj). std::filesystem should be used to generate paths, etc in an interoperable way instead of rolling your own (although in practice it doesn’t matter; Windows accepts forward slash as a directory separator as well).
@John: VS2017 Community is free and supports almost the same feature set as Professional. You may want to pick that up if you’re interested in working on this. It can be installed side-by-side VS2012.
OGL notices shouldn't be an issue. Using the --ogl option from the CLI (currently the only interface type available) prints a notice near-identical to Paizo's and Dreamscarred Press's. The --help info tells you about the --ogl switch. --version tells you that it's OGL, and that a copy of the license should have been included with the program. A few more mentions are scattered across the documentation included with the program.
If CMake has any better learning resources than Make, I'll definitely look into using it. Makefiles (at least, hand-written ones) don't seem to be that complicated, but the learning aids are terrible. Automake's are somehow even worse.
I looked into std::filesystem, but it isn't fully implemented in GCC yet. The closest analogue is experimental/filesystem, which (from what little I read on it) doesn't implement or doesn't correctly implement a lot of the library.
Still, thanks for the input. I probably won't be able to include any suggestions in the next version, but that's only because 0.2 is almost into the bugtesting phase. If I can get a few free moments before the holidays are over, it shouldn't be long before I can drop it.
P.S.: A friend told me that Windows won't translate fslash to bslash when written into programs, it's just that cmd.exe and explorer.exe both autoconvert the paths. That said, he admits that he was in his mid-teens the last time he did any programming, so it's more than likely he just doesn't remember. I'd love it if that were the case, because that's less platform-specific code I'd have to write.
John Napier 698 wrote: Thanks, but I'm not sure my Windows 10 subversion is adequate enough. I tried downloading and installing last week and got nowhere. I might be better off just working on the UI for the Windows port. I know basically nothing about source control software, so please forgive me if this is a dumb question, but would subversion even work with Github? Wouldn't you need git?
I heard somewhere that you could cajole makefiles into working on Windows with either a specialized version of make or by installing Cygwin and using their version of make. Supposedly, there's some way of tricking Cygwin into using a compiler that will compile native Windows code as opposed to Cygwin-compatible code. Either way, some parts depend on certain files existing in certain places, which won't be true because the makefile says they get put in locations that only exist on Unices.
Normally, makefiles are machine-generated and not human-readable, but I wrote this one by hand so it is. Mine is essentially the most basic possible form of shell script, merely a list of commands to be stepped through for each make rule. I think all of the commands used exist on Windows, though with slightly different syntax. I know mkdir exists on Windows, and I think that rm and cp exist too.
The general structure of a makefile rule is:
(file): dependencies
<tab here>commands
Blank dependencies mean there are none. The first rule listed is run if make is run without specifying a rule, unless a default rule has been specified. If the file listed exists, make assumes the rule has already been run and exits without running the commands again. The phony rules don't even check for the file, you just type `make <rulename>` and it runs the commands. The dashes in front of certain commands tell make that it's okay to keep going if those fail. The at signs tell make to not print that command's output to the terminal. The pound signs denote comments.
Many people have written better write-ups than I can about each of the commands I used. Look through the online man pages if you're not sure what a certain flag does, and adopt it to Windows. The makefile is 26 lines long (including whitespace), hopefully it shouldn't be too hard to slog through.
Don't go too crazy on the UI. It already sort of has a cross-platform UI, it's just text-based instead of graphical. There are cross-platform UI libraries (qt and wx are the most popular), both of which I would have to play with before even thinking about writing any code for. What I'm trying to say is, if you spend several months perfecting this thing, be aware I will almost certainly rip it out at some point to toss in something that's cross-platform out of the box. The only UI changes I would make at this time would be converting the -- switches to something more idiomatic on your platform of choice (if memory serves, only single-letter options, / instead of - or --, and change --help to /?). Though, of course, you're not me and if you send me something better, I'd be glad to have it.
P.S.: I was about to hit post when it occurred to me that you may have trouble with reading some of the text files. I don't remember if I told my editor to use Windows-style line endings (carriage return + line feed) or Unix-style line endings (just the line feed). Most Windows programs will render either correctly, but notepad.exe is not one of them. Notepad++ renders both correctly. I think Firefox will render both correctly if you point the address bar to the text file's location. I think Visual Studio will also render either correctly, but IIRC like most IDEs it isn't the easiest thing in the world to make it open a file on the HDD without adding it to the project first.
Anyways, it's crazy late my time. Good night, everybody!
Pathfinder Adventure, Adventure Path, Lost Omens, Maps, PF Special Edition, Starfinder Adventure Path, Starfinder Maps, Starfinder Roleplaying Game Subscriber
Once 0.2 drops I'd be willing to convert it to cmake and get it working on windows as a PR. Just didn't want to waste time if things are changing. Git for windows automatically converts LF to CRLF in the working copy (and back to LF when committing) by default, so don't worry about line endings.
For command line switches, I have a port of getopt() to windows, so imo just leave things as-is. I can throw in that library as a shim and all will be well (assuming you're using getopt for Linux).
skizzerz wrote: Once 0.2 drops I'd be willing to convert it to cmake and get it working on windows as a PR. Just didn't want to waste time if things are changing. Git for windows automatically converts LF to CRLF in the working copy (and back to LF when committing) by default, so don't worry about line endings. Great!
skizzerz wrote: For command line switches, I have a port of getopt() to windows, so imo just leave things as-is. I can throw in that library as a shim and all will be well (assuming you're using getopt for Linux).
Actually, I didn't use getopt. I wanted to make this as close to compatible with Windows as possible before actual Windows compatibility could be added. So instead, I just had the program do strcmp with argv[1]. I figured that it wouldn't ever get enough CLI options to make this an issue.
Fair warning, I am planning to put a contributor's agreement in the next version. It'll basically say that, if you send me changes/additions, you keep the copyright on your additions/changes unless you explicitly grant it to the project owner, but the current project owner can change the license to any license the FSF has declared a free software license. It may have another clause or two, something along the lines of, "It's your fault if your changes get me in legal trouble", but it's mostly there so I don't have to ask 15 people if I can change the license to something actually suitable to software instead of TTRPGs. Is that cool with you? Do you have any advice on what it should/shouldn't say?
I just learned about something Windows users could do to get a native binary on their system. Something called MinGW apparently has a Windows port of make. The make install command won't work, but it might at least build the program and it'll probably work right if you change the template file location (defined in platform.hpp) to something that can actually exist on Windows. It should be easy to do a manual install for PFSB
Also, I didn't mention this before, because I thought it was obvious, but in case it's not: Cygwin is basically a POSIX emulator. PFSB should run no-problem on Cygwin. Just make sure you install the right packages on Cygwin and you should be able to build+run it.
Also, 0.2 should drop either Monday or Thursday. All I need to do is finish some documentation and do a test install.
No. What I meant then was that my Windows 10 subversion was inadequate for VS2017. But now it seems that it was just a bad connection. I'll try again later. I've already got the source.
0.2 is ready. I managed to get more done in this release than I thought I would. I fixed 1 major bugs, 1 less major bug and a few minor bugs. I also added a few features. XP now includes commas. It is now possible to add DR, SR, and weaknesses to monsters. Special Abilities can now be formatted like they should be in a proper stat block. More changes can be found in changelog.txt.
Still *nix-only for the moment, but that may change in the coming weeks, because:
I'm now accepting contributions. A couple of people mentioned trying to port the build system to cmake, which is natively compatible with Windows. Hopefully they're also good enough to remove the dependency on G++ caused by my complete ineptitude with Makefiles and Autotools. Until it does get fixed, my only recommendation is to look into MinGW, which I've heard can build Make-powered stuff natively on Windows (changes will have to be made to expected file paths), or to install Cygwin, which should build and run the code with no changes necessary as long as you make sure to install make and a GCC-6/G++-6 or better package
Whatever else happens, 0.3 will definitely feature SLA support, probably spells too.
Zip:
https://github.com/frozenMustelid/pfsb/archive/v00.002.zip
Tarball:
https://github.com/frozenMustelid/pfsb/archive/v00.002.tar.gz
Pathfinder Adventure, Adventure Path, Lost Omens, Maps, PF Special Edition, Starfinder Adventure Path, Starfinder Maps, Starfinder Roleplaying Game Subscriber
I've done some initial work converting things to use cmake (this will also remove the dependency on g++ -- cmake is a replacement for autoconf in the sense that it generates the Makefile and related build environment things for you). It still needs more work before it will compile on Windows, and I'll be testing Linux compilation as well before opening the PR. Probably won't be today, but we'll see.
Regarding command line processing, instead of peppering the code with #ifs, I'd just recommend either accepting both styles of command line params on all platforms, or acception only unix-style params on all platforms. Makes things easier and reduces the chance of platform-specific bugs.
Here's what I've done so far. There are some issues with that commit that I'll be resolving in follow-ups but it lays the groundwork for what I'll be sending over.
Pathfinder Adventure, Adventure Path, Lost Omens, Maps, PF Special Edition, Starfinder Adventure Path, Starfinder Maps, Starfinder Roleplaying Game Subscriber
Before I make sweeping changes, just want to run the following by you for your perusal and approval:
1. I want to take a dependency on boost::program_options to perform command line processing in a cross-platform manner. This will also involve killing platform.hpp with fire; we can do platform detection in cmake and have it define tokens in config.hpp.in instead so we can avoid having #ifs in the code itself.
1.5. Said tokens will be employed as a replacement for the path to the template file; cmake can do platform detection and generate a list of paths that the code can check for the template file.
2. I want to convert a lot of uses of C-strings and raw pointers to use safe alternatives such as std::string, passing by (const) reference, or RAII techniques such as std::unique_ptr if pointers are absolutely needed. This will increase code safety against things like buffer overflows and help prevent memory leaks.
3. If we're only supporting C++14, I want to convert uses of cstdio to use boost::filesystem. If C++17 is allowed, it will be converted to std::filesystem instead. (My preference is to go in for C++17 unless your local build system doesn't support that)
4. I want to rename all of your enum values. SHOUTY_NAMES should be reserved for macros, as you've discovered with collisions on HUGE. Furthermore, making them enum classes (instead of plain enums) will allow us to avoid polluting their enclosing scope with extraneous symbols.
5. General C++ conformance and stylistic issues: do not use "using namespace std" inside of header files, do not name things with leading underscores, rename files to be more descriptive of what they're about (splitting things up into multiple translation units as needed), avoid putting definitions inside of header files (put inside its own translation unit instead so we don't run into linker issues), avoiding "central" header files so that incremental compilation isn't stymied whenever we need to change it, etc.
Saved the new source. I'll try to do an overnight install of VS2017 Community.
skizzerz wrote: 1. I want to take a dependency on boost::program_options to perform command line processing in a cross-platform manner. This will also involve killing platform.hpp with fire; we can do platform detection in cmake and have it define tokens in config.hpp.in instead so we can avoid having #ifs in the code itself. Sounds alright to me. I was kind of expecting platform.hpp to die when a proper build system came around.
skizzerz wrote: 1.5. Said tokens will be employed as a replacement for the path to the template file; cmake can do platform detection and generate a list of paths that the code can check for the template file. Sounds good to me.
skizzerz wrote: 2. I want to convert a lot of uses of C-strings and raw pointers to use safe alternatives such as std::string, passing by (const) reference, or RAII techniques such as std::unique_ptr if pointers are absolutely needed. This will increase code safety against things like buffer overflows and help prevent memory leaks. Seems largely unnecessary, but I'm not married to the current find-replace functions. Leaky memory (at least on Linux) gets freed upon program exit. A quick glance at the codebase indicates that almost nothing gets affected except the find-replace functions and the undocumented game select feature, and the only pointers those use are null-terminated character arrays. What I'm trying to say it, go for it if you think it's necessary. I don't think it's priority, but if it's better code than what I already have, it would be stupid to not include it.
Speaking of the find-replace function, someone finally told me what was wrong with it. strcmp does not return at the first difference like I thought it did, so it tries to read everything in memory until it finds something to interpret as '\0'. It can be fixed by adding a character to the memory allotted to potentialMatch, then setting the last char to '\0', or by using strncmp in line 354 and using keyLength as the new param (which is what I did.)
skizzerz wrote: 3. If we're only supporting C++14, I want to convert uses of cstdio to use boost::filesystem. If C++17 is allowed, it will be converted to std::filesystem instead. (My preference is to go in for C++17 unless your local build system doesn't support that) GCC-7 doesn't properly support std::filesystem. GCC-8 apparently does, but it's so bleeding-edge it hasn't even been released yet. Also, some distros' GCC packages are infamous for being out of date. IIRC mine shipped with GCC-4.9, and it was released about a year ago.
skizzerz wrote: 4. I want to rename all of your enum values. SHOUTY_NAMES should be reserved for macros, as you've discovered with collisions on HUGE. Furthermore, making them enum classes (instead of plain enums) will allow us to avoid polluting their enclosing scope with extraneous symbols. I have only just heard of enum class, and I already like it. I haven't played with it much, but just changing the declaration doesn't cause any compile errors and it lets me define NUL in both. It almost seems like a Java-style enum, which is great because Java enums are one of the few times where Java differs from C++ and I prefer the Java version. As long as there's no hidden catch, like a bunch of extra code having to be written to make the switch statements work correctly, or if it makes it hard to convert to an int (which I don't think this program even does), this looks awesome.
I'm less a fan of changing the enum names, though. I had always heard that most programmers (C/C++/Java at least, I've that some users of newer languages prefer different conventions) expect to see constants in all-caps with underscores between words, and I think it's a good practice. It indicates immediately that a value should not change, that it's either set at compile time or set once during program operation.
I agree that there should be a visual difference between preprocessor macros and all other constants, and for some reason I thought that single underscores were reserved for the user, but apparently I was wrong. Do you have any suggestions? I don't like keeping them lowercase, it looks like a normal variable. I don't like capitalizing the first letter, it looks like a programmer-defined data type. aLtErNaTiNg cAsE CaUsEs eYe bLeEdInG. Unless there's something I'm not mentioning, I'd prefer to keep the constants named as they are, though the macros can have the leading underscores removed because that was my screwup.
skizzerz wrote: 5. General C++ conformance and stylistic issues: do not use "using namespace std" inside of header files, do not name things with leading underscores, rename files to be more descriptive of what they're about (splitting things up into multiple translation units as needed), avoid putting definitions inside of header files (put inside its own translation unit instead so we don't run into linker issues), avoiding "central" header files so that incremental compilation isn't stymied whenever we need to change it, etc. For the most part, I'm unsure of what you mean exactly. Changing using namespace std to using std::whatever is fine (I did using namespace std because I hate constantly going back to the top of the file to add a new function) and I'm not sure where I learned that leading underscores are okay, but I thought that I had done all of the other things.
pfMon.hpp contains all of the info needed for a PF monster, except for a few struct and enum declarations, which go in pfMeta.hpp. The actual function implementations go in pfMon.cpp, except for a few pieces of code that either are non-game-specific or will be shared when other systems are added to PFSB (both of which go in main.cpp). errors.hpp contains some #defines to make it easy to have consistent and meaningful exit codes, and maybe actual error classes if I (or a contributor) ever feels like it's important enough to warrant spending time to write them. I'm also not sure exactly what you mean by a central header file. I can see why it's generally not the best idea to bunch #defines inside of a header file, but IMO this is a case where it makes sense. Unless you're referring to linker issues I'm not aware of, the only thing I can think of are issues with double defining a macro.
Without more specifics I'm failing to see a problem with most of the things in the above paragraph. Or maybe it's just because it's 5AM my time and I need sleep. Anyways, good night, and thanks for your help.
Pathfinder Adventure, Adventure Path, Lost Omens, Maps, PF Special Edition, Starfinder Adventure Path, Starfinder Maps, Starfinder Roleplaying Game Subscriber
Frozen Mustelid wrote: I have only just heard of enum class, and I already like it. I haven't played with it much, but just changing the declaration doesn't cause any compile errors and it lets me define NUL in both. It almost seems like a Java-style enum, which is great because Java enums are one of the few times where Java differs from C++ and I prefer the Java version. As long as there's no hidden catch, like a bunch of extra code having to be written to make the switch statements work correctly, or if it makes it hard to convert to an int (which I don't think this program even does), this looks awesome.
I'm less a fan of changing the enum names, though. I had always heard that most programmers (C/C++/Java at least, I've that some users of newer languages prefer different conventions) expect to see constants in all-caps with underscores between words, and I think it's a good practice. It indicates immediately that a value should not change, that it's either set at compile time or set once during program operation.
I agree that there should be a visual difference between preprocessor macros and all other constants, and for some reason I thought that single underscores were reserved for the user, but apparently I was wrong. Do you have any suggestions? I don't like keeping them lowercase, it looks like a normal variable. I don't like capitalizing the first letter, it looks like a programmer-defined data type. aLtErNaTiNg cAsE CaUsEs eYe bLeEdInG. Unless there's something I'm not mentioning, I'd prefer to keep the constants named as they are, though the macros can have the leading underscores removed because that was my screwup.
With an enum class (instead of plain enum), the only way to access the enum value is to preface it with the enum type name. In other words, if you have the code "enum class Size { fine, diminutive, tiny, small, medium, large, huge, gargantuan, colossal }" the only way to access the various sizes is by doing e.g. "Size::tiny", "Size::huge", etc. -- simply specifying "tiny" or "huge" won't work. That is the only difference between an enum class and an enum, so any code that uses it will work as-is given your stated preference for that means of access anyway.
There's no real standard C++ naming convention, I just have a personal preference against all uppercase stuff if they aren't preprocessor macros or constexpr expressions. If you want enum values to be all uppercase, that's your call and I'll keep things as-is. :)
The C++ standard library uses class names and members as all_lowercase_with_underscores, but the Standard doesn't dictate that user code follow the same methodology. CamelCase and lowerCamelCase work just as well, after all.
Regarding leading underscores:
ISO/IEC 14882:2017 wrote: Section 5.10 [lex.name]
3 In addition, some identifiers are reserved for use by C++ implementations and shall not be used otherwise; no diagnostic is required.
(3.1) — Each identifier that contains a double underscore __ or begins with an underscore followed by an uppercase letter is reserved to the implementation for any use.
(3.2) — Each identifier that begins with an underscore is reserved to the implementation for use as a name in the global namespace.
The linker issues arise from double-defining functions, not macros. When a function is defined in a header with external linkage and included into multiple translation units, the linker will see duplicate definitions when linking those TUs together and error. For a trivial example, see the following:
header.h wrote: #ifndef HEADER_H
#define HEADER_H
int foo() { return 1; }
int bar();
#endif
foo.cpp wrote: #include "header.h"
#include <iostream>
int main() {
std::cout << foo() << " " << bar() << std::endl;
}
bar.cpp wrote: #include "header.h"
static int i = 0;
int bar() {
i += foo();
return i;
}
When attempting to compile with the command "g++ foo.cpp bar.cpp" you receive the following error:
Quote: $ g++ foo.cpp bar.cpp
/tmp/cc09C3h7.o: In function `foo()':
bar.cpp:(.text+0x0): multiple definition of `foo()'
/tmp/cc59HWQ1.o:foo.cpp:(.text+0x0): first defined here
collect2: error: ld returned 1 exit status
Downloaded the Visual Studio 2017 build tools (the command-line tools and no IDE) and compiled my first program. Will begin working to port the Generator to Windows.
John Napier 698 wrote: Downloaded the Visual Studio 2017 build tools (the command-line tools and no IDE) and compiled my first program. Will begin working to port the Generator to Windows. Neat! I feel bad about telling you this after 4 days, but 0.3 is looking close to ready. I have no idea when I'll have time to finish it, though. The coding for most of the new/improved features is done, but I haven't done any bug or quality testing at all. Most of the code hasn't been touched, but there are a few new files.
I may be able to find time later this month to finish 0.3, but maybe I won't. It almost certainly won't happen this week, and next is looking pretty bleak too. If you want me to post what I have in a new branch on the Github, I will. It builds, but I don't know yet if it works right. I made a change to findAndReplace(), which is pretty fragile.
Please, if you don't mind.
John Napier 698 wrote: Please, if you don't mind. Sorry it took so long, I was having technical difficulties. I just published code to a new branch ("development") on the github page. Hopefully everything made it through okay. Also, I'm pretty sure I forgot to add a few changes to the changelog, but I can't remember what they are off the top of my head.
Frozen Mustelid wrote: John Napier 698 wrote: Please, if you don't mind. Sorry it took so long, I was having technical difficulties. I just published code to a new branch ("development") on the github page. Hopefully everything made it through okay. Also, I'm pretty sure I forgot to add a few changes to the changelog, but I can't remember what they are off the top of my head. I just remembered to mention this: Next update after 0.3 will probably be an XML update. I haven't decided what library to use yet, but I'll make sure it's compatible with Windows too.
So, it's been almost a year with no update, so I figured I'd post an update.
No, the project is not abandoned. I have just had a very, very busy year, and will probably remain busy until at least mid or late summer next year.
Where I'm at right now is that I was close to releasing 0.3 and adding SLAs/spells to monsters. I was running into a weird bug that's honestly a little hard to debug from where it is in the code, and I've only been able to make time for a few days in the last year to even try to mess with it. Usually, by the time I am able to get around to it I've had to spend most of the time allotted to figuring out exactly what problem I was having in the first place and redoing my old tests.
I may or may not add a Pathfinder 2 mode to the system. Ever. It's not high priority (because honestly from what I've seen it looks like garbage). One day I would like to see this program support most well-known TTRPGs, but right now the highest priority is getting full PF1e monster support (minus some PC stuff), a working GUI mode, the ability to give monsters core class levels, and a working Windows version (which should be more or less trivial now that I have a proper Windows install and will be either in 0.3 or 0.4). A few other features would be nice, but I expect most of the other features I'd add are either trivial to implement or directly related to those 3 things I mentioned.
If I get free time to work on this before summer, I expect to spend it working on an unrelated project. Most of my summer will probably be split between this other project and PFRPG, but with how my life has been going recently, any plans I make are tentative at their absolute best.
Recent threads in Technology
|
