@redrum @Cernel

Hi, I'm just a newbie into all this.
Do you know if there is any development about being able to use these special Sub abilities?

If I want to restrict Subs in First Strike phase to only hit surface warships, excluding aircraft (of course) and submarine (also), do you believe this small step can be more easily implemented?

It will not add another screen, or other phase at all. Just make aircraft and Subs not available as valid target.

Thanks @Cernel, I was really hoping I was overlooking something simple, but at least it is possible as you suggested.

Thanks for the help! it works now.
=D.PNG
=).PNG

Thanks for the help you two! It looks great now and I think I got the hang of it!
yay2.PNG

@Cernel

GD it you sure got the eye. "Also be sure the phase is exactly called "russiansPurchase" (not validated)."

It's "russianPurchase" Had me chasing my tail for half a day. Big thanks 🙂

@LaFayette no. redrum helped me out. thanks lafayette.

I figured it out! You have to designate Japan as the initial territoryowner for each of the Kamikaze sea zones! YAAAAAAAAAH

thanks man.

Right on! Thanks for the info 👍

I figured it out thanks to Hepp's help in private chat. Here was the solution: changeOwnership only seems to work if the players changing ownership are at WAR with each other. So the trigger now has 3 steps. First it changes relationship to WAR. then another trigger does the change in ownership. And then a third trigger changes the relationship back to Allied. 🙂

@Cernel Here is the panel

844c0c9d-d5a3-4dcb-b165-45d2ad417fa2-image.png

The trick is that A&B start at war and the real players randomly ally with A or B. A & B are nominal players with no territories or units.

Yah. that was it. And another typo. thanks man

@Hepps Thanks for your help, but I just researched it and found out how to remove the background.

@Cernel well damn. now its working. that so weird. cuz all the other Objectives.Properties files i've checked 'appear" to have linebreaks there. But hey, it worked, so i'm happy. THanks man. When u gonna be back on to continue our game 🙂

@danelyoung The scenario is still not working in pre-release, but works in the stable version.

A StackOverflowError is simply signals that there is no more memory available. It is to the stack what an OutOfMemoryError is to the heap: it simply signals that there is no more memory available. JVM has a given memory allocated for each stack of each thread, and if an attempt to call a method happens to fill this memory, JVM throws an error. Just like it would do if you were trying to write at index N of an array of length N. No memory corruption can happen. The stack can not write into the heap.

The common cause for a stackoverflow is a bad recursive call. Typically, this is caused when your recursive functions doesn't have the correct termination condition, so it ends up calling itself forever. Or when the termination condition is fine, it can be caused by requiring too many recursive calls before fulfilling it.

Here's an example:

public class Overflow { public static final void main(String[] args) { main(args); } }

That function calls itself repeatedly with no termination condition. Consequently, the stack fills up because each call has to push a return address on the stack, but the return addresses are never popped off the stack because the function never returns, it just keeps calling itself. If the stack is full you can't push, if you do you'll get stack overflow error. StackOverflowError is avoidable if recursive calls are bounded to prevent the aggregate total of incomplete in-memory calls (in bytes) from exceeding the stack size (in bytes).

@Frostion I am actually close to getting something working.

<attachment name="conditionAttachmentJapaneseEnemyUnitPresent" attachTo="Japanese" javaClass="games.strategy.triplea.attachments.RulesAttachment" type="player"> <option name="enemyPresenceTerritories" value="all" count="each"/> </attachment> <attachment name="triggerAttachmentJapaneseEnemyUnitCount" attachTo="Japanese" javaClass="games.strategy.triplea.attachments.TriggerAttachment" type="player"> <option name="conditions" value="conditionAttachmentJapaneseEnemyUnitPresent"/> <option name="resource" value="PUs"/> <option name="resourceCount" value="1"/> <option name="when" value="after:BBidplace"/> </attachment>

The trigger is not firing, but I am getting close to having a way of counting all enemy units and all friendly units. I can then use the difference for some rough handicapping.

In many scenarios, there is no obvious historical (or hypothetical) conflict. This way I can just assign random sides and balance them, rather than having a free-for-all, which I find makes for uninteresting play.

Ok thanks, that worked!

thanks guys!

@Frostion Yes it does, thank you for the additional information.