Node System - Why? [Stupid Question]

[hehegurl 13]

Hi! 

Used to dabble in scripting way back when, but lost touch and am interested in possibly learning a bit myself again. I remember back when I was more active (god.. 2011? maybe earlier? haha) everyone used a a state system for their main loop (some pseudo code below to describe what I mean).

main() {
	checkState();
	if STATE = BANK {
		do blah
	}

I see that using node frameworks are now what is heavily being used - excuse my noobness, but from my cursory looking at how nodes work they seem somewhat functionally the same in terms of function and the end result as the simple state system. Obviously there is a reason Nodes are superior, I'd love it if someone could perhaps briefly explain the benefits of using such a system.

Once again - sorry for the silly question but so far I've just read tutorials on how to implement node system - but with no reason *why* to implement such a thing.

Thanks to anyone who replies

[Milasoft 202]

Nodes are basically used to make the script more organized with cleaner code. I prefer to use the built in TaskScript framework over custom Nodes for simple scripts. Once you get into more advanced scripts, there are better ways to write them.

[Miami 369 7]

The benefits of using node system. For one you have have your TaskNodeClasses seprate. if you have them in your resource folder you can call them whenever you want. If you use TaskScript class the onLoop() method isn't forced on. Also if you create a class that is initializable and extends TaskNode. Each class can represent a skill like WCing or fishing. Or even something simple like dropping.  All you have to do is add these TaskNodeClasses into the task list.

The cons is that It get complicated, buggy, hard to debug, a lot of code...… I also feel like TaskScript is limited and is met for simple scripts. 

 

The benefits of using state system. Its pretty much the same thing. The TaskNodeClasses will become methods() and most of the code will be in one class. I also feel like you have more control in the way you call the States. You can also make simple and generic methods, that you can pass arguments for example fisher-cooker script:

The con, you may have a lot of code in a single class. 

        inside onloop
		switch(getState()) {
		case FISHING:
                status = "Fishing(): ";
                if (applyFish() && !isReadyToFishAny()) {
                    stop();//counter measure
                }

                FisherData.FishData currentFish = findFishingType();
                if (currentFish != null) {
                    status = "Fishing() list: " + fishingList.toString();
                    if (isReadyToFish(currentFish.fishType())) {
                        fishLogic(getFishingSpot(), currentFish);
                    }
                }
                break;
				}

	private void fishLogic(Area area, FisherData.FishData data) {
        if (area != null && data != null) {
            if (!area.contains(getLocalPlayer())) {
                walkTo(area.getRandomTile());
                log("Walking to spot: timer: " +timer.formatTime());
                sleep(700,1000);
            }
            else {
                openInvTab();
                if (getInventory().getEmptySlots() > miniAmount) {
                    status = "Currently fishing: " +data.toString();
                    if (location != null) {
                        NPC fishSpot = getNpcs().closest(location.npc());

                        if (fishSpot != null) {
                            status = "Let's interact with: " +fishSpot.getName();
                            if (timer.elapsed() > 3500) {
                                entityInteraction(fishSpot, data.action(), true);
                                //moves mouse off of screen after interaction.
                            }
                        }
                    }
                }
            }
        }
    }

 

 

[Milasoft 202]

10 minutes ago, Miami 369 said:

The cons is that It get complicated, buggy, hard to debug, a lot of code...… I also feel like TaskScript is limited and is met for simple scripts. 

It's actually very simple, not buggy if you write the correct code, a lot easier to debug instead of scrolling through 1000 lines of one class, and about the same amount of code just a lot cleaner. Also, you can extend upon TaskScript to add more functionality. I do agree it is more for simple scripts though.

[Nuclear Nezz 2107]

Using nodes is better for larger more complicated scripts, in my opinion.

I mean, not ours because you're limited on the functionality and control over the nodes and how they're ran, but I have my own node system I use, that I run through abstract script.

Generally my structure goes as follows

script->node managers->nodes
so you'd have BankManager which has Bank,Travel, etc
AttackManager which has equipment nodes, consumable nodes, and then interaction nodes

 

It makes it easier to read and debug because each section is completely separate from everything else. Breaks during banking? It's in your bank node. Breaks while walking to your combat place? It's in your combat manager->travel node

Plus at that point, if you structure your managers well, you reduce the amount of checks each iteration to find out what you should be doing.

eg: instead of running through 30 if/else before you get to your combat, you run through your 2-5 manager checks, and then your combat checks.

[hehegurl 13]

Thanks for your replies guys, I can certainly see the advantages of such a system in a complex script. Funny reminder when that old dungeon script got its code leaked and it was literally a single file, thousands of lines - must've been a nightmare to work on! 

[LogicSoup 92]

nodes r for losers who script!

onLoop() all the way