CW2 version 0337
CW2 editor version 0336
Have uninstalled/reinstalled both before posting here.
Unless I am completely misunderstanding the difference between start and interval, there appears to be an issue with the start delay on the emitters.
I have made and attached a map that I think illustrates the issue. From left to right, top to bottom:
Row 1:
1. default emitter (start=30, interval=15)
2. start=60, interval=15
3. start=90, interval=15
4. start=150, interval=15
5. start=0, interval=150
6. start=15, interval=150
7. start=30, interval=150
8. start=150, interval=150
Row 2:
1. start=0, interval=1
2. start=0, interval=15
3. start=0, interval=30
4. start=0, interval=60
5. start=1, interval=1
6. start=1, interval=15
7. start=1, interval=30
8. start=1, interval=60
Instead of firing as suggested by their start and interval, it appears that emitters only use the interval to determine firing time.
Perhaps if you tell us what you observe versus what you expect to happen, we might be able to better understand if there is a problem. :)
For instance, the first 4 emitters in row 1 all have start times on multiples of their interval times. Hence when they fire, they will all fire at the same time, but will start progressively later. This they seem to do. Unless, of course, I misunderstood you.
Ah, but the second four in the same row all delay for at least their interval of 150. That might be a problem.
This appears to be 'correct' in accordance with how it is coded (famous excuse). Here's how it is coded:
public function update(onlyOverStash:Boolean = false):Boolean {
updateCount++;
if (updateCount < start) return false;
if (updateCount % interval == 0) {
//Emit creeper
}
}
The updateCount is increased before frame 0 is processed, so emitters with a start delay of 0 (zero) will only emit after the first interval.
If the first frame isn't 0 (zero), but 1, this frame will be skipped as well.
Yeah, it's little things like this that make me hesitate to touch this. I could easily go re-code this... But it could have an impact on all existing maps.
Is it Java that has the concept of
++updatecount and updatecount++?
Seems it might have solved this "issue."
Sorry for not explaining it better, but that is indeed the issue I am experiencing. Maybe some screenshots will help.
First screenshot is taken ~1 frame in. The emitters in row 2, cells 1 and 5 fire as expected but the emitter in row 1, cell 5 and emitters in row 2, cells 2-4 and 6-8 do not.
The second shot is taken at ~15 frames. The emitters in row 2, cells 2 and 6 fire now.
The third shot is at ~1 second. The emitters in row 1, cell 1 and row 2, cells 3 and 7 fires.
The fourth shot is at ~4 seconds. By now, the only emitters that shouldn't have fired are the ones in row 1, cells 4 and 8. However row 1, cells 4-8 have not fired and will fire at 5 seconds, even though they all have different start/interval combinations.
I've thought about this some (played some chopraider for a while). I could probably fix this for future maps and leave the old maps alone. I could code the game to look at the map editor version used to create the map. If it is later than some version, then use the new emitter logic.
That seems to be a slippery slope...
It really isn't a huge deal for me, just something I noticed when playing around with the map editor after the update to 0336 and figured I'd report it in case it is a bug and/or not working as intended.
It would be nice if this issue could be addressed (at least for future maps, although fixing it probably won't affect existing maps that much).
Because the initial delay isn't applied correctly, it's currently impossible to have emitters out of sync.
For instance:
Emitter 1:
Delay: 0
Interval: 900 (30 seconds)
Emitter 2:
Delay: 450 (15 seconds)
Interval: 900 (30 seconds)
You would expect these 2 emitters to alternate every 15 seconds, but instead they will both fire at the same time (every half minute).
The initial delays for field action loops and dig packet dispersals do work correctly (taking this delay into account every time).