The official --=jscam=-- thread

For AI and campaign script related discussions and questions
Post Reply
User avatar
NoQ
Special
Special
Posts: 6187
Joined: 24 Dec 2009, 11:35
Location: /var/zone

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

Post by NoQ » 03 Nov 2014, 06:57

Goth Zagog-Thou wrote:Go ahead and take over Mission 3 in my stead, NoQ. You're moving along at a far better pace than I am. :(
Don't worry about me. I'm not going to run out of missions any time soon (:

User avatar
NoQ
Special
Special
Posts: 6187
Joined: 24 Dec 2009, 11:35
Location: /var/zone

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

Post by NoQ » 03 Nov 2014, 10:59

Per wrote:You should be able to set LZ_COMPROMISED_TIME by giving setReinforcementTime() a value of 999999 (defined as SCR_LZ_COMPROMISED_TIME in C++). This value should obviously have been defined as a constant in qtscriptfuncs.cpp already. Feel free to fix :)
I think i finally figured out what is it good for. It displays "--:--" instead of just hiding the interface, seems to be the only difference. Pushed.

Per
Warzone 2100 Team Member
Warzone 2100 Team Member
Posts: 3753
Joined: 03 Aug 2006, 19:39

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

Post by Per » 03 Nov 2014, 22:11

I always thought tutorial and fastplay really were campaigns. Just much smaller ones.

User avatar
NoQ
Special
Special
Posts: 6187
Joined: 24 Dec 2009, 11:35
Location: /var/zone

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

Post by NoQ » 04 Nov 2014, 06:38

Yeah, good point, btw. Now i think that Tutorial is a campaign (and should be done as such technically), and Fastplay is a challenge mission (and should be done as such technically).

Fastplay actually contradicts the original campaign (plot-wise), so even though it looks similar, i think it's not a good idea to put it into the campaign menu.
_____

I'm thinking about cam*daynight.slo and stuff. First of all, i'm still unsure why the fog is broken, i keep missing this discussion. This script slowly fades the fog color in or out, emulating day and night. Then, if it cannot be restored, then probably we could try out different skybox images... But fading would be a problem. Also we have setSunIntensity and setSunPosition, probably worth having a look.

User avatar
NoQ
Special
Special
Posts: 6187
Joined: 24 Dec 2009, 11:35
Location: /var/zone

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

Post by NoQ » 04 Nov 2014, 10:20

A little demo.
Forum attachment preview doesn't handle incrementally animated gifs, hence external link.

Code: Select all

// rules.js

var a = 0.0;
function updateSun()
{
	var s = Math.sin(a);
	var c = Math.cos(a);
	var c1 = (1.0 + c) / 2;
	var h = (c1 > 0.3) ? c1 : -0.3;
	var i = (c1 > 0.3) ? 0.3 + 0.7 * c1 : 0.51;
	setSunPosition(s, -h, c);
	setSunIntensity(
		i, i, i,
		0.8, 0.8, 0.8,
		1.0, 1.0, 1.0
	);
	a += 0.1;
}

setTimer("updateSun", 100);
Not sure if we really want that, considering that terrain isn't re-lighted, and shadows are ugly in most directions, and also shadows don't fade out, and keep appearing in the air when sun is below ground, and why is y looking downwards anyway?...

User avatar
NoQ
Special
Special
Posts: 6187
Joined: 24 Dec 2009, 11:35
Location: /var/zone

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

Post by NoQ » 04 Nov 2014, 16:33

Does anybody have 2.3.9 (or earlier) running, in order to explain how does New Paradigm AI behaves in SUB_1_3?

On 3.1.1, it starts with throwing three minipods into attack, then throws newly produced units into attack one by one, without any grouping, while keeping commander with hmg and med cannon tanks in defense. The "without any grouping" part contradicts my memories of walkthrough-making, but i no longer have libvorbis outdated enough to compile 2.3.9.

*watching the video* Hmm, maybe it's really that weird.

*reading the code* Hmm, no, there seems to be some code that does something else.

Anyway, SUB_1_3 is started now, but not yet ready for commit. Frankly, maturity of libcampaign.js (i don't add much stuff here on this level, only support for AI repair facilities at most) does not really make conversion faster: most of the time is still spent in understanding the original script, and that's where help is really most wanted (:

User avatar
vexed
Inactive
Inactive
Posts: 2461
Joined: 27 Jul 2010, 02:07

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

Post by vexed » 05 Nov 2014, 04:09

I don't recall this exact mission, however, I do know that some parts of the campaign are broken (or made much more easier) because of the removal of the formation code.
Not quite sure how to solve that, if we are going for a 1:1 port of what they did.
I don't think we have a group command available where they protect the main unit. :hmm:
/facepalm ...Grinch stole Warzone🙈🙉🙊 contra principia negantem non est disputandum
Super busy, don't expect a timely reply back.

User avatar
NoQ
Special
Special
Posts: 6187
Joined: 24 Dec 2009, 11:35
Location: /var/zone

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

Post by NoQ » 05 Nov 2014, 06:11

Eureka!! Formation movement. This might be it. All the pieces come together now. Look.

We are not doing a 1:1 port in terms of code; in fact, we're trying to mimic the existing behavior with completely different code, which would be more stable and sensible, with clearer abstractions for common patterns. So far it seems that the necessary amount of accuracy can be achieved.

And whenever we notice a change in campaign between 1.x and 3.1.x, we have a chance to prioritize implementing the old version's behavior, and i believe this is what we should certainly try to do.

Now, as we are talking about an AI, we already have NullBot's tristate movement system, which is the closest thing we have to formation movement, since it allows him to keep his attack group(s) packed tightly and at the same time move forward steadily, and it is also well-tested, and known to be good enough performance-wise, even in javascript. The downside compared to the original formation movement is that it doesn't put long-range stuff behind and short-range stuff in front. So i'm refering to this algorithm as "partial formation movement" below.

I was wondering if i'd have to implement a similar system in libcampaign.js to use with campaign AIs. Now it's clear that such advanced solution is truly necessary.

Finally, we've been talking about the cluster system recently. Cluster analysis is a vital part of NullBot's tristate movement system as well.

So i've got a desperate plan. How about i figure out how to fix the cluster analysis on the C++ side, based on my experience with NullBot, then i can both (1) re-implement partial formation movement on top of the cluster system, including the F11 key for the players, and (2) either allow enforcing C++-side formation movement on JavaScript groups, or expose cluster API to scripts and re-implement NullBot and campaign formation movement on top of that?

P.S. Somebody still needs to confirm the usage of formation movement in the older versions of the game :hmm:

User avatar
Goth Zagog-Thou
Regular
Regular
Posts: 1582
Joined: 06 Jan 2007, 08:08
Location: Delta Base
Contact:

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

Post by Goth Zagog-Thou » 06 Nov 2014, 05:16

Nice, that's what I was talking about as well. Not a 1:1 port, but instead replicating the behavior -- and in so doing, making it more efficient, cleaner, and with smaller file size to boot. This will be a good exercise for me as well, as it will get me into "good practices" mode when I port Cam 4 to JS.

User avatar
vexed
Inactive
Inactive
Posts: 2461
Joined: 27 Jul 2010, 02:07

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

Post by vexed » 07 Nov 2014, 05:18

Broke out the original game, and yes, the units are all moving in formation, and are speed limited. (as in, they all move at the same speed, staying in formation.).

Yeah, I meant 1:1 logic wise, not code wise.

I'll try to check out the performance his of the cluster system this weekend.
/facepalm ...Grinch stole Warzone🙈🙉🙊 contra principia negantem non est disputandum
Super busy, don't expect a timely reply back.

stiv
Warzone 2100 Team Member
Warzone 2100 Team Member
Posts: 876
Joined: 18 Jul 2008, 04:41
Location: 45N 86W

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

Post by stiv » 07 Nov 2014, 06:45

I recall the speed limiting code being removed. Don't remember the reason why.

Per
Warzone 2100 Team Member
Warzone 2100 Team Member
Posts: 3753
Joined: 03 Aug 2006, 19:39

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

Post by Per » 08 Nov 2014, 11:45

stiv wrote:I recall the speed limiting code being removed. Don't remember the reason why.
It was not synced with other peers, so it would create horrible desync issues. It was also a terrible way to implement formations. Unfortunately, we do not have anything better yet...

User avatar
NoQ
Special
Special
Posts: 6187
Joined: 24 Dec 2009, 11:35
Location: /var/zone

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

Post by NoQ » 08 Nov 2014, 20:13

Pushed SUB_1_3, so far without grouping, and without commander either. Will need more work.
____________

I'm having a C++-side problem with commanders. Even though i exposed DORDER_COMMANDERSUPPORT, whenever i actually give this order, i receive a message that commander is already full. In cmdDroidMaxGroup(), all three - droid level and both stats - are zero; commander droid id is correct.

Upd: psDroid->asBits[COMP_BRAIN] is 0. For normal commanders it's 1.
The droid is pre-placed on the map and uses this template:

Code: Select all

    "NP-M-Command-Halftrack": {
        "available": 1,
        "body": "Body8MBT",
        "id": "NP-M-Command-Halftrack",
        "name": "*NP-M-Command-Half-track*",
        "propulsion": "HalfTrack",
        "type": "DROID",
        "weapons": [
            "CommandTurret1"
        ]
    },
Steps to reproduce:
  1. Pull the gits.
  2. Apply the patch
    use-commander.patch
    (790 Bytes) Downloaded 185 times
  3. Start the alpha campaign.
  4. Cheat

    Code: Select all

    ascend sub-1-3s
    biffer baker
  5. Fly away with your tanks on a transport.
  6. Attack the yellow base to trigger commander movement.

User avatar
vexed
Inactive
Inactive
Posts: 2461
Joined: 27 Jul 2010, 02:07

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

Post by vexed » 09 Nov 2014, 05:40

IMO, type should be DROID_COMMAND, and the JSON is missing the brain ("brain": "CommandBrain01") for some units...
In fact, IMO, anything that has a CommandTurret should be of type DROID_COMMAND, and have "brain": "CommandBrain01".
(though, I suppose you could "fix" it script side, but that could get ugly :hmm: )
I'll stick patch in the ticket. http://developer.wz2100.net/attachment/ ... ROID.patch

BTW, major performance hit on this mission...
/facepalm ...Grinch stole Warzone🙈🙉🙊 contra principia negantem non est disputandum
Super busy, don't expect a timely reply back.

User avatar
NoQ
Special
Special
Posts: 6187
Joined: 24 Dec 2009, 11:35
Location: /var/zone

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

Post by NoQ » 09 Nov 2014, 07:07

Hmm. In ini times it used to say

Code: Select all

[NP-M-Command-Halftrack]
name=*NP-M-Command-Half-track*
compBody = Body8MBT
available = 1
compPropulsion = HalfTrack
type = DROID
weapons = CommandTurret1
So i think droidType was auto-detected somehow, based on components :hmm:

Post Reply