I guess I could set a normal border with 1-sided attack dice, but that is such a hack, and I feel players are likely to be confused and try to attack. I just wanted to make sure there isn't some other way to do this that I am missing. I could try to edit the XML directly, and add two borders between the two territories, but I have the feeling this won't work. If no one else has tried that, I'll give it a shot.
Give it a shot and tell us if it works.
Ozyman wrote:I guess I could set a normal border with 1-sided attack dice, but that is such a hack, and I feel players are likely to be confused and try to attack. I just wanted to make sure there isn't some other way to do this that I am missing. I could try to edit the XML directly, and add two borders between the two territories, but I have the feeling this won't work. If no one else has tried that, I'll give it a shot.
I don't believe it should work. Tom made it so that between two territories there can only be a single (directional specific) border. There have been multiple bugs in which it's been possible to add multiple borders between the same two territories, in which I think what happens is that the Flash Player will choose one over the other but not honor both. I assume this is what would happen if you edit the XML.
It would be cool if there could be some combo borders (ie View/Fortify) available, although some wouldn't be allowed (ie Attack/Fortify or Artillery/Attack).
He has risen!
Yeah - I'm almost positive that I accidentally had a map with two borders (although in that case i think it was a view border & and attack border), and it broke the map somehow, although I can't remember how. I'll probably give a view/fortify border a shot at some point just to see what happens, unless Tom chimes in and confirms that it won't work.
You can view across a Fortify only border, won't that work?
tom wrote:You can view across a Fortify only border, won't that work?
tom tom tom you need to play some more games
You can only view across a Fortify border if you own the territory in which you are "viewing" to. Otherwise it's fogged as normal.
He has risen!
haha. I was wondering about that, but I have not played many games with fortify-only borders, and I think none with fog yet. Well it would be nice to have a "view & fortify" border, but it is not critical for my map.
An attack + view border would be nice also.
What else would round it out:
fortify + view
attack + view
artillery + view
artillery + fortify
Is that every combination that makes possible sense?
how about border attributes:
attacktype: default/one-way/artillery (anything new)
grantsvision: yes/no
fortify: yes/no
This could be a drop-down in the designer for the first and check boxes for the others (default is default/yes/yes). Probably a major change, but would cover all possibilities and would scale.
Yes agreed - it basically needs a rewrite of the border code to use flags instead of just a 'type' attribute.It's quite a big piece of work as there are a lot of places this code is used throughout the Player, Designer, and game engine and a lot of potential for nasty bugs. I agree it does need to happen at some point, prioritizing it is the question.
tom wrote:Yes agreed - it basically needs a rewrite of the border code to use flags instead of just a 'type' attribute.It's quite a big piece of work as there are a lot of places this code is used throughout the Player, Designer, and game engine and a lot of potential for nasty bugs. I agree it does need to happen at some point, prioritizing it is the question.
I'd like to bring this topic back to life, as my two most recent boards (Dungeonquest and Perilous Swamps of Kjeldor) are causing problems for players because I can't have an attack/fortify border that also allows vision through the heavy fog. I can either make an attack/fortify border or a view-only border, but not both. In dungeonquest, I would like the option for a default border (i.e. one that allows player to attack or fortify across it) that also grants vision. In Perilous Swamps, I want to mix a fortify-only border with vision. Right now, neither is possible and people are upset about it.
For the record, I did mention it in one of the Review Games - There could be a reasonable workaround if there were Real-Time Factories. Specifically, the Territory that needs to originate the view w/o attack border could be the sole member of a factory that immediately captures an off-board territory with a view-only border to the target territory.
The workaround is not that complicated to execute, but it would raise the territory count and as a result, raise the volume of our pleas for Token Territories.
The real-time factories (and token territories) would be key for that workaround, as delayed vision is often just as confusing from a player perspective unless the board is specifically designed around that effect.
i think that multiple border types needs rewritten before real-time factories. that is the most fundamental flaw we've got here.
plus, once that's in place other things can then be added to the code. the more we add before he gets to it (RT factories, for instance) the more chances for bugs...
Tom:
any way to test run a '3rd/4th' player as a debug option? those two would be native/flash players with the border upgrades (so essentially copy paste the current code and tweak it to run the 3/4th players with update code). this way we can try to work thru the bugs on existing boards.
i see this being helpful in a two-stage implementation.
- we would test with current boards as is with native/flash players as backup to make moves if the bug presents itself (they'd have to default to the way they currently are to not break boards).
- after we've worked out most/all the bugs we can, then let designers (a few?) go and update their boards with the new border types (if they wanted them updated). then we can really see how things change on existing boards. (this may require only a select few to play current games as this may present some unknown advantages while the bugs are worked out)
...crap that just caused some issues...
or maybe better yet, we start new 'unranked' games on the 3/4th players and leave the 'real' games to continue to be played on the orig players while the bugs are worked out.
- i think this also means that current boards in production would run DEV games on 3/4th player. they would be unable for official release until the multiple border thing is kinked out.
I'd be glad to help with testing. Setting up a secondary player/server for testing a big change like this sounds like a reasonable precaution. Most existing boards wouldn't need to be changed at all since they were designed with the current limitations.
It might be nice to do the per boarder fog control as well at the same time. How to deal with existing fog settings should remain as close as possible to the current system while also adding flexibility. So in addition to Alpha's list it could be:
Where default under vision means that it shows the vision that you would normally see under the current fog setting. Yes and no would override the current fog setting (the same way vision borders currently do).