The official --=jscam=-- thread

[NoQ]

BTW, major performance hit on this mission...

Hmm, i'm not noticing anything. Runs smoothly with 100 units (the current limit, takes 20 minutes to transport here).

Made me have a look at the performance monitor, anyway. The only thing i'm having above performance limits is the two hackAddMessage() calls. I may have a look at the tactics function (and victory condition function), but so far even that doesn't seem to be very heavy.

Unlike AI scripts, we can afford 10x larger max lag values here, because only one instance of the script is running.

Code: Select all

=== PERFORMANCE DATA ===
    160 calls     0ms avg     0ms worst       0 over limit       0 over half limit eventDestroyed()
      1 calls     1ms avg     1ms worst       0 over limit       0 over half limit eventTransporterExit()
      1 calls     0ms avg     0ms worst       0 over limit       0 over half limit camCallOnce()
      3 calls     0ms avg     1ms worst       0 over limit       0 over half limit __camContinueProduction()
      1 calls     2ms avg     2ms worst       0 over limit       0 over half limit eventAreaScavTrigger()
      1 calls     1ms avg     1ms worst       0 over limit       0 over half limit eventCheatMode()
      2 calls     0ms avg     0ms worst       0 over limit       0 over half limit __camSetOffworldLimits()
      1 calls     0ms avg     0ms worst       0 over limit       0 over half limit sendScouts()
      1 calls    56ms avg    56ms worst       1 over limit       0 over half limit playYouAreInContraventionOfTheNewParadigm()
     13 calls     0ms avg     1ms worst       0 over limit       0 over half limit eventAreaNPTrigger()
     23 calls     0ms avg     1ms worst       0 over limit       0 over half limit eventObjectSeen()
    345 calls     3ms avg    15ms worst       0 over limit       2 over half limit __camTick()
      1 calls     6ms avg     6ms worst       0 over limit       0 over half limit eventStartLevel()
    120 calls     0ms avg     2ms worst       0 over limit       0 over half limit eventGroupLoss()
     13 calls     2ms avg     9ms worst       0 over limit       0 over half limit __camTacticsTick()
      1 calls    21ms avg    21ms worst       1 over limit       0 over half limit playNPWarningMessage()
      9 calls     0ms avg     0ms worst       0 over limit       0 over half limit eventAreaRemoveBeacon()
    455 calls     0ms avg     1ms worst       0 over limit       0 over half limit eventAttacked()
    208 calls     0ms avg     1ms worst       0 over limit       0 over half limit eventAreaNorthConvoyTrigger()
      1 calls     1ms avg     1ms worst       0 over limit       0 over half limit eventAreaSouthConvoyTrigger()
      9 calls     0ms avg     1ms worst       0 over limit       0 over half limit eventPickup()
      1 calls     1ms avg     1ms worst       0 over limit       0 over half limit eventAreaWestConvoyTrigger()
    103 calls     0ms avg     1ms worst       0 over limit       0 over half limit eventDroidBuilt()
     20 calls     0ms avg     1ms worst       0 over limit       0 over half limit eventChat()
      1 calls     0ms avg     0ms worst       0 over limit       0 over half limit playNPWarningSound()

Btw, i can commit this more pretty performance monitor format.

[NoQ]

Done with SUB_1_3, now we have sorta-formation-movement (regroup = true) and commander support (pushed vexed's patch as-is, seemed good enough).

Will become a bit less active now, from the next week, so anybody would have a chance to catch up with the changes (:

[NoQ]

A few discussion topics. Easy to implement, hard to decide.

1. Difficulty-based time limits. What i have in mind is: NORMAL (default) would have the classic time limit, EASY would have around 1.5x more time (ridiculously easy), HARD would have around 0.5x time (whenever applicable). Probably a fourth difficulty level, INSANE, is worth it, along the lines of [1] (barely beatable mode for strong players).
   
   Currently difficulty is implemented through
   • +/-20% droid damage for human and AI.
   • +/-10% power income for human only.
   And i like none of those because they're not obvious, nobody would really notice such tweaks and have no clue what the option does. Time limits are obvious though.
2. Beta-1 and Gamma-1 levels have weird reinforcements arriving, as you noticed: when you run out of your own units to evacuate, some python heavy cannon tanks etc. start arriving by transport, with thousands of experience. So it's pointless to accumulate experience, when you can have 30 hero units for free on these levels (and one or two is enough as long as you use commanders, which you should do). On the other hand, since we now allow starting the game directly from Beta or Gamma campaign, we should be given some units at start.
   
   So, should this "feature" be removed? Should experience of these units be decreased?

[Ranger]

For me having a time limit on every map is somewhere between weird and nasty. Sure, time limit on a map where 'that nuke is gonna blow, run for your life' makes sense, but everywhere? Besides the mechanic of finishing the map early, then idling to milk the map until timer runs out might use some rethinking .

[vexed]

(pushed vexed's patch as-is, seemed good enough).

Erm, didn't really intend that patch to go in 'as is'. It has a craptastic commit message.

Code: Select all

=== PERFORMANCE DATA ===
    calls | avg ms | worst ms | worst ms at | >=limit | >=limit/2 | function
       14 |      0 |        7 |      150904 |       0 |         0 | eventAreaWestConvoyTrigger
      559 |      0 |       67 |       96904 |       1 |         0 | __camBasesTick
        1 |      3 |        3 |       41704 |       0 |         0 | eventCheatMode
      560 |      0 |       14 |       42704 |       0 |         1 | __camTick
      136 |      0 |        1 |      348504 |       0 |         0 | eventAreaNorthConvoyTrigger
        1 |     12 |       12 |      128404 |       0 |         1 | eventAreaScavTrigger
       32 |      0 |       17 |      210604 |       0 |         1 | eventAreaSouthConvoyTrigger
        9 |      0 |        3 |      332804 |       0 |         0 | eventPickup
        2 |      0 |        1 |       41804 |       0 |         0 | __camSetOffworldLimits
      102 |      0 |       19 |      346604 |       0 |         1 | eventGroupLoss
      250 |      0 |       20 |      133104 |       0 |         1 | eventAttacked
        8 |      0 |        2 |      168404 |       0 |         0 | __camContinueProduction
       13 |      0 |        2 |      131304 |       0 |         0 | eventObjectSeen
        1 |      1 |        1 |       44704 |       0 |         0 | playNPWarningSound
        1 |      4 |        4 |      101704 |       0 |         0 | sendScouts
        1 |     89 |       89 |       41704 |       1 |         0 | eventStartLevel
        1 |     17 |       17 |       46704 |       0 |         1 | playNPWarningMessage
        1 |     18 |       18 |      349104 |       0 |         1 | playYouAreInContraventionOfTheNewParadigm
       15 |      0 |        5 |       61604 |       0 |         0 | eventChat
      577 |     11 |       70 |      409804 |      58 |       231 | __camTacticsTick
        1 |      2 |        2 |       97904 |       0 |         0 | camCallOnce
      162 |      0 |        4 |      527004 |       0 |         0 | eventDestroyed
       97 |      0 |        2 |      468004 |       0 |         0 | eventAreaNPTrigger
       15 |      0 |        5 |      102704 |       0 |         0 | eventAreaRemoveBeacon
       16 |      1 |        7 |      138804 |       0 |         0 | eventDroidBuilt
        1 |      2 |        2 |       53504 |       0 |         0 | eventTransporterExit

Anything that takes more than 8-10ms is too much IMO, with basically the 4 units you start off with.

A few discussion topics. Easy to implement, hard to decide.

1. Difficulty-based time limits. What i have in mind is: NORMAL (default) would have the classic time limit, EASY would have around 1.5x more time (ridiculously easy), HARD would have around 0.5x time (whenever applicable). Probably a fourth difficulty level, INSANE, is worth it, along the lines of [1] (barely beatable mode for strong players).
   
   Currently difficulty is implemented through
   • +/-20% droid damage for human and AI.
   • +/-10% power income for human only.
   And i like none of those because they're not obvious, nobody would really notice such tweaks and have no clue what the option does. Time limits are obvious though.
2. Beta-1 and Gamma-1 levels have weird reinforcements arriving, as you noticed: when you run out of your own units to evacuate, some python heavy cannon tanks etc. start arriving by transport, with thousands of experience. So it's pointless to accumulate experience, when you can have 30 hero units for free on these levels (and one or two is enough as long as you use commanders, which you should do). On the other hand, since we now allow starting the game directly from Beta or Gamma campaign, we should be given some units at start.
   
   So, should this "feature" be removed? Should experience of these units be decreased?

Hmm, for 1)While you could use time as a factor, I also think that spawn times should play a role. The harder you make it, the quicker they build units (and/or group them up with bigger waves).

For 2) The reinforcements for those were always a cheat, in that, you could only make that happen if you jump start into CAM_2A or CAM_3A. Since you would have started off with basically nothing if they didn't do that.
Now that, that is more easily available, we should just make the units have no rank.
If people want full benefits, they should play all the way through the campaign from start.

Also, the artifact detection covers a too wide area IMO. I rather have it so it actually looks like your unit is going to pick it up, instead of being able to get it from 2-3 units away from the artifact.

[Goth Zagog-Thou]

I'm reading the source code on Github (qtscriptfuncs.cpp) .. was this the recommended reading for checking where things were in regards to the current status of the JS API?

And the Buildbot is outputting Portable versions of Master. Was this intended?

[NoQ]

Erm, didn't really intend that patch to go in 'as is'. It has a craptastic commit message.

Whoops sorry Was hurrying to commit the whole level before the end of weekend.

Code: Select all

    calls | avg ms | worst ms | worst ms at | >=limit | >=limit/2 | function
      577 |     11 |       70 |      409804 |      58 |       231 | __camTacticsTick

Hmm, that's A LOT of lag. I cannot reproduce that though, even with 100 units on my side. And since your CPU can't be 800MHz, i keep suspecting that there's something OS-specific in this It should be easy to improve performance of this function, but i'd also love to see an explanation. Probably we need a more low-level profile, with API functions included... I can try to implement that sort of profiling. Because it's one of the few actually important issues we're having

The harder you make it, the quicker they build units (and/or group them up with bigger waves).

This should also be easy to implement.

Also, the artifact detection covers a too wide area IMO. I rather have it so it actually looks like your unit is going to pick it up, instead of being able to get it from 2-3 units away from the artifact.

Yeah, it's even possible to pick them up from the other side of a wall (not through cliffs though). But it's not script problem, it's everywhere, including oil drums in skirmish.

Now that, that is more easily available, we should just make the units have no rank.
If people want full benefits, they should play all the way through the campaign from start.

Yeah, thinking the same thing.

was this the recommended reading for checking where things were in regards to the current status of the JS API?

It's recommended when you encounter a bug, or just before you encounter one, i.e. make sure a new untested function you're about to use works as intended (:

[Goth Zagog-Thou]

Thanks NoQ. Just making sure.

[NoQ]

I've got an idea. Why don't we use QElapsedTimer for performance measurements, as it was designed to do that (using monotonic real-time clock, etc.) I blindly suspect that QTime might be doing some context-switching on some systems (?) Because 10msec might just be the normal time quantum of thread-switching on Windows, or something like that (??) edit: Yay, we can also use nano-second precision, kinda ... though microseconds should be enough.

• QElapsedTimer.patch

  (2.71 KiB) Downloaded 258 times

Here's my profile with 100 units and QElapsedTimer.

Code: Select all

    calls | avg (usec) | worst (usec) | worst call at | >=limit | >=limit/2 | function
        9 |         53 |          244 |         73104 |       0 |         0 | eventAreaRemoveBeacon
       41 |         33 |          275 |        168504 |       0 |         0 | eventAreaNPTrigger
        1 |        201 |          201 |         95504 |       0 |         0 | camCallOnce
        1 |        888 |          888 |        104404 |       0 |         0 | eventAreaSouthConvoyTrigger
        2 |         59 |          101 |         17404 |       0 |         0 | __camSetOffworldLimits
      319 |         30 |          442 |         94504 |       0 |         0 | __camBasesTick
       23 |         25 |          162 |         75104 |       0 |         0 | eventObjectSeen
        1 |        116 |          116 |         29204 |       0 |         0 | eventTransporterExit
      335 |       3403 |        12782 |        315404 |       0 |         5 | __camTacticsTick
        1 |        795 |          795 |         17304 |       0 |         0 | eventCheatMode
        1 |       5790 |         5790 |         17304 |       0 |         0 | eventStartLevel
        1 |      45884 |        45884 |        108004 |       1 |         0 | playYouAreInContraventionOfTheNewParadigm
        5 |        101 |          113 |        123904 |       0 |         0 | __camContinueProduction
      320 |        207 |         1386 |        299304 |       0 |         0 | __camTick
        1 |        834 |          834 |         83904 |       0 |         0 | eventAreaScavTrigger
       99 |         60 |         2303 |        159504 |       0 |         0 | eventGroupLoss
        9 |        112 |          408 |        158904 |       0 |         0 | eventPickup
        1 |        112 |          112 |         20304 |       0 |         0 | playNPWarningSound
       20 |         68 |          260 |         31304 |       0 |         0 | eventChat
        1 |       1196 |         1196 |         72104 |       0 |         0 | eventAreaWestConvoyTrigger
      105 |         12 |          303 |         94304 |       0 |         0 | eventDroidBuilt
        1 |        131 |          131 |         77304 |       0 |         0 | sendScouts
        1 |      21969 |        21969 |         22304 |       1 |         0 | playNPWarningMessage
      135 |         17 |           71 |        160504 |       0 |         0 | eventAreaNorthConvoyTrigger
      603 |         13 |          324 |        106004 |       0 |         0 | eventAttacked
      177 |         16 |          172 |        144904 |       0 |         0 | eventDestroyed

edit: and also there's this thing called QScriptEngineAgent, with which we can do more precise profiling.

[Per]

Patch looks fine to me.

[vexed]

Code: Select all

=== PERFORMANCE DATA ===
    calls | avg (usec) | worst (usec) | worst call at | >=limit | >=limit/2 | function
        1 |       2856 |         2856 |         38004 |       0 |         0 | eventCheatMode
        1 |     176222 |       176222 |         38004 |       1 |         0 | eventStartLevel
        1 |       1463 |         1463 |         49704 |       0 |         0 | eventTransporterExit
      135 |        108 |         1101 |         98204 |       0 |         0 | eventAreaNorthConvoyTrigger
      418 |         99 |          810 |        102404 |       0 |         0 | eventAreaSouthConvoyTrigger
        3 |        645 |         1323 |        109904 |       0 |         0 | eventAreaNPTrigger
      190 |       4231 |        43534 |        171004 |       7 |        14 | __camTick
      120 |        444 |        36349 |         97204 |       1 |         0 | eventGroupLoss
      191 |         88 |         2586 |         82604 |       0 |         0 | eventAttacked
        1 |       7720 |         7720 |         72504 |       0 |         0 | eventAreaScavTrigger
        2 |       3456 |         4591 |         82904 |       0 |         0 | eventDroidBuilt
        1 |       1037 |         1037 |         81404 |       0 |         0 | camCallOnce
        1 |      18603 |        18603 |        107404 |       0 |         1 | playYouAreInContraventionOfTheNewParadigm
      127 |         95 |          282 |         98204 |       0 |         0 | eventAreaWestConvoyTrigger
        1 |       2198 |         2198 |         41004 |       0 |         0 | playNPWarningSound
        1 |      16334 |        16334 |         43004 |       0 |         1 | playNPWarningMessage
      127 |        134 |         1275 |         91704 |       0 |         0 | eventDestroyed
        1 |       4067 |         4067 |         98004 |       0 |         0 | sendScouts
        2 |        390 |          717 |         38104 |       0 |         0 | __camSetOffworldLimits
        2 |        852 |         1204 |        165404 |       0 |         0 | __camContinueProduction
      200 |      15767 |        84744 |        119104 |      63 |        41 | __camTacticsTick
       24 |        590 |        12056 |         80404 |       0 |         1 | eventObjectSeen
        6 |       1367 |         3228 |         92304 |       0 |         0 | eventPickup
       25 |         77 |          246 |         98204 |       0 |         0 | eventAreaRemoveBeacon
      189 |        235 |         2209 |         54204 |       0 |         0 | __camBasesTick

And, my CPU is a quad core, 4GHz.

Oh, got some more bugs, but first, I would like to ask, just how are you tracing script code these days, is it just throwing debugs into the code, or something else ?

Code: Select all

>	Warzone2100-Dbg.exe!removeStruct(STRUCTURE * psDel, bool bDestroy) Line 4574	C++
 	Warzone2100-Dbg.exe!destroyStruct(STRUCTURE * psDel, unsigned int impactTime) Line 4718	C++
 	Warzone2100-Dbg.exe!js_removeObject(QScriptContext * context, QScriptEngine * __formal) Line 2122	C++
 	Qt5Scriptd.dll!0f343e09()	Unknown

Ick.

As for the bugs, on sub1-3s (well, actually, I assume this happens on all levels, but, it is easier to trigger on this one) it seems that __camCheckBaseEliminated(group) is being called way too late, and is using a stale list of entries, thus causing issues.

More specifically, you assume that a person will always destroy a base, instead of running into the base, getting the needed artifact, and getting out of dodge.

Code: Select all

		if (camDef(bi.cleanup))
		{
			var leftovers = enumArea(bi.cleanup);
			for (var i = 0; i < leftovers.length; i++)
			{
				obj = leftovers[i];
				if (__camIsValidLeftover(obj))
				{
					// remove with special effect
					camSafeRemoveObject(obj, true);
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Since the game already cleaned up everything, the script then tries to cleanup again... (turn on LOG_DEATH, and you will see it tries to remove the same structures)
Also, it seems the lose condition is incorrect, if you lose, and continue, it will pop up the ending screen again. So, once this is triggered, it shouldn't be triggered again and again.
Oh, that reminds me of something else, the radar can't be seen, if you don't make the HQ first, then go to an offworld mission, then come back, and build the HQ, you won't get the radar.

The other bug, I'll commit a patch.

And the Buildbot is outputting Portable versions of Master. Was this intended?

Yes.

[NoQ]

Code: Select all

    calls | avg (usec) | worst (usec) | worst call at | >=limit | >=limit/2 | function
      200 |      15767 |        84744 |        119104 |      63 |        41 | __camTacticsTick

Uhm, still uhm. Is there anybody here who could check this on both linux and windows on the same machine?

Also, it seems the lose condition is incorrect, if you lose, and continue, it will pop up the ending screen again. So, once this is triggered, it shouldn't be triggered again and again.

Emm, i think i once fixed that and then broken again. But in any case, it wasn't working well even when i fixed it (the screen didn't reappear again, but nothing sensible happened anyway)

Oh, that reminds me of something else, the radar can't be seen, if you don't make the HQ first, then go to an offworld mission, then come back, and build the HQ, you won't get the radar.

That's because rules.js is not loaded on wzscript levels [1].
I'm fixing it along with converting levels.

Code: Select all

>   Warzone2100-Dbg.exe!removeStruct(STRUCTURE * psDel, bool bDestroy) Line 4574   C++
    Warzone2100-Dbg.exe!destroyStruct(STRUCTURE * psDel, unsigned int impactTime) Line 4718   C++
    Warzone2100-Dbg.exe!js_removeObject(QScriptContext * context, QScriptEngine * __formal) Line 2122   C++
    Qt5Scriptd.dll!0f343e09()   Unknown

Hmm. I think i've seen such crashes once in a while. From your investigation, i understand that it happens when you finish the level, then game cleans up everything on the map automatically (without the script knowing), but then something weird happens on script callbacks on destruction of things. If this is the case, i suspect the proper solution would be to shut down all scripts before automatic cleanup at end of level (?) Anyway, i can try to fix it on the script side.

5496352 Don't allow the transporter to get oil (or any other feature) on campaign games.

Code: Select all

if ((game.type == CAMPAIGN) && ...) {
    checkLocalFeatures(psDroid);
}

Emm, now i cannot pick up things at all in skirmish

Oh, got some more bugs, but first, I would like to ask, just how are you tracing script code these days, is it just throwing debugs into the code, or something else ?

There is plenty of debug() prints around the code, wrapped in camTrace() to get turned on only when you enable cheats. You can add your own traces of course (and keep them around if found useful and don't spam too much) (and probably create special cheats to activate more prints if they are both useful and spammy). There's also jsdebug.

[vexed]

D'oh....
Will fix another way, actually... will clean up as well.
I'll make a ticket.

[NoQ]

Meanwhile, i noticed that wz campaign often has circle area labels - something like "droidInRange(x,y,radius)" as event trigger. I wonder if it's worth it to have an extra sort of labels to support this (with support for hackMarkTiles and eventArea, and probably enumArea). Because approximating circles with rectangles doesn't work very well.

[Per]

Meanwhile, i noticed that wz campaign often has circle area labels - something like "droidInRange(x,y,radius)" as event trigger. I wonder if it's worth it to have an extra sort of labels to support this (with support for hackMarkTiles and eventArea, and probably enumArea). Because approximating circles with rectangles doesn't work very well.

I did a quick implementation of circles, and I was struck by how little difference there was in practice between squares and circles. Maybe it should not come as a surprise, really, since our tiles are quite big... Attached patch also contains the triggered changes posted earlier.