Don't worry about me. I'm not going to run out of missions any time soon (: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.
The official --=jscam=-- thread
Re: The official --=jscam=-- thread
Maps | Tower Defense | NullBot AI | More NullBot AI | Scavs | More Scavs | Tilesets | Walkthrough | JSCam
Re: The official --=jscam=-- thread
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 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
Maps | Tower Defense | NullBot AI | More NullBot AI | Scavs | More Scavs | Tilesets | Walkthrough | JSCam
Re: The official --=jscam=-- thread
I always thought tutorial and fastplay really were campaigns. Just much smaller ones.
Re: The official --=jscam=-- thread
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.
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.
Maps | Tower Defense | NullBot AI | More NullBot AI | Scavs | More Scavs | Tilesets | Walkthrough | JSCam
Re: The official --=jscam=-- thread
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?...
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);
Maps | Tower Defense | NullBot AI | More NullBot AI | Scavs | More Scavs | Tilesets | Walkthrough | JSCam
Re: The official --=jscam=-- thread
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 (:
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 (:
Maps | Tower Defense | NullBot AI | More NullBot AI | Scavs | More Scavs | Tilesets | Walkthrough | JSCam
Re: The official --=jscam=-- thread
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.
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.
/facepalm ...Grinch stole Warzone contra principia negantem non est disputandum
Super busy, don't expect a timely reply back.
Super busy, don't expect a timely reply back.
Re: The official --=jscam=-- thread
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
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
Maps | Tower Defense | NullBot AI | More NullBot AI | Scavs | More Scavs | Tilesets | Walkthrough | JSCam
- Goth Zagog-Thou
- Regular
- Posts: 1582
- Joined: 06 Jan 2007, 08:08
- Location: Delta Base
- Contact:
Re: The official --=jscam=-- thread
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.
Re: The official --=jscam=-- thread
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.
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.
Super busy, don't expect a timely reply back.
Re: The official --=jscam=-- thread
I recall the speed limiting code being removed. Don't remember the reason why.
Re: The official --=jscam=-- thread
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...stiv wrote:I recall the speed limiting code being removed. Don't remember the reason why.
Re: The official --=jscam=-- thread
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:
____________
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"
]
},
- Pull the gits.
- Apply the patch
- Start the alpha campaign.
- Cheat
Code: Select all
ascend sub-1-3s biffer baker
- Fly away with your tanks on a transport.
- Attack the yellow base to trigger commander movement.
Maps | Tower Defense | NullBot AI | More NullBot AI | Scavs | More Scavs | Tilesets | Walkthrough | JSCam
Re: The official --=jscam=-- thread
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...
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...
/facepalm ...Grinch stole Warzone contra principia negantem non est disputandum
Super busy, don't expect a timely reply back.
Super busy, don't expect a timely reply back.
Re: The official --=jscam=-- thread
Hmm. In ini times it used to say
So i think droidType was auto-detected somehow, based on components
Code: Select all
[NP-M-Command-Halftrack]
name=*NP-M-Command-Half-track*
compBody = Body8MBT
available = 1
compPropulsion = HalfTrack
type = DROID
weapons = CommandTurret1
Maps | Tower Defense | NullBot AI | More NullBot AI | Scavs | More Scavs | Tilesets | Walkthrough | JSCam