0 Members and 1 Guest are viewing this topic.
8/14/2014: Structure building. API and server core not under development yet.8/15/2014: API building begins. 8/16/2014: Events added. Begining work on definitions.
My layout is defined below.CLASS NAME: Class Description Anything tabbed denotes a sub-class The sub-class description appears before the first hyphen (-) Anything with a + before it means it is a method associated with the given classThis File's purpose: This file is to contain a basic layout of how the structure is built. Applying Micro-organizational structures to allow macro processing in a hopefullyefficient manner.===================BEGIN CLASSES==========================================API CLASS OBJECTS=======================EVENT: An "event" is anything that requires a process to complete. These will consist of the majority of the way's a plugin interacts with the server. Ordered Event's - Must be executed in a specific order. Event Node - a component that defines a piece or whole of an event. EX: Player clicks an object 5 tiles away, there would be two event nodes, one for the walk to and another for the event. They are FIFO queued. If player walks away before they reach it, the Queue is broken, and a new process takes place. Target Node- A part of an interaction event node. A "target" means there is only one "item" (item, ground item, NPC, button, etc.) involved. Ground Target - any kind of interaction event that has something on the ground, that requires coordinates is considered a ground target. Ground Item Target - an Item that is on the ground. (Pick-up, Light (logs)) Ground Object Target - an object in the world players can interact with(Open-up Bank, Chop tree, ETC.). Inventory Target - any time there is only one item involved Player Inventory Target - An item in the player's inventory interface. Menu Inventory Target - Any other interface(Game window and inventory locations, not chatbox) that has item's in it. NPC Target - An event node that says you wish to interact with a given NPC. EX: Talk, quick-start(minigame), open bank, pickpocket,Attack, etc. Player Target - An event node having to do with interacting with another player. EX: Walk-here, Follow, Trade, Duel, etc. Recipe Node - Not necessarily a disaster, until it comes to the programming. A nice way of saying, using something on something else. EX: Item on item, Item on Object, Spell on item, spell on object, Spell on NPC, Item on NPC, ETC.. Ingredient - Part of any recipe. It needs at least two things(otherwise it is a target). Item Ingredient - an Item that is used as part of a recipe. NPC Ingredient - using a spell or item to interact with an NPC. Player Ingredient - using another Ingredient on a player (Spell or item mainly) Object Ingredient - using a spell or item to interact with a game Object. Requirement - passive part of a recipe. Like an ingredient, you must have it for a recipe to work. Level Requirement - a level required for the given recipe. Quest Requirement - a stage requirement of a given quest must be completed. Abstract Requirement - Make your own :P Walk To - Walking to any location in the world. Animation - Show what the player is doing. Node so it can be strung into parts. NPC Chat - Talking with an NPC - this will allow it to be built individually. Allows queuing next one as this one terminates. Consider talking to an NPC as a single event. Broke into manageable parts. Login - Handling the process of a player connecting to the server. Death Hook - What is executed when player's health reaches 0. - Typically runs as animation, dropped items, then teleport/reset anim. Logout - Handle the process of what needs to happen when a player disconnects. Kicking from minigames/canceling further tasks/Saving the character/ ETC. Abstract Event +preprocess - happens once on start +process - happens as needed. +post process - happens right before the event is killed. Cyclic Event - An event that after executing the process() method will be re-queued for execution. Will use Date objects in sync with the server's calendar for timed executions. SKILL: A class that will denote that there is experience and levels involved. ====================SERVER OBJECTS====================SKILL MANAGER: How the plugins will access a given skill. Skills are mapped with their index (as defined by client). (hitpoints = 3, attack = 0, etc.)ENTITY: Any in-game that has a coordinate and is changeable/controllable/movable. Living Entity - Anything that has life, and can die - contains death hook NPC - any "character" in the game that has an on-board brain. Player - any "character" in the game that has to process packets. Client - a player is controlled by an outside source Server dummy - player is controlled by the server. Morphable Entity - An entity That has a setting ID associated with it. Note that an NPC can be living and morphic.<<>>EXPAND THIS<<>> Objective Entity - Any kind of object that has a task associated with it. "Climbing" a ladder. PACKET: An event that must be handled that has to do with client-server communication. Incoming Packet - Any packet that is from the client. Object Actions - Interacting with an object in the world creates one of these packets Item Actions - interacting with an item will create one of these packets Ground Item Action - Clicking an object on the ground will create one of these packets. Inventory Item Action - Clicking an option on an item in the player's inventory will create one of these packets. Menu Item Action - clicking an option in a menu on an item will create one of these packets. (Bank All, Sell 5, ETC.) NPC Actions - Player interacting with an NPC will generate one of these packets. (Talk, Pickpocket, ETC.) Use Item Actions +On Ground Item +On Object +On NPC +On Player Use Spell Actions +On Ground Item +On Object +On NPC Command Action - ("::") Button Action +Button Action +Alternate Button Action - the other packet associated with clicking a button. packet 134 i think in 317? Walk To +Game window walk +Minimap walk ====================LAYOUT AUTHORS====================Matzie================DISCLAIMER================Nothing is set in stone. Not all suggestions will be accepted.
smart phones are dumb
would be nice if there was a plugin API specification that others agreed on and implemented in their sources
are you going to be using version control so we can see the code?
Quote from: lare69 on August 15, 2014, 10:46:24 AMare you going to be using version control so we can see the code?PM me by chance about what you are talking about and i may be able to set that up. I do have very poor internet though, so i can't use too much of the bandwidth :lEDIT: I am doing this in java because that is where my talent lies. I hope to be able to work on this for at least an hour a day.
Wasn't this the goal of Apollo
I would very much like to get this online, so i could have input as i am going. It would suck to start something i been working on for weeks, "doesnt work" FML. I really wont figure out my downfalls until i start the server implementation, and i can't begin that until i finish the API.I never even heard of apollo lol. Think i may of seen one post about it, but then again most of the time i am in the help threads.
It would be arguably the best emulator ever written if it had functionality beyond trying to be scalable and the plugins weren't so raunchy.
Reloading plugins without restarting the server should not be a priority at this stage.You're not dealing with a production environment subject to service-level agreements so you shouldn't be worried about it at all.Besides, in the real world you would stage your changes first (in a test environment), make sure they work, and then do a scheduled deployment to the production environment during off-peak hours. You certainly wouldn't change the production environment's configuration on an ad-hoc basis.So to conclude: Don't sweat plugin reloading.
Quote from: Lothy on August 16, 2014, 10:29:50 AMReloading plugins without restarting the server should not be a priority at this stage.You're not dealing with a production environment subject to service-level agreements so you shouldn't be worried about it at all.Besides, in the real world you would stage your changes first (in a test environment), make sure they work, and then do a scheduled deployment to the production environment during off-peak hours. You certainly wouldn't change the production environment's configuration on an ad-hoc basis.So to conclude: Don't sweat plugin reloading.That is a lengthy way of saying "low priority goal" lol? I know right now i am just focused on getting the content of the API. There are a lot of different aspects. A lot of them are hard to think of off of the top of my head ._.What does a player/npc/object/item/skill/etc. all contain?I need to make sure i hit the main points so this project can hit the ground running.If anyone could post a list of things like this it would be very useful!Something like my little section in the first post. I am trying to decide on a way of handling "uses" at the moment.(Use - [on/with] -)