Author Topic: Building a New Module  (Read 655 times)

Legacy_Demkey

  • Newbie
  • *
  • Posts: 36
  • Karma: +0/-0
Building a New Module
« on: June 05, 2014, 04:26:01 am »


               

Hi everyone, I'm brand new to this forum, so if I'm breaking any protocols let me know.


 


I’ve started a module many moons ago but never finished it. I’m wanting to get back into the game and would love to host this as a PW in an almost pure Guild-based PVP server. I have most of the world created but I’m not familiar with how to make it an actual PW.


 


I have two questions; first, is it worth me finishing this module and putting out there? Is there enough of a player base still out there? Secondly; if there is a chance I can draw players over, what do I do in order to make this a PW? Is there a resource/thread here somewhere on this forum that can help me?



               
               

               
            

Legacy_MagicalMaster

  • Hero Member
  • *****
  • Posts: 2712
  • Karma: +0/-0
Building a New Module
« Reply #1 on: June 05, 2014, 06:55:45 am »


               

You're not breaking protocols, but you might have better luck with answers in the Modules, Scripting, or PW forum.


 


If you're hoping for hundreds of players then no, not enough of a playerbase.  If you're content with a few dozen players online at most if you're really lucky then yes -- but I wouldn't count on a large player count initially.  Also need something special to lure people to your server.


 


Making it into a PW mainly involves...


 


1. Stopping exp29oi$ts (break up the word so it's not searchable)


 


2. Enabling and using a server vault


 


3. Making sure your scripts/spawn system can reset on their own (or plan to reset the module daily or something)


 


4. Setting up your server so it can actually be logged onto by others


 


Others will probably have further and more detailed advice (just dashing this off), but if somehow no one else helps you I can get you more information and help within the next day or two.  Just short on time at the moment.



               
               

               
            

Legacy_Demkey

  • Newbie
  • *
  • Posts: 36
  • Karma: +0/-0
Building a New Module
« Reply #2 on: June 06, 2014, 03:24:01 am »


               

Thanks MM, 


 


Seems rather simple '<img'>


               
               

               
            

Legacy_BelowTheBelt

  • Hero Member
  • *****
  • Posts: 699
  • Karma: +0/-0
Building a New Module
« Reply #3 on: June 06, 2014, 04:18:33 am »


               

The key to making it a Persistent World is to ensure that your systems are persistent.  This includes banking, quest status, journal entries, the module calendar, etc... to cover all the data you need PCs to continue to have access to after the server reset.    It depends on how you store this data whether it will survive a reset. For example, data stored on the PC does not survive a reset while data on items or in a database, does.


 


Also, have a plan for solo players on your PW.  Make sure there's stuff for them to do while waiting for others to join.


 


The actual process of hosting it as a PW is fairly simple, though can be tricky to get the router configured correctly with the port forwarding, firewalls, etc...


 


Then, you need a website and a forum.  A PW needs a home for players to report bugs, schedule games, get updates, etc...


 


All in all, I'd say definitely give it a go.  There's always room for something new and different.



               
               

               
            

Legacy_Demkey

  • Newbie
  • *
  • Posts: 36
  • Karma: +0/-0
Building a New Module
« Reply #4 on: June 07, 2014, 04:42:57 am »


               

Is there a set of scripts out there that will help me implement and control the things that you mentioned?


 


My router is all set and I have the module already out there for a couple of my friend to help with testing.


 


I had a forum setup a while back for our guild that I was planing on just reconfiguring. I'm probably going to hold off  a bit on a website till I know we can go live with the module.



               
               

               
            

Legacy_MagicalMaster

  • Hero Member
  • *****
  • Posts: 2712
  • Karma: +0/-0
Building a New Module
« Reply #5 on: June 07, 2014, 05:35:06 pm »


               

Sort of, but there are tons of ways to achieve certain ends.


 


A very basic end is something like having monsters respawn -- but this can be done with respawning encounter triggers, manually resetting encounter triggers, a custom-built spawn system, or any of several spawn systems on the vault.


 


In other words, it would probably be better for you to list a specific issue you need to solve and describe how you want the general solution to happen and we can help with the specifics.



               
               

               
            

Legacy_Demkey

  • Newbie
  • *
  • Posts: 36
  • Karma: +0/-0
Building a New Module
« Reply #6 on: June 07, 2014, 06:53:20 pm »


               

The first one that comes to mind is something that auto-saves the players location if they leave the game.



               
               

               
            

Legacy_MagicalMaster

  • Hero Member
  • *****
  • Posts: 2712
  • Karma: +0/-0
Building a New Module
« Reply #7 on: June 09, 2014, 02:45:58 am »


               

That's not a subject I'm all that familiar with, but a solution would be to effectively store their location as a LocalLocation on a permanent item in the player's inventory.  Main question then becomes "when" do you update that location because when you leave I'm not sure if the "OnClientLeave" script can retrieve info from the PC that just left.



               
               

               
            

Legacy_BelowTheBelt

  • Hero Member
  • *****
  • Posts: 699
  • Karma: +0/-0
Building a New Module
« Reply #8 on: June 09, 2014, 03:52:36 am »


               

What I'd recommend is having an item that you automatically give to players to help with this.  Possibly you already outfit players with items, such as a climb tool or other 'system' tool that they won't try to drop, sell, your death system wont take, can't be pickpocketed, etc..  Essentially a plot item that's not droppable.


 


Then, periodically save the PC's location to that item.  After each rest, for example, and/or as part of each area enter script.  Lots of servers give PCs location-saving widgets that when used, allow the PC to save that exact location to augment the auto-saving that they've set up.


 


Then, when your PC enters the world, your OnEnter module script looks for that variable, say the "LastLocation", on the item and then moves the PC to that location.


 


This is how we set the do it in our area OnEnter:


 




object oArea = GetArea(oPC);
object oDatabase = GetItemPossessedBy(oPC, "database");
string sID = GetStringLeft(GetName(oPC),10)+GetPCPublicCDKey(oPC);
string sAreaTag = GetTag(oArea); // Sets up a string using the Tag of the Area


if(!GetLocalInt(oArea,"NoSave"))
    {
    vector vPosition = GetPositionFromLocation(GetLocation(oPC));
    int nAreaX = FloatToInt(vPosition.x);
    int nAreaY = FloatToInt(vPosition.y);
    int nAreaZ = FloatToInt(vPosition.z);
    SetLocalInt(oDatabase, "LocationSet" + sID, 1);
    SetLocalInt(oDatabase, "AreaX_" + sHID, nAreaX);
    SetLocalInt(oDatabase, "AreaY_" + sHID, nAreaY);
    SetLocalInt(oDatabase, "AreaZ_" + sHID, nAreaZ);
    SetLocalString(oDatabase, "AreaTag_"+ sHID, sAreaTag);    }


 


Then, as part of the entering script when a PC returns to the server after a reset, the below occurs.  I don't run it on the Module's OnEnter event, but rather through an NPC in the start area that grants access to the world.


 


        


string sID = GetStringLeft(GetName(oPC),10)+GetPCPublicCDKey(oPC);
        object oArea = GetArea(GetObjectByTag(GetLocalString(oDatabase, "AreaTag_"+ sID)));
        if (GetLocalInt(oDatabase, "LocationSet_" + sID))
            {
            if (oArea !=OBJECT_INVALID)
                    {
                    SendMessageToPC(oPC,"Jumping to your saved location");
                    DelayCommand(1.5, AssignCommand(oPC, ActionJumpToLocation(Location(oArea, Vector(IntToFloat(GetLocalInt(oDatabase, "AreaX_" + sHID)), IntToFloat(GetLocalInt(oDatabase, "AreaY_" + sHID)), IntToFloat(GetLocalInt(oDatabase, "AreaZ_" + sHID))), 0.0))));
                    }
            }

               
               

               
            

Legacy_MagicalMaster

  • Hero Member
  • *****
  • Posts: 2712
  • Karma: +0/-0
Building a New Module
« Reply #9 on: June 09, 2014, 08:06:29 am »


               


This is how we set the do it in our area OnEnter:




 


Like I said, I know next to nothing about this particular topic, but does SetLocalLocation not work for something like this?  Why do you need to break the location down into vectors and such?


 


The memory leak for location deal with recursive calls, I believe, so I assume it's not tied to that.



               
               

               
            

Legacy_BelowTheBelt

  • Hero Member
  • *****
  • Posts: 699
  • Karma: +0/-0
Building a New Module
« Reply #10 on: June 09, 2014, 02:07:47 pm »


               

I can't recall specifically, but do remember having issues that this solved.  Not sure if the issues were related to PC logout or a strange bug that would sometimes send PCs to the location, but in an area different than where they had saved.  This was 5 years or more ago, so I'm a bit fuzzy on the details.



               
               

               
            

Legacy_henesua

  • Hero Member
  • *****
  • Posts: 6519
  • Karma: +0/-0
Building a New Module
« Reply #11 on: June 09, 2014, 07:33:37 pm »


               

autosaving location across server resets is tricky because a location struct has the Area Object pointer at the start. I believe the function for establishing a location is


 


Location(oArea, vPosition, fFacing);


 


position and facing work as long as you have the right area, but oArea is an object which is a temporary item in RAM while the module is loaded. The next time the module loads this same pointer can very likely point to a different object or something invalid.


 


That is why for persistent locations the tag is stored instead of the object reference. There is another problem with this as well: tags are not unique. To solve this problem I often include area resref with the tag and then have a custom function which gets oArea from tag and resref. Basically you get every area by tag, and then sort by resref. if resref is not found, then i look for fallbacks.


 


All that aside, BelowtheBelt's solution is a good one.



               
               

               
            

Legacy_Shadooow

  • Hero Member
  • *****
  • Posts: 7698
  • Karma: +0/-0
Building a New Module
« Reply #12 on: June 09, 2014, 07:38:21 pm »


               


autosaving location across server resets is tricky because a location struct has the Area Object pointer at the start. I believe the function for establishing a location is


 


Location(oArea, vPosition, fFacing);


 


position and facing work as long as you have the right area, but oArea is an object which is a temporary item in RAM while the module is loaded. The next time the module loads this same pointer can very likely point to a different object or something invalid.


 


That is why for persistent locations the tag is stored instead of the object reference. There is another problem with this as well: tags are not unique. To solve this problem I often include area resref with the tag and then have a custom function which gets oArea from tag and resref. Basically you get every area by tag, and then sort by resref. if resref is not found, then i look for fallbacks.


 


All that aside, BelowtheBelt's solution is a good one.




summed up:


 


instead of saving complete location you need to disassemble the location to the area tag, X,Y,Z position and facing and store these values separately into database (SetCampaign*/SetPersistent*). Then next time when player logs in, you retrieve all these values and assemble location from it by a Location function


 


Plus - make sure your areas have an unique tag.