I think it is time to have a discussion about 3.2 development. Most of us have stated at different times that such and such a feature should be included in 3.2.
I’d like us to layout a firm plan of what we will be including in 3.2 and give ourselves a reasonable timeline to try and follow and get it done and get 3.2 out in a timely fashion.
Can we set a date (is 30 June too early) as a cutoff for new features?
What are our priority features to include?
For me they are:
Tango Icon support
Named KeyStrokes
Counter autoloader
Improved Game updater
Calculated Properties and in-line Java expressions (Stage 1 Beanshell)
This is all stuff for developers, but 3.1 was all about the user experience, so I have a baklog of developer improvements ready to go.
–
Michael Kiefte, Ph.D.
Associate Professor
School of Human Communication Disorders
Dalhousie University
Halifax, Nova Scotia, Canada
tel: +1 902 494 5150
fax: +1 902 494 5151
I think it is time to have a discussion about 3.2 development. Most of us have stated at different times that such and such a feature should be included in 3.2.
I’d like us to layout a firm plan of what we will be including in 3.2 and give ourselves a reasonable timeline to try and follow and get it done and get 3.2 out in a timely fashion.
Can we set a date (is 30 June too early) as a cutoff for new features?
What are our priority features to include?
For me they are:
Tango Icon support
Named KeyStrokes
Counter autoloader
Improved Game updater
Calculated Properties and in-line Java expressions (Stage 1 Beanshell)
This is all stuff for developers, but 3.1 was all about the user experience, so I have a baklog of developer improvements ready to go.
–
Michael Kiefte, Ph.D.
Associate Professor
School of Human Communication Disorders
Dalhousie University
Halifax, Nova Scotia, Canada
tel: +1 902 494 5150
fax: +1 902 494 5151
I am finding that I have a number of projects ‘mostly’ finished, but cannot get back to them to polish them up for final inclusion. I keep getting sidetracked by other priorities. Would you be interested in taking over a couple of the RFE’s I have started?
The Counter autoloader is one that is very nearly done, it just needs a bit of spit and polish to ensure it is easy to use.
The other obvious one is Terrain Properties - it is one that I just never get around to. It’s probably 80% complete and what is there works well. Would you be interested in taking it over?
I had a very simple idea of a lookup table with terrain properties were input as cells in a spreadsheet with location name as the key. But I seem to recall you had a fancy GUI. Before I say whether I’d take it over, what do you have left to complete?
The current source is in the SVN repository under VSQL in the terrain project.
You activate it in a module by importing two classes:
Into your module, import terrain.TerrainDefinitions. Use this to define the different types of terrain.
Into a board, delete the existing HexGrid and import terrain.TerrainHexGrid.
Edit the new HexGrid and click the ‘Edit Grid’ button to open the Terrain Grid editor.
Working: Hex Terrain (e.g. swamp/sea/hills/impassible), Edge Terrain (e.g. cliff, river), Tag Terrain (Essentially Properties that can be hung off terrain)
Not Working: Line Terrain (e.g. roads, railway). The editor does not work (However, check the VSQL-Dominik project which has fixes and extensions).
The main reason I keep putting this off is working out how to present all of this information to module developers an easily accessible way. Have a look at TerrainBasicPiece which exposes a new property CurrentTerrain which will return the terrain of the hex a piece is in. The two modules that actively use this access the terrain information via custom Java classes, apart from the $currentTerrain$ attribute.
How do we return information about edge terrain and line terrain? Could it even be used in a module?
The Tag terrain would be returned as additional properties. e.g the Port (true/false) tag could be returned by property terrain_Port.
I have some vague ideas floating around about a configurable tool to generate a custom ‘Area of Effect’ based on configurable rules that access terrain info.
I’ve never been quite convinced that these facilities are useful to the average developer.
Perhaps we could introduce this in stages. The most useful and easiest to use features are the Hex and Tag terrains. These can easily be used by most modules and this could be implemented pretty much right away with little work.
Interested in your thoughts, even if you want to leave it with me. Looking over it again has fired me up to get something happening again.
What I’m working on is a generic way to provide a GC directly into a multi-texture grid. It’s inspired by TextureRenderer which allows you to paint directly into an OpenGL texture, including entire GUIs, animations, etc. However, it’s not suitable for our purposes because there are hard limits on how big a single texture can be and there are constraints such as 2^n dimensions which are annoying. What I would like to do is substitute a GC from a MultiTextureRenderer at the lowest level and uh… well… hope for the best.
At the simplest level, it should work. The painful parts are then going to be user interaction which have to be addressed separately. That may be where the model/view comes in, because there’s really no generic front-end that I can think of like GC for rendering. I could generate events from the OpenGL from mouse clicks, etc., but I haven’t thought that far.
I’d love to say that I’m almost finished, but I’m not. It’s pretty easy to slap together a mock-up, but I’m spending more time on this.
I want to do some basic improvements to the Server Status pane. I’d like to see syncing straight to a game; At the moment it takes no less than 8 mouse clicks to join a live Vassal Game.
Also, I’d like to see a Main chat area in a pane on the Module Manager window; But I’m not sure I can do this without server-side changes; May need to take it up with rk.
That would be great if you could look after that. I have signed
RFE [2492729] Streamline Room Creation process - AutoSynch
over to you. It shouldn’t be too hard, all the code is there, just manually activated at the moment. I had a good look over this code when I was fixing the locked room problem, so feel free to pick my brains if you get stuck.
It should be possible. Look at how a module creates the Main Room for itself. Essentially, we want the Module Manager to pretend to be a module, joining a Main Room for a virtual module, perhaps called ‘Chat Room’?
Perhaps baby steps is the best way to go. I think you’re right here. Get the hex and tag terrain properties working and see how people use it. I think this would be relatively easy. The properties mechanism should search the terrain properties right after stack properties and before map and global properties.
As for hex sides, I’m not sure how they can be used and probably shouldn’t be introduced immediately. Same with lines. I can’t think of a way that module programmers can use them.
Let me see if I understand. What you’re talking about is basically keeping the 2D rendering logic in VASSAL, but painting it onto a surface that the user can rotate and manipulate. Is that right? Do we think this would give us any performance improvement or is just a fancy way of implementing the rotate-the-map-view feature request?
