If there’s only one predefined setup in a module, why does the wizard ask you to select one?
why have a predefined setup in the first place if you intend to have a static setup
Anyways, this could be filtered…true. Think the whole module load/setup wizard needs some polishing.
It’s the only way you can set GamePiece states such as rotation or PropertySheet values. You can’t start a piece rotated without it.
- M.
On 15/03/2008, Dab <messages@forums.vassalengine.org (messages@forums.vassalengine.org)> wrote:
Post generated using Mail2Forum (mail2forum.com)
actually a gamepiece will start the ways you configure it. i know what predefined setups are good for. i use them for scenario setups too.
but you can go to a single piece in the editor dclick to open the window where you can edit the pieces traits. in the upper pane there is a preview of said single piece. this “preview” has full funtionallity concering all traits present. this includes rotation frex.
although in this case every newly created game piece you drag from the gamepiece palette would start with exactly the same configurations defined in this “preview” pane.
Actually i was just bitching around So don’t take it too serious
If you have fixed amount of ounters, and there is a static starting setup for the game (frex monopoly or other simple games) there is no need to use a game palette at all! I would implement the counters using at start stacks. But thats a design question…
p.s.: im doing this approach on the wif mod im creating currently
Interesting. I didn’t know that. That actually saves me a lot of work. I had no idea that the states were actually saved in buildFile. Thanks!
- M.
On 15/03/2008, Dab <messages@forums.vassalengine.org (messages@forums.vassalengine.org)> wrote:
Post generated using Mail2Forum (mail2forum.com)
I see what the problem is. You cannot change the states inside traits that are within prototypes. I should say, you can change them, but they won’t be saved. Hmmm… tricky. Should I go with predefined setups or eliminate the prototypes.
Here’s a question: if you have a module that uses a property sheet for all your units, would you put the property sheet in the prototype definition and edit the property values in a predefined setup, or would you put property sheets in all of the units individually and edit them in the module editor? What does everyone think?
I suspect most people would give each unit their own individual property sheet in the module editor. Bit of a pain though – they all have the same property names. No problem for me as all of this is being generated automatically, but if someone wants to modify the module later…
The other question is, if states are saved in the buildFile, why doesn’t it save the states of inner prototypes? I guess the answer is that the states are tied so closely to the traits, you’d have to jump through hoops to figure out which traits each state belongs to. And besides, all backward compatibility would be lost.
- M.
On 15/03/2008, Michael Kiefte <mkiefte@dal.ca (mkiefte@dal.ca)> wrote:
Post generated using Mail2Forum (mail2forum.com)
guess this is a logical problem. if you put the rotate into a prototype, the engine cannot know to which traits the rotate are to be applied on the game piece at runtime. At least not at design (module build) time.
Think of this like an interface in java or an abstract class sort of thing. You define a kind of behavior, without relating it a special “predefined game piece”, read not attached to an existant piece (no memory, just abstract behavior.
What does this mean for your case:
You cannot interpolate at the prototype, you have to interpolate at the actual “single piece” that is implementing the prototype. Try it, i should work, does for me at least
As for the other questions. Its almost always the better ways to go with prototypes! But as related to what i just explained: you cannot predefine any values for a spreadsheet at the prototype! This has do be done on the piece implementing the prototype anyways. Its almost always better (and rewarding) to start prototyping early on. Think about an intelligent set of prototypes before you do all the monotonous counter editing. This
might safe a lot of time and usualy leads to a better maintainable module.
Ergo you have to edit the property sheet on the units anyways! The prototype can only provide the logic but wont save any values, as there are no pieces (think of memory allocated) for a prototype.
What you have to think of, and whats the real decision to make in my opinion is: With a predefined Setup you will have an amount X of pieces of set A with a property sheet a[P]. If you delete the piece during the game, its lost, the next one you create wont have the values stored! A predefined setup is a save game. A moments snapshot of the game that you can load via a menu and is supplied with the module, as opposed to stored on your hdd and you choose to load it. If you decide to edit the pieces in the game pallete and your module has an option to delete and create pieces (from this game palette) each piece a from the game platte will have values a[P0] as defined in the modul.
I think its a question of how you desinged your module from the start. If the amount of pieces is static and there is no delete/ create option the pre defined option will do fine as this option is almost equal in effect to the other option in this scenario. Although, i would recommend an at start stack with piece without a delete trait in this case…this is why i was making some fun in my initial statement.
On the other hand: If you have an unlimited supply of game pieces, that is realized with a game palette (seems logical to have a possibility to delete in this case as well), it is much better to go with the property sheets “predefined on the single pieces in the gamepalette”. This will ensure that the Counter A from the game palatte (identified by his unique property sheet A[P0]) will have A[Pi=P0] in his property sheet on creation (with A[P0] being the values you hacked into the module). It strikes me thats what you want to archieve here.
In my opinion the use of prototypes in general is not involved in this decision, i recommend extensive use of prototyping. Especially on huge module just to safe some time -.-
Hope this helps.
p.s.: i havent done this yet on a real module. but this is what i understand from what i know about vassal so far. i could be wrong -.-
p.p.s.: I am sorry for my monotonous english. im not a native speaker
If you’re property sheet is in a prototype, then you cannot save properties values in any piece that implements that prototype no matter what you do. It may give the appearance that it will, but it won’t – I’ve checked. If you change property values in the prototype, then those will be saved, but they will be the same for all the pieces that implement that prototype.
Thanks for the suggestions!
- M.
Post generated using Mail2Forum (mail2forum.com)
Which is logical when you think about it. The properties you are setting in the Editor are saved in the buildfile, so if the a trait is defined in a prototype, then that’s where the properties that are set will be stored, and thus have to be applied the same to every counter that defines that prototype. It is a natural consequence of the way prototypes work.
The ‘pieces’ that are displayed in the GamePiece config dialog and GamePiece palettes are not ‘real’ pieces that are saved anywhere as such. They are built at the time you start editing them and reflect the setting of the traits defining them.
You really have only two ways to work around this issue:
-
Define the property sheet in a prototype, but use predefined setups in which you pull the counters you need and apply the property sheet info to the pulled counters.
-
Define the property sheet individually in each counter.
Refards,
Brent.
Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org
Post generated using Mail2Forum (mail2forum.com)
I’ve decided to do the latter for the moment as adjusting only a few pieces in a save game is quite complicated. Doing it this way also gives me more flexibility in many of the other traits.
- M.
Post generated using Mail2Forum (mail2forum.com)
This is an instance where placing traits into a prototype is not the correct choice.
You use protoypes to share identical traits with identical setup between counters. Property Sheets are a bit ‘special’ in that you often do not want the identical setup used in each counter. It’s just one of those things!
Brent.
Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org
Post generated using Mail2Forum (mail2forum.com)
Thus spake “mkiefte”:
I see that no one answered your question. I suspect that this is a bug.
Rodney?
–
J.
Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org
Post generated using Mail2Forum (mail2forum.com)
I think this is not a bad used of prototypes. Whats missing here is the feature to define default values for traits in single pieces that derive from a prototype just like you can for traits that are defined on the piece itself. This should be possible by all logic, and is a flaw in the prototype implementation to me.
For the initial topic I’d classify this as an ui logic bug.
No good reason for this. I’ll look into getting it fixed, but don’t hold up 3.1 for it.
rk
Post generated using Mail2Forum (mail2forum.com)