Warzone 2100 Forums

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 (:

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.

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

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.

A little demo.
Forum attachment preview doesn't handle incrementally animated gifs, hence external link.
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?...

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 (:

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.

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

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.

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.

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

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...

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:
Steps to reproduce:

1. Pull the gits.
2. Apply the patch

   use-commander.patch

   (790 Bytes) Downloaded 303 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.

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 )
I'll stick patch in the ticket. http://developer.wz2100.net/attachment/ ... ROID.patch

BTW, major performance hit on this mission...

Hmm. In ini times it used to say So i think droidType was auto-detected somehow, based on components