We should combine Plugins with Global Extensions

A Plugin can do everything that a Global Extension can do, can’t it? And I believe a Global Extension can do everything that a Plugin can do as well. Both have to include custom code to add components to the menu of available traits, for example.

I worry that people will be confused between the global ‘plugin’ directory, the global ‘ext’ directory and the module-specific ‘ext’ directories. Can we just stick with plugins? Also, there should be some docs on how to create a plugin.

rk

Global Extensions definitely cannot do everything that a Plugin can. Global Extensions do not get loaded when you are in the Module or Extension editor, while Plugins do. That is the primary difference between them - Plugins add resources that the editors can use.

On the other hand, plugins are loaded before the GameModule is completely built, so there are limitations on what components they can hang off.

Let me think about this. I think we can do something that will allow plugins to do both jobs. So tentatively, yes, let’s ditch the concept of ‘Global Extensions’ and the global ‘ext’ directory.

How about we include the code, but just not document Plugins at all for 3.1 until we get this sorted out. I don’t think anyone except me is in a tearing hurry to actually implement a Plugin.

Brent.


Brent Easton
Analyst/Programmer
University of Western Sydney
Email: b.easton@uws.edu.au


Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

Im always eager to try out new stuff - what you got cooking? Advanced terrain traits more since last AVL build? :slight_smile:

[/quote]

Am adding ‘Attribute’ terrain to my terrain editor so you can, essentially, hang properties of map hexes. For example, you might add the Boolean attribute ‘Port’ to all the Port hexes on a map, so that components would be able to test for Port=true in property expressions. Ultimately, I would like fold all of this work into the core.

Plugin number 1 though, will be the Calculated Property trait plugin. Due to licensing issues, Calculated Property can’t be folded into the core.

Brent.


Brent Easton
Analyst/Programmer
University of Western Sydney
Email: b.easton@uws.edu.au


Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

If a plugin is going to add a component to every single module, it pretty much has to be limited to adding components directly to the top-level GameModule. An alternative, I suppose, would be to add a something to every component of a given type. For example, when using a plugin, every MapWindow gets a copy of a certain component added to it.

I like the idea of plugins. It allows you to build against and release non-LGPL-compatible libraries, as Brent says. It also can give you a clear upgrade for custom code. For example, if the pre-release TurnTracker had been in a plugin, we could have solved all the compatibility problems by just releasing an updated plugin.

To get it right, though, we have to pay close attention to exactly what plugins a module was built with, which means writing some validation and version-checking code. I don’t think we have that yet, so I agree with Brent to put plugins in as an undocumented feature for v3.1 and finalize it in v3.2.

rk

Post generated using Mail2Forum (mail2forum.com)

I’m not of the same opinion about plugins or extensions. I think it puts too much onus on the module designers to release modules as a package. And if they do not release all plugins/extensions in a zip with the module, you get "you need version x.xx of plugins … … … … " errors when syncing; This is a total end-user nightmare as far as I’m concerned. Are plugins and extensions really worth the extra headaches and complexity?

A good example of this recently was the Car Wars module, every time I tried to sync with the live game I was presented with a dozen messages telling me I had to download new versions of most of the extensions I already had. So I had to, somehow, find where these plugins were located on the net, then download them, then put them in the correct folder… then re-start Vassal and re-sync… then realise I had missed one and have to repeat the whole process. So now I don’t bother going in to watch live CW games… I can only begin to imagine what people with less Vassal knowledge must go through, I’m guessing they just give up.

I believe we should force modules to be totally self-contained. One download, one file, no hoops.

Ben

Brent, could you elaborate a little more on the ‘attribute’ terrain?
Is it the same as exposing CurrentTerrain? Or will it allow multiple tags for exposure and will it extend to hex lines or vertex?

Right now using ‘Current Terrain’ (Hex) in conjunction with CP’s IF, I’m able to crude count movement points, assign modifiers etc… to a Static real time CP or GP. that components can read themselves. But this is all hex only.

The main limitation right now is not being able to access the Line terrain and have it work in some manner with LOS or with Hex. CP’s can pretty much do most anything else I’ve found (except fire a key command!).

What is left for CP’s? Will you expand on things like SumStack to SumZone, SumLocation etc…as usable shortcuts or leave it standalone?

Tim,

Yes, very similiar. It allows you to basically tag hexes with properties that will be accessible to counters in the hex. For example, it may be important in your game that Ports and Beach hexes are tagged because something different happens to counters in those sort of hexes. Other hexes might have Victory Points attached to them. You would set up the attributes for this map as

Port - true/false
Beach - true/false
VP - string

Hex A1-22 might be a Port hex worth 2 VP’s so for counters in that hex $Port$ = true and $VP$ = 2

Attributes can be defined to be one of 3 types:-

  • true/false
  • List of values
  • freeform text

Do you mean the ability to expose the Hex edge terrain (rivers, cliffs etc.) to counters? I could do this right now, but the problem is doing it in a meaningful/useful way. What would you call the property names?

I’m not sure what you mean by Line Terrain?

Sure, whatever you think is useful.

Regards,
Brent.


Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

What does the interface for this look like? What does the player do
with this information? If the cursor hovers over a hex, will there be
some window that displays terrain info?

  • M.

On 19/02/2008, Brent Easton b.easton@exemail.com.au wrote:


Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

Michael,

This is a project I have been developing over the last year or so, initially to support my ‘A Victory Lost’ module. Units with command range of an HQ unit are activated, but the command range is affected by Terrain. I needed somewhere to save that terrain information.

I have built an interface to add the terrain data to Hex Grids and you can see this in action if you download the AVL module and hit the ‘Edit Grid’ button on the Hex Grid on the main map. That version supports the recording of full hex terrain and hex edge terrain. The terrain data is stored in a comma-delimited text file in the zip archive that can be easily edited/generated by spreadsheet etc.

I use the terrain information in AVL in some custom code to generate terrain dependent ‘Area of Effects’ and a terrain dependent ranged ‘Global Key Command’. So far, there is little or no interface to this information from Vassal itself. A unit can query $CurrentTerrain$ to find the name of the terrain in the hex it is sitting in, but that’s it.

Part of my reticence in merging this into the core is the want of useful ways to present this data for module designers. My feeling is that it is primarily useful for feeding into custom code, custom LOS being the obvious example.

To answer your question, the CounterDetailViewer can already display Text include $variable$'s, so it will have no trouble at all displaying full hex terrain and attributes.

Edge terrain is more complicated. How do you make that available in a useful way? $CurrentEdgeTerrainSouth$?

The code is actually very easy to merge into the core, it is pretty much stand-alone. If there is enough interest we could perhaps merge it into 3.2, but perhaps have it as an Advanced option? e.g. The HexGrids would have a Checkbox ‘Enable Terrain?’ which would enable the extended editor.

Regards,
Brent.


Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

Brent,

My bad -I said line but meant the hex edge.

Storing the info as CurrentHexEdgeN/NE/SE/S/SW/NW might work.
For purposes of piece/counter movement counting/adjustments, it might also work being able to expose a ‘LastHexEdge’ property when counters move hex to hex (similar to PreviousLocation in idea?)

Combat modifiers would be the toughy (strategic or tactical). Piece might have a river edge which can modify attacks on one hex edge but it is being attacked by a piece from non river hex side. LOS would be a factor needed in determining ’ did LOS cross the river hex edge? etc… and somehow tie into the Terrain stuff for use

Tim,

Unless you have a sideways grid, in which case it is NE/NW/E/W/SE/SW

But could you actually usefully use this information in standard Vassal?

This is probably not a bad idea. It would be set whenever a counter is moved from one hex to an adjacent hex. It would not be defined if the counter moves more than one hex or to other maps etc.

I can envisage modifications to the PieceMover that would allow you to turn on a special mode where it is physically impossible to move a counter except to adjacent hexes. Say ‘Movement Plotting Mode’ that is enabled by a ‘Plot Move’ command in a new counter trait.

This is where it becomes extremely difficult provide access to the terrain information in a generic ‘programmable’ way.

I do have some ideas to allow terrain to affect ‘Area of Effect’ and the range of ‘Global Key Commands’. It is very closely related to LOS. A terrain affected ‘Area of Effect’ is (I think) just a visual map of what hexes are in LOS of a source hex. I believe the ways that terrain interact with LOS and command ranges etc. are actually fairly limited and could potentially be encoded:-

Hex terrain:

  • LOS may not enter
  • LOS may not leave
  • LOS not affected
  • LOS blocked by nth occurence if this terrain

Edge Terrain:

  • LOS may not cross
  • LOS may cross, but not leave subsequent hex

Cheers,
Brent.


Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

Thus spake “Brent Easton”:

I wouldn’t use cardinal directions in the names—that’s bound to be
confusing, since the top of the map is often not north, and the hex
grain might be running east-west so that you have a vertex at the
bottom instead of a side.


J.


Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

This may be slightly off topic but Hex terrain and/or hexside terrain may also affect LOS/Movement/whatever in a way that is not On/Off 0/1 :

Some games use systems were movement/los can pass through hex/hexside on a random roll.

Imagine a hexside terraintype = Mtn pass or a hex terrain type=marshes. Depending on weather it could be passable, blocked or random.

One such gamesystem is the one used for BobbyLee & SamGrant blockgames from Columbia games.

Dry weather=one can go through passes, Mud weather=1-3 success, 4-6 failure.

So terrain effect can depend on another global property value. But here it’s maybe a tad to complicated to be part of the ‘standard’ features you have in mind for terrains.

Another things is that terrain can have ‘features’. Features being a list of properties (number or string or boolean) that units/triggers/hotkeys could test.

One example: in EuroFront2, HQ rebuilding costs for some nations (UK, US) change if HQ unit is in Major port, adjacent to major port or in minor port. If a terrin hex has properties like MajPort, MinPort, AdjMajPort, the cost for units could be automatically adjusted.

The possibility to add such user defined properties that can be tested by a unit could be a nice thing.

Sorry if that was completely out of topic but since this has to do with what is implemented in LostVictory and I had already thought about using this in my own module design for ColumbiaGames “Front” serie games for HQ command range, I thought I could chime in :slight_smile:

Would that be necessary?

You can already define movement 1 hex at a time via keystroke w/ move fixed distance trait. This still leaves the ability to utilize other movement methods such as Send to Location, drag n drop etc… as you may still need these for other things like sending pieces to dead pile etc…
It would just be incumbant on the designer to make sure they add 6 necessary moved fixed distances in a proto.

David,

While many games will follow basic rules, there will be plenty that use more complicated variations. These will either not be supported at all, will be supported in that particular module by custom code, or may end being incorporated into future upgrades.

This is what I was talking about earlier ‘Attributes’ and Has already been added to my work in progress versions. Although, I am thinking of renaming them from Attributes to Tags. Less computery.

Yep, that is exactly what ‘Attribute’ terrain is.

I would be very interested if you could email me the HQ command range rules for the ‘Front’ games, for my research.

Cheers,
Brent.


Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

Brent,

Can’t wait for those ‘tags’ :slight_smile:

In the meantime, is there a way for a unit to test the presence of another gamepiece in the same location it occupies ? If that’s possible I could devise unmovable invisible “Ports” pieces that I would setup on the map with at start stacks and if my HQ units can tests if they are stacked with one this could do the trick.

Now about the HQ, I’ll send you a “digest” version of it in the comming days. In short, command range is based current strenght of the HQ, hex control & terrain :
A “3” HQ commands 3 hexes away but…
Command range can be traced only through passable terrain
Command range can be traced only through Friendly or Disputed terrain (not Enemy controled terrain).

The most tricky thing will be hex control and here it may well need a specific custom code.

More in your mail box soon

Short answer to testing presence of pieces. Yes you can do that.
Various combinations of GP, DP, Trigger, GKC or Marker can achieve it

Aradiel messages@forums.vassalengine.org wrote:

Post generated using Mail2Forum (mail2forum.com)

Tim,

Could develop a bit your short answer? :wink:
I had the idea that something using the elements you cited would be possible but maybe I’m too tired right now for the idea to surface in my sleep lacking mind :frowning:

Can you give me a specific example of what you would like to happen - and I’ll make you up a small demo showing it - i.e what does the HQ do if it lands on a hex with a hidden port marker?