The official --=jscam=-- thread

[NoQ]

Almost ready to push CAM_1C, after i got it running with the following script API changes:

• 0001-qtscript-Add-functions-necessary-to-implement.patch

  (7.31 KiB) Downloaded 319 times

(does anybody have a better idea?)

[vexed]

Are you in a rush to commit this, or can this wait until after the 3.1.2 release ?
If you can't wait, go ahead and commit, the worst that can happen is a revert.

[NoQ]

I'm in no any rush, that's exactly why i'm asking for a review^^
Just more than one way to implement that, and i might be missing something in the underlying mechanics.

[NoQ]

What we need is a button to display mission objectives.

In fact, we already have one (F5 / Intelligence display), but it is so counter-intuitive, that nobody ever looks there. Also, texts there need to be made more clear and simple and straightforward, eg. "Destroy all enemy bases and recover all artifacts", or "Intercept and destroy enemy scout force in the canyon and recover the artifact. Then destroy the enemy base."...

Probably the easiest way to fix the button itself is to make it display mission objectives (instead of nothing) right after it was pressed (without re-showing the intro movie for the objectives).

[MaNGusT]

Cool story time..
When I played the campaign 1st time on psx, I was researching the intelligence display for every f*cking word that could help me to accomplish the mission. Many times my fails required me to restart and it made me to love this game even more. It was the way of trial and error. I'm categorically against that even a single word will be changed in manner it wasn't created originally. It has to be as is. IMHO.

You could create a "more info" button in intelligence display to show your own "literally simplified task" for guys that want to pass the mission but not "explore" the world of warzone created by pumpkin studio.

[NoQ]

Yay cool story bro. Even though i disagree on the fun of exploring game bugs, you do have a point. Anyway, even without changes in wording, i'm still for a ui change. Clicking a button only to see an empty rectangle is so disappointing.

[montetank]

Also, texts there need to be made more clear and simple and straightforward, eg. "Destroy all enemy bases and recover all artifacts", or "Intercept and destroy enemy scout force in the canyon and recover the artifact. Then destroy the enemy base."...

Agree ! especially in other languages. Thats what i wrote today : viewtopic.php?f=45&t=10985#p130337

[NoQ]

Pushed CAM_1C after all, the level seems polished enough, and most of the bugs were carefully preserved. I didn't make the AI produce an unlimited number of trucks, as the original campaign does. It still produces an unlimited number of sensors though.

Anyway, we now have some easy-to-use dummy truck management in libcampaign.

[NoQ]

Done with CAM_1CA (the first transporter counter-attack level). I also think i managed to work around the problem that we can't have two transporters at once, even for an enemy player (because LZ aka "no-go area" is always only one, and probably other stuff). Now libcampaign transparently queues them up, so even both LZs in CAM_1C are enabled simultaneously and transporters arrive synchronously, they are handled correctly.

[NoQ]

Will be afk for a couple of weekends.
Don't think i'd be able to finish SUB_1_4A before that.
You guys have a good chance to catch up (:

[NoQ]

Some curious rudimentary comments in SUB_1_4A code:

Code: Select all

//build list NP Medium Factory
//   0, 1 = produce Rocket Cyborg, chaingun cyborg

This level is the first one after the first defense level. Before the level, briefing says that the Project intercepts a transmission from New Paradigm to Nexus, which says that they have recovered the Synaptic Link Technology.

The comment might indicate that there was a plan to make the New Paradigm produce cyborgs as early as here. Moreover, they were supposed to be produced from a tank factory (?) (the one with one extra module).

But in fact cyborgs appear only on the next level. And, in particular, the very powerful rocket cyborgs only appear in the last alpha mission.

[Per]

I just did some rudimentary testing today in campaign, and noticed that I get random assert failures in the first off-world mission, due to the scripting system not being up once we start processing off-world world setup, and that triggers scripting events. I'm not sure how to fix this, since the level-loading sequence is such a horrid undecipherable mess of hacks and workarounds that once you change something you break lots of other things... It is tempting to just move control over the mission stuff entirely into qtscript. At least that way, from the viewpoint of the C++ engine, it is easier to keep things neat and consistent. However, that might break all the old campaign stuff from working until it is ported over...

What we need more than anything at the moment, I think, is a description of how the level change system is supposed to work, including intended state changes and which part of the game is in control of what (.lev? scripts? engine? .gam?). Or perhaps, if we start changing it without caring about the old, how is should work...

[NoQ]

This seems to agree with what i've seen...

Well, i'm not quite sure how exactly wzscript levels now need to be working. In any case, we need to run rules.js on every level, even if the level itself is coded in wzscript (but now we don't, which leads to bugs like command center not working), not sure: probably loading it would help?

[NoQ]

What we need more than anything at the moment, I think, is a description of how the level change system is supposed to work, including intended state changes and which part of the game is in control of what (.lev? scripts? engine? .gam?). Or perhaps, if we start changing it without caring about the old, how is should work...

Yeah, that's a great thing to think about (: Probably some sort of level.json? upd: /me wishes to remove addon.lev and stuff and replace it with json as well.

We seem to use a limited set of hardcoded map change variants: stay on the same map, expand the map's scroll limits, fly to an away mission, transfer to another campaign, ??? at some point a group of units disappears and arrives on a later level, there seem to be special hacks for that as well... Not sure how to unhardcode it, because i still don't quite grasp how much thought was put into that.

upd: In wesnoth scripting language, you can store a group of units in a variable that is preserved across levels, remove them from the map and then restore them later [1]. This turns out to be quite handy.

[vexed]

I just did some rudimentary testing today in campaign, and noticed that I get random assert failures in the first off-world mission, due to the scripting system not being up once we start processing off-world world setup, and that triggers scripting events. I'm not sure how to fix this, since the level-loading sequence is such a horrid undecipherable mess of hacks and workarounds that once you change something you break lots of other things... It is tempting to just move control over the mission stuff entirely into qtscript. At least that way, from the viewpoint of the C++ engine, it is easier to keep things neat and consistent. However, that might break all the old campaign stuff from working until it is ported over...

Do you mean, replace some entries in the wrf file just to load the needed scripts, or do you mean something different?

What we need more than anything at the moment, I think, is a description of how the level change system is supposed to work, including intended state changes and which part of the game is in control of what (.lev? scripts? engine? .gam?). Or perhaps, if we start changing it without caring about the old, how is should work...

I don't think anyone has made a full state machine diagram on what should/shouldn't happen, but, we do know it is fairly complex on how everything ties together for the loading of things, especially for the campaign, with all the extras they have for it.
It was pretty difficult pouring over logs to see how everything fits, to find bugs.
What we have to remember is, Pumpkin did its best to fit and reuse as much code as possible, and they loved using pointer swaps for multiple things all in the name to save as much space as possible, as well as using basically memory dumps to save things.

Sure, in the long term, it would be wise to change to a more forgiving, and smarter design, but, in the short term, touching so many things all at once is just getting us into trouble since we don't have any way to verify results from one stage to the next besides doing releases.