Introduction

Progress reports and musings from the developers on the current gaming tools.

Moderators: dorpond, trevor, Azhrei

username
Dragon
Posts: 277
Joined: Sun Sep 04, 2011 7:01 am

Re: Introduction

Post by username »

JavaFX 2 is not available for linux until late 2012. For JavaFX 1.3 I need to have an Oracle account, before I can download. If I have to do all this, I wonder whether we can ship the runtime without many users being forced through that hassle.

User avatar
jfrazierjr
Deity
Posts: 5176
Joined: Tue Sep 11, 2007 7:31 pm

Re: Introduction

Post by jfrazierjr »

username wrote:JavaFX 2 is not available for linux until late 2012. For JavaFX 1.3 I need to have an Oracle account, before I can download. If I have to do all this, I wonder whether we can ship the runtime without many users being forced through that hassle.
I "seem" to think that I recall seeing somewhere that the plan is to actually include JavaFX as part of core java when it is available... so for example, Java 7 Update 10 would bundle JavaFX as part of it's installation package. OR perhaps is was that JavaFX would be part of Java 8's release....I don't know...
I save all my Campaign Files to DropBox. Not only can I access a campaign file from pretty much any OS that will run Maptool(Win,OSX, linux), but each file is versioned, so if something goes crazy wild, I can always roll back to a previous version of the same file.

Get your Dropbox 2GB via my referral link, and as a bonus, I get an extra 250 MB of space. Even if you don't don't use my link, I still enthusiastically recommend Dropbox..

User avatar
Azhrei
Site Admin
Posts: 12086
Joined: Mon Jun 12, 2006 1:20 pm
Location: Tampa, FL

Re: Introduction

Post by Azhrei »

You're correct, Joe. I remember reading that as well.

JavaFX would be part of the expanded runtime, sort of like how the JavaScript interpreter is a separate download but is part of the Java 6 specification. (I think I got that right. if not, someone will correct me. ;))

And it's a bummer that JavaFX won't be available for Linux right away, but to be honest I'm not sure how much JavaFX will be used early on. We likely won't use it at all in the early stages as we'll be busy working on more pressing issues (like getting a persistence layer that works). And it will be part of the OpenJDK in any case, and I really need to get MT's problems with the OpenJDK worked out because that's the only way to get Java 7 on OSX right now (my main development platform).

User avatar
jfrazierjr
Deity
Posts: 5176
Joined: Tue Sep 11, 2007 7:31 pm

Re: Introduction

Post by jfrazierjr »

Azhrei wrote:You're correct, Joe. I remember reading that as well.

JavaFX would be part of the expanded runtime, sort of like how the JavaScript interpreter is a separate download but is part of the Java 6 specification. (I think I got that right. if not, someone will correct me. ;))

And it's a bummer that JavaFX won't be available for Linux right away, but to be honest I'm not sure how much JavaFX will be used early on. We likely won't use it at all in the early stages as we'll be busy working on more pressing issues (like getting a persistence layer that works). And it will be part of the OpenJDK in any case, and I really need to get MT's problems with the OpenJDK worked out because that's the only way to get Java 7 on OSX right now (my main development platform).
Depending on WHEN we start working on 1.4, I highly doubt JavaFX will ever be part of that branch at all. While I have no official say in the matter, if I had my way, 1.4 would be quite small and focused on code re-write for the "back office" (ie, overhaul the GUI in a few key "targeted" places, but mainly leave it alone). IMHO, that would include(in this order):
  • convert to run under OSGi
  • javascript macro support(of course, that does NOT mean dom level editing since that would require a "real" browser which is dependent on JavaFX or some other future technology)
  • Vision/Lighting overhaul
I know there are more things on the list, but personally, I would much rather focus on a much smaller list of items(ie, once "these"(for whatever definition of "these" we choose) items are completed, we will release 1.4) and if someone NOT on the main Dev team happens to add full feature support for somethings else prior to those items being completed AND it happens to be stable and conforms to the direction we want to go then it gets into the code.

My belief mirrors Dorpond's to a large degree that we need to build momentum, and IMHO the best way to do that is to have small short focused dev cycles that add a small number of features and then call that release done. Though multiple layers is part of the initial plan, I personally feel like that is a fairly large project and should not be attempted in 1.4, again owing to wanting momentum to build....

As for GUI overhaul, my rough guess is that it will be mid-late 2012 (and in a/my perfect world we would be PAST 1.4 and even past 1.5!!!)
I save all my Campaign Files to DropBox. Not only can I access a campaign file from pretty much any OS that will run Maptool(Win,OSX, linux), but each file is versioned, so if something goes crazy wild, I can always roll back to a previous version of the same file.

Get your Dropbox 2GB via my referral link, and as a bonus, I get an extra 250 MB of space. Even if you don't don't use my link, I still enthusiastically recommend Dropbox..

User avatar
Azhrei
Site Admin
Posts: 12086
Joined: Mon Jun 12, 2006 1:20 pm
Location: Tampa, FL

Re: Introduction

Post by Azhrei »

Yes, Craig and I were thinking along the same lines... We'll use 1.4 to implement OSGi and fix anything that must be fixed to work within the OSGi framework, but the GUI stuff and new features will wait for 2.0. Very few user visible changes in 1.4 most likely (although there are a couple I can think of right away).

username wanted a list of outstanding bugs. He was thinking of potentially working on them while waiting for 1.4 to get underway. So here they are, in no particular order (I'm leaving out the two that are on my list):
  1. Any chance the Export Screenshot IF statement can be fixed? http://forums.rptools.net/viewtopic.php ... ad#p209076
  2. Setting just width or height doesn't cause the other to be scaled so that the aspect ratio is maintained? http://forums.rptools.net/viewtopic.php ... 36#p211836
  3. TEA’s and GEA’s should be viewed as GEA’s when starting a server with IF=OFF. How much work would be involved in this?
  4. Set the StartServer IF checkbox based on whether the currently loaded maps have TEA; or if the maps contain no TEA, leave the IF checkbox at its default value
  5. Perhaps turning fog on/off on a map that has TEA should offer to clear TEA for all tokens? Maybe no prompt if the entries in the TEA for the map refer to tokens that no longer exist anywhere in the campaign?
  6. When loading a campaign with a server already running, warn the user if any maps contain TEA (provide map names?). Easiest UI would just be a listbox probably...
  7. Saving a macroset over the top of a campaign leaves assets in-place in the file http://forums.rptools.net/viewtopic.php ... 95#p210294
  8. Loading campaign doesn't draw the screen correctly on the first refresh of the map
  9. Moving seems to clear fog for all players, while Meta-I only clears for the selected token(s); need verification, then fix
  10. Add build.xml target for clearing the version.txt to get back to DEVELOPMENT
  11. Add startup check that grabs notes from rptools.net for display to user (used for things like version notes, update notes, serious bugs found after release, and so on). This isn't a bug fix but could be very important if 1.3 is going to be the only stable build for many months.
  12. Feedback on SVN 5769 (latest as of 7/3) http://forums.rptools.net/viewtopic.php?f=60&t=19195
  13. Right-click menu on tokens sometimes is above or under the statsheet (If statsheet is being displayed, map rendering should be clipped out of that area, or the glasspane should be used for the statsheet (where is JPopupMenu put?), or use a JLayeredPane and put the statsheet on top)
  14. When I draw VBL with the Poly Line tool and try to start a new line where the last line ended, it won’t work. I have to literally draw the line somewhere else and then go back to that point or use <Escape> to cancel the drawing and start again.
  15. Using the "#" in campaign properties should imply the "*", but without the "*" actually showing up in the list

username
Dragon
Posts: 277
Joined: Sun Sep 04, 2011 7:01 am

Re: Introduction

Post by username »

The list is growing instead of decreasing, just like any bug report list will. I assume they are sorted by priority, even though you stated differently. With an unordered list, we will never have chance to reach the "break even"; when to start 1.4. (That's what I believe.) I started with #1. (Post in other thread.)

BTW: isn't #8 the bug for which I posted a fix here? Is it still present? (Or is it in the list because it's slated only for b88, which hasn't been through testing?)

User avatar
Azhrei
Site Admin
Posts: 12086
Joined: Mon Jun 12, 2006 1:20 pm
Location: Tampa, FL

Re: Introduction

Post by Azhrei »

username wrote:The list is growing instead of decreasing, just like any bug report list will. I assume they are sorted by priority, even though you stated differently.
They are not sorted by priority.
BTW: isn't #8 the bug for which I posted a fix here? Is it still present? (Or is it in the list because it's slated only for b88, which hasn't been through testing?)
Yes, you posted a fix. But I seem to recall some feedback that said it wasn't 100%. Was that wrong?

READERS: Has anyone had a problem with the initial campaign load occurring with some of the graphics not be drawn correctly on the initial view?

User avatar
CoveredInFish
Demigod
Posts: 3104
Joined: Mon Jun 29, 2009 10:37 am
Location: Germany
Contact:

Re: Introduction

Post by CoveredInFish »

Azhrei wrote: READERS: Has anyone had a problem with the initial campaign load occurring with some of the graphics not be drawn correctly on the initial view?
Yes. At least one of my campaign file still has this error. The behaviour has changed after the patch but wasnt gone completly.

(If you need it: http://dl.dropbox.com/u/1821838/deadlan ... _b80.cmpgn)

User avatar
Azhrei
Site Admin
Posts: 12086
Joined: Mon Jun 12, 2006 1:20 pm
Location: Tampa, FL

Re: Introduction

Post by Azhrei »

Thanks. I grabbed your campaign file for testing purposes.

username
Dragon
Posts: 277
Joined: Sun Sep 04, 2011 7:01 am

Re: Introduction

Post by username »

I cannot reproduce this with my still patched b86 version and the campaign file supplied for download. Azhrei, did you merge my 2nd patch? My 1st patch indeed only solved part of the problem, while the 3rd is for an unrelated issue. (They are all on page 2. Do posts have an id? It would be nice to be able to refer to them.)

username
Dragon
Posts: 277
Joined: Sun Sep 04, 2011 7:01 am

Re: Introduction

Post by username »

Azhrei wrote:
username wrote:The list is growing instead of decreasing, just like any bug report list will. I assume they are sorted by priority, even though you stated differently.
They are not sorted by priority.
That would be nice though. I saw you coming in on #1 as well. The discussion has drifted somewhat there and does not look to be a priority issue once the NPE was gone?

User avatar
Azhrei
Site Admin
Posts: 12086
Joined: Mon Jun 12, 2006 1:20 pm
Location: Tampa, FL

Re: Introduction

Post by Azhrei »

username wrote:Azhrei, did you merge my 2nd patch? My 1st patch indeed only solved part of the problem, while the 3rd is for an unrelated issue. (They are all on page 2. Do posts have an id? It would be nice to be able to refer to them.)
Heh, probably not. Looking back I see that you named all three of them patch.txt! In the future it would be good to use unique names, and preferably something indicative of what the patch is fixing. For example, concurrency patch 1.txt and concurrency patch 2.txt.

Okay, I looked at the second patch as well. It adds a lot of synchronization to methods in the ZoneRenderer which seems like the wrong approach; we really should determine what the problem is and fix it, not put bandages all over the place. :|

So I added some debugging code and found that the only place that was called from a thread other than the EDT was the Zone.flush(Token) method. So I added a synchronized block around that one statement and cleared the tokenLocationCache in renderTokens() and that seems to have fixed the problem. I believe the real issue was the structure not being cleared, but I don't understand how that could happen. Somehow that structure was being filled with data prior to the first repaint() event being processed, but since renderTokens() isn't called except as part of a repaint, how can that occur? In any case, I ended up using the core part of your patch. Thanks! :D

Testers: please update to SVN 5835 and try this out. @CiF: MT now loads that test campaign from b80 that you linked to.

User avatar
CoveredInFish
Demigod
Posts: 3104
Joined: Mon Jun 29, 2009 10:37 am
Location: Germany
Contact:

Re: Introduction

Post by CoveredInFish »

Azhrei wrote:Testers: please update to SVN 5835 and try this out. @CiF: MT now loads that test campaign from b80 that you linked to.
Awesome. I found no campaign file of mine that would produce the bug anymore.

User avatar
Azhrei
Site Admin
Posts: 12086
Joined: Mon Jun 12, 2006 1:20 pm
Location: Tampa, FL

Re: Introduction

Post by Azhrei »

CoveredInFish wrote:Awesome. I found no campaign file of mine that would produce the bug anymore.
Excellent. Credit goes to username for locating the trashed tokenLocationCache variable. :D

username
Dragon
Posts: 277
Joined: Sun Sep 04, 2011 7:01 am

Re: Introduction

Post by username »

Azhrei wrote:In the future it would be good to use unique names, and preferably something indicative of what the patch is fixing. For example, concurrency patch 1.txt and concurrency patch 2.txt.
I'll try to keep that in mind. Still it would be nice, if the forum software had Ids to posts.
Azhrei wrote:Okay, I looked at the second patch as well. It adds a lot of synchronization to methods in the ZoneRenderer which seems like the wrong approach; we really should determine what the problem is and fix it, not put bandages all over the place. :|
As you state further down, the root cause is still not known. You just applied less bandages. It boils down to a matter of taste.
Azhrei wrote:I believe the real issue was the structure not being cleared, but I don't understand how that could happen. Somehow that structure was being filled with data prior to the first repaint() event being processed, but since renderTokens() isn't called except as part of a repaint, how can that occur? In any case, I ended up using the core part of your patch. Thanks! :D
The cache is used a lot. (That's why I had synchronized all access to it.) I tried to keep the cache more private by removing external access except by the EDT methods. It felt like I had half of the Maptool ripped apart, whence I aborted that idea.

Post Reply

Return to “Developer Notes”