Leaderboard

Yo! I just had a Call To Arms about this thread from Cyrem, so figured I'd have a think about this to see if anything comes to mind... Firstly, a brief explanation of how (I can best remember) the RR tasks work... Each RR/unit has a task list which will be added to based upon the priority list. IIRC the tasks are as granular as "walk here", "pick up ore", "get in this vehicle", "fight this RockMonster", etc... Hitting Call To Arms will always pause the task list, and set it aside. This you may all know already, but I'm also using this as an opportunity to remind myself. I would say this this is almost certainly true: Now, as for the cause of the Idleness Syndrome, I would speculate that you have probably already touched on likely causes in this thread... Task list buffer max-size/filling up: This is certainly possible, however I don't recall such a limit being in place (and I believe this is something we would have spotted as being the case during development). I'm pretty sure this is a dynamic linked-list, so should be able to grow pretty much unfettered. Task duplication: Again, I wouldn't rule it out, however I would probably err against this as being the cause, since there were always "is this possible" checks performed both when adding tasks to the list, and when performing them. Actually... I just had one thought in a similar line of thinking that could still be feasible... Path-finding: I'm actually leaning towards this being behind this problem, at least in part. When a unit is told where to go, their path to get there is determined ahead of time, and "refined" as they move (i.e. if something gets in the way, or the map changes in some way). It is entirely possible that as the walkable-area of a map grows (i.e. from mining) and the need for walking large distances increases (i.e. fetching ore) that a situation is occurring where their tasks are coming into conflict. I don't think it would be as simple as trying to fetch ore that has already been deposited, however if <insert magic cause> here occurs, meaning they can no longer evaluate a path to their current task *but* the task still seems "possible" (and therefore active) then they could possibly enter the fugue state that you're seeing. This last item would explain why it occurs mainly for the minifigures, since they perform many more repetitive tasks that exist only for that unit-type, so if the conflict relates somehow to one of those specific tasks *and* pathfinding, then we're far more likely to see it than a vehicle that performs fewer repetitive tasks. Ultimately, I think this will likely be caused by 2 or 3 factors combining in a particular way (e.g. "something to do with pathfinding" + "something to do with ore collection" + "maybe something to do with priorities"), which then causes a backlog of tasks waiting to be assigned, meaning once units become idle they try to do the same thing and get stuck themselves. I know this doesn't necessarily provide you with an answer, but hopefully it may give you a nudge towards tracking it down. And if, at some point 17 years ago, this bug was somehow my fault... um... I'm sorry!! ?

I sometimes like to imagine that RRU was created not just as a place for mod-related research of LEGO Rock Raiders (branching into other classic games later), but also as a mandated group therapy and recovery program for sufferers of Idleness Syndrome. Have you never laid witness, and are curious about what exactly is Idleness Syndrome? The major symptom of the syndrome is that your Rock Raiders simply refuse to do anything, sometimes even disobeying direct orders. Even if you've got a cave full of crystals and ore to collect, possibly just an inch from the foot of a Raider, they'll stand there, gormless and stoic as their oxygen meter ticks away. At best, they'll get stuck in a loop of eating sandwiches, as if that'll kickstart their brain back into action. This thread is a space for us to postulate on what the root cause of this problem is. If you're a programmer, this might be a good chance to think about the way the internal AI logic handles task management. If you're a player of the game with no real coding experience, feel free to try and throw up your wildest ideas, even if you're not sure of how AI in games are programmed. We can't ever really know the answer for sure, but we might find a cause that's really close.

There are a couple facts I believe I've established in my own research; From the User Interface in-game, we can determine that there is the ability to dynamically assign priorities; that is, what your Raiders should be focusing on before anything else. Different Raider units can do different tasks, and in normal conditions, when unclicked or not following a direct order, Raiders will immediately do a series of different actions until there's nothing left to do. Certain priority tasks cannot be auto-assigned to a Raider. Raiders will not automatically drill or reinforce walls unless instructed to. Speaking in a Discord chat (which actually prompted this topic), Cyrem poked at the idea that the array of todos is not dynamic, but has a max size. Cirevam discussed the nature of how todos are actually generated, probably by scanning active items that can be interacted with in the world from the origin (the top-left corner). I pondered the connection of the priorities setting. I suspect that from the collective of all Raiders on the level (whom I will refer to as the "Hive") every individual Raider (whom I will refer to as a "Peer") pull their orders (called "Tasks") from an array of all tasks to complete at any stage of the level. Tasks are created, stored in the array and then assigned to individual units when they require a new one. Giving a direct order to a Raider likely cancels their current task (or moves the current task back into the array) and feeds them the personalised order. I suspect that Idleness Syndrome sets in regarding the way every peer gets a new task and how the array of tasks is maintained. I have two predominate theories on how this could play out: One possibility is that new tasks are generated during play. An example, if you drill a wall, ore and sometimes crystals spawn. When these items are spawned, tasks are automatically generated and saved to the master array for handling these objects, such as bringing a crystal back to the Tool Store. This system might have a major oversight, where when a player gives a direct order, it is not checking to see if there already exists a task for that object in the master array. This creates a duplicate task which the Raider completes, and with enough of these, the master-array is filled with duplicate, incompletable tasks as the required object no longer exists. This system might have an oversight where the array, given that it has a max size, may simply have too many elements inside it, and so new tasks get lost and forgotten as older tasks (which might be blocked by paths that can't be crossed, for example) haven't been cleared out to make space yet. I shudder to think, but it might be a possibility that the system never actually cleans up the array or attempts to shuffle elements down or put new elements at the beginning, and once you've reached the maximum automatic tasks, gives up. The second possibility is that tasks are not generated dynamically, but at specific "intervals", at which point the game scans the level to determine what needs doing, and organises the master-array with all the tasks ordered by the current priority set (that, or there's a controller responsible for scanning through the master-array to determine the best task for an individual peer requesting something new to do). The system might encounter a scenario where it fails to refresh. If the system is setup to refresh based on a timer, when a unit requests a new order, when the master-array is empty or so forth, it might be possible that the system tries to determine if a task is actually accessible or not, or other factors. It's possible those factors are too strict, or the refresh functionality is designed to fail silently if it encounters something it didn't expect, leaving the array destined to never be fixed. If the system is setup to refresh based on a condition becoming true (as opposed to a regular interval timer), then if that condition never becomes true, no new tasks will be generated. For example, if a bunch of incompletable tasks are in the master-array and the system will only refresh when the master-array is empty. If the developers used some kind of "time-out" system to stop refreshing the master-array if it's taking too long, then maybe it's just that the time-out is too fast. The tl;dr of that whole chunk is that I think it's very likely an oversight on the behalf of the developers, possibly even a known bug they didn't have time to address.

I’ve recently experienced this issue on a new level I’m making. After 40 minutes of testing a level, all my RR’s going idle midway is infuriating. #1 My first theory that needs testing is that it’s to do with the amount of objects in existence on the map. Usually when this has been occurring, my map has been full of ore laying everywhere. In real life we might call this choice overload, but it may seem that in LRR a choice overload results in nothing getting done. I guess to test this theory I need to get a lot of ore on the map and see if I can cause this quickly. #2 My Second theory was that, the game is assigning the RR’s to do tasks that is not possible for them to perform. For example, the task list is full of "ore pickup" commands for ore that is on the other side of lava or water. Then game gets stuck where it continuously assigns these tasks because perhaps they are the next that matches whatever conditions the game picks by, but they can’t actually be performed.

Does the following event also count as idleness syndrome? I thought, that this might be also be helpful: I remember, that I once played an ice level (the one with the invisible lava erosion) and I wanted to play longer on that map. Therefore I deactivated "collecting crystals" in the priority menu and the Rock Raiders did other tasks like collecting ore. After a while it got boring and I turned the "collecting crystals" task on, but apparently they forgot, what crystal were since they didn't collect a single one. I also tried things like turning everything off except collecting crystals. I think, I also had transport vehicles in that level and I don't know, if Rock Raider also ignored crystals from buildings, that I teleported up. The details are blurry since this particular game happened ~ one to three years ago.

I know my post is basically "You're all wrong," but that's because I'm trying to dismiss theories that my evidence doesn't back. This post seems really harsh but my experience with LRR just doesn't fit your theories. No - Idleness Syndrome occurs even when your input into your LRRs is minimal - it typically occurs at the height of your mining spree when you're in first-person mode in a Chrome Crusher with four Loader Dozers and ten STTs behind you. Max size is an idea, but older tasks won't fit the bill - in maps where everything is accessible (eg vanilla Rocky Horror) and any task can be done, Idleness Syndrome still occurs. In which case Idleness Sydnrome should predictably occur with some variance - some games have completed without it, so that can't be right. My wild guess would be that the game scans for new tasks every tick - every time the NERPS executes. After all, demolish a wall on a new map when there's nothing else to do and your raiders will immediately start running over. All of those result in no new tasks being generated, ever. Yet Idleness Sydnrome occurs on a per-raider basis, and raiders can sometimes "snap out" of it (often by going into First Person view). No, Idleness Sydnrome never affects vehicles... unless it is the most severe of most severe Idleness Syndrome bugginess which is probably an entirely separate bug. All LRRs disappear off the map and those in vehicles will still work on.... some condition. I think the condition was that you never selected them, or selected them for a sufficiently brief period of time. I've only ever encountered this bug one on Baz's Mod Water Works, which is a colossal map. Wait, no, there's the idleness of STTs in front of Ore Refineries. This never happens anywhere else, and often everything else is fine, but that one STT will stubbornly sit in front of the Ore Refinery doing nothing. (Solution: teleport it up). Given Scorpions are entirely functional with minimal modifications other than their .ae being incomplete, LRR's development was rushed (as we know from Karl). I would suggest the latter. Now for a couple of other random bits that could be related: It is raider-specific. Some LRRs will do nothing whilst others continue unabashed. There is a maximum number of minifigures that can target a monster at any time - the others will stand around idly. I thought this number was 3 but then I saw only one Raider shooting a Monster with the other two happily standing by. Perhaps it has something to do with ore disappearing into the Ore Refinery? Idleness Sydnrome is... about... four? times worse on maps that have inacessible objects - eg Water Lot of Fun, or Fire 'N' Water. Try to build a base on both sides simultaneously and your LRRs work incredibly slow. A precursor to Idleness Sydnrome is that your raiders idle for a second or two, then perform a task. Just before Idleness Syndrome reaches its climax, raiders will walk to ore (automatically!) but not pick it up. The larger the map, the higher the chance of reaching Idleness Syndrome - I have not encountered it on extremely dense maps with a 200 crystal count Picking up all the ore in one cavern (with about ten STTs) seems to alleviate the symptoms, but will not stop it. I have never seen a no-carry Loader Dozer get Idleness Syndrome. I have seen them drive to one side of the map, clear one piece of rubble, drive back, etc. Fewer LRRs (I usually TP down no more than 25) seems to alleviate the symptoms Idleness Syndrome does not cause a crash Too many Recharge Seams (>5 is my estimate) causes a very specific variant of Idleness Syndrome - raiders that pick up a crystal will spazz between "recharge crystal" and "move." Drop the crystal, disable the priority, and things revert to normal AFAIK. _ _ Now for some rubbish theories of mine: Idleness Syndrome always takes a certain amount of time to induce - I have never seen it happen immediately. Despite the most careful strip-mining, taking care to pick up every piece of ore before continuing, it still occurs. This may be because I am mining too much before allowing the ore to be cleared - perhaps there is a limit of tasks, below which no Idleness Syndrome ever occurs? Something I have seen happen is raiders chasing other raiders (or a STT chasing a raider, heheheh) for their resources - or an STT chasing itself as per this. Perhaps this task is stored as "Incomplete and to be resumed later" and never cleared, hogging up the list? The game has no prioritization of close objects at all, as @Cirevam has very clearly demonstrated. This makes me suspect the game has "List of things to do" and "List of spare units to do them with." Perhaps it checks for units that are idling as defined in the .ae? If so, would removing the idle line in the .ae mean that automatic tasks were never generated due to no "idling" LRRs? However this doesn't account for vehicles almost never getting Idleness Syndrome. It's clearly tied to level size in some way, shape, or form - and not so much "crystal count" or "carefulness of picking up ore," it's just level size. It must have some random pathfinding elements, because it does not occur predictably on the same level - although this may not account for human interaction.

Does anyone remember if idleness syndrome affects vehicles? I remember it only affecting raiders, but it's been so long since I've run into the problem. As for the "todo scanning" hypothesis, I'm going to make some test maps to see if raiders choose the furthest task or if they choose the one closest to the origin. Maps like Frozen Frenzy and Rocky Horror both start in the south and can be prone to idleness syndrome. Maybe it's their size or the average playtime, but Cyrem's recent experience with his 25x51 map say otherwise. I created a 9x50 map oriented north to south, placed a Tool Store at the southernmost tile, then placed five pieces of ore spaced evenly north, from south to north. The raider got them in a seemingly arbitrary order: 35124, where 1 is the closest ore. I will run some more tests, but an initial impression is that the job manager or whatever it may be is creating jobs in a semi-random way.

Just thought I'd given everyone a heads up that via my requesting, compressed files, i.e. .qst (quest), .bmb (material), col, mbk, level.pkg, .txt files, you name it, can now be decompressed using QuickBMS after a month of hard work (in silence) from aluigi. Script: http://aluigi.altervista.org/bms/island_xtreme_stunts.bms If the program asks you: - the script has requested to load a function from the dll MEMORY_FILE3 do you want to continue (y/N)? (as some files will), say yes. Also, DON'T OVERWRITE files as some of them throw a fit on conversion, decompress them to a different directory. To recompress, open a blank text file and put this in it, and save it as any name with the .bms extension: get SIZE asize log MEMORY_FILE 0 0 put SIZE long MEMORY_FILE append log MEMORY_FILE 0 SIZE append math SIZE + 4 get NAME filename log NAME 0 SIZE MEMORY_FILE Courtesy of aluigi

This bug can be induced by using the Tunnel Transport: http://www.rockraidersunited.com/gallery/image/11845-disappearing-diggerpng/ Only time I see this is with the TT, and it happens with enough regularity that this could have been one of the reasons this vehicle was disabled in the original game. The only other time I've seen the bug is in the custom map uploaded here, Odyssey. I've determined that one Raider on an island (which has an energy crystal on it) will trigger the bug after a short period of time. Removing the Raider has resulted in the rest never disappearing. Since I mentioned Odyssey, I have found that I can "cure" Idleness Syndrome slightly after getting into the cavern accessible by land in the starting area. For some reason, the Raiders cease idling for the most part once I have freed the first trapped unit that I can reach. But, once every wall is drilled, and all resources collected (in that area), the syndrome returns. For the record, I witnessed two instances in the last few days of vehicles suffering from idleness syndrome but NOT the Raider driving them. First instance was in Gephyrophobia: Small Truck refuses to pick up anything and will drive around to new ore/crystals and sit there. This level is huge, so that might have played a role. Second instance was in Cornered: A Loader Dozer drove around to different squares and refused to clean anything. And it was an unupgraded one too. Granted, I did have a good deal of rubble to be cleared. And this map is massive as well. I've seen this once every few levels, and it isn't limited to Transport Trucks. Raiders have done this too, although sometimes I can't click on them. ---------------------------------------------------------------- Something I wanted to share is that from my experience, I've seen idling Raiders appear when a priority gets turned off, and then turned back on. This might be wreaking havoc with the pathfinding process, especially if the tasks are possibly getting screwed up by them appearing and "disappearing" thanks to the user turning things on and off. Any thoughts on this? Also, I've done a lot of experimenting with reactivating unused priorities, and I've noticed some differences in the performance of the AI and the number of occurrences of idleness syndrome. Maybe Idleness Syndrome is in fact related to pathfinding+priorities?

Just imagine... ... Imagine a computer game. More specifically, a real-time-strategy game. But not with medieval knights. Not with spacemen. No, something far better - with both. Both sides made out of Lego bricks. Imagine starting with the classic AOE three minifigures... Imagine harvesting Yellow bricks to build more minifigures.... Imagine harvesting Grey bricks to build weapons for those minifigures... ... and harvesting all sorts of bricks to start building small vehicles.... Imagine using those vehicles to harvest more bricks to build more vehicles.... ... to build war machines of destruction... ... And then imagine the other player doing exactly the same thing. Picture the carnage. Robin Hood's arrows bringing down giant alien spaceships, which are in turn bombing Aquanauts submarines trying to mine silver crystals to add a giant death beam to the Neptune Discovery Lab. Mars Mission tanks grabbing with Police Cars, and aliens walking away handcuffed. Pirate ships boarding submarines. Chrome Crushers drilling the front off those inferior Power Miners vehicles. Spamming Galaxy Squad speeders to fight off an unexpected invasion of tribesmen lead by Achu. Training "super units", like the MX-81 Hypersonic Operations Aircraft, only to find that your enemy has build the Mobile Devastator before you and has just wiped out half of your Aquanaut allies... ... and of course, destroying anything yields precious bricks back, so imagine sending a fleet of Small Transport Trucks to pick up the wreckage of the defeated Agent Bikes so you can upgrade your Chrome Crushers to have a second laser on them to defeat the second wave of inevitable Agent Bikes... ... and using those bricks to repair your frontline Exo-Force mechs with Mechanics while they pelt away at the Fire Station... ... then imagine starting LDD or variants thereof, and creating your own units... your own faction to bash the Ice Planet / Insectiods alliance with crossbows mounted on cars... expanding on tech trees of short-lived themes.... bringing new units to complement a strategic weakness... ... of course, the keyword here is "imagine," as I can't code for peanuts. But still. It's a nice idea to think about.

Man, I should Call to Arms more often haha Thanks for popping in and sharing some insight! Thanks for clarifying how the tasking system works, (RR's each having a tasklist rather than a global task system saying 'You go there and do this'). I guess we'll need to do more pathfinding testing with some big maps.

I performed a test on the case of too many pieces of ore on the map with a total of 1050 pieces exposed. However after collecting 200 they were still happily collecting the ore, without any sign of idleness. So perhaps it is not the amount of exposed ore, or the fact that there are too many objects to perfom tasks on. I am now going to perform a test on making an accessible toolstore, inaccessible... then teleport in a new accessible toolstore to see if this messes them up. EDIT: This also failed to make a difference.

Topic updated, all files and images are now hosted on RRU so the links shouldn't break again.

Screenshot of next version when it comes... Thank you.

@aidenpons! I thought it would be very important to inform you about the caos that occured regarding the follow on from the beginning of the orginal post given at a time that a member that joined many years ago posted about this website of recent times that since a certain Jimbob on no particular variety made a pience known as a form of artwork by the human species and how it was added to another form of medium used for conveying technical information such as it's been fixed. wot.