The official --=jscam=-- thread

[NoQ]

Testing now ... Hmm, i think it should say "l.triggered" rather than "l.id" in writeLabels(), and also counter array index...

Or should it say "

Code: Select all

l.triggered = 1;
l.id = viewer->id;

" in ****LabelCheck()?[/s] Anyway, i don't have my area events triggered right now on the first level

Hmm, i guess l.id doesn't make sense for area and radius labels, it should say "l.triggered" in loadLabels() as well...

And in js_resetArea() as well... no need to have two different variables to check if the label was triggered.

Hmm, i've just noticed a mechanism to have area labels work for specific players only. I did it manually. Need to try as well.

Hmm, then i need a mechanism to set who can see a group, as well. Because group.player is already in use for a different functionality.

Hmm, almost done. I'm adding a ".subscriber" field to labels (on both json and c++ side) in AREA, RADIUS, OBJECT, GROUP labels.

Hmm, or maybe not. For groups, only eventGroupSeen is triggered, and receiveAllEvents mechanism already handles the subscribers pretty well.

[NoQ]

Emm, i'm almost ready, but still in doubt how to handle the .subscriber.

Plan A

• Leave as is - AREA and RADIUS have .player property for area events, OBJECT and GROUP have no special properties for that, but are triggered either when viewer is me or receiveAllEvents.
  
  Pros: No work needed, no compatibility breaking, works similarly to other events.
  Cons: I'd still have to receiveAllEvents in campaign, and hence the 'player==me' filter becomes useless for eventSeen.

Plan B

• Implement .subscriber property for AREA and RADIUS (for eventArea) and OBJECT and GROUP (for eventSeen). Disregard receiveAllEvents.
  
  Pros: I don't have to filter eventSeen manually.
  Cons: It sounds inconsistent to disregard receiveAllEvents, and we're breaking older label files (i already have a fix done).

[Per]

Several good finds, there. Looks like we're working on the same thing, though. And I was for a moment there really baffled about what was going on in regards to area labels not getting set, until I realized that you are resetting them automagically based on a script filter in libcampaign.

I'm not sure what the .subscriber property would do. There is already a .player property for areas and radius, but I notice that you are not using it which means that babas trigger them. And then in libcampaign, you filter those away. Isn't that unnecessary?

My latest patch attached. Fixes stuff you mentioned above, improving jsdebug display of labels, as well fixing handling overlapping areas and reporting to all players.

[vexed]

Hmm, at this point, I am wondering how to fix the performance issues, as shown in the timings post.
Those are pretty bad IMO.

[NoQ]

My latest patch attached.

Uhm, that'd be a lot of merging, because i diverged quite a bit by now.

I'm not sure what the .subscriber property would do. There is already a .player property for areas and radius, but I notice that you are not using it which means that babas trigger them. And then in libcampaign, you filter those away. Isn't that unnecessary?

Such filtering on script side is a performance overhead, and i'm trying to avoid it. I've just noticed that i can use .player property of AREA and RADIUS and eventArea, and fixed that on my side. Now, i want to do the same for OBJECT and GROUP and eventSeen, but .player property is already used for a different purpose: it doesn't make much sense for a player to have an event of seeing his own object or group. So i'm planning to introduce another property of a label, namely .subscriber, for the same purpose. Then, it'd make sense to rename this property to "subscriber" for areas as well, for consistency. And objects and groups would have both "player" and "subscriber" fields with different values and semantics. That's the motivation.

Hmm, at this point, I am wondering how to fix the performance issues, as shown in the timings post.
Those are pretty bad IMO.

I'd first try to have the script-level profiling running [1]. It's easy enough to optimize functions you mentioned, i will do that, you don't need to bother and spend valuable time on that, but still i'd rather first-profile-then-optimize.

[NoQ]

This commit is getting big, so i'd better push now and save the rest for later, i guess.

Known issues:

• I had a crash on SUB_1_1 (which is not yet converted to javascript) after transport takeoff after using jsdebug in previous missions, it seems that a stale labelModel pointer remain after deletion of the model (?)

  crash.zip

  (11.46 KiB) Downloaded 333 times

• I'm spammed with

  Code: Select all

  Log message: info    |09:43:01: [triggerEventSeen:1233] Scripts not initialized yet
  Log message: info    |09:43:01: [triggerEventSeen:1233] Assert in Warzone: qtscript.cpp:1233 (scriptsReady), last script event: 'N/A'

• If both OBJECT and GROUP labels are present on an object, eventGroupSeen is never triggered. Both events should be triggered. Causes a problem for me on CAM_1B where sensor tower on the hill is both OBJECT (to drop artifact) and GROUP (for "enemy base detected"). Do not want to fix this sort of stuff after 11pm, because callFunction() and label map are in different translation units.

[NoQ]

Groups defined in labels.json are available in all script engines. When we set .triggered for one script for the group's label, other scripts fail to receive the eventGroupSeen for this group.

I'd really like to move things around in qtscript.cpp/qtscriptfuncs.cpp/qtscriptdebug.cpp because they are interacting in a very weird way right now. All three modules need access to labels and groups and that sort of stuff, but those are static and put into just one random file out of three.

(no, e10467c doesn't fix that)

[NoQ]

Pushed some performance optimizations. Wondering if it needs more (:

[NoQ]

o_O they made invisible no-go areas in CAM_1C so that the player couldn't build on next level's NP transport landing zones.

[NoQ]

Whoops, forgot to ref 139fcd6b3a08330e47beb8d98356bb20805904d4 to the ticket #4234.

Also, it seems that people cannot comment in this ticket and attach patches; this requires some higher-level access. With my access level, i can only change ticket type from task to bug and then comment.

Spoiler:

Not that there seem to be many patches around to attach

__________

CAM_1C exposes a new issue with commanders: they may be too fast for their army. The fourth scout group being sent at you at level start consists only of tracked tanks, while its commander is on half-tracks. So the commander reaches you alone, with his army only 1/3-way there, despite being attached to the commander and controlled by it. I guess i'd have to workaround and manage the commander as an ordinary unit instead (with regrouping).

[vexed]

Whoops, forgot to ref 139fcd6b3a08330e47beb8d98356bb20805904d4 to the ticket #4234.

Also, it seems that people cannot comment in this ticket and attach patches; this requires some higher-level access. With my access level, i can only change ticket type from task to bug and then comment.

Hmm, can you try again ?

[NoQ]

Yeah, works now
________

CAM_1C is ~3/4 ready, done with labelling and setting up 10 bases and 5 factories, now need to code libcampaign support for enemy transports, and that's it.

[NoQ]

Guys. Please raise your hands if you ever noticed (before reading this post) that on CAM_1C enemy transports are coming to the LZs from random directions (not completely random though, and also flying away to a different set of random directions). Cause i really hate the idea of coding such ridiculous flexibility for the generic "incoming enemy transport" code in the library (not really hard to code, just unnecessary complication for level developers).

[montetank]

Guys. Please raise your hands if you ever noticed (before reading this post) that on CAM_1C enemy transports are coming to the LZs from random directions (not completely random though, and also flying away to a different set of random directions). Cause i really hate the idea of coding such ridiculous flexibility for the generic "incoming enemy transport" code in the library (not really hard to code, just unnecessary complication for level developers).

You are at CAM_1C? You are very diligent I cant raise my hand, because i never noticed that. You are right-i made several tests. For example-sometimes the first enemy transport came from SSE, Sometimes from SE. (I made screenshots). It is absolutely not important for the game. Why loosing time?

[NoQ]

Enemy transporters would need a bit of extra work on C++ side. In order to use startTransporterEntry(), i'd first need to addDroidToMissionList() the transporter itself, then addDroidToMissionList() all the droids inside it, then addDroidToTransporter() the droids to transporter (the transporter won't fly in at all unless it has droids inside).

Or maybe it's worth it to make a single uber-function for that... Or maybe reuse addDroid() with, say, x=y=-1 instead of making a new addDroidToMissionList() function?