Javascript API documentation

[Goth Zagog-Thou]

Request:

centreViewPosition(x, y, [scroll true/false], scroll rate [1-100]) -- Centers the current view to x, y with option to scroll to that location or to immediately center the view at that location. The current way in WZScript does not do a nice scrolling effect (as if the player were to use the mouse at the screen edge), but instead centers the view immediately to that location.

I have use of this for effect and story purposes in Cam 4.

[Goth Zagog-Thou]

Another request.

For the eventResearched() function, could the .player property be added? Might need to add this to the research object itself too. This would greatly assist with checks that I currently need to do that I really *can't* do currently.

The code that I'm working with is:

Code: Select all

if (structure.player == selectedPlayer && research.name == "R-Sys-Sensor-Tower02" && research.done == true)
	{
		enableResearch("R-Sys-Sensor-Upgrade01", selectedPlayer);
	}

And the code that I would *like* to be able to use is:

Code: Select all

if (structure.player == selectedPlayer && research.name == "R-Sys-Sensor-TurretHvy" && research.done == true)
	{
		if (research.player == selectedPlayer && research.name == "R-Defense-TowerConst02" && research.done == true)
		{
			enableResearch("R-Sys-Sensor-Tower02", selectedPlayer);
		}
	}

Thanks ahead of time. If it can't be done this way, I'm open to alternatives.

[NoQ]

I don't understand, what difference would you expect to see between structure.player and research.player? And, most importantly, why do you expect research.name to be equal to at least two different values at the same time?

[Goth Zagog-Thou]

That's the way I've had to do it to make the simulated research script work. Remember that Cam 4 isn't artifact-driven. Check the Cam 4 dev thread -- I've been crying (literally) about it for 3 months.

I did indeed try it the conventional way, and it wouldn't cooperate. Here's the current (& fluctuating) rules.js I'm using for Cam 4's guts. It's quite a beast. No guarantees it'll work at this particular moment -- I've been neck-deep in it ALL day. It's more for reference so you (and anyone who is interested) can see how I've violated modified it.

rules.js

[Goth Zagog-Thou]

And yes, I'm open to any and all suggestions anyone may have to make it better.

[NoQ]

Emm. Does anybody else understand what is Goth trying to do? I think we could really use some answers to the questions i just asked.

The code you would *like* to be able to use cannot work regardless of anything being added or removed.

[Goth Zagog-Thou]

I'll explain.

For some reason (or any number of reasons) in Campaign mode while performing research, topics don't enable when they should. My approach is to simulate research like what one would have in a Skirmish or MP game. The research code in the rules.js will enable topics as they are researched, bypassing the problem(s). I've spent quite a bit of time troubleshooting and working on a fix.

The problem seems to be a combination of issues. The exact same research tree (plus some "dummy" topics I added for weapon paths and auto-repair which are not part of the "standard" Contingency tree) works flawlessly in MP and Skirmish. No amount of prodding would make it fully work in Cam 4. Scripting it out in rules.js was (to my mind) a logical solution.

That's why it is there. And it does indeed work. Needs more tuning, of course, but it functions.

[NoQ]

And the code that I would *like* to be able to use is:

Code: Select all

if (structure.player == selectedPlayer && research.name == "R-Sys-Sensor-TurretHvy" && research.done == true)
	{
		if (research.player == selectedPlayer && research.name == "R-Defense-TowerConst02" && research.done == true)
		{
			enableResearch("R-Sys-Sensor-Tower02", selectedPlayer);
		}
	}

what difference would you expect to see between structure.player and research.player?

why do you expect research.name to be equal to at least two different values at the same time?

[Goth Zagog-Thou]

The first is to check that we've researched something in our facility.

The second is to check that we've researched a second topic already.

Isn't this the way I should be doing things? Like I said, I'm open to suggestions.

[Iluvalar]

For optimisation, you'd gain a lot of speed by testing structure.player == selectedPlayer only once at the beginning. then, test only once that research.done == true. Inside those 2 Ifs chain your tests for research.name == "xxx" .

you want something like :

Code: Select all

if(research.name == "xxx"){
  enableResearch("xxxmk2");
  if(isDone("yyy")){
    enableResearch("xyxy");
  }
}
if(research.name == "yyy"){
  enableResearch("yyymk2");
  if(isDone("xxx")){
    enableResearch("xyxy");
  }
}

If you have many of those conjonction researches, you might as well create another more elegant system... But, for a start this would work.

[NoQ]

Of course not. research object describes a single research item. research.name is a single string object. It cannot be equal to two things at once. It sounds as if you misunderstand the whole idea of programming language (?)

Is this what you're trying to say?:

Code: Select all

function eventResearched(research, structure, player) {
    // we don't care about function arguments at all
    if (getResearch("R-Defense-TowerConst02").done 
            && getResearch("R-Sys-Sensor-TurretHvy").done)
    {
        enableResearch("R-Sys-Sensor-Tower02", me);
    }
}

And now i'm starting to understand what the problem is: being designed for AI scripts, this mechanism won't work unless surrounded by hackChangeMe() or something like that.

A possible workaround would be to store such info in some static variable:

Code: Select all

function eventResearched(research, structure, player) {
    if (typeof(eventResearched.meta) == undefined)
        eventResearched.meta = {};
    eventResearched.meta[research.id] = true;
    if (eventResearched.meta["R-Defense-TowerConst02"]
            && eventResearched.meta["R-Sys-Sensor-TurretHvy"])
    {
      enableResearch("R-Sys-Sensor-Tower02", selectedPlayer);
    }
}

But what we really need is, i think, an optional second player parameter for getResearch().

Another idea that you may like is to organise research tree in a more readable way:

Code: Select all

researchTree = [
    ...
    // this is much shorter than five lines of nested if.
    { item: "R-Sys-Sensor-Tower02", prereqs: [ "R-Defense-TowerConst02", "R-Sys-Sensor-TurretHvy" ] },
    ...
];

function isDone(research) {
    return getResearch(research).done; // or whatever will be there
}

function eventResearched(research, structure, player) {
    researchTree.forEach(function(res) {
        if (isDone(res.item))
            return;
        if (res.prereqs.every(isDone))
            enableResearch(res.item);
    });
}

[Goth Zagog-Thou]

Exactly the reason I brought the problem to the community. I never claimed to be good at it. This is as much a learning experience for me as anything else.

Thanks for the input. I'll give it my full attention after my surgery this coming monday (surgery #2, I might add).

[Per]

Request: centreViewPosition(x, y, [scroll true/false], scroll rate [1-100]) -- Centers the current view to x, y with option to scroll to that location or to immediately center the view at that location.

Did you try cameraSlide(x, y)? It should do exactly what you request (except for being able to control the scroll rate).

But what we really need is, i think, an optional second player parameter for getResearch().

Added.

Most functions are made for AI usage, but can easily be adapted for campaign use with very small work. Just keep requesting such changes when you see the need for them.

[Goth Zagog-Thou]

Thanks Per. I'll give that a spin.

[Per]

Added replaceTexture(old texture, new texture), which allows you to replace textures from scripts. For example usage, see how this is used to move the logic of switching base plate depending on tilesets from WRF system to scripting system in rules.js. I believe it can also be used to drive some rather fancy graphics changes from scripts (day/night time, summer/winter...?).