The official --=jscam=-- thread

For AI and campaign script related discussions and questions
User avatar
Berserk Cyborg
Code contributor
Code contributor
Posts: 938
Joined: 26 Sep 2016, 19:56

Re: The official --=jscam=-- thread

Post by Berserk Cyborg »

From eventStartLevel do:

Code: Select all

hackAddMessage("C21_OBJECTIVE", PROX_MSG, CAM_HUMAN_PLAYER, true);
And you can then use hackRemoveMessage when at the area trigger. When you setup bases this is all automatically handled by the campaign library (cam1-c is a good reference).

for groups you could do something like this:

Code: Select all

camManageGroup(camMakeGroup("AREA"), CAM_ORDER_ATTACK, { 
     pos: camMakePos("POSITION"),
     fallback: camMakePos("POSITION2"),
     morale: 50,
     regroup: true
});
For this mission you only need pos. Search for camManageGroup in libcampaign for more information.

As for my changes I added entry and exit points for the transporter. The ally transporter is actually a structure so all I did was count how many structures the ally has when arriving at the trigger. Also CAM_HUMAN_PLAYER is defined in libcampaign.
Alpha993
Rookie
Rookie
Posts: 16
Joined: 16 Dec 2016, 15:56
Location: Italy, Cervignano del Friuli, UD

Re: The official --=jscam=-- thread

Post by Alpha993 »

So, if I understood correctly, I can feed camManageGroup with the camMakeGroup function, which will make a group of droids based on the area label I feed to it and then set them to attack and pursue enemies a certain position by feeding camManageGroup the order and position parameters.

Code: Select all

//create group of cyborgs and send them on war path
camManageGroup ( camMakeGroup("cyborgPosition"), CAM_ORDER_ATTACK, {
                            pos: camMakePos ("cyborgAttack"),
                            morale: 50,
                            regroup: true
});
Set cyborgAttack to 896, 6272.
Do I have to set up all the other groups aswell, or is the default order for a droid to guard its position based on its sensor range?
With this taken care of, I'm just left with having to fix the transferred units not being carried over to cam2b.
User avatar
Berserk Cyborg
Code contributor
Code contributor
Posts: 938
Joined: 26 Sep 2016, 19:56

Re: The official --=jscam=-- thread

Post by Berserk Cyborg »

Alpha993 wrote:Do I have to set up all the other groups aswell, or is the default order for a droid to guard its position based on its sensor range?
I think the 2-1 level only has that one group. You could look for other droids and make them groups if you want to. And if a droid is not in a group then it will stay where it is at until an enemy comes near it.

Edit:
MB2A_MSG in https://github.com/Warzone2100/warzone2 ... rief2a.txt points to the wrong video sequence (should be c002.ogg). But plays cam2intb.ogg after it which is a repeat of the last few seconds in c002. Any documentation on editing these?
Nevermind, I found a way to disable the second video. I will start one 2-2 and related sub-missions next.
Alpha993
Rookie
Rookie
Posts: 16
Joined: 16 Dec 2016, 15:56
Location: Italy, Cervignano del Friuli, UD

Re: The official --=jscam=-- thread

Post by Alpha993 »

Is there a way of making a group with specific droids whose ID is known?
User avatar
Berserk Cyborg
Code contributor
Code contributor
Posts: 938
Joined: 26 Sep 2016, 19:56

Re: The official --=jscam=-- thread

Post by Berserk Cyborg »

Alpha993 wrote:Is there a way of making a group with specific droids whose ID is known?
Try camMakeGroup: http://buildbot.wz2100.net/files/javasc ... tml#sec198
Use object labels and just make an array of droids.

example object label:
"object_0": { "label": "droid", "id": X, "player": 2, "type": 0 }
Alpha993
Rookie
Rookie
Posts: 16
Joined: 16 Dec 2016, 15:56
Location: Italy, Cervignano del Friuli, UD

Re: The official --=jscam=-- thread

Post by Alpha993 »

So something like initializing 5 variables, use getObject to assign them a droid,then DroidArray.Push(droid1) and so on to add them to the array and then feed that to camMakeGroup()?
Per
Warzone 2100 Team Member
Warzone 2100 Team Member
Posts: 3780
Joined: 03 Aug 2006, 19:39

Re: The official --=jscam=-- thread

Post by Per »

Alpha993 wrote:Is there a way of making a group with specific droids whose ID is known?
Use groupAdd(groupId, object) where groupId is some number that you reserve for your new group. Just make sure no other code uses that Id, and you should be good.
User avatar
Berserk Cyborg
Code contributor
Code contributor
Posts: 938
Joined: 26 Sep 2016, 19:56

Re: The official --=jscam=-- thread

Post by Berserk Cyborg »

Almost done with 2-2. Now the Collective commander can finally escape instead of mindlessly driving into a building. I will do 2-C next.
User avatar
NoQ
Special
Special
Posts: 6226
Joined: 24 Dec 2009, 11:35
Location: /var/zone

Re: The official --=jscam=-- thread

Post by NoQ »

I had a thought regarding the relatively recent eventVideoDone discussion. It should have more libcampaign support, ideally we should provide a function like this:

Code: Select all

function eventStartLevel() {

    // Calls `hackAddMessage("MB1D_MSG", MISS_MSG, CAM_HUMAN_PLAYER, true);` instantly.
    // Or maybe not instantly, if there are already videos in the playlist.
    // Calls `hackAddMessage("MB1D_MSG2", MISS_MSG, CAM_HUMAN_PLAYER, true);` on the next eventVideoDone.
    // Support as many arguments as necessary, maybe pass the list of videos as an array if you prefer that.

    camEnqueueVideo("MB1D_MSG", "MB1D_MSG2");

}
In order to make this work, you'd have to let libcampaign subscribe to eventVideoDone and pop items from some "playlist" variable one by one (while the new function populates the playlist). While doing so, you shouldn't break the possibility to subscribe to eventVideoDone from within the level code as well, as the user may want to make other actions there. Which is why we use javascript hooks in libcampaign to subscribe to events, implemented by __camPreHookEvent(). We already use this for a lot of things, like detecting artifact pickup, or tracking transporter movements.

This way we also prevent the level author from calling a "hack"-prefixed function.

Anybody likes this idea? :hmm:
User avatar
Berserk Cyborg
Code contributor
Code contributor
Posts: 938
Joined: 26 Sep 2016, 19:56

Re: The official --=jscam=-- thread

Post by Berserk Cyborg »

I like that idea. It would make calling videos a bit easier. I did something similar to what you outlined for levels that need multiple video calls (without interruption) by placing the messages in an array and calling them with an index incremented after each video plays.

I have not been working on the scripts lately, but do you think it would be best to add enemy vtol attack/run away support to libcampaign for Beta and Gamma? Otherwise each level that needs them will get bloated with repetitive code.

And speaking of campaign hooks I have noticed that a lot of reports such as ticket #4552 are showing levels getting errors after loading saves. This can prevent a level from being able to be completed in some cases. An easy reproducible bug is merely saving in 1-C and loading and a report similar to the ticket above will happen.
User avatar
NoQ
Special
Special
Posts: 6226
Joined: 24 Dec 2009, 11:35
Location: /var/zone

Re: The official --=jscam=-- thread

Post by NoQ »

I have not been working on the scripts lately, but do you think it would be best to add enemy vtol attack/run away support to libcampaign for Beta and Gamma? Otherwise each level that needs them will get bloated with repetitive code.
Definitely. The whole point of libcampaign is core reuse between levels. There's essentially no bigger thought behind it. Just try to reach parity between the amount of code and the amount of thought put into the level.
And speaking of campaign hooks I have noticed that a lot of reports such as ticket #4552 are showing levels getting errors after loading saves. This can prevent a level from being able to be completed in some cases. An easy reproducible bug is merely saving in 1-C and loading and a report similar to the ticket above will happen.
Well, it used to work back when i tested that. Savegame format is not powerful enough to store complex javascript objects (anything more complex than simple structures), so saving hooked functions cannot work, however hooks should be blindly reapplied upon reload.
User avatar
vexed
Inactive
Inactive
Posts: 2538
Joined: 27 Jul 2010, 02:07

Re: The official --=jscam=-- thread

Post by vexed »

Hey, I know most of the devs are busy with real life stuff, but, I am wondering, before any commits go on, how exactly all this should be tested?

Do we have volunteers that can test these changes before they go into the main repo?
If not, are the campaigns being changed at all, or is it more or less a direct port from the original source files?
Has anything been verified between how 3.1.x's levels vs what it is done now?
What I worry about the most is performance issues, and the campaigns not being as they originally were.

In fact, those of you that are doing the conversion, you can make .wz files of the changes, and people can test them that way (via the override method), since, those don't require code changes since the last release, right?
Then we can have this thread to report any issues as well, and we can get that much needed testing started before we do any commits in the main repo.


Really sorry can't help more right now, but I am swamped with work. :(
/facepalm ...Grinch stole Warzone🙈🙉🙊 contra principia negantem non est disputandum
Super busy, don't expect a timely reply back.
User avatar
Berserk Cyborg
Code contributor
Code contributor
Posts: 938
Joined: 26 Sep 2016, 19:56

Re: The official --=jscam=-- thread

Post by Berserk Cyborg »

It would be best, in my opinion, to get a bunch of volunteers to test the whole Alpha campaign at the moment. I try to make everything more or less the same so not much will be different (unless I happen to mess something up or the original scripts do not do what they were meant to). So yes, just porting is going on.

3.1 and 3.2 are the same except 3.2 has missing video sequences/audio files with some levels in Beta/Gamma and enemy unit production is broken (or some levels are just completely broken to begin with).

I packed all my changes from my campaignJS branch into this .wz file for campaign:
Updated-Campaign.wz
Edit: Updated mod file version #3.
-Beta 2-1/2-C.
Last edited by Berserk Cyborg on 19 Mar 2017, 20:20, edited 3 times in total.
User avatar
vexed
Inactive
Inactive
Posts: 2538
Joined: 27 Jul 2010, 02:07

Re: The official --=jscam=-- thread

Post by vexed »

Actually, windows & linux testers can get the builds from buildbot located here: http://buildbot.wz2100.net/files/master/

Then they can be up to date with master.

I'll do an announcement shorty to drive more traffic to this thread.
/facepalm ...Grinch stole Warzone🙈🙉🙊 contra principia negantem non est disputandum
Super busy, don't expect a timely reply back.
User avatar
Berserk Cyborg
Code contributor
Code contributor
Posts: 938
Joined: 26 Sep 2016, 19:56

Re: The official --=jscam=-- thread

Post by Berserk Cyborg »

I have added some basic vtol attack and run away support to the campaign library. Thus making 2-A ready for testing. Probably can be improved more. I also updated the campaign enemy templates for every remaining mission (the ones that are used) so future coordination is easier.
Post Reply