Jump to content

(Almost) Everything You Wanted To Know about Vehicles, Upgrades, and .ae files


aidenpons
 Share

Recommended Posts

LRR vehicles are an interesting mess of an interaction between their Stats { InternalVehicleName { section in Lego.cfg and their relevant .ae file.

 

Let’s run over the basics first:

 

In Lego.cfg , take a look at VehicleTypes {  (line 2000 or so). This is where you actually define “this is a vehicle and you should pay attention to it.” There’s some trickery going on with the Granite Grinder (internal name: WalkerDigger) that I don’t fully understand, but for everything else the format is

InternalNameThatLegoCFGUses  Path\To\Relevant\Folder

That folder must also contain an .ae file of the same name. So Vehicles\Hoverboard must contain Hoverboard.ae . Vehicles\SMLP must contain SMLP.ae . This is what I refer to as the “ae file.”

You’ll also need to define it under ObjectNames, as well as just below at ObjectTheNames; ObjectNames defines the tooltip text and ObjectTheNames defines the “You can now transport *the Tunnel Scout*“ or whatever.

There’s also InterfaceBuildImages, which defines the icon, Dependencies, which says what you need to teleport it. You’ll need to add new lines to this if you’re making a new unit. There’s also ObjTtSFXs , which defines the hover-over tooltip sound, but is not necessary to get a vehicle working. Anyway, now onto the interesting stuff.

 

THE CFG SECTION

 

This is in the Stats { section, under InternalVehicleName (the one you defined under VehicleTypes). Browse around! If you want something super-basic with no upgrades to confuse you (highly recommended) take a look at the Tunnel Scout (SmallHeli) or Cargo Carrier (LargeCat). Here’s the contents of LargeCat { :

 

 

 

 

LargeCat {                    ; [Carry][Scan][Speed][Drill] (No carry) (Drill???)

                  Levels                        1
                  RouteSpeed              01.500
                  SurveyRadius            0
                  TrackDist               80.0
                  CollRadius              22.0
                  CollHeight              25.0
                  PickSphere              50.0
                  CanBeDriven             TRUE
                  CrossWater              TRUE
                  UseWaterTeleporter      TRUE
                  ClassAsLarge            TRUE
                  CarryVehicles           TRUE
                  CostCrystal             4
                  EngineSound             SND_Catamaran

                  ShowHealthBar           TRUE
            }

Some of this is mentioned under Creature Modding for the Cadet. It should be pretty obvious when you take a simple example:

  • Levels is upgrade shenanigans (more on this below)
  • RouteSpeed is how fast it moves (tiles per second? Never bothered to quantify the units. Just look at other things)
  • SurveyRadius is the scan radius (for the radar minimap)
  • TrackDist is how far the pop-out tracker camera keeps away from it (you know, the one you never use because it’s on minimap mode?)
  • CollRadius is the collision radius. LRR only handles collision as cylinders, and this is the radius. This is used for First and Second Person View, whether a Rock Monster punch actually hits the vehicle, as well as whether a laser will hit it or not.
  • CollHeight is, as you expect, collision height.
  • PickSphere is the radius from which it can pick things up. Mostly relevant for things like raiders and monsters, as vehicles just drive over to stuff and it goes into their bucket (more on this later).
  • CanBeDriven implies this is a vehicle.
  • CrossWater. Guess what this does! There’s also CrossLand and CrossLava. As you can see, if you leave out any of those it automatically assumes FALSE (this is true of most things).
  • UseWaterTeleporter. Does it use the Docks to teleport down? ONLY use this if the vehicle CANNOT cross land (=> it’s a boat). Otherwise RRs don’t know how to get to it as they can’t walk on water to get to it.
  • ClassAsLarge Solely used for designating things into the Small and Large Vehicles menus.
  • CarryVehicles. This is the Cargo Carrier’s function, after all!
  • CostCrystal, crystal cost. CostOre and CostStuds won’t do anything if you try to use that.
  • EngineSound. Calls Sounds { to point it to the relevant file
  • ShowHealthBar haven’t toyed around with this

I won’t explain all the parameters because a) they’re not needed and b) you should be copy-pasting out an existing vehicle and editing it as opposed to making your own from scratch!

 

Some more interesting parameters are to do with lasers. There are many things you need to do if you want a vehicle to have a laser on it. One of these things is the lines

Tracker TRUE
CanDoubleSelect TRUE

 Just look an existing vehicle and you'll get a good idea.

The next entertaining bit is to do with Levels. This has some odd behaviour. Many of the vanilla objects have sections that are not defined as they should, with extra values fortunately LRR ignores those extra values. The Rapid Rider has 3 levels which is utterly absurd!

Let’s look at the Small Digger.

(FYI, a DrillTime of 0 indicates “undrillable.” Handy for lasers and when you upgrade things to get drills).

 

 

 

SmallDigger {
                  Levels                        8
                  RouteSpeed              02.000:02.000:04.000:04.000:02.000:02.000:04.000:04.000
                  SoilDrillTime           01.000:01.000:01.000:01.000:01.000:01.000:01.000:01.000
                  LooseDrillTime          02.000:01.000:02.000:01.000:02.000:01.000:02.000:01.000
                  MedDrillTime            04.000:02.000:04.000:02.000:04.000:02.000:04.000:02.000
                  HardDrillTime           180.000:150.000:180.000:150.000:180.000:150.000:180.000:150.000
                  SeamDrillTime           08.000:04.000:08.000:04.000:08.000:04.000:08.000:04.000
                  MaxCarry                0:0:0:0:0:0:0:0
                  SurveyRadius            0:0:0:0:4:4:4:4
                  TrackDist               50.0
                  CollRadius              10.0
                  CollHeight              12.0
                  PickSphere              20.0
                  CanBeDriven             TRUE
                  CrossLand               TRUE
                  RouteAvoidance          FALSE
                  UseSmallTeleporter      TRUE
                  VehicleCanBeCarried     TRUE
                  CostCrystal             1

                  UpgradeCostOre          0:5:10:10
                  UpgradeCostStuds  0:1:2:2

                  ShowHealthBar           TRUE

                  EngineSound             SND_SmallEngine
            }

 

This now has 8 Levels! But wait, there are only four upgrades. This is because there are 8 combinations of the upgrades it gets. (That’s a lie but keep going with it until I explain more):

  1. No Upgrades
  2. Drill Only
  3. Engine Only
  4. Drill + Engine
  5. Scanner Only
  6. Drill + Scanner
  7. Engine + Scanner
  8. Drill+Engine+Scanner

 

There, that’s 8 levels. This is just the way LRR works, as opposed to specifying EngineNoUpgradeSpeed and EngineUpgradeSpeed. One positive of this is that it means you can change what the upgrades do with extra stuff so you could make a Loader Dozer that has its Carry upgrade go slower. (Please don’t do that, they’re slow enough as it stands).

However if you now look at SmallTruck, the Transport Truck, you’ll see it has 16 levels. :S That’s funny  it only gets three upgrades, which is 8 total, right?

 

 

 

SmallTruck {                  ; [Carry][Scan][Speed][Drill] (No drill)

                  Levels                        16
                  RouteSpeed              2.0:2.0:3.0:3.0:2.0:2.0:3.0:3.0:2.0:2.0:3.0:3.0:2.0:2.0:3.0:3.0
                  MaxCarry                003:003:003:003:003:003:003:003:006:006:006:006:006:006:006:006
                  CarryStart              000:000:000:000:000:000:000:000:003:003:003:003:003:003:003:003
                  SurveyRadius            000:000:000:000:004:004:004:004:000:000:000:000:004:004:004:004
                  TrackDist               50.0
                  CollRadius              10.0
                  CollHeight              12.0
                  PickSphere              20.0
                  CanBeDriven             TRUE
                  CrossLand               TRUE
                  UseSmallTeleporter      TRUE
                  VehicleCanBeCarried     TRUE
                  CostCrystal             2
                  EnterToolStore          TRUE

                  UpgradeCostOre          5:5:10:0
                  UpgradeCostStuds  1:1:2:0

                  ShowHealthBar           TRUE

                  EngineSound             SND_SmallEngine

            }

 

 

 

And you’ll notice that several of the parameters are just duplicated: for instance look at the first and second levels,

 

RouteSpeed              2.0:2.0
MaxCarry                003:003
CarryStart              000:000
SurveyRadius            000:000

Utterly identical!

 

 

That’s because the game doesn’t determine max levels by how many upgrade combinations it has. Instead, it determines it by what the highest upgrade is. Bear with me as I explain this:

 

 

Drill works like OFF:ON:OFF:ON:OFF:ON:etcetera . That is why the Small Digger looks like

MedDrillTime            04.000:02.000:04.000:02.000:04.000:02.000:04.000:02.000

Off, on, off, on, off, on, etcetera.

 

 

The Engine upgrade looks like

OFF:OFF:ON:ON : OFF:OFF:ON:ON

(added extra spaces for clarity)

. Which is why the Small Transport Truck looks like

RouteSpeed              2.0:2.0:3.0:3.0:2.0:2.0:3.0:3.0:2.0:2.0:3.0:3.0:2.0:2.0:3.0:3.0

 

 

The Scanner upgrade looks like

OFF:OFF:OFF:OFF : ON:ON:ON:ON

(again, extra spaces for clarity)

. So stuff like the SmallTruck

SurveyRadius            000:000:000:000:004:004:004:004:000:000:000:000:004:004:004:004

And the Carry upgrade looks like

OFF:OFF:OFF:OFF:OFF:OFF:OFF:OFF : ON:ON:ON:ON:ON:ON:ON:ON

 

 

 

Regardless of what upgrades it actually gets, you need to make sure that the sections are filled out properly. So if you want just one carry upgrade which has only two combinations, carry on and carry off, you’ll still need to fill everything out to 16 levels. Just duplicating the stuff is fine.

UpgradeCostOre and UpgradeCostStuds are the upgrade costs (surprise!). What is a little more surprising is their order. It is

Carry:Scanner:Engine:Drill

If you can spot why this is the case, well done you, and if you can’t, don’t worry about it.

 

 

 

So you may have filled out the Stats section correctly but your vehicle doesn’t actually have the upgrade capability. Or you want to take an upgrade off a vehicle, and it won’t go away.

This can be rationalized by thinking about the Carry upgrade, which goes up to 16. If I had Carry and Drill the numbers in SoilDrillTime would change. But there would still be numbers in SoilDrillTime anyway. How does LRR determine from that that it’s supposed to get a Drill upgrade or not get a drill upgrade?
Maybe it’s UpgradeCostOre / UpgradeCostStuds. Good guess, but it isn’t. It’s controlled in a different file entirely!

 

 

the AE file!

 

 

 

AE files control graphics. More importantly, they control graphics in such a way that if you fail to specify graphics the function will fail to execute.
Let’s take a look at the Rapid Rider (SmallCat), as it’s the simplest. It’s a bit big for me to be able to paste it out here in full.

The top stuff specifies some nifty things that we’ll get to later. Scale is handy for bodging monsters. Also, all vehicles need 4 wheels or the game doesn’t know where they go. For an example of wheels not working correctly see this: https://www.rockraidersunited.com/topic/1740-frozen-wheel-frenzy/?do=findComment&comment=34469

Then there’s some stuff about mediumpoly { and highpoly { , and in other files there’s FPPoly { , which can come in handy but isn’t necessary unless you’re trying to change the look of a vehicle (which is beyond the scope of this document).

Next is Upgrades { , which we’ll get to in a moment. What we want at the moment is Activties!


This specifies what the vehicle can do. So the SmallCat (Rapid Rider) has:

     Activities {
            Activity_Stand                            Stand
            Activity_Route                            Drive
            !Activity_HitLeft                         HitLeft
            !Activity_HitRight                              HitRight
            !Activity_HitFront                              HitFront
            !Activity_HitBack                         HitBack                
            Activity_TeleportIN                             TeleportIN

      }

The left column is an internal name for the activity. Stand means idle, Route means move, and most of them are self-explanatory (at least if English is your native language). The right column is just a label identifier for later in the file. So just below this for instance is

      TeleportIN {
            FILE        SC_Teleport
            LWSFILE           TRUE
            LOOPING           FALSE
      }

FILE specifies the name of the Lightwave .lws (LightWave Script) that is the animation. LWSFILE is always set to TRUE (don’t know what it does). LOOPING turns up occasionally but seems ignorable. There’s also TRANSCOEF, which seems to be a speed up/slow down parameter for the animation. 0 (and 1?) mean no change. I haven’t toyed with this but you’re welcome to.

So the Rapid Rider can stand (idle), route (move), get hit, and teleport in. Not much, eh?

 

 

In a lot of these cases the game defaults to the idle (or just the first? I don’t actually know) animation if you haven’t specified it for instance, with Carry (which you can specify, at least if monsters and raiders are any judge) the game seems to know to default to the move animation. Which is nice.

 

 

I don’t know what the exclamation marks do, so don’t ask me.

 

 

However, the .ae also determines what a vehicle can do. If you want it to be drillable, you’ll need to add Activity_Drill. If you want it to shovel, you’ll need to add Activity_Clear. If you want it to carry vehicles, you’ll need to add the activity for that too. (Just grab it out of another vehicle’s .ae file to know what you need to do).

 

 

At this point it’s worth noting the full list of vehicle functionality:

  • carry ore and crystals
  • carry small vehicles
  • drill walls
  • have a laser
  • clear rubble
  • scan things

Until LRR 2 comes out, it is impossible for vehicles to be able to do anything else. So these are off the list, for instance:

  • reinforcing
  • picking up studs
  • smooth Power Paths
  • automatically zapping monsters on Action Stations
  • anything that isn’t a functionality of an existing vehicle in LRR

However, it is possible for one vehicle to do all of these at once! https://www.rockraidersunited.com/topic/8467-hover-scout-upgrade/

Although curiously if a vehicle is carrying something it is unable to drill, clear rubble. Dropping the cargo enables drilling again. This is probably why the Small Digger has no Carry functionality. (This is also why the Loader Dozer carry sucks hard as it’s impossible for it to shovel whilst carrying)


 

However, what’s also needed are these things called nulls. These basically define where stuff goes. For instance, the Small Transport Truck has a null to define where its wheel goes. It has another null to define where the driver goes. It has another null to define where the camera goes.
More usefully, it has a null to define where its resources go. Actually, it has a null to define where one resource goes. It has 8 more nulls too. Wait, 9 total? Yep. It has 3 for the initial carry. But then its 6 upgrades are in a different spot meaning it needs more nulls for that. That’s what CarryStart does in the CFG it specifies the null offset for carry nulls.

 

A carry null isn’t exactly necessary as if you leave it out the resource will graphically just stay at the position you picked it up, but be with the vehicle so you probably want one anyway.

 

A drill null is also necessary. Not entirely sure why, but you’ll need it.

 

These nulls are defined in the .lws file for the activity. Editing .lws files properly requires LightWave, however it’s super easy to add new nulls in Notepad!++. (I highly recommend this tool over Notepad. It’s fantastic!). You'll probably want to add your nulls to the move and stand animation, but don't bother with the Hit ones unless you really want to - the stuff will just disappear for that animation and come back when it's finished. (This is why the STT drops its cargo when hit: it doesn't have carry nulls in its hit animation!) Also, you can point multiple activties to the same file, which is nice.

 

Take a look at SmallHeli\SH_Hover.lws . There’s a whole bunch of interesting stuff which we don’t really care about but we’re interested in the nulls. Somewhere you’ll find something like

 

 

 

AddNullObject CAMERANULL
ShowObject 8 7
ObjectMotion (unnamed)
  9
  2
  0 17.12506 -71.58105 0 11.9 0 1 1 1
  0 0 0 0 0
  0 17.12506 -71.58105 0 11.9 0 1 1 1
  30 0 0 0 0
EndBehavior 1
ParentObject 1
ShadowOptions 7

 

 

I don’t know what most of this does but I do know this much:

0 17.12506 -71.58105 0 11.9 0 1 1 1

This controls the position and probably rotation of the null. The co-ordinates are of the form

X Y Z ?????????????????

 

That is to say, “side-to-side” “up-and-down” “forward-and-back.” So you can see that this camera null is quite high up and quite far back, and I don’t know what the other numbers do.

 

So, if we want a carry null, we might write something like this:

AddNullObject CARRY_NULL
ShowObject 8 7
ObjectMotion (unnamed)
  9
  2
  0 5 -11 0 0 0 1 1 1
  0 0 0 0 0
  0 5 -11 0 0 0 1 1 1
  30 0 0 0 0
EndBehavior 1
ShadowOptions 7

And we would paste it at the end of the null list. Pasting it in the middle causes things to break occasionally as occasionally nulls reference other things by their position in in the list, so don’t interrupt it.

 

And we can now define it up the top of the .ae, like so

 

CarryNullName                 CARRY_NULL
CarryNullFrames               1

If we had multiple carry nulls we’d adjust CarryNullFrames accordingly.

The same idea goes for adding a drill null!

 

If you’re adding a null to put a laser there’s a little more work you need to do in the .ae file. Just copy and paste it from the other vehicles with lasers, but it seems you need

 

xPivot                              Rotator
PivotMaxZ                     0.3
PivotMinZ                     -0.3
FireNullName                  Fire_Null

 

 

You don’t need to make a null and call it Fire_Null. That line just needs to exist. Similarily xPivot and Rotator have nothing to do with the .lws file. There’s probably more that could be played around with here (probably allows you to mount lasers on the side of something, like yPivot, but I haven’t needed to try this).

 

Now, what if you want upgrades? Well, even if you don’t you still need to specify what happens at the “no upgrades” level!

 

 

Most of the stuff is pretty explanatory. Take a look at SmallHeli.ae :

 

Upgrades {
                  ; '000' represents a three bit binary number for each type of upgrade...             
                  ; All the parts in every section will be removed when any other level is selected...
                  ; Format (No spaces are allowed in the second column:
                  ; <Upgrade part (defined in Lego.cfg)>    [TAB] <Null object name>,<Null instance (1-n)>
                  ;     Object                  Null

                  ;Binary sequence order is [carry] [scan] [speed] [drill]
                  ;therefore a vehicle with carry and speed upgrade will be 1010

            Level0000 {
                  ROTORS                        Blades_NULL,1

                  ;NO UPGRADES AS OF 9/11/98

            }

 

This defines what to put where. In the case of the SmallHeli, it’s just putting the rotors on the first Blades_Null. There’s one more thing if you want to put a laser on a null you specify the WeaponType (from WeaponTypes { in the cfg) you want it to use after that. So

BIGlaser                      BM_TurretNULL,1,BigLazer

 

“What” can be anything as defined under UpgradeTypes { in the .cfg . In particularly, Sbucket is a handy bucket that you can put on a vehicle. You could mount anything on anywhere!

 

 

Most of this is pretty straightforward. Copy and paste, fill out stuff as you think it’s necessary, add your new things, and so on. You’ll need to do this for every combinations of upgrade.


If you leave out a combination here, it just means that when you upgrade to that combination none of the stuff that should be showing will be showing.

But now! If you try out your new vehicle, it can now upgrade! Yep, whether a vehicle can upgrade or not is defined in the .ae file.

 

 

It’s very easy to break this by leaving out something anywhere. If you want an example, take a look at Hover Scout Upgrade: https://www.rockraidersunited.com/topic/8467-hover-scout-upgrade/


(Still got to troubleshoot its carry upgrade)

 

 

And that’s mostly it, I think!

I wrote this while tired so I may have forgotten something important :P

 

 

EDIT: Yes, there was one more thing! The driving animations are handled somewhere entirely differently - Pilot.ae . I'm not too sure what's going on there either but if you try and copypaste an existing vehicle you should be all good.

  • Like 3
Link to comment
Share on other sites

I'm still reading through the first post, so I'll add addendums here and keep editing until I get through all of it. I'm finished.

 

Quote

PickSphere is the radius from which it can pick things up. Mostly relevant for things like raiders and monsters, as vehicles just drive over to stuff and it goes into their bucket (more on this later).

PickSphere is used for the size of the selection box around units, as well as their collision for the mouse. If you set it to zero, you cannot directly click on the unit to select it. You must click and drag. Generally, units pick up things either by putting their origin directly over the object's origin (trucks picking up materials), or by putting a specific null on the target object's origin (monsters, Cargo Carrier). But I remember that, sometimes, units don't need to move to pick up nearby materials if they are close enough. Maybe it uses CollRadius. I haven't tested that.

 

 

An easier way to explain the vehicle upgrade system, if you understand binary, is to consider that upgrades are (probably) stored as four bits.  If 0000 is the beginning state of the vehicle, then 0100 is an upgraded state. It goes like [Carry][Scan][Speed][Drill], so that upgrade state is a vehicle with a scanner and nothing else. 1001 means it has a carry and drill upgrade. 1111 means it has everything. Since Carry is first, you can ignore it if the vehicle has no carrying ability. That's why the SmallDigger has eight levels and the SmallTruck has sixteen. 0111 is 7 in decimal, and 1000 is 8. The SmallDigger's level variable will never go higher than 7, so you don't need to specify anything further than that.

 

 

Quote

It has another null to define where the driver goes

This is false but I wish it were true. Any driver nulls you see are unused. The driver is always positioned at the origin and his animations are manually synced to the vehicle's. This is extremely annoying as it means I have to copy a blank raider to a new vehicle, position him, tie him to the null I'm using to animate the vehicle, then delete the vehicle (without deleting that animation null) and export the raider animation. I can't just sit a raider at the origin. Repeat this for each of the vehicle's animations. If you ever looked into Time Raiders' files, you might see LWS files like "DigTankDrillCombined.lws". Anything with "combined" is one of these vehicle-with-raider animations I saved before deleting either the vehicle or the raider. If I ever make revisions to the vehicle's animations, I use this file.

 

 

Quote

A drill null is also necessary. Not entirely sure why, but you’ll need it.

The game checks to see if this null collides with a wall to know when to start drilling it. It has to be out far enough because the null rides up the wall... sometimes. The specifics are still unknown to me. Some vehicles like to ride up walls and others don't. There are also differences between first and third person drilling.

 

 

Quote

This controls the position and probably rotation of the null. The co-ordinates are of the form

X Y Z H P B X Y Z

X position, Y position (height), Z position, horizontal rotation (clockwise positive), pitch (downwards positive), roll (anticlockwise positive, labeled as B for some reason), X scale, Y scale, Z scale

 

 

Quote

You don’t need to make a null and call it Fire_Null. That line just needs to exist. Similarly xPivot and Rotator have nothing to do with the .lws file. There’s probably more that could be played around with here (probably allows you to mount lasers on the side of something, like yPivot, but I haven’t needed to try this).

These values do correspond to an LWS file. They are used by the laser object that gets tacked onto the vehicle. Rotator is a null that is a parent of every object in the animation, but you can use anything from the animation as long as everything else is a descendent of it. Fire_Null is where the laser shot is spawned. These MUST be specified correctly or the laser will not work right. It will not rotate and it will not create the laser shot, but it may still fire if you click. Usually the laser sound plays and nothing else happens. I don't remember ever messing with yPivot.

 

 

Quote

What we want at the moment is Activities! This specifies what the vehicle can do.

The funny thing about this is that, up until recently, I thought this was true. It's actually false, which sucks. Activities merely allow you to specify an animation for a given activity. The actual activities are hard coded by object type. I discovered this when trying to make a raider type that could only do a limited number of things. I will post my findings here because CYREM HID HIS TOPIC FROM PUBLIC VIEW

 

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

 

There's something interesting about raider types that all of you should know if you decide to pursue your own additional raiders in the future. It seems like the activities that objects can do are not limited by the Activities listed in the object's AE file. The real factors are a combination of CFG entries and (assuming) hard code. I created a brand new raider type with only a few basic activities to see if it was possible to limit what it could do, but the game doesn't ignore missing activities. So while this new raider will pick up and drop materials as expected, since it has the right activities and animations...

 

large.Minimovers.png.e3439eda9943184e80a

 

...it will also drive vehicles even though there's no activity. Also, things like teleportation and training/upgrades happen instantly since there's no animation defined (which is specified by the activity). The result is a floating robot that does everything much more quickly than the standard raider.

 

large.Minidriver.png.e2d5f6571361be895c8

  • Like 3
Link to comment
Share on other sites

Nice, thanks for the clarifications! I'll edit those in at some point in time. :P

 

On 8/29/2019 at 10:19 AM, Cirevam said:

An easier way to explain the vehicle upgrade system, if you understand binary, is to consider that upgrades are (probably) stored as four bits.  If 0000 is the beginning state of the vehicle, then 0100 is an upgraded state. It goes like [Carry][Scan][Speed][Drill], so that upgrade state is a vehicle with a scanner and nothing else. 1001 means it has a carry and drill upgrade. 1111 means it has everything. Since Carry is first, you can ignore it if the vehicle has no carrying ability. That's why the SmallDigger has eight levels and the SmallTruck has sixteen. 0111 is 7 in decimal, and 1000 is 8. The SmallDigger's level variable will never go higher than 7, so you don't need to specify anything further than that.

Yeah, that's a much better explanation that what I gave XD

 

On 8/29/2019 at 10:19 AM, Cirevam said:

The funny thing about this is that, up until recently, I thought this was true. It's actually false, which sucks. Activities merely allow you to specify an animation for a given activity. The actual activities are hard coded by object type. I discovered this when trying to make a raider type that could only do a limited number of things. I will post my findings here

Ah yes, I remember your post. A little testing later, turns out I don't need to define an activity for Drill or Clear in order to drill or clear rubble. I'm not sure which activity it defaults to for the animation - it's either Stand (idle) or Route (move). Certainly for Carry it defaults for Move. In that case, it's determined by the .cfg and whether you specify ClearRubble as well as WhateverDrillTime.

 

I also discovered something similar with monsters. Adding Activity_Gather automatically adds all the Rock Monster AI (compare with Small Spiders or Bats): all of it. Sleep, wake up, smash buildings, try and make rocks, go into walls, and presumably come out of walls. The rock functionality is a little silly due to no Carry nulls being specified - so they go to glitchily make a rock (which doesn't succeed) and then go off to smash a building in melee.

(A monster that doesn't sleep should be possible by specifying an insanely large WakeRadius in the .cfg, so it wakes up automatically)

 

One more thing I didn't mention: deposit nulls. These are needed if you want vehicles that can carry resources. They seem to specify the position where the unit goes after it drops something off in the Power Station or the Ore Refinery. I seem to have good results with a deposit null that looks like this:

 

AddNullObject DEPOSIT_NULL
ShowObject 9 7
ObjectMotion (unnamed)
  9
  2
  -8 0 2 0 0 0 1 1 1
  0 0 0 0 0
  -8 0 2 0 0 0 1 1 1
  27 0 0 0 0
EndBehavior 1
LockedChannels 3
ParentObject 23
ShadowOptions 7

The co-ordinates are probably the most important part: off to the side and forward a bit.

 

Specify a deposit null incorrectly - not sure what 'incorrectly' means - and when dropping stuff off in the Ore Refinery / Power Station, the vehicle will freeze. You can get it out of this state by going into 1st person mode, driving around, and then giving it another order or two. I saw this bug once in vanilla LRR, oddly.

Link to comment
Share on other sites

Deposit nulls are used to position the Pilot when exiting a vehicle, but I would not be surprised if they pulled double duty. The nulls aren't strictly necessary for vehicle function. I opened up a drilling vehicle I'm working on and it does not have a deposit null. But... it's a drilling vehicle. Maybe they're necessary for cargo vehicles. Perhaps we could look a little further into that.

Link to comment
Share on other sites

  • 1 year later...

I never fully got to the bottom of this, but it seems that whether a monster behaves like a Small Spider (walk around randomly) or a Rock Monster (starts sleeping in caverns, picks boulders from walls, etc) is determined by whether it has certain entries in its ae - particularly Emerge.

 

I didn't find a way to have a Rock Monster behave "aggressively" (as in, actively hunt out buildings) without having the pick-up-boulder jank (which causes silly results if the animations aren't actually set up to carry anything).

Link to comment
Share on other sites

 Share

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.