Custom Map #3842: map 145 BIGPAC-2 (Runner Bickford). By: yum234

[yum-forum]

This map had lots of lag for me as well but I still enjoyed beating it, thanks!

Thank You for comments!  :)

Sorry for for lag problem in map created on Your Desire.  :-[

As a compensation I created new version of this map (BICKFIRD PAC) with the same scenario, not so hard and without big lag problem!  Please, enjoy it! :)

[yum-forum]

I have to agree with Doom.  The map looks great and I'd love to play it but there is no way my system can handle this.  It's not a terrible system (can play most AAA games) but the lag here is just too much.  Makes me sad because I'd really like to give it a shot.

I don't know exactly what is causing all the lag, but if I had to guess I'd say it's the sheer amount of packets that have to be sent over the network.  "Best path" algorithms tend to be fairly processor intensive and you have TONS of things needing to be calculated each frame.  Here's something that I've thought about that might help on a map like this.  Given the size of the map, I wonder if it might be more efficient in terms of computational power to break the network into smaller pieces that are not connected.  Then, power up each section with guppies that come from PZs in a well defended portion of the base.  That would make the overall map less connected and each "map" within the map would be smaller.  That should theoretically make the best path algorithm require less computation.  Again, I've not tried this, but I do wonder if it would help.

Anyway, like I said, the map looks great but I won't be able to play it. :(

Thank You for comments!  :) :)

I tested Your idea about using guppies. Was not successful.
Main problem in number of units (weapons etc.). I remember similar problems in CW2 and CW3 in usual big maps when You have to build many many weapons. That is why I created improved version of this game (BICKFORD PAC) with the same scenario, not so hars and without big lag problems! Enjoy it, please!  :)

[D0m0nik]

Finished at last, about 1hr to achieve every 5 mins and for the fist time ever no pausing required!

[yum-forum]

Until the game end condition is met, the script is doing a lot of work. The main bottlenecks are that each frame it is checking to see if all the items are destroyed (Triggering victory) and it's also checking to see if it should start rebuilding any destroyed item, and if yes, can it rebuild it? (Is the ground clear of active digitalis and creeper?).

These checks all happen for each square of the map, each frame, and this is why huge maps are so extremely laggy.

One change I made long ago, and I don't know if it's in your recent version or not, is to make it so it only does those checks once every 20 frames or so, instead of every single frame. That helped a little bit at the time. You might experiment with that.

Main problem in number of units (weapons etc.). I checked and desided to create improved version of this map.
Name: BICFKRD PAC. Very similar scenario, more easy and almost without lag problem!  Please, try it. Hope You will enjoy!  :)

[yum-forum]

Finished at last, about 1hr to achieve every 5 mins and for the fist time ever no pausing required!

Great and C 8) 8) 8L!

Sorry for lag problems! As a compensation I created new version of this map (BICKFORD PAC) for enjoyable playing! Please, try!  :)

[mzimmer74]

Until the game end condition is met, the script is doing a lot of work. The main bottlenecks are that each frame it is checking to see if all the items are destroyed (Triggering victory) and it's also checking to see if it should start rebuilding any destroyed item, and if yes, can it rebuild it? (Is the ground clear of active digitalis and creeper?).

These checks all happen for each square of the map, each frame, and this is why huge maps are so extremely laggy.

One change I made long ago, and I don't know if it's in your recent version or not, is to make it so it only does those checks once every 20 frames or so, instead of every single frame. That helped a little bit at the time. You might experiment with that.

I haven't looked at any CRPL but if this is what's going on it seems to me like there are a couple of ways to make this much more optimized.  I don't know if any of these are possible in CRPL, but thought I'd give the basics of both ideas.

First, instead of checking for each square, is there any kind of function along the lines of "CN1 STILL ALIVE"?  If there is, couldn't you just check to see if any CNs are still on the map and if there aren't then have it be a win?  Once all three CNs are gone the game is basically over anyway.  Everything from that point is purely mop up.

Second, is there a way to receive "item destroyed" and "item created" events?  If there are, could you have a global variable that decreases on each destruction and increases on each creation?  Once the number of items left gets down to a certain point then start using the current method.  I would probably not go down to zero in case you got some kind of weird number problem, but if you set it to a number like 20 or something I'd think you could get rid of a lot of the computational lag and still be able to be precise with the actual time of the win.

Anyway, as I said I'm not familiar with CRPL so put these ideas out there as a thought to look at.  Maybe someone who is knowledgeable with CRPL could say whether either way would be possible.

Edit:  I decided to pull open the CRPL and take a look at it.  From what I can tell the time intensive part isn't the checking for win condition but checking to rebuild.  If that's correct then neither of the above ideas will do anything to help with the lag.  Oh well, should have known it wouldn't be something that simple! :P

[GoodMorning]

That is the issue. Rebuild checks can be optimized only so far, and they are already generating floods of "X Lost" event tags.

That said, I haven't opened up that specific script yet. "Si non confectus, non recifiat" (Or, in a different language and dialect, "If the relevant object is currently functional, do not attempt to repair it.")

[isj4]

I didn't enjoy the map.
It is so big that it makes it repetitive.
The number of PZ beams effectively disables 1 of the only 2 weapons the creeper has.
The AC spores were a nuisance and not a challenge. And I couldn't destroy them or turn them to my side (flip spores?)
Nullifier-beyond-the-gap is OK a couple of times but not 20 or so (I didn't count).
The number of PZ reactors made energy starvation impossible.
The aforementioned PZ beams made extend-digitalis-in-void a chore. There were one or to gaps where I could do that but then I had to extend the digitalis a long way.

Visually the map is nice and appealing.

The overall impression I got from the map is that there were no feel of "power amplification" and no sneaky tactics. Just brute force.

Possibly a bug: it seems to me that at least some of the berthas could continue to fire even after I had cut off their energy supply. I think some of the early PAC maps suffered from the same bug.

[yum-forum]

I didn't enjoy the map.
It is so big that it makes it repetitive.
The number of PZ beams effectively disables 1 of the only 2 weapons the creeper has.
The AC spores were a nuisance and not a challenge. And I couldn't destroy them or turn them to my side (flip spores?)
Nullifier-beyond-the-gap is OK a couple of times but not 20 or so (I didn't count).
The number of PZ reactors made energy starvation impossible.
The aforementioned PZ beams made extend-digitalis-in-void a chore. There were one or to gaps where I could do that but then I had to extend the digitalis a long way.

Visually the map is nice and appealing.

The overall impression I got from the map is that there were no feel of "power amplification" and no sneaky tactics. Just brute force.

Possibly a bug: it seems to me that at least some of the berthas could continue to fire even after I had cut off their energy supply. I think some of the early PAC maps suffered from the same bug.

Thank You for comments!  :)
I also noticed that Berthas worked without energy supply!

[stdout]

I also noticed that Berthas worked without energy supply!

If this is happening, you are using an old version of the PAC scripts. I fixed that bug long ago.

[yum-forum]

I also noticed that Berthas worked without energy supply!

If this is happening, you are using an old version of the PAC scripts. I fixed that bug long ago.

I was happy when found PlayAsCreeper-2015-01-25.cw3.

Can You supply me with newest template?

[stdout]

Yes, it's this post:

http://knucklecracker.com/forums/index.php?topic=17638.msg132982#msg132982

Your template .cw3 file should be about 144K in size if it's the right one.

[yum-forum]

Yes, it's this post:

http://knucklecracker.com/forums/index.php?topic=17638.msg132982#msg132982

Your template .cw3 file should be about 144K in size if it's the right one.

Thank You!
But I had the same name and size file. Will try "newest"  :)

[lmorovan]

Honestly, I am enjoying this map very much, impressive design and game play. Lagging doesn't bother me much, the map should not suffer or be modified. I take my time and enjoy every moment, it's almost like painting. So far, the best PAC map I have ever played. THANK YOU.

[toolforger]

Gruesome lag, and once I were past the 2000 assist support, it was essentially just a waiting game, often interrupted and reset by Bertha fire.
The size of the map made it then a seeking game to check which spot might look promising, plus trial&error afterwards.

Not fun.