LEGO Rock Raiders Water Works

[Lair]

 

WATER WORKS IS THE MOST CRASH-f****ING-INDUCING LEVEL IN THE GAME, f**** FROZEN FRENZY, f**** BACK TO BASICS, THIS LEVEL IS THE TRUE NIGHTMARE OF TEDIUM, AND IT'S EVEN f****ING WORSE IN BAZ'S MOD WHERE IT TAKES FOREVER TO COMPLETE SINCE YOU HAVE TO USE A SMALL DIGGER TO DRILL THROUGH MILES OF HARD ROCK TO GET ENOUGH CRYSTALS BECAUSE IT'S THE ONLY DIGGING VEHICLE THAT CAN BE CARRIED AND THEN IT CRASHES FOR ABSOLUTELY NO REASON JUST AS YOU'RE ABOUT TO WIN, JUST LIKE IN VANILLA, f**** THIS LEVEL, f**** WHOEVER CAME UP WITH IT, f**** KARL FOR PROBABLY PROGRAMMING IT EVEN THOUGH HE'S COOL OTHERWISE, DAMN IT ALL TO HELL

 

anyway I don't think it's one of the better missions in the game, but that's just my opinion

[lol username]

I'm featuring this topic

[Cirevam]

I'm pinning this topic

[darkf]

I feel like someone should make a mod that randomly crashes, at random times. (Next version of Baz' mod? :D)

Now the question is whether it's the game or the mod that crashed. It's about 50/50.

[aidenpons]

20 hours ago, darkf said:

I feel like someone should make a mod that randomly crashes, at random times. (Next version of Baz' mod? :D)

You would be surprised at how difficult that is to do.

 

It's extraordinarily difficult to force LRR to crash at a random time. LRR just crashes in general, you might say. It would be possible to make a random timer that opens a cavern that spawns twenty five slimy slugs per second (that causes insane lag and a crash shortly after - found that out when one of my NPL scripts tied to "monsters-in-existence" broke), but truly "random" timers would be hard to make - and it'd be level-specific.

 

It's possible to get things to crash when something specific happens - such as specifying an invalid bitmap for the play-saxophone animation and then waiting around long enough for the game to crash. I suppose you could call that random, although to make that into a useful (for a given definition of "useful") crashing function would take about 100 idle (on second thoughts, carrying would be more useful) abilities in the Pilot.ae, only one of which crashes.

 

What is known is that the likelihood of LRR crashing goes up with the amount the game is handling - RRs, vehicles, monsters, tiles, power paths, etc etc etc. Hence it's possible to NPL-script these to spawn (particularly mass-demolishing walls / screwing around with everything), but you need to script that. In particular, I've noticed decreasing stability with size of map - Lava Laughter has practically never crashed despite filling everything to the near-corners and collecting 200 Energy Crystals, whereas a huge map like Water Works has a higher chance of going kaput.

 

Why did I bother writing this up on causing LRR to randomly crash? I haven't a clue

 

Also I'm disappointed Ringtail, you didn't let Windows check for a solution to the problem. I'm sure it'll find you a solution in no time.

[darkf]

@aidenponsGood write-up (thanks), but I'd be really surprised if it were actually hard to crash given invalid values in scripts. Sounds like a job for testing at some point.

As for randomness, I'm not 100% sure how the timers work (namely their precision), but it might be possible to construct a PRNG with them.

You know, for science...

[aidenpons]

Quote

I'd be really surprised if it were actually hard to crash given invalid values in scripts

Usually in my experience the .npl just fails to compile. (Usually). What is possible is triggering this to a whole bunch of things that you know will cause the game to crash - mass-spawning slugs is a particularly easy one.

 

:slugloop

GenerateSlug

goto slugloop

 

(heck, I can't even remember my NPL syntax. That looks about right).

 

The game will crash in no time.

 

Quote

I'm not 100% sure how the timers work

I can't remember off the top of my head how many times they run, but I'm pretty sure the .npl script tries to run twenty-five times per second (or maybe it executes a command every 1/25 of a second), and I can't remember the timer frequency, but I'm sure they should be accurate to seconds. I suspect they increase by 25 per second, because I vaguely recall thinking they increased by 1 per second and as such became overloaded with slugs as the game was spawning them at 25x the rate I wanted.

 

A PRNG would be doable even without timers, as you can just place NPL marker scripts and use when they're crossed by LRR's as a random generator. And you can throw the amount of Support Stations the player has built into that mix as well. LRR's scripts have all sorts of odd functions that nobody quite knows how they works but never uses because they're so oddly specific they don't even appear in tutorials.

 

By far the simplest PRNG for Slimy Slug scripts I've devised simply puts the number of Rock/Ice/Lava monsters (via the GetMonstersOnLevel command) and spawns a number of slugs equivalent to that. The second simplest just divides the crystal count by about 50 and spawns that number of slugs with a timed gap in between.

 

----------------------------------

 

Aren't you happy Water Works doesn't have slugs on top of madness?

[Lair]

43 minutes ago, aidenpons said:

What is possible is triggering this to a whole bunch of things that you know will cause the game to crash - mass-spawning slugs is a particularly easy one.

:slugloop GenerateSlug goto slugloop

I've done this with monster emerges and it never crashed, just lagged to hell. does slug AI work differently? maybe equating specifically powered buildings complicates it? wait actually I did that with PTL script, I didn't know you could do that with NPL too. nerps sounds way more complex than I remember, guess I should look into it sometime and see if there's anything cool that can be made out of it.

 

 

also I'd like to update that my second attempt at this level failed because the AI shat itself as a result of too much rubble on the map, and the game started to drop frames more and more even though my number of units was unchanged so I can only assume it was from calculating pathfinding , it's f****ing dwarf fortress all over again.

 

unrelated but later on water lot of fun crashed when i clicked on "teleport to LMS Explorer" for a random raider, good game very stable.

[darkf]

2 hours ago, aidenpons said:

Usually in my experience the .npl just fails to compile. (Usually).

 

Hmm, what compiler are you using? It should be perfectly cromulent to insert bad values into the binary directly -- heck, it might not even crash until it's executed. (A simple test of this would be to use an out of range function ID.)

It is my guess scripts run every frame, yes -- not sure if the game is framelocked or not, but it would explain the 25 Hz you were getting.

 

2 hours ago, aidenpons said:

LRR's scripts have all sorts of odd functions that nobody quite knows how they works but never uses because they're so oddly specific they don't even appear in tutorials.

You mean functions not used in the game levels at all? Interesting.

That's a good idea, I need a list of all functions actually used in levels... perhaps I shall compile one.

[Cirevam]

An easy way to get the game to crash 50% of the time, if you don't need monsters on the level, is to designate a rock monster as the Slug in the level's CFG entry. Put a slug hole in an isolated 2x2 cavern that is revealed, and set the level's EmergeTimeout to whatever you want (monsters use that + emerge triggers instead of NERPS unless explicitly called by NERPS). Normally, monsters are initially spawned inside of a wall and are moved ahead of their animation (there are nulls that control this) which prevents them from crashing the game by being inside the wall. Slug holes spawn monsters with a random heading, which means the monster will be facing a wall in our scenario 50% of the time. That means that the monster will spawn INSIDE the wall as it is moved forward from its spawn point. Active objects inside of a wall crash the game 100% of the time. I don't know why. Maybe it's an out-of-bounds thing since items can appear on top of walls and raiders can run on walls, but those cases are not technically inside walls.

 

EmergeTimeout rolls immediately when the level starts, so there's a 50% chance your game crashes a few seconds after starting. If it doesn't, you have a 50% chance every time EmergeTimeout runs out. It's like Russian Roulette but with LEGO^TM bricks!

 

Bonus: Add slug holes to the normal play area so monsters can harass your raiders every time the dice rolls.

RaiderBonus: Add even more 2x2 slug hole caverns for a higher crash chance!

MegaRaiderBonus: Add trap caverns with slug holes surrounded by three walls (four may be possible with dugg map trickery) so your chance of crashing increases even more as you play!