Hubert Cater

Consider it done

Thanks for the thoughts Sharkman and interestingly enough I believe the original test versions actually had Italy set up the way you suggest in that you still had to DoW once you reached 100% mobilization but we ended up changing it to what it currently is for the official release. I believe testing showed some frustration that Italy still needed to DoW and some confusion as to why it was not automatically at war. IIRC these were a few of the problems that cropped up and why we use the current model for simplification. Some good counter points though and we'll have to think about this some more to see if there is a better overall solution/compromise.

That makes sense so my guess is that it is an incorrect mod for your game, probably a Global Conflict base game mod for GOLD etc. Can you confirm that the right mods were downloaded for the game you are attempting to play it on?

I can confirm that this is now fixed for the next patch

Can you send me a saved game of the error so that I could take a look to see what the problem might be? Send to support@furysoftware.com

Can you confirm that you downloaded the correct mod for GOLD or was it a mod for the base Global Conflict game? I only mention this as there are two download sections for GOLD and Global Conflict.

Hi Rocko1, Unfortunately not at this time, all countries for each side are under your control and only the enemy countries will be controlled by the AI. Hope this helps, Hubert

This is often true but just looking at the campaign I don't think it is the case in this one instance... as soon as I get the turn from David I should be able to confirm though.

SeaMonkey, I guess I'm always easily amazed

That looks like it might be a bug as China should be able to attach 5 units, please send to support@furysoftware.com Hubert

Thanks for the feedback EdR and glad to hear you are enjoying the games

Me too actually but every once in a while someone finds a bug like this where my initial reaction is along the lines of "You win the prize!" because it surprises me just as much that it has never been noticed before. So, you definitely win the prize on this one

The ability to detach after a swap is definitely a bug... I looked into what the user manual mentions about readiness and this might be going all the way back to SC2 and is of course incorrect as David is right, the readiness effects are instant. This is due to the fact that readiness is always dynamically calculated and not a stored value as readiness can decrease during the course of a turn, i.e. as a unit loses strength from attacks and so on. But in the case of attachments it should be fine as long as you cannot cycle through attached units since once a unit moves it should not be detachable and I've now corrected the bug with swaps on my end for the next build. Thanks for the report, Hubert

Sorry to hear that Amadeus and I would strongly suggest for him to open a support ticket to http://www.battlefront.com/helpdesk as without more information it would be hard to say for sure what the problem might be, i.e. it could be an anti-virus issue or something else entirely.

Thanks again for your interest but unfortunately nothing just around the corner just yet. The idea of an iPad or other mobile version is still just something we are thinking about at this stage

This is most likely a weather issue, i.e. if the carrier is in stormy water or if there is rain then it will not be able to attack.... could this be the case here?

Hi Mike, Send me an email at support@furysoftware.com as I have something for you to look at that might be of some help. Hubert

Correct, the link needs to be active before the event is even looked at as it is only relative to the decision once made. After that the trigger is indeed in reference to the #TRIGGER value. So for TYPE=0 if all the other conditions are satisfied and let's say you have a #TRIGGER= 50 then there is a single check and if the #TRIGGER is satisfied the event occurs, if not it is removed and never looked at again. This is useful if you would like to have a one time event in the game that may or may not happen. For #TYPE=1 it will keep checking until the #TRIGGER value is satisfied. This is useful if you want the event to eventually occur but would prefer some randomness as to when it will actually happen in game. Hope this helps, Hubert

This is a video card error that a reboot usually resolves.

I think there is a point here with the TYPE= 2 as we haven't really used them until recently so let me discuss this with Bill and see if what you propose will work, i.e. just in case I'm not missing anything on our end for TYPE= 2 and we can go from there. The only docs we have are the headers included for each script file, the notes in the Editor Help file as well as some extras in the Extras\Docs folder. Probably not exactly what you are looking for but some of it might help

Thanks for all the feedback gentlemen and I can at least say that we'll see what we can do to try and incorporate as many good ideas as we can in the new game

Actually the original idea behind the DEs (on our end) was to use them linked together, i.e. one DE then links to another DE and so on based on the previous response... so with this in mind it was critical that DE results remain applicable throughout the lifetime of the campaign as we also use them to link to other events quite often later on in the war as well. I'm not sure if there is an easy way around that for what you have in mind but it sounds like you may have come up with a partial solution. For the trigger, it doesn't take precedence, it is just another one of the criteria that must be true for the event to fire. But setting it to 100% guarantees it will always be true.

The highlighter for ConTEXT is included in the Extras\ConTEXT folder for all of the SC2 games. I believe it is called SC2 Script.chl or something like that. I like the Notepad++. I took a look at it after your original recommendation in the forums a while back and I use this now as well for some tasks such as search and replace in files as it is a bit more robust than ConTEXT in this regard.

Hi Mike, I think both sides are right on this one. For example, if a DE is set to type=2, as far as I can tell it is reset condition wise, as Bill suggests, to recheck if all the conditions are satisfied before it will pop up again as a decision to the player. However, what happens internally is that once a decision is made, the decision, yes or no, is stored as a variable for the lifetime of the game to be picked up upon by subsequently linked events. The only thing that will change the stored decision value is if the DECISION pops up again and the user changes their answer to the YES or NO question. Not sure if this helps but this is what is happening behind the scenes code wise.

No partially developed scenarios should be fine