LRR Musings

[aidenpons 972]

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.

 

 

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.

 

 

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

 

 

 

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?

 

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)

[Cirevam 1,575]

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.

[Slimy Slug 66]

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 972]

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

[jamesster 7,202]

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

 

[Slimy Slug 66]

 

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