wyrmtools-developers Mailing List for Wyrm Tools
A suite of tools for any RPG system
Status: Pre-Alpha
Brought to you by:
wyrmtools
You can subscribe to this list here.
2006 |
Jan
(1) |
Feb
|
Mar
(6) |
Apr
(9) |
May
(1) |
Jun
(1) |
Jul
(5) |
Aug
(3) |
Sep
(1) |
Oct
|
Nov
(1) |
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2007 |
Jan
|
Feb
(1) |
Mar
(2) |
Apr
(2) |
May
|
Jun
(3) |
Jul
(3) |
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
2008 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: SourceForge.net <no...@so...> - 2008-03-19 18:46:22
|
Feature Requests item #1920007, was opened at 2008-03-19 13:46 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=724981&aid=1920007&group_id=132696 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Other Group: None Status: Open Priority: 5 Private: No Submitted By: yrogerG (luckycharms) Assigned to: Nobody/Anonymous (nobody) Summary: Automatically move cursor to text fields in dialogs Initial Comment: When creating a dialog to add an element into the model, it would be nice to move the cursor into the text field where you type something, instead of leaving the user to mouse-click or tab into the space manually. This way, frustration is reduced somewhat with the interface of the program. As you have no Category for "User Interface", I selected Other, and I didn't know if selecting Next Major or Next Minor release was of importance, but I figure the fix to this submission would be fairly easy. Hope this still reaches you. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=724981&aid=1920007&group_id=132696 |
From: SourceForge.net <no...@so...> - 2007-11-27 12:10:28
|
Bugs item #1839415, was opened at 2007-11-27 12:10 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=724978&aid=1839415&group_id=132696 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Other Group: Pre-Alpha Status: Open Resolution: None Priority: 5 Private: No Submitted By: Simon Brooke (simon_brooke) Assigned to: Nobody/Anonymous (nobody) Summary: 0.13 fails to launch on Linux Initial Comment: 0.13 fails to launch on Linux, complaining of a widget disposal problem; see attached log file. Windows version starts without problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=724978&aid=1839415&group_id=132696 |
From: SourceForge.net <no...@so...> - 2007-07-26 02:14:41
|
Bugs item #1760719, was opened at 2007-07-25 22:14 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=724978&aid=1760719&group_id=132696 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: User Interface Group: Pre-Alpha Status: Open Resolution: None Priority: 5 Private: No Submitted By: Wyrm Tools (wyrmtools) Assigned to: Wyrm Tools (wyrmtools) Summary: Layout fragments not updated with their effective element Initial Comment: When you update the name of an element (e.g. via an editor), all associated layout fragments should be updated in the UI to reflect the new name. This is no longer occurring, and thus is a regression. ENVIRONMENT: Wyrm Tools 0.12.0 REPRO STEPS: 1) Create a repository and import the d20 SRD. 2) In the Model Explorer, set the Source Layout to be Publisher/Type/Name. 3) Expand the Sources node completely. It should display a branch "Wizards of the Coast->Rulebook->System Reference Document". 4) Expand the Publication Types node to reveal the "Rulebook" element. 5) Open the publication type editor for the "Rulebook" element. 6) Change the name of the element (e.g. to "Rulebook2"). 7) Save the changes to the element. EXPECTED BEHAVIOR: Both the element under Publication Types and the fragment under Sources should reflect the changed name. ACTUAL BEHAVIOR: Only the element under Publication Types is updated. The fragment under Sources still displays the original name. It appears this broke in revision 1.10 of org.wyrmtools.internal.core.model.Model on 2005-10-23. The comment indicates elements that do not exist in the model do not have their events propagated through the model, otherwise detached elements firing events cause all sorts of problems. A quick fix seemed to be adding an exception to the !element.exists() expression, namely if( !element.exists() && element.getType() != IFragment.TYPE ) but it is not clear if this will cause any additional regressions. Not to mention it's just plain ugly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=724978&aid=1760719&group_id=132696 |
From: SourceForge.net <no...@so...> - 2007-07-23 03:01:32
|
Bugs item #1758656, was opened at 2007-07-22 23:01 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=724978&aid=1758656&group_id=132696 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Other Group: Pre-Alpha Status: Open Resolution: None Priority: 9 Private: No Submitted By: Wyrm Tools (wyrmtools) Assigned to: Wyrm Tools (wyrmtools) Summary: d20 SRD classes have incorrect d20:spellPoints scripts Initial Comment: All d20 SRD classes had d20:spellPoints scripts added as part of TASK 140326. Unfortunately, these scripts end up contributing more points than intended at class levels after the first. The scripts must be re-written to incrementally add spell points at each additional level, rather than attempting to reproduce the SRD class spell slot tables verbatim. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=724978&aid=1758656&group_id=132696 |
From: SourceForge.net <no...@so...> - 2007-07-21 03:13:00
|
Bugs item #1757881, was opened at 2007-07-20 23:12 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=724978&aid=1757881&group_id=132696 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: User Interface Group: Pre-Alpha Status: Open Resolution: None Priority: 5 Private: No Submitted By: Wyrm Tools (wyrmtools) Assigned to: Wyrm Tools (wyrmtools) Summary: Layout fragments are leaked Initial Comment: The various implementations of org.wyrmtools.ui.model.ILayoutFragment implement IModelListener. Although their dispose() implementation unregisters themselves as model listeners, this method is never called. (This is because all structure providers assume their elements are IElements, which should not have their dispose() method invoked arbirtrarily.) Thus, every layout fragment ever created is leaked. This not only causes memory usage to increase, but the model listener list becomes so huge that UI updates take increasingly longer the longer the application is running. Weak references should be used for layout fragments. This could be implemented by passing a proxy that wraps the layout fragment in a WeakReference to the IModel.addModelListener() method. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=724978&aid=1757881&group_id=132696 |
From: SourceForge.net <no...@so...> - 2007-06-09 02:36:45
|
Bugs item #1733918, was opened at 2007-06-08 22:36 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=724978&aid=1733918&group_id=132696 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Persistence Group: Pre-Alpha Status: Open Resolution: None Priority: 5 Private: No Submitted By: Wyrm Tools (wyrmtools) Assigned to: Wyrm Tools (wyrmtools) Summary: Prereq alerts not displayed in d20 character editor Initial Comment: Under certain conditions, prerequisite violations are not displayed in the character editor, even though the user is warned of them before commiting the operation that would result in the violation. This has been primarily seen when adding feats with prerequisites. [ENVIRONMENT] This is occurring in the Wyrm Tools 0.12.0 release candidate. [REPRO STEPS] 1. Create a new d20 character. 2. Open the character in the character editor. 3. Do whatever is necessary to get the character to level 1 (set race, class, abilities, etc.). 4. SAVE THE CHARACTER AFTER ADDING THE LEVEL 1 CLASS (this is the key to the repro). 5. Add a feat with a prerequisite (for this test, I used Cleave, which has a prereq of the Power Attack feat). 6. Dismiss the warning that indicates a prerequisite will be violated if the operation is committed. [EXPECTED BEHAVIOR] The Cleave feat will be added, but an alert will displayed next to it in the Selected Feats tree. [ACTUAL BEHAVIOR] The Cleave feat is added, but no alert is displayed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=724978&aid=1733918&group_id=132696 |
From: SourceForge.net <no...@so...> - 2007-06-04 01:51:31
|
Bugs item #1730450, was opened at 2007-06-03 21:51 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=724978&aid=1730450&group_id=132696 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: User Interface Group: Pre-Alpha Status: Open Resolution: None Priority: 5 Private: No Submitted By: Wyrm Tools (wyrmtools) Assigned to: Wyrm Tools (wyrmtools) Summary: New Campaign wizard throws exception Initial Comment: The New Campaign wizard throws an exception immediately when it is invoked when no game system plugins are installed in the workspace. See the attached stack trace for additional details. It appears no check is being made for an empty game system array before updating the UI. Such a check should be added and an appropriate error message should be displayed in the title area of the wizard (similar to what is done when no open repositories are available). (This bug was submitted privately via e-mail by Steven Woolley <bobafett2040[at]gmail[dot]com>.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=724978&aid=1730450&group_id=132696 |
From: SourceForge.net <no...@so...> - 2007-06-04 01:48:27
|
Bugs item #1730449, was opened at 2007-06-03 21:48 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=724978&aid=1730449&group_id=132696 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: User Interface Group: Pre-Alpha Status: Open Resolution: None Priority: 5 Private: No Submitted By: Wyrm Tools (wyrmtools) Assigned to: Wyrm Tools (wyrmtools) Summary: New Source wizard throws exception Initial Comment: The New Source wizard throws an exception immediately when it is invoked when no game system plugins are installed in the workspace. See the attached stack trace for additional details. It appears no check is being made for an empty game system array before updating the UI. Such a check should be added and an appropriate error message should be displayed in the title area of the wizard (similar to what is done when no open repositories are available). (This bug was submitted privately via e-mail by Steven Woolley <bobafett2040[at]gmail[dot]com>.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=724978&aid=1730449&group_id=132696 |
From: SourceForge.net <no...@so...> - 2007-04-25 02:00:17
|
Bugs item #1707047, was opened at 2007-04-24 22:00 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=724978&aid=1707047&group_id=132696 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Persistence Group: Pre-Alpha Status: Open Resolution: None Priority: 5 Private: No Submitted By: Wyrm Tools (wyrmtools) Assigned to: Wyrm Tools (wyrmtools) Summary: Modified element scriptable properties not exported Initial Comment: When editing an element in a Wyrm Tools session, making a change to one of its scriptable properties, saving the change, and then exporting that element, all in the same session, the changes are not reflected in the exported data. If one stops and restarts Wyrm Tools after making the change and then exporting the data, the correct data is reflected in the export. [ENVIRONMENT] Wyrm Tools 0.10.0 Windows XP SP2 MySQL 4.1 [REPRO STEPS] 1) Create a new d20 spell element (and whatever supporting elements are required to do this). 2) Open the element in the spell editor. 3) Add a few spell level prerequisites. 4) Save the element and close the editor. 5) Export the repository containing the element. [EXPECTED BEHAVIOR] Examining the export data should reveal the same number of spell level prerequisites added in (3). [ACTUAL BEHAVIOR] The number of spell level prerequisites is always zero. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=724978&aid=1707047&group_id=132696 |
From: SourceForge.net <no...@so...> - 2007-04-15 01:08:20
|
Bugs item #1700841, was opened at 2007-04-14 21:08 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=724978&aid=1700841&group_id=132696 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Persistence Group: Pre-Alpha Status: Open Resolution: None Priority: 5 Private: No Submitted By: Wyrm Tools (wyrmtools) Assigned to: Wyrm Tools (wyrmtools) Summary: Import/export fails with large number of elements Initial Comment: Attempting to import and/or export a large number of elements fails with an exception. The exception stack trace is exteremely large with many nested exceptions. The root cause is a java.net.BindException when the persistence layer attempts to open a connection to the MySQL database. Examining the output of "netstat -a" during an export shows that there is a huge number of TCP sockets in the TIMED_WAIT state. Thus, it appears the persistence layer is opening new connections to the database faster than the open sockets time out and can be reclaimed by the OS. The JPOX persistence layer appears to be opening a new connection every time it needs to read from or write to the database. That is, there is no connection pool being used. Further research shows that JPOX does not support connection pooling out-of-the-box. It's obvious the lack of a connection pool is causing so many connections to be opened in a relatively short period of time, thus overwhelming the TCP/IP stack. JPOX does support various connection pool plugins, and it seems appropriate that to fix this bug, one of those plugins should be added to the Wyrm Tools platform and/or JPOX fragment distribution. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=724978&aid=1700841&group_id=132696 |
From: SourceForge.net <no...@so...> - 2007-03-20 03:17:23
|
Bugs item #1684073, was opened at 2007-03-19 23:17 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=724978&aid=1684073&group_id=132696 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: User Interface Group: Pre-Alpha Status: Open Resolution: None Priority: 5 Private: No Submitted By: Wyrm Tools (wyrmtools) Assigned to: Wyrm Tools (wyrmtools) Summary: Summary View font size too small with IE7 installed Initial Comment: After installing IE7 on Windows, the various information displayed in the Summary View is 33-50% smaller than when IE6 is installed. It looks like this problem is due to a difference between IE6 and IE7 how it interprets CSS relative font sizes (e.g. small, medium, large, etc.). All Summary View stylesheets need to modified to use explicit em-sizes rather than relative sizes to ensure consistency across all browsers. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=724978&aid=1684073&group_id=132696 |
From: SourceForge.net <no...@so...> - 2007-03-14 02:13:03
|
Bugs item #1680277, was opened at 2007-03-13 22:13 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=724978&aid=1680277&group_id=132696 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Printing Group: Pre-Alpha Status: Open Resolution: None Priority: 5 Private: No Submitted By: Wyrm Tools (wyrmtools) Assigned to: Wyrm Tools (wyrmtools) Summary: d20 character sheet not printed correctly in PCL format Initial Comment: The d20 character sheet prints fine for all formats except for PCL. It appears the cells that have a black background and a white foreground are not handled properly by PCL. These cells always appear as solid black rectangles -- the text is never present. This is most likely a problem with how the XSL-FO is transformed to PCL, but it's not clear why. Both PDF and AWT do not have this problem. Currently, the XSL-FO sets the backgroundcolor of the table-cell to black and the foreground color of the embedded blocks to white. I tried moving the background-color attribute from table to block, but it was still rendered the same. It would be helpful if someone with knowledge of PCL could examine the output to determine if this is a z-order problem. It might possibly be a bug in FOP. REPRO STEPS: 1. Open the editor for a previously created d20 character element. 2. Select the Print action. 3. Select the PCL character sheet template. 4. Print it. EXPECTED BEHAVIOR: The character sheet should be printed correctly. ACTUAL BEHAVIOR: The table cells with a black background have no text. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=724978&aid=1680277&group_id=132696 |
From: SourceForge.net <no...@so...> - 2007-02-12 02:53:10
|
Bugs item #1657670, was opened at 2007-02-11 21:53 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=724978&aid=1657670&group_id=132696 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Persistence Group: Pre-Alpha Status: Open Resolution: None Priority: 5 Private: No Submitted By: Wyrm Tools (wyrmtools) Assigned to: Wyrm Tools (wyrmtools) Summary: d20 JavaBeans persistence delegates log to the wrong plugin Initial Comment: The d20 JavaBeans persistence delegates are logging to the platform CorePlugin object rather than the d20 game system D20CorePlugin object. These must be changed in order to prevent misinformation in bug reports. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=724978&aid=1657670&group_id=132696 |
From: SourceForge.net <no...@so...> - 2006-11-28 03:40:56
|
Bugs item #1604221, was opened at 2006-11-27 22:40 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=724978&aid=1604221&group_id=132696 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Other Group: Pre-Alpha Status: Open Resolution: None Priority: 5 Private: No Submitted By: Wyrm Tools (wyrmtools) Assigned to: Wyrm Tools (wyrmtools) Summary: WTML export for d20 Speak Language skill fails Initial Comment: The WTML export operation for the d20 Speak Language skill fails with a NullPointerException. From the logs, it appears this is due to the fact that this skill has no key ability. The code that exports the skill's key ability does not check for a null reference. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=724978&aid=1604221&group_id=132696 |
From: SourceForge.net <no...@so...> - 2006-09-27 03:03:05
|
Bugs item #1566116, was opened at 2006-09-26 23:03 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=724978&aid=1566116&group_id=132696 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: User Interface Group: Pre-Alpha Status: Open Resolution: None Priority: 5 Submitted By: Wyrm Tools (wyrmtools) Assigned to: Wyrm Tools (wyrmtools) Summary: Exception thrown in New Character wizard Initial Comment: ENVIRONMENT: Wyrm Tools 0.5.0 Windows XP SP2 MySQL 4.1 REPRO STEPS: 1) Use a repository that has *no* campaigns. 2) Invoke the New wizard and select d20 Character; click Next. EXPECTED BEHAVIOR: The New Character wizard should start, but all the controls should be disabled and an error message should appear at the top saying there are no campaigns available. ACTUAL BEHAVIOR: An generic error dialog appears. The stack trace output to the error log is attached. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=724978&aid=1566116&group_id=132696 |
From: SourceForge.net <no...@so...> - 2006-08-20 02:24:31
|
Bugs item #1543309, was opened at 2006-08-19 22:24 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=724978&aid=1543309&group_id=132696 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Other Group: Pre-Alpha Status: Open Resolution: None Priority: 5 Submitted By: Wyrm Tools (wyrmtools) Assigned to: Wyrm Tools (wyrmtools) Summary: Incorrect available skill points for multi-class characters Initial Comment: When a multi-class character gains a level, the number of skill points gained at that level are being calculated incorrectly. The problem seems to be that ALL classes are contributing to the skill point contribution rather than only the class in which a level was just gained. REPRO STEPS: 1) Create a first-level character. 2) Advance the character to second-level in a new class (i.e. make them multi-class). EXPECTED BEHAVIOR: The number of available skill points should be equal to the number of points contributed by the second class at second level plus any racial modifier. ACTUAL BEHAVIOR: The number of available skill points is equal to the number of points contributed by the first class at second level plus the number of points contributed by the second class at second level plus any racial modifier. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=724978&aid=1543309&group_id=132696 |
From: SourceForge.net <no...@so...> - 2006-08-13 01:47:56
|
Bugs item #1539369, was opened at 2006-08-12 21:47 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=724978&aid=1539369&group_id=132696 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: User Interface Group: Pre-Alpha Status: Open Resolution: None Priority: 5 Submitted By: Wyrm Tools (wyrmtools) Assigned to: Wyrm Tools (wyrmtools) Summary: d20 racial male weight modifier field displays wrong value Initial Comment: In the d20 Race editor, on the Physical page, in the Height/Weight section, the male weight modifier field displays the wrong information. It always seems to display the same value as the female weight modifier regardless of what value is typed into the field. That is, after making a modification and moving to the next field, the field contents change to whatever is in the corresponding female field. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=724978&aid=1539369&group_id=132696 |
From: SourceForge.net <no...@so...> - 2006-08-04 03:33:25
|
Bugs item #1534282, was opened at 2006-08-03 23:33 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=724978&aid=1534282&group_id=132696 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: User Interface Group: Pre-Alpha Status: Open Resolution: None Priority: 5 Submitted By: Wyrm Tools (wyrmtools) Assigned to: Wyrm Tools (wyrmtools) Summary: Source copyright field does not wrap on initial load Initial Comment: If the source copyright field is set to a sufficiently long string, the corresponding field in the source editor does not wrap it to the window width. Rather, the panel expands to the width necessary to display the entire line, and horizontal scroll bars appear in the editor pane. For sample data, use the official d20 SRD copyright statement (three lines): Open Game License v 1.0a Copyright 2000, Wizards of the Coast, Inc. System Reference Document Copyright 2000-2003, Wizards of the Coast, Inc.; Authors Jonathan Tweet, Monte Cook, Skip Williams, Rich Baker, Andy Collins, David Noonan, Rich Redman, Bruce R. Cordell, John D. Rateliff, Thomas Reid, James Wyatt, based on original material by E. Gary Gygax and Dave Arneson. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=724978&aid=1534282&group_id=132696 |
From: SourceForge.net <no...@so...> - 2006-07-18 03:18:37
|
Feature Requests item #1524246, was opened at 2006-07-17 23:18 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=724981&aid=1524246&group_id=132696 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Other Group: Next Minor Release Status: Open Priority: 5 Submitted By: Wyrm Tools (wyrmtools) Assigned to: Wyrm Tools (wyrmtools) Summary: Complete import/export functionality Initial Comment: Due to Java Bug 6215865, the implementation of import/export was never completed. This Java bug is still open, thus a workaround must be found to complete the import/export functionality in the product. As part of this request, all platform and d20 model elements, where applicable, must be made fully exportable and importable. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=724981&aid=1524246&group_id=132696 |
From: SourceForge.net <no...@so...> - 2006-07-08 03:20:53
|
Feature Requests item #1519075, was opened at 2006-07-07 23:20 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=724981&aid=1519075&group_id=132696 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Other Group: Next Major Release Status: Open Priority: 5 Submitted By: Wyrm Tools (wyrmtools) Assigned to: Wyrm Tools (wyrmtools) Summary: Dynamically remove model elements as plugins are stopped Initial Comment: At some point, Wyrm Tools is going to support dynamically stopping plugins while the application is running rather than only stopping them when it is shutdown. BUG 1519066 documented a problem in which the d20 core plugin was stopped, but the model still contained references to d20 model elements, causing ClassNotFoundExceptions to be thrown. The fix implemented was simply to close the model when the d20 core plugin was stopped. We need to support a more robust method that can handle arbitrary plugins being stopped at any time. I can think of two possible designs at this time: 1) Add a new method to IModel that closes any openable elements which contains elements defined by the plugin being stopped. Maybe something like: public void close( ClassLoader cl ); It would have to iterate through all the registered elements in the model looking for ones whose ClassLoader matches the specified one (presumed to be the stopping plugin's ClassLoader). Thus, every plugin which contributes classes to the model must call this method in their stop() method. 2) Have the model implementation listen for plugins being stopped and do the same thing as in (1). This has the added benefit of not requiring plugin authors to worry about cleaning up after themselves. At this point, I'm not sure if we can intercept a notification that says a plugin is about to be stopped rather than receiving the notification after the fact. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=724981&aid=1519075&group_id=132696 |
From: SourceForge.net <no...@so...> - 2006-07-08 02:49:52
|
Bugs item #1519066, was opened at 2006-07-07 22:49 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=724978&aid=1519066&group_id=132696 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Persistence Group: Pre-Alpha Status: Open Resolution: None Priority: 5 Submitted By: Wyrm Tools (wyrmtools) Assigned to: Wyrm Tools (wyrmtools) Summary: Model throws exception when closed during shutdown Initial Comment: The Wyrm Tools model is explicitly closed when the org.wyrmtools.core plugin is stopped. During this operation, the JPOX persistence layer throws a ClassNotResolvedException because it cannot find (in this specific case) the org.wyrmtools.internal.systems.d20.core.model.Abilitie s class. The reason the class cannot be found is because the org.wyrmtools.systems.d20.core plugin has already been stopped due to how Eclipse shuts down plugins based on their dependencies. In this case, org.wyrmtools.systems.d20.core depends on org.wyrmtools.core, so it is shutdown first. This has the side effect of leaving elements in the model whose classes can no longer be resolved. We need to support some kind of layered close mechanism for the model whereby contributing plugins ensure their elements are removed as they are stopped. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=724978&aid=1519066&group_id=132696 |
From: SourceForge.net <no...@so...> - 2006-07-04 00:53:31
|
Bugs item #1516694, was opened at 2006-07-03 20:53 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=724978&aid=1516694&group_id=132696 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: User Interface Group: Pre-Alpha Status: Open Resolution: None Priority: 5 Submitted By: Wyrm Tools (wyrmtools) Assigned to: Wyrm Tools (wyrmtools) Summary: Improper alert reporting for insufficient skill/feat points Initial Comment: If a user attempts to add ranks to a skill/feat within the d20 character editor, but they have an insufficient number of points remaining, an alert is reported to the user. Unfortunately, there are several bugs: 1) The user does not see the alert unless they go to the Overview page (although they do see a red 'X' on the Skills/Feats tab). 2) There is no way to clear the alert short of closing the editor and re-opening it. REPRO STEPS: 1. Create a new d20 character and open it in the d20 character editor. 2. Add a new level to the character. 3. Go to the Skills page and allocate all available skill points. 4. Attempt to add a new skill rank when zero skill points remain. EXPECTED BEHAVIOR: Some sort of alert should immediately be visible to the user warning them that no skill points remain. The alert should be dismisable and not persist. ACTUAL BEHAVIOR: A red 'X' appears on the Skill tab. The alert text appears in the 'Alerts' list on the Overview page. There is no way to clear the alert. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=724978&aid=1516694&group_id=132696 |
From: SourceForge.net <no...@so...> - 2006-07-03 00:24:14
|
Bugs item #1516062, was opened at 2006-07-02 20:24 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=724978&aid=1516062&group_id=132696 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: User Interface Group: Pre-Alpha Status: Open Resolution: None Priority: 5 Submitted By: Wyrm Tools (wyrmtools) Assigned to: Wyrm Tools (wyrmtools) Summary: Cannot cancel Add Level wizard for first-level character Initial Comment: Attempting to cancel out of the Add Level wizard when adding a character's first level fails with an ArrayIndexOutOfBoundsException. REPRO STEPS: 1) Open the editor for any zero-level character. 2) Add a new level by double-clicking any available class on the Class page of the editor; this brings up the Add Level wizard. 3) Click Next to advance past the first page. 4) Click Cancel on the Hit Points (the second) page. EXPECTED BEHAVIOR: The wizard should be dismissed with no effect on the original character. ACTUAL BEHAVIOR: An ArrayIndexOutOfBoundsException is thrown (see attached) and an error dialog pops up to display the exception. Dismissing the dialog brings one back to the wizard. The only way to dismiss the wizard is to click Finish. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=724978&aid=1516062&group_id=132696 |
From: SourceForge.net <no...@so...> - 2006-06-18 03:33:25
|
Bugs item #1507978, was opened at 2006-06-17 23:33 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=724978&aid=1507978&group_id=132696 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Other Group: Pre-Alpha Status: Open Resolution: None Priority: 5 Submitted By: Wyrm Tools (wyrmtools) Assigned to: Wyrm Tools (wyrmtools) Summary: Invoking IScriptEngine.getAdapter() returns null Initial Comment: While updating some DiceScript unit tests, I attempted to get an instance of the DiceScript engine as follows: final IDiceScriptEngine engine = (IDiceScriptEngine)CorePlugin.getDefault() .getPlatform().getScriptEngineManager() .getScriptEngine( IDiceScriptEngine.PREFIX ) .getAdapter( IDiceScriptEngine.class ); This expression is returning null. Some debugging revealed that the result of getScriptEngine() is a ScriptEngineProxy instance. It seems that the proxy's getAdapter() method is not correctly processing the request to cast to an IDiceScriptEngine and returns null. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=724978&aid=1507978&group_id=132696 |
From: SourceForge.net <no...@so...> - 2006-05-27 02:58:51
|
Bugs item #1495839, was opened at 2006-05-26 22:58 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=724978&aid=1495839&group_id=132696 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Other Group: Pre-Alpha Status: Open Resolution: None Priority: 5 Submitted By: Wyrm Tools (wyrmtools) Assigned to: Wyrm Tools (wyrmtools) Summary: Per-level hit point adjustment not calculated correctly Initial Comment: The d20 SRD specifies that per-level hit point adjustments (e.g. the Constitution modifier) are to be evaluated dynamically. That is, if a character's CON modifier was +1 when they advanced from level 2 to level 3, and +2 when they advanced from level 3 to level 4, the hit point adjustment due to this modifier is retroactive to previous levels. The current implementation evaluates this adjustment at the time the character attains a new level, but never updates it. The CharacterLevel object must be modified to subscribe to the character's HP adjustment topic and re-evaluate the total adjustment appropriately. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=724978&aid=1495839&group_id=132696 |