LRR Musings

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

16 hours ago, 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?

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.

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.

3 hours ago, Slimy Slug said:

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

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.

 

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.

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.

 

 

23 hours ago, 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.

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

 

3 hours ago, Slimy Slug said:

Sorry if I rambled a bit X3.

That's what this topic is for

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 12: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.  

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 12:55 PM, Slimy Slug said:

Sorry if I rambled a bit X3.

 

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

X3

 

 

12 hours ago, 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.

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

 

Oh and before I forget

Spoiler

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...

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

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.

 

Spoiler

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

 

 

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.

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)

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