The official --=jscam=-- thread

For AI and campaign script related discussions and questions

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

Postby Berserk Cyborg » 31 Dec 2016, 19:34

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.
Berserk Cyborg
Code contributor
Code contributor
 
Posts: 125
Joined: 26 Sep 2016, 19:56

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

Postby Alpha993 » 31 Dec 2016, 20:39

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.
Alpha993
Rookie
Rookie
 
Posts: 16
Joined: 16 Dec 2016, 15:56
Location: Italy, Cervignano del Friuli, UD

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

Postby Berserk Cyborg » 31 Dec 2016, 21:20

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/warzone2100/blob/master/data/base/messages/brief2a.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.
Berserk Cyborg
Code contributor
Code contributor
 
Posts: 125
Joined: 26 Sep 2016, 19:56

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

Postby Alpha993 » 03 Jan 2017, 17:06

Is there a way of making a group with specific droids whose ID is known?
Alpha993
Rookie
Rookie
 
Posts: 16
Joined: 16 Dec 2016, 15:56
Location: Italy, Cervignano del Friuli, UD

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

Postby Berserk Cyborg » 03 Jan 2017, 21:50

Alpha993 wrote:Is there a way of making a group with specific droids whose ID is known?

Try camMakeGroup: http://buildbot.wz2100.net/files/javascript/javascript007.html#sec198
Use object labels and just make an array of droids.

example object label:
"object_0": { "label": "droid", "id": X, "player": 2, "type": 0 }
Berserk Cyborg
Code contributor
Code contributor
 
Posts: 125
Joined: 26 Sep 2016, 19:56

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

Postby Alpha993 » 03 Jan 2017, 23:26

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()?
Alpha993
Rookie
Rookie
 
Posts: 16
Joined: 16 Dec 2016, 15:56
Location: Italy, Cervignano del Friuli, UD

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

Postby Per » 04 Jan 2017, 02:07

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.
Per
Warzone 2100 Team Member
Warzone 2100 Team Member
 
Posts: 3561
Joined: 03 Aug 2006, 19:39

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

Postby Berserk Cyborg » 09 Jan 2017, 03:33

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.
Berserk Cyborg
Code contributor
Code contributor
 
Posts: 125
Joined: 26 Sep 2016, 19:56

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

Postby NoQ » 25 Jan 2017, 12:07

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
NoQ
Special
Special
 
Posts: 6042
Joined: 24 Dec 2009, 11:35
Location: /var/zone

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

Postby Berserk Cyborg » 25 Jan 2017, 18:49

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.
Berserk Cyborg
Code contributor
Code contributor
 
Posts: 125
Joined: 26 Sep 2016, 19:56

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

Postby NoQ » 26 Jan 2017, 12:38

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
NoQ
Special
Special
 
Posts: 6042
Joined: 24 Dec 2009, 11:35
Location: /var/zone

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

Postby vexed » 30 Jan 2017, 00:02

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
vexed
Inactive
Inactive
 
Posts: 2385
Joined: 27 Jul 2010, 02:07

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

Postby Berserk Cyborg » 30 Jan 2017, 01:02

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
Requires Git Master
(24.83 KiB) Downloaded 48 times


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.
Berserk Cyborg
Code contributor
Code contributor
 
Posts: 125
Joined: 26 Sep 2016, 19:56

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

Postby vexed » 05 Feb 2017, 04:34

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
vexed
Inactive
Inactive
 
Posts: 2385
Joined: 27 Jul 2010, 02:07

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

Postby Berserk Cyborg » 05 Feb 2017, 07:47

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.
Berserk Cyborg
Code contributor
Code contributor
 
Posts: 125
Joined: 26 Sep 2016, 19:56

PreviousNext

Return to Scripting