LRR Musings

[aidenpons]

There are a bunch of minor discoveries I've made that don't warrant a topic in themselves but could still be good to have written down somewhere. Instead of posting in this topic each time I make a single find. I'll probably just edit the topic. If I make something significant I might post.

 

Greenish = Changed since last update

 

 

Things that Work that aren't NERPs:

 

An ObjectList.ol does not require Object1 { ... Object2 { .... etc. You can use any names you like. This is very handy when trying to work out exactly which object is a STT and which is a RR and which is driving which; you can instead write SmallTransportTruck { ....  and Driver1 {...

No clue how Map Creator handles this though.

 

Erosion is able to erode water, but in the process of doing so the tile is unselectable (likely because water is unselectable)

 

Don't Panic's OL contains a commented out Electric Fence in a curious manner (a commented out name). Normally if you have an invalid name the game crashes upon loading that level.

 

 

Things that Work that are NERPS:

 

Using GetFenceIconClicked as a proxy to fences on level, you can tie slug spam to fence number.

 

Another slug script idea could be "every time you teleport down anything, slugs come at you?" However not everything is covered by this; eg there is GetSmallDiggersOnLevel but no GetSmallTrucksOnLevel (or commands to that effect). This'd work by:

 

If you have no Power Paths or vehicles or anything the game will fail the level for you; no NERPs commands needed! Also if you have no oxygen the game will also fail you.

 

List of ways in which to nerf Electric Fences:

- give them an OxygenCoef

- give them a HealthDecayRate so they teleport up

- give them an absurd amount of dependencies so they're only teleportable lategame

 

Using NERPs scripting to pave over a slug hole with a path at the start of a level can allow for hitherto undetected slugs to come out beneath your base. This'll come in handy when I remake Back to Basics

 

Should really get around to an .ae file guide and Editing .lws with Notepad

 

 

 

Things that Don't Work:

 

SetTutorialBlockIsPath and SetTutorialBlockIsGround do not change lava. This is a shame, as I was hoping to be able to pave over lava using this command when a Tunnel Transport was on that tile after having been over water. Oh well (Can Cyrem change this for Community Edition?)

 

While any vehicle (or anything) is carrying ore (or crystals), it is unable to drill or clear rubble.

 

 

 

General Musings:

 

 

When in 1st person, debug key Z plays the Sandwich animation. Can I point this to the fire-laser animation? Or can Cyrem use exe editing to point this to the Fire activity, thus creating a way in which you can manually shoot RMs yourself?

 

RechargeTime of Electric Fences clearly does something, as I've seen RMs walk through a fence then get zapped. Is this actually working as intended? And is there any visual indicator of this at all?

 

Why is half the stuff in WeaponTypes damages of 0.1 ? Is that fraction of total health? Or just 0.1 damage?

 

STOP doesn't always do what it should (send the Nerps script up to the top). I have yet to look into this but my current theory is that it has something to do with commands being below the Stop... must look into this further, as well as see what a decompilation spits out.

 

RMs are affected by Disappearing Raiders, but slugs are not. This means RMs use a fundamentally different AI to slugs.

 

 

 

 

 

As I said in the introduction, I'll update this topic whenever.

 

(Last Update: originally posted 15/4/19)

(2/07/19 - erosion erodes water)

Edited August 2, 2019 by aidenpons

[Cirevam]

  On 4/15/2019 at 7:43 AM, aidenpons said:

When in 1st person, debug key Z plays the Sandwich animation. Can I point this to the fire-laser animation? Or can Cyrem use exe editing to point this to the Fire activity, thus creating a way in which you can manually shoot RMs yourself?

Expand  

I just replaced the Eat { animation with the shooting one. I also replaced the entire activity with Shoot { in a second test. Two things happen: if you remain in 1st or 2nd person, the camera goes blank because the animation doesn't have any camera nulls defined. The second thing is that nothing is fired. I tried it without a weapon and with a weapon equipped, pressed Z, then quickly went back to 3rd person to see if anything fired. The camera gets really shaky, but that's it.

 

We will need EXE magic to change that debug key to call whatever handles shooting. We will also need a fixed animation, which is super easy.

[ShadowDraikana]

Keep in mind that Z and X are for strafing left and right respectively when debug keys are not enabled.  

 

Raiders only fire once Action Stations is sounded, which means that activity and is directly tied to that event.  I would say that the game's pathfinding changes to seek out targets, and once it identifies one, the Raider is sent off to attack.  Some observations of this show that it behaves the same way as the general tasks in that it seems to randomly pick which monster to attack.  Another question is what determines how far away a Raider should be before firing.  Adjusting the weapon range seems to mitigate some of the issues with firing out of range but the game has a knack for finding ways to get the Raiders out of range still.  Furthermore, the Raiders sometimes appear to dynamically adjust to the monster's position.  This means that if the monster is moving towards the Raider, he will stop and start firing at a certain point, even though the pathfinding told him to go somewhere.  This creates two possibilities: 1. The game is actually updating the paths dynamically rather than waiting for the current move operation to finish or 2. creatures have some sort of a radius that when entered triggers the attack animation of a Raider.  Testing seems to show 1 might be the case.  The Raiders adjust their destination relative to the monster that is being tracked.

 

Finding out what the game needs for the laser to be fired is key here.  If we can force it to use not only that activity but also meet the condition for firing the weapon, this idea of mapping to a key may actually be possible.  

 

Sorry if I rambled a bit X3.

 

Inb4 Cyrem or someone else debunks literally everything I said lmao.

[aidenpons]

  On 4/16/2019 at 7:55 PM, Slimy Slug said:

1. The game is actually updating the paths dynamically rather than waiting for the current move operation to finish or

Expand  

I think this is the case. My current theory is that the pathfinding algorithm generates a path for absolutely everything every frame. This contributes to Idleness Syndrome.

 

  Quote

Some observations of this show that it behaves the same way as the general tasks in that it seems to randomly pick which monster to attack.

Expand  

My theory is not 'randomly' but 'in order;' if you have one raider and ten monsters, he will fire one shot at each monster before shooting the first monster again. This is why the sleeping RMs in Rocky Horror are so annoying.

 

 

  On 4/16/2019 at 12:19 AM, Cirevam said:

I just replaced the Eat { animation with the shooting one. I also replaced the entire activity with Shoot { in a second test. Two things happen: if you remain in 1st or 2nd person, the camera goes blank because the animation doesn't have any camera nulls defined. The second thing is that nothing is fired. I tried it without a weapon and with a weapon equipped, pressed Z, then quickly went back to 3rd person to see if anything fired. The camera gets really shaky, but that's it. 

 

We will need EXE magic to change that debug key to call whatever handles shooting. We will also need a fixed animation, which is super easy.

Expand  

I know you probably weren't checking this, but after "firing" was his sandwich-o-meter filled back up to maximum again? I would suspect it would be, because it's still calling the same activity which is fundamentally what is going on (the animation barely matters except for some nulls...)

I think it'll need EXE magic

 

  On 4/16/2019 at 7:55 PM, Slimy Slug said:

Sorry if I rambled a bit X3.

Expand  

That's what this topic is for

[lol username]

Always wanted to be able to do more in first person mode as a kid. Would be neat to see this done.

 

  On 4/16/2019 at 7:55 PM, Slimy Slug said:

Finding out what the game needs for the laser to be fired is key here.  If we can force it to use not only that activity but also meet the condition for firing the weapon, this idea of mapping to a key may actually be possible.  

Expand  

I wonder if it'd be possible to narrow down where in the exe the press-z-to-nom debug key functionality is, and essentially adapt that.

 

  On 4/16/2019 at 7:55 PM, Slimy Slug said:

Sorry if I rambled a bit X3.

Expand  

 

  On 4/16/2019 at 7:55 PM, Slimy Slug said:

X3

Expand  

 

[ShadowDraikana]

 

  On 4/18/2019 at 9:04 AM, jamesster said:

I wonder if it'd be possible to narrow down where in the exe the press-z-to-nom debug key functionality is, and essentially adapt that.

Expand  

That's kinda what aidenpons was asking for in his first post.

 

Oh and before I forget

  Reveal hidden contents

X3

 

Ok yeah maybe I've been spending too much time reading all that assembly in Legend of Mata Nui's script.  I get a tad squirrely after I've spent some time buried in it...

[aidenpons]

excited Aiden noises

 

so if you were on the Discord you might have noticed that I discovered that I can pass at least one function a negative number: namely, AddPoweredCrystals. In doing so it freezes the game for about seven seconds, but once it's done it's happy and moves on.

 

This is a way to penalize the player via scripts for doing something I don't like. Hitherto if you step on a hidden tile, or just do anything which I told you not to do in the mission briefing, all I can do is send erosion your way, monster spam, or slug spam. The first is irreversible and the second two can be beaten off.

 

Now, however, I can depower your buildings with this simple script:

GetCrystalsCurrentlyStored = 0 ? Stop

TRUE ? SetR1 0
TRUE ? SubR1 GetCrystalsCurrentlyStored

TRUE ? AddPoweredCrystals GetR1 

I can record how many crystals in total I've taken away from you so that when you stop doing whatever I don't like I can hand the crystals back to you.

 

 

Immediate ideas for this:

- Forcing the player to build one Power Station per three buildings (coming soon to a custom map near you!)

- If a special object moves onto a tile, depower all buildings

- Offline base that only becomes powered when condition X is met (finding a Recharge Seam, maybe?) - think Air Raiders, but instead of building 2 power paths and calling it a day you now need to go on a long RPG quest chain

- Depowering all buildings also depowers all Electric Fences
- Under the pretense that "teleporters need power," take crystals away from you each time you teleport a vehicle down, or every 5th raider, or suchlike

 

 

EDIT: Just found out that you can set a negative number of crystals by subtracting more crystals than you currently have. The game seems to be mostly fine with this: crystals display as -1 or whatever. Power Paths still show as powered but all buildings do not have power. Electric Fences still work.
EDIT2: Game's not fine and raiders are unable to be teleported down.... Huh.

Edited September 19, 2019 by aidenpons

[aidenpons]

Minor post, but while experimenting with OxygenCoef, OxygenRate, and the new CE functionality, I discovered that the "10 raider limit before you must build a Support Station" is entirely tied to the OxygenCoef of the Support Station and not a phantom 10 as I had hoped.

 

This script - which also serves as an example of the new Cafeteria functionality available in Beta 5 and above - is supposed to - and mostly does with some faff on the side (CMP commands are not working as intended to skip code, though the script works regardless thanks to SetProperty not doing anything if said property does not exist - just take a look at the patch log) - reduce the OxygenCoef of raiders, the Air Filter if it exists, and the Support Station by a factor of 10, and increase the OxygenRate of levels by a factor of 10. It also goes through RRULevels 1 through to 8 for the Custom Level Cafeteria Framework's sake.

 

  Reveal hidden contents

CFG:Open Lego.cfg


// Adjust coefs of Support Station so 100 raiders = 10 drain
// but still 10 raiders = 1 Support Station
CFG:SetProperty Lego*\Stats\Barracks\OxygenCoef 1.0
CFG:SetProperty Lego*\Stats\Pilot\OxygenCoef -0.1

// check for Air Filter
VAR:FromCFG AirFiltRate Lego*\Stats\AirFilter\OxygenCoef 0
CMP AirFiltRate = 0 SkipAirFilterModification
// so only if the air filter exists will this jump not activate and things go accordingly
CFG:SetProperty Lego*\Stats\AirFilter\OxygenCoef 0.2:0.25:0.33
@@SkipAirFilterModification


// now... we want to go through all 25 levels, and the 8 RRU levels if those exist
// read their oxygen coefficient, multiply it by ten, and save it there

VAR maxnumlevels 25
VAR maxnumRRUlevels 8
VAR currentlevel 1
VAR i 1

@@OxygenLevelLoop
 VAR:FromCFG LevelOxygen Lego*\Levels\Level{i|D2}\OxygenRate 0 
 CFG:SetProperty Lego*\Levels\Level{i|D2}\OxygenRate {( {LevelOxygen} * 10 )}
 // CFG:SetProperty Lego*\Levels\Level{i|D2}\OxygenRate {LevelOxygen}
 // CFG:SetProperty Lego*\Levels\Level{i|D2}\OxygenRate 1
 VAR:Increment i
CMP i <= {maxnumlevels} OxygenLevelLoop

VAR iRRU 1
@@OxygenRRULevelLoop
 VAR:FromCFG RRULevelOxygen Lego*\Levels\RRULevel{iRRU|D2}\OxygenRate 0
 CMP RRULevelOxygen < 1 SkipThisRRULevel
 CFG:SetProperty Lego*\Levels\RRULevel{iRRU|D2}\OxygenRate {( {RRULevelOxygen} * 10 )}
@@SkipThisRRULevel
 VAR:Increment iRRU
CMP iRRU <= {maxnumRRUlevels} OxygenRRULevelLoop


 


CFG:Save

 

 

[aidenpons]

Did this predominately to document it for Manic Miners, but thought I might as well put it on the forum too: a list of all the idle animations of raiders. There's a lot!

 

 

Unused:
VLP_backflip - Raider leans down and forward, then does a very quick backflip
VLP_clap - Raider claps sarcastically slowly.
VLP_clap2 - Raider claps slowly, as well as a very slight jump around the 3rd clap.
VLP_clap3 - Raider looks around and claps. Of all the claps, this feels the most like actual applause from a crowd.
VLP_clap4 - Raider claps very quickly and looks around a little.
VLP_jumpceleb - Ever seen Mario jump in Super Mario Bros? This is it, complete with hand rising into the air. Falls back down and returns to standing a lot quicker than Mario does.
VLP_look - Raider looks to both sides (before crossing the road )
VLP_rubhands_lookleft - Like VLP_rubhands, but raider looks over his left shoulder
VLP_rubhands_lookright - Like VLP_rubhands_lookleft, but right
VLP_Saxplay - Raider pulls a saxophone out of their right pocket, plays it whilst tapping their right foot in time as musical notes come out and swirl, then puts it away again
VLP_Saxplayfast - Like VLP saxplay, but the music is quicker and the song shorter
VLP_shiver - Raider shakes quickly for a brief moment.
VLP_shiver_flap - Raider shakes quickly, and also huddles their arms close and stamps their feet

VLP_wipebrow - Raider quickly uses their right arm to wipe their forehead.

 

Used:
VLP_beckon - Raider looks backward over their right shoulder, then swings their arm a full circle. I always took this for an arm stretch as opposed to any kind of beckoning
VLP_clipboard - Raider pulls a blue clipboard out of their right pocket, reads it (subtle, but very convincing head movement: head moves left to right then down a bit then left to right then down etc), nods, then puts it away.
VLP_rubhands - Raider rubs hands and stomps legs, like one does to keep warm.
VLP_scratchhead - Raider uses their left hand to scratch their head.
VLP_Standingjump - Raider quickly jumps into the air.

 

 

It's really impressive how low-poly yet incredibly detailed these animations are. Whoever made them did an outstanding job. Even though Lightwave forgot where the textures on the raider where and it was a blend of triangles, it was incredibly impressive how easy it was to see what was going on. It's outstandingly clear that VLP_clap3 is applause (perhaps for the saxophone player?), despite being so incredibly small.

 

 

 

Oh, and if you want to enable these animations you'll need a handful of lines in Pilot.ae. You can already see that four of these animations are used under Actitives:

		Activity_Waiting1				Waiting2
		Activity_Waiting2				Waiting7
		Activity_Waiting3				Waiting16
		Activity_Waiting4				Waiting20

all you really have to do is expand this out from Activity_Waiting5 to Activity_Waiting20. Normally, if you were adding your own, new, animations, you'd also need to define them like, say:

	Waiting14 {
		FILE		VLP_Saxplay
		TRANSCOEF	0.0
		LWSFILE	TRUE
	}

but they're already defined there in Pilot.ae, they just aren't hooked up to be idle animations.

 

Quick AE technical note, as these files aren't documented much: the Activity_Waiting is hardcoded and is the idle animations that will play. The number at the end of it indicates that the game will pick one of these at random to play when it decides to play an idle animation. The name of Waiting2 isn't important at all and solely links to later in the AE file where the actual .lws file is defined.

[phenix8fr]

If I understood correctly, it is possible to change each waiting activity to an existing one, but it is impossible to add a new one. (not Waiting21 or more)

[Cirevam]

I think it's more like you can't add new types of activities, but you can add more of the same activity. You could have a hundred different Activity_Waiting entries as long as the number on the end is different. So I can't add Activity_KickMonsterInTheFace since that doesn't already exist, but I can add Activity_Waiting100 if I wanted.

 

Activities are a little flexible. In the past,  I've added some "new" ones to the Rock Raider in order to support custom vehicles. You will not find the following activities in the base game, but they work. Go into the Pilot.ae file and look at the activities for vehicles (what the raider does when driving vehicles), and you'll see something similar.

	;ON R3F1

		Activity_R3F1					StandST
		Activity_StandR3F1				StandST

	;ON Bulldozer

		Activity_Bulldozer				StandBull
		Activity_StandBulldozer				StandBull
		Activity_ClearBulldozer				ShovelBull

 

[aidenpons]

Emrg.map has a lot of non-used data in it (try loading Frozen Frenzy's Emrg map in Tuto.map mode and taking a look at it). It seems that whilst 1 is the trigger and 2 is the emerge, 3 would potentially be a second emerge - either a failsafe, or two monsters coming from one trigger. Similarly you can see 7-8-9, 13-14,15, etc. Work by Trigger_Fallin / Trigger_Segfault shows it's possible to mod/hack LRR to use this data and cause multiple monsters to emerge off a single trigger.

 

In regular LRR, multiple triggers can activate one emerge (and the emerge goes on EmergeTimeOut), but you are not able to activate a second emerge off a single trigger under basically any known circumstances: multiple emerges won't fire, if you drill one emerge point and have a second, the second will not fire, etc. You would usually have to script this with NERPs (which gets very painful very quickly).

[aidenpons]

  On 10/9/2021 at 12:13 AM, aidenpons said:

Emrg.map has a lot of non-used data in it (try loading Frozen Frenzy's Emrg map in Tuto.map mode and taking a look at it). It seems that whilst 1 is the trigger and 2 is the emerge, 3 would potentially be a second emerge - either a failsafe, or two monsters coming from one trigger. Similarly you can see 7-8-9, 13-14,15, etc. Work by Trigger_Fallin / Trigger_Segfault shows it's possible to mod/hack LRR to use this data and cause multiple monsters to emerge off a single trigger.

 

In regular LRR, multiple triggers can activate one emerge (and the emerge goes on EmergeTimeOut), but you are not able to activate a second emerge off a single trigger under basically any known circumstances: multiple emerges won't fire, if you drill one emerge point and have a second, the second will not fire, etc. You would usually have to script this with NERPs (which gets very painful very quickly).

Expand  

 

Update! You can see this in action in Run the Gauntlet! Open up Map Creator, load Level20's Surf.map, then switch it to Tuto.map mode and load Emrg.map in as Tuto mode so you can see the raw data.

Not only do the monsters not emerge from the blocks Map Creator thinks they should (1->2, 7->8, 13->14, etc, instead it's 1->3, 7->8, 13->17), if you set EmergeTimeOut to 1 in the cfg (0 doesn't work for whatever reason), you get multiple monsters from one trigger - you get a monster from all the blocks. So block 1 triggers 2 3 4 5 6 , block 7 triggers 8 9 10 11 12, etc. Unfortunately a lot of these are still assigned as corner walls, so you don't get emerges from them, but the idea of there being 20+ monsters chasing you in Run the Gauntlet is ... definitely scarier than what we got.

 

Practical use? Unfortunately not a lot. EmergeTimeOut of 1 has all sorts of nasty consequences like constantly spamming monsters, and if you want a swarm of monsters you can do that in a much more controlled and reliable fashion with SetRockMonsterAtTutorial, which doesn't even require multiple blocks - if you paint a lot of blocks 2 and call SetRockMonsterAtTutorial 2 , you'll get a monster at all the blocks (and not just a Rock Monster, whatever you specified in EmergeCreature).

 

I've annotated in the regular game which blocks cause what to emerge, 1, 7, 13, 19, 25, etc are the triggers that if something is on the tile, they'll emerge. 2-6 are the emerge blocks that accompany trigger 1. 8-12 are the emerge blocks that accompany trigger 2. Etc ...

 

*Map Creator shows the block marked 2 as Hard Rock, but because it's defined in Dugg.map as a hidden cavern, there's actually nothing there and it's just ground. Don't Panic is a good example of where Surf.map and Dugg.map can butt heads, and what the game does as a result.

 

If EmergeTimeOut is set to 1, then trigger 1 causes emerges at 3 but also 4 (2 is ground, 5 & 6 are corners). Trigger 7 causes emerges at 8, 9, and 10 (as well as likely 11 and 12, but they were drilled when I tested this). Trigger 13 causes emerges at 17 and 18 (the rest being corners), and so on.

 

As you can see, a lot of corner walls, which means even with EmergeTimeOut you only get 2-3 monsters despite more being marked since monsters can't emerge from corner walls. But if they were all valid emerge walls, I'd expect an emerge from all of them. ... Which is a lot more terrifying than the small amount of monsters we actually got in this level.

 

[aidenpons]

Interesting finds with Emrg.map in Air Raiders! This map has a couple of triggers by the waterfront which are offscreen on the left of this image. In particular, let's look at trigger, block 19.

 

 

Normally, when you run over block 19, a monster appears at block 20. That's all as expected and you can see that if you load Emrg.map into Map Creator on Emrg.map mode.

But it doesn't end there... If block 20 doesn't result in an emerge (eg: drilled/reinforced/is corner), the game checks the next block, 21: which in this case is also invalid because it's a corner. So then it checks 22 and sends a monster from there. Unless that one was drilled, in which case it tries 23, then it tries 24, and at that point it gives up (because 25 is a trigger).

 

Even in Frozen Frenzy, the most classic trigger-emerge right next to each other, has a backup emerge event 3 at the end of the cavern which can and will go off if you drill block 2:

 

 

 

So they're not for multiple monsters, but rather, backup emerge events in case the walls were drilled. Fascinating!

 

Practical applications: Quite a lot, actually! It's always bugged me that you can just reinforce or drill the wall a monster will come from and then forget about them as you've now deactivated the emerge part of that trigger-emerge pair. Just reinforce it up and you can forget about that forevermore. But with this, you can have a spooky monster come from a second wall! Or a third! Or a fourth! Or a fifth!

 

Combined with trigger walls (something the LRR devs never did - basically, you can have multiple instances of a trigger and they'll all work, creating a trigger wall which, if you want to get into the cavern, you will end up crossing), you should reliably be able to get a monster up unless the player has reinforced literally every single wall in the cavern!

 

Unfortunately, it's still just one monster caused by one trigger (unless, as outlined in the previous post, EmergeTimeOut is unusably low) - for more than one, you'll need to use NERPs scripting. I guess you could have two triggers right next to each other, but that gets messy quickly. But this is significantly less headbanging than wrangling your way around the incessantly mangled NERPs scripts - put in your triggers of 1, 7, 13, 19, etc, and fill out the emerge priority list of 2-6, 8-12, 14-18, 20-24, etc!

 

 

 

I'm... kinda surprised it took anyone this long to figure this out. It's pretty obvious if you load a map like Run the Gauntlet that the monsters are actually emerging from different spots than what Map Creator thinks they should be. And in Air Raiders (which prompted this whole check), I have many memories of monsters appearing from spots that Map Creator didn't think they do. I guess we took what was provided to us and just went with that.

 

I likely won't be using this tech in any custom levels any time soon - my attention on creation is wholly focused on MM at this point (which, if nothing else, deserves a mention for its sheer stability - over the course of testing this alone, LRR crashed twice ), but it doesn't mean I won't hunt oddities like this down