Would development of Vassal 4 or later be simplified if all the calculations required by module developers were handled externally to vassal and hyperlinks used to get those results into vassal itself?
When I was working, I needed to write reports based on a bunch of calculations. Excel did the calcs and word did the reports. To make my life easier, I developed a word template that ‘imported’ the appropriate data from the various excel cells, including any graphs, etc. All I had to do then was write words. The excel data was there.
Excel and its various equivalents, can handle a lot of formulas. Global properties, equations, etc can all be handled within the spreadsheet. Vassal would just access the spreadsheet automatically, either to get a result or to pass data to get a result.
If a spreadsheet became a part of vassal, through some sort of licencing agreement with one of the freeware versions, then vassal will be able to tap into the power and versatility of the spreadsheet environment to do even more awesome stuff. There is no need for developers to learn how to ‘java’, or whatever is needed for a new version. All they need to do is learn how to use the spreadsheet, the inbuilt capabilities, etc. That and the excel/excel equivalent already has a strong help and reference library, obviating the default ‘trial and error’ equation development process I (and maybe many other Vassal module developers) have gone through.
I do know that access to the power and equations building standard inherent with most spreadsheet software enables a single point of reference for everything a module developer may want to do with his/her module. Vassal, as it currently stands, has quite a number of reasonably powerful equation building capabilities. But they are disparate and a developer can founder uselessly trying to find a solution to what what he/she wants to calculate. This is exasperated by the paucity of documentation of vassal abilities and enhancements that have been included over time.
Frex you can set the ‘mouse over stack viewer’ to display the sum of various things across various layers. But you cannot do this with calculated properties. CPs, on the other hand, can do a whole lot more than the ‘mouse over’ thing.
Get rid of the disparity, get rid of the paucity of how to do it, get rid of the need to develop a knowledge of some, relatively, obscure code base. How many people use a spreadsheet? How many people use java (or the version 4 replacement)?
Go with the known power and versatility of proven spreadsheet software that also comes with fully documented help for all its functions.
Surely Vassal can only gain impetus from this. Concentrate on the gaming aspect, leave the computations to a spreadsheet.
This is a common feature in business application, a way to import what is called “decision tables” from excel.
The new Vassal is supposed to get LUA as a scripting language IIRC, not Java, nothing obscure. A lot of games use lua scripting.
As for how many people use Java, certainly more than C++ and Lua combined. Just they usually use it to earn good money on the job and not to write modules for free
My thought was to leverage off a known mathematical system, with a large array of functions for use and well supported by good help functionality. Global properties and all calculations in one area. Only need to reference a cell to get a game piece to display/use a value.
Reference to number of java users was wrt the number of people that use spreadsheets. I’m far more comfortable with using spreadsheets than all that beanshell/java expressions, etc. Particularly when the supporting documentation does not appear to have been updated for some time - Vassal 3.1 Designers Guide. We’re now at 3.3.x and 3.2.17 was around for a long time.
Whatever the new vassal will use for its development, there will always be a need to perform calculations, etc. The greatest hurdle for a new version, using LUA or whatever, will be writing the supporting documentation. Using a spreadsheet will obviate a lot of that necessary documentation as it is already built in. Vassal development can focus on everything else with the confidence that the maths part is fully taken care of.
Having people try to write code in a spreadsheet is a recipe for disaster. Have you seen someone try to run their whole business from one spreadsheet? That’s what you’ll end up with. It will be an unmaintainable mess. It’s not a thing I want to encourage, and it’s what will happen if we let people do it. As much as possible, we should make tools which help the user avoid creating a twisty pile of junk. V3 didn’t manage that, and I don’t want us to repeat the same mistake with V4.
I know I am the green guy around here who hasn’t so much as PRed a typo yet. But, from my decades of experience I cannot agree with uckelman more. Recursive Rabbit Hole Ahead.
Yes. Not try, do. Various companies hunt millions worth of Euros through Excel sheets. SAP is too expensive and unnecessary for them, small business applications too complicated to get them developed.
Also, it’s much MUCH easier to … “be an extremely sincere and honest accountant and tax payer” if there is no professional accounting software handling your numbers. Yay, capitalism. But no worries, some day we will get our Star Trek world, with no money, no salaries, no minorities ruling over majorities, and a central information network like this one en.wikipedia.org/wiki/OGAS
Having people try to write code in a spreadsheet is a recipe for disaster.
Who suggested writing code in a spreadsheet? I did not.
I suggested that all those numerous (mathematical) calculations that one needs to perform for a vassal module game would be far better done by a spreadsheet. Said spreadsheet having very well documented abilities and quite powerful inbuilt functions.
Let Vassal do its great enabling for us guys to make an electronic version of any table top game, but do away with the (rather) stilted equation/maths inherent capability of whatever you’re using for ver 4. It took me a long time to work out how to really do equations/maths with java in ver 3.x. Even then it has nothing that compares to what a competent spreadsheet can do (in a fraction of the time).
Further, if not going with this concept, do not limit people to integers or decimal numbers stored as text. What a crappy way of doing number crunching. Life would be simpler if 1+1.1 equaled 2.1 not (float)(1+1.1) equals 2.1. Or, as I have met with several of my formula within the module winter1==1&&1.0numatkrwintunits1b/numatkrunitsb>=0.5?2:0. to make this work I had to add the 1.0numatkr etc to (1) get the equation to work and (2) prevent calc error messages (essentially using a string instead of a number). If a developer selects that a global property is a number then make it so - BUT not only as an integer.
And Vassal is written in a strongly typed language, and so will be V4. An integer number is something completely different from a floating point number.
