wyrmtools-developers Mailing List for Wyrm Tools (Page 2)
A suite of tools for any RPG system
Status: Pre-Alpha
Brought to you by:
wyrmtools
Menu
▾
▴
wyrmtools-developers — Developer discussion list
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...> - 2006-04-30 01:36:20
|
Bugs item #1479141, was opened at 2006-04-29 21: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=1479141&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 update source campaign setting in editor Initial Comment: Changing a source's campaign setting in the editor and saving does not commit the change to the database. ENVIRONMENT: Wyrm Tools 0.2.0 Windows XP SP2 JPOX 1.1.0 RC1 MySQL 4.1 REPRO STEPS: 1) Create two campaign settings and a source. 2) Open the source in the source editor. 3) Select the campaign setting that is not currently selected. 4) Save the source. EXPECTED BEHAVIOR: The newly-selected campaign setting should remain selected as it is now the source's campaign setting. ACTUAL BEHAVIOR: The selection reverts to the original campaign setting. Examining the database indeeds shows no change was committed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=724978&aid=1479141&group_id=132696 |
|
From: SourceForge.net <no...@so...> - 2006-04-28 04:04:12
|
Bugs item #1478151, was opened at 2006-04-28 00:04 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=1478151&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 open d20 character editor Initial Comment: The d20 character editor fails to open. See the attached stack trace for the exact error. A quick examination makes it clear the problem is most likely the JDO fetch depth is not set properly. Since we spent most of our time in this release working on the generic element editor framework, we never bothered to update the d20 character editor. The fix for this problem should address the d20 character editor directly. We will port this editor to the generic element editor framework in the next release. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=724978&aid=1478151&group_id=132696 |
|
From: SourceForge.net <no...@so...> - 2006-04-28 03:40:50
|
Bugs item #1478148, was opened at 2006-04-27 23: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=1478148&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: Plugin classes not getting exported Initial Comment: The ExactAlignmentPrereqScriptCompiler.ExactAlignmentPrere qCompiledScript class does not seem to get exported when bundled in the plugin JAR file. It almost seems like the file name (ExactAlignmentPrereqScriptCompiler$ExactAlignmentPrer eqCompiledScript.class) is too long or something because other nested classes in this package are properly exported. Not sure if this is an Eclipse export problem or a ZIP file format constraint. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=724978&aid=1478148&group_id=132696 |
|
From: SourceForge.net <no...@so...> - 2006-04-28 02:16:42
|
Bugs item #1478125, was opened at 2006-04-27 22:16 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=1478125&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: testRemoveScript test case is failing Initial Comment: The AbstractScriptableElementTestCase.testRemoveScript test is failing for all unit tests that extend this test case. The stack trace from a representative failure is attached. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=724978&aid=1478125&group_id=132696 |
|
From: SourceForge.net <no...@so...> - 2006-04-23 02:49:24
|
Feature Requests item #1474868, was opened at 2006-04-22 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=724981&aid=1474868&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: Code Quality (Refactoring) Group: Next Minor Release Status: Open Priority: 5 Submitted By: Wyrm Tools (wyrmtools) Assigned to: Wyrm Tools (wyrmtools) Summary: Require transactional reads on all model elements Initial Comment: The platform currently forces the JDO PMF option "javax.jdo.option.NontransactionalRead" to "true" in an effort to (prematurely) optimize the domain model. This behavior has been the root cause of some hard-to-diagnose bugs (e.g. BUG 1472714). It also causes some out-of-sync data problems because the code does not force instances to refresh themselves from the datastore when necessary. This has been observed when editing an element (in an editor), committing the changes, and then viewing the property pages for the same element -- the property pages incorrectly see the pre-edit state. It would be better for us to enforce transactional read behavior by default and require developers to enable nontransactional reads when they feel it is necessary. Therefore, this feature will require that all platform and d20 model elements be modified to handle transactional reads. This will require two major tasks. 1) All element accessors must now throw ModelException. This will change several interfaces. 2) All element accessor implementations will now have to wrap the access in a transaction similar to what mutators must do. It is recommended that a framework be developed to make this easier on developers, similar to what was done with the Element.IPropertyMutator interface and its corresponding implementation classes. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=724981&aid=1474868&group_id=132696 |
|
From: SourceForge.net <no...@so...> - 2006-04-23 02:04:47
|
Bugs item #1474848, was opened at 2006-04-22 22:04 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=1474848&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: 1 Submitted By: Wyrm Tools (wyrmtools) Assigned to: Wyrm Tools (wyrmtools) Summary: JPOX persistence-by-reachability at commit fails Initial Comment: The JPOX JDO implementation, by default, runs its persistence-by-reachability algorithm at commit time. In order to workaround a problem in BUG 1472714, this feature was turned off. This bug report is being written up in the hope that in the future someone may actually figure out what the root cause of the problem is. In summary, the JPOX persistence-by-reachability algorithm, when run at commit time, will mistakenly think a newly persisted instance is no longer reachable. See the detailed comments below. ENVIRONMENT: Windows XP SP2 JPOX 1.1.0 RC1 MySQL 4.1 REPRO STEPS: 1) Create a new d20 race element (do whatever is necessary to get the application in an appropriate state to do this). 2) Open the race in the race editor. 3) Go to the Abilities page. 4) Set the Strength ability adjustment to "+3". 5) Save the race. 6) Set the Strength ability adjustment to "-3" (or anything other than "0"). 7) Save the race. EXPECTED BEHAVIOR: The race should be saved with no errors. ACTUAL BEHAVIOR: An exception is thrown indicating a constraint violation. The constraint violation is due to JPOX attempting to delete the new PersistentScript because its persistence-by-reachability algorithm thinks the new object is no longer reachable even though it has already been persisted. See the logs attached to BUG 1472714 for additional information. I hate to bring up the term "race condition". However, after stepping through the JPOX code with the debugger, I could not get this problem to occur. If I stepped over the transaction commit() statement in the element editor, it would happen. This is weird because I don't think there are any other threads accessing JPOX to cause a race condition in the first place. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=724978&aid=1474848&group_id=132696 |
|
From: SourceForge.net <no...@so...> - 2006-04-19 03:11:50
|
Bugs item #1472716, was opened at 2006-04-18 23:11 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=1472716&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: 3 Submitted By: Wyrm Tools (wyrmtools) Assigned to: Wyrm Tools (wyrmtools) Summary: Slush bucket widget not displayed properly in Eclipse forms Initial Comment: The slush bucket widget is not displayed properly when used in an Eclipse-forms-based editor (e.g. the Skills page of the d20 class editor). It does not inherit the properties of the form and so appears different than the other controls on the form. The widget should be modified to optionally accept a FormToolkit so it can apply the form's properties to its composite members during construction. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=724978&aid=1472716&group_id=132696 |
|
From: SourceForge.net <no...@so...> - 2006-04-19 03:04:57
|
Bugs item #1472714, was opened at 2006-04-18 23:04 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=1472714&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: 9 Submitted By: Wyrm Tools (wyrmtools) Assigned to: Wyrm Tools (wyrmtools) Summary: Editing scriptable properties fails at reattach commit Initial Comment: Editing a scriptable property in a certain manner using an element editor fails when the element is reattached and committed. The specific condition that must be true is that, at commit time, a new script must have been added and an existing script with the same topic ID must already exist in the element's script list. When this is true, the persistence layer fails due to a constraint violation (see the attached log) and the entire transaction is rolled back. A quick debugging session made it appear that JPOX was not correctly merging the new script with the persistent (attached) element. Thus, the persistence-by-reachability algorithm thinks the new script is not reachable. Because it was previously passed to makePersistent(), JPOX tries to remove it from the datastore. This results in a constraint violation because only the script is removed, not its parent row in the element's script list join table. The repro steps provided below are for one specific case. It was verified that editing other scriptable properties in completely different element types exhibited the same failure. ENVIRONMENT: Windows XP SP2 JPOX 1.1.0 RC1 MySQL 4.1 REPRO STEPS: 1) Create a new d20 race element (do whatever is necessary to get the application in an appropriate state to do this). 2) Open the race in the race editor. 3) Go to the Abilities page. 4) Set the Strength ability adjustment to "+3". 5) Save the race. 6) Set the Strength ability adjustment to "-3" (or anything other than "0"). 7) Save the race. EXPECTED BEHAVIOR: The race should be saved with no errors. ACTUAL BEHAVIOR: An exception is thrown indicating a constraint violation (see attached log). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=724978&aid=1472714&group_id=132696 |
|
From: SourceForge.net <no...@so...> - 2006-04-05 03:18:25
|
Bugs item #1464651, was opened at 2006-04-04 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=724978&aid=1464651&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: UiUtils.removeIf predicate test is reversed Initial Comment: The predicate test in org.wyrmtools.internal.ui.util.UiUtils.removeIf is reversed. It should be if( !predicate.evaluate( ... ) ) Correcting this bug will require reversing all IUnaryPredicate implementations that exist in the project. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=724978&aid=1464651&group_id=132696 |
|
From: SourceForge.net <no...@so...> - 2006-03-29 05:01:53
|
Feature Requests item #1460427, was opened at 2006-03-29 00:01 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=1460427&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: Code Quality (Refactoring) Group: Next Minor Release Status: Open Priority: 5 Submitted By: Wyrm Tools (wyrmtools) Assigned to: Wyrm Tools (wyrmtools) Summary: Migrate platform element property sheets to editors Initial Comment: Platform model elements do not currently support being detached from the datastore. This prevents proper transactional behavior when their properties are being edited. This support must be added. Additionally, property sheets are not the proper medium for editing elements, as the concept of applying changes to properties on a specific page is incompatible with the JDO attach/detach facility. Therefore, all element properties should be modified via an editor rather than via a property sheet. Property sheets will be reserved for editing/viewing element meta data. This FREQ only applies to platform model elements. A separate FREQ will be submitted for the d20 model elements. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=724981&aid=1460427&group_id=132696 |
|
From: SourceForge.net <no...@so...> - 2006-03-27 04:21:12
|
Feature Requests item #1459056, was opened at 2006-03-26 23:21 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=1459056&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: Code Quality (Refactoring) Group: Next Minor Release Status: Open Priority: 5 Submitted By: Wyrm Tools (wyrmtools) Assigned to: Wyrm Tools (wyrmtools) Summary: Embed string bundles in platform model elements Initial Comment: Platform model elements currently have a link relationship with their associated string bundle, if applicable. The detachment feature of JDO does not support this type of relationship. Because we plan on moving all element property sheets to editors, full detachment support is required. Each localizable platform model element should have a new field added of type StringBundle. All legacy StringBundle manipulation code should be removed. This FREQ only applies to platform model elements. A separate FREQ will be submitted for the d20 model elements. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=724981&aid=1459056&group_id=132696 |
|
From: SourceForge.net <no...@so...> - 2006-03-27 02:50:39
|
Feature Requests item #1459025, was opened at 2006-03-26 21:50 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=1459025&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: Code Quality (Refactoring) Group: Next Minor Release Status: Open Priority: 5 Submitted By: Wyrm Tools (wyrmtools) Assigned to: Wyrm Tools (wyrmtools) Summary: Upgrade to JPOX 1.1.0 RC1 Initial Comment: The JDO 2.0 specification has been finalized and fully implemented in JPOX 1.1.0 RC1. We need to upgrade to this release so we can begin correcting code that does not correspond exactly to the final JDO 2.0 specification. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=724981&aid=1459025&group_id=132696 |
|
From: SourceForge.net <no...@so...> - 2006-03-25 15:06:22
|
Bugs item #1458304, was opened at 2006-03-25 10:06 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=1458304&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: Delete action key binding does not work Initial Comment: The key binding for the Delete action in the Model Explorer does not work. The only way to execute this action is via the context menu. I believe this is a regression introduced with the new Wyrm Tools workbench application deployed for 0.1.0. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=724978&aid=1458304&group_id=132696 |
|
From: SourceForge.net <no...@so...> - 2006-03-15 03:16:13
|
Feature Requests item #1450097, was opened at 2006-03-14 22:16 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=1450097&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: Code Quality (Refactoring) Group: Next Minor Release Status: Open Priority: 5 Submitted By: Wyrm Tools (wyrmtools) Assigned to: Wyrm Tools (wyrmtools) Summary: Use org.eclipse.osgi.util.NLS for package message bundles Initial Comment: We currently use our custom org.wyrmtools.internal.util.MessagesUtil class for all package message bundles. Eclipse 3.1 introduced the org.eclipse.osgi.util.NLS class to do the same thing. Refactor existing package message bundles to use the new class to avoid redundancy. Remove the org.wyrmtools.internal.util.MessagesUtil class. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=724981&aid=1450097&group_id=132696 |
|
From: SourceForge.net <no...@so...> - 2006-03-14 03:51:22
|
Bugs item #1449338, was opened at 2006-03-13 22: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=1449338&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: Workbench window state is not persistent Initial Comment: The workbench window state is not saved when the application exits. The workbench is reset to use the default perspective layout everytime it starts. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=724978&aid=1449338&group_id=132696 |
|
From: Rusty S. <wyr...@ya...> - 2006-01-28 02:59:07
|
Welcome to the Wyrm Tools developer discussion list. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com |
