Bugs

[grombit]

@sschnar1

correct i have noticed this as well.
not just to the end of a game as well.when i was test playing calm before the storm mod.
it was doing the same thing.sticking on combatI.
i have to say that turn resolution is the main problem i have had with sc3.
the joke is that the new engine is slower than the old engine with sc2.
I.E sc pacific theater is a lot faster with turn resolution than sc3.
i know because i have stop watched checked the two games.
unless hubert can improve on this,scenarios with a lot of units & decision events are a waste of time.
the budapest mod was taking 50 mins to resolve 1 AI turn,due to the large number of units.
this engine is also double slow at checking & implementing the list of decision events !!!

[sPzAbt653]

this engine is also double slow at checking & implementing the list of decision events !!!

I can agree with this, as I have worked on some modding and added Pop Ups so that I can monitor if things are firing as intended. On occasion these popups will fire during a turn [as if the engine were checking decisions while the computer is playing its' turn, as opposed to the beginning or end of the turn]. Some of them are related to Decision Events that are all in the same area of the script, all next to each other, yet it takes 20+ seconds for each one to fire, each turn. I don't know how the engine is running things, but to a knumbskull like me it seems out of whack [:)]

[v1.09.06, but its been like this, didn't just start with this version].

[grombit]

@ sPzAbt653

thanx for replying,at least some one with a reasonable grip on reality agrees with me.
in fact sPzAbt653 has as good pedigree as a modder.
he is the co-author of DIRECTIVE21.by the way i was impressed enough with 653H to make up 2 custom unit sets for it.
one for the 3D sprites & one for the 2D nato.
i will pm you about this & your mod.
anyway,clearly the system with sc3 needs speeding up a bit & hopefully hubert will do some thing about it.
grombit

[Hubert Cater]

ORIGINAL: sschnar1

I am running 1.09.06 Single Player with Allied AI.

I have not noticed this problem on any my other games that reached 1945 of the previous versions, but it is getting PAINFULLY SLOW. Upwards of 40 minutes doing just 'THINKING (Combat I) ...', btw: '...' is not cycling, it looks like all is stopped, Task Manager indicates that it is still processing consuming 29% CPU time.

This slowness started around APRIL 1945 and was getting longer and longer, it is now APRIL 1946 with delays up to 40 minutes just doing (Combat I). This reminds me of the old days where computers had to sort out available memory. I suspect some sort of AI Decision is having an issue.

I would attach the game file(s) but I don't see how to attach it here.

If you have one of these slow turns handy could you send it to support@furysoftware.com?

Thanks as I'd be happy to take a look as something doesn't sound right at all as that should not be happening. Having the turn will help me to narrow down and correct the issue,
Hubert

[Hubert Cater]

ORIGINAL: grombit

@sschnar1

correct i have noticed this as well.
not just to the end of a game as well.when i was test playing calm before the storm mod.
it was doing the same thing.sticking on combatI.
i have to say that turn resolution is the main problem i have had with sc3.
the joke is that the new engine is slower than the old engine with sc2.
I.E sc pacific theater is a lot faster with turn resolution than sc3.
i know because i have stop watched checked the two games.
unless hubert can improve on this,scenarios with a lot of units & decision events are a waste of time.
the budapest mod was taking 50 mins to resolve 1 AI turn,due to the large number of units.
this engine is also double slow at checking & implementing the list of decision events !!!

Hi Grombit,

Thanks for the feedback and one thing I can say for sure is that the engine itself is definitely not slower than SC2, in fact if the game was using the SC2 engine for the new map size and the number of events for SC3 it would be much more slower than what you are currently finding.

It is just that as the map and number of units has increased in size, as well as the number of events, things do take a longer time to process. To put things into perspective:

Pacific Theater Map -> 198x82 = 16236 hexes
SC3 Map -> 268x138 = 36984 hexes

Map is more than double the number of hexes/tiles and for the events there are around 5 times more events scripted for SC3 ETO versus SC2 Pacific as well.

But all of that being said, it sounds like an issue with that one routine and as soon as I am able to sort it out, after seeing a saved turn with the problem, then things should speed up considerably.

For mods like the Calm Before The Storm, there are even more events and I noticed this right away as it took quite some time for the engine to sort out the number of events to examine on the very first turn.

It is a careful balance between quality game play via events and turn resolution speed for sure,
Hubert

[Hubert Cater]

ORIGINAL: sPzAbt653

this engine is also double slow at checking & implementing the list of decision events !!!

I can agree with this, as I have worked on some modding and added Pop Ups so that I can monitor if things are firing as intended. On occasion these popups will fire during a turn [as if the engine were checking decisions while the computer is playing its' turn, as opposed to the beginning or end of the turn]. Some of them are related to Decision Events that are all in the same area of the script, all next to each other, yet it takes 20+ seconds for each one to fire, each turn. I don't know how the engine is running things, but to a knumbskull like me it seems out of whack [:)]

[v1.09.06, but its been like this, didn't just start with this version].

It really is for now just the number of events and all the associated conditions (which gives us increased flexibility in design) that eats up a lot of the time here. Compare the number of events for SC3 versus SC2 Blitzkrieg and you quickly see the difference. Again, we can really only speed this up by reducing the number of events, but the tradeoff is possibly a lower standard of game play in return.

[sPzAbt653]

It really is for now just the number of events and all the associated conditions

If it is working optimally then all is good. I can tell by running the 'update' on the scripts that the number of them in a given category has a definite effect on the time needed to go thru them. It still doesn't seem excessive, but in this age of faster computers when something takes more than 3 seconds we tend to scrunch our noses. The one example I was referring to pertains to twelve of these [below] that I added to a mod in the DE Events, all next to each other in succession, and I am assuming that due to the 'AI Response' popups that I can see that I was watching these events progress in real time, which takes 20 seconds to fire between each one.

{
#NAME= DE 148 - U-Boat Losses (Jan Mayen Convoys)
#POPUP=
#IMAGE=
#SOUND=
#FLAG= 1
#TYPE= 2
#AI= 0
#LEVEL= 0
#GV= 1[1,100]
#LINK= 0[0]
#COUNTRY_ID= 116
#TRIGGER= 80
#DISPLAY_ORDER= 0
#DECISION= 148
#MPP_UPDOWN= -5
#MPP_TURNS= 1
#MPP_TEXT= U-Boat Losses (Jan Mayen Convoys)
#NOTES=
#NOTES_POSITION=
#AI_RESPONSE= 100
#AI_RESPONSE_POPUP= U-Boats cause losses on the Jan Mayen Convoy Route
#DATE= 1939/09/03
#TEXT_RGB= 0,0,0
#SHADOW_RGB= 0,0,0
; Murmansk is in Allied hands
#ALIGNMENT_POSITION= 211,16 [2]
#NATIONAL_MORALE_TRIGGER= 0 [0]
; USSR politically aligned with Allies and not surrendered
#VARIABLE_CONDITION= 116 [2] [100] [0]
#CONDITION_POSITION= 133,11 [0,1] [1,1] [1] [0]
}

Obviously these events have several things to check, but it feels a little off that it would take 20 seconds to go thru one of these, so much so that I thought maybe the engine was doing something else in between, or stopping and starting over, or who knows what! I am not complaining, just pointing out something. If that is the way it is, then fine. As far as the map size and number of units, I can definitely see the reason for the computer to be a little slower. There is a lot to do.

[rjh1971]

Hi all

Since v1.09 Beta when you "force march" naval units some times the path they sail through is not set as revealed from FOW.
Hubert can you take a look into it?
Thanks.

[Hubert Cater]

Hi sPzAbt653,

If these are added as DECISION events then what happens after each one is checked, if it is successful and fires as a DE event then due to the nature of how DEs link to all the other events, each one of the other events in game is checked to see if any applicable effects apply related to the DE. So what you see is the time it takes to parse through every single other event in the campaign for a matching link, and then for any related event conditions to be parsed and to then fire if applicable. This happens each time a DE fires and as mentioned if you have a lot of events it unfortunately in the end just takes some time.

Just taking a quick look at the current 1939 Campaign, there are 203 DECISION events with just over 1400 events to parse for every hit on every DECISION.

[Hubert Cater]

ORIGINAL: rjh1971

Hi all

Since v1.09 Beta when you "force march" naval units some times the path they sail through is not set as revealed from FOW.
Hubert can you take a look into it?
Thanks.

Hi rjh1971,

This is at the moment intentional and was changed in v1.04:

- naval units in Naval Cruise mode will now only reveal hidden units from its final destination position and no longer along its movement path.

[crispy131313]

Is it a bug that American occupied Greenland shows Axis ships to the Allied player with FOG on, despite there being no towns around.

[rjh1971]

ORIGINAL: Hubert Cater

ORIGINAL: rjh1971

Hi all

Since v1.09 Beta when you "force march" naval units some times the path they sail through is not set as revealed from FOW.
Hubert can you take a look into it?
Thanks.

Hi rjh1971,

This is at the moment intentional and was changed in v1.04:

- naval units in Naval Cruise mode will now only reveal hidden units from its final destination position and no longer along its movement path.

Oh,my bad then. Thanks for replying Hubert.

[sPzAbt653]

each one of the other events in game is checked

Ahah! It is working as intended, and it does go back thru all of them when one is triggered!

To speed up the game, add a Flag for 'Event Check= Value Range [0, 1]; True= 1; False= 0). True to run as it does now, False to not check all other events. For when the designer knows that this event has no effect on anything else and is not affected by anything else, as is the case for the DE 148 that I showed above. [;)]

[nnason]

Do not reduce AIs effectiveness for speed. SC works well in the background do email culling or wash the car while waiting. However it would be great to have an action review like already implemented in PBEM so can review what happened while I was washing the car.

[Hubert Cater]

ORIGINAL: sschnar1

I am running 1.09.06 Single Player with Allied AI.

I have not noticed this problem on any my other games that reached 1945 of the previous versions, but it is getting PAINFULLY SLOW. Upwards of 40 minutes doing just 'THINKING (Combat I) ...', btw: '...' is not cycling, it looks like all is stopped, Task Manager indicates that it is still processing consuming 29% CPU time.

This slowness started around APRIL 1945 and was getting longer and longer, it is now APRIL 1946 with delays up to 40 minutes just doing (Combat I). This reminds me of the old days where computers had to sort out available memory. I suspect some sort of AI Decision is having an issue.

I would attach the game file(s) but I don't see how to attach it here.

This AI calculation error has now been fixed on my end... 40 minutes now down to seconds as there was a bit of a hiccup in the code in this one section.

[sPzAbt653]

Hi Bill - not a bug but I came across this in the Guards scripts and think maybe it is a typo, as 23 = China.

{
#NAME= Germany Minor Guard - Hungary
#POPUP=
#FLAG= 1
#TYPE= 2
#COUNTRY_ID= 52
#TRIGGER= 100
#LEVEL= 0
; Set global variable condition to always trigger (dummy value)
#GV= 1[1,100]
; Set link value to always trigger (dummy value)
#LINK= 0[0]
#LENGTH= 1
#HOLD= 0
#ADD_HQ= 0
#GOAL_POSITION= 184,88
#DATE= 1939/09/01
#STEAL= 0
; Set friendly positions:
; 1st Line - Budapest
#FRIENDLY_POSITION= 184,88
; Set variable conditions:
; 1st Line - Hungary politically aligned with Axis and not surrendered
#VARIABLE_CONDITION= 23 [1] [100] [0]
; Set tactical conditions:
; 1st Line - Budapest not tactically threatened (dummy condition)
#TACTICAL_CONDITION= 184,88 [3]
; Set dummy activate position (no units at position 0,0)
#ACTIVATE_POSITION= 0,0 [0,0] [0,0] [0]
; Set dummy cancel position (single neutral unit at position 0,0). This is not possible as no
; unit can occupy tile 0,0 so event will not be cancelled due to #CONDITION_POSITION
#CANCEL_POSITION= 0,0 [0,0] [1,1] [0]
}

[BillRunacre]

Thanks Steve! [:)]

[sPzAbt653]

Just saw this reference to Spain in the 'ukturkeywarning' [:)]

[Hubert Cater]

Thanks, good catch [:)]

[sPzAbt653]

Not sure if this is worth reporting as it is a unique situation and probably something I have done wrong in 653N, but I had the thought that it could be a bug in the code somewhere.

I added Canada as a Major using the blank 6th slot.
I did this because I've added a slim possibility, under limited conditions and as an option to the player, for the UK to surrender using a Surrender 2 script.

I am test running it playing the Axis against the computer Allies, and I have triggered the UK Surrender Option. The Germans have only two units scheduled to arrive by the Production Queue. When the first one arrives it is somehow now a Canadian unit? And cannot be placed. The same happens when the second unit in the queue arrives. I have had these same units set up to arrive this way for many games in the past and have never had any issue, so I imagine it has something to do with Canada being added as a Major, I guess. No idea, really.

Edit: The arrival hex, Berlin, is Axis owned.