A preserved archive of the Logical Gamers community forums, 2009-2025. The original threads and posts, served read-only. Registration, posting and private messages are gone for good.

POS Development Checklist

1.1k views · started by Chris ·
#1
POS Development Checklist

  • Pokemon Data File

  • Pokemon Data File Parser

  • Pokemon Value Holder

  • Trainer Value Holder

  • Pokemon Proper Statistics

  • Packet Builder

  • Packet Reader
  • Packet Handling
  • Map Creation
  • NPC Creation

  • Client GUI
  • Client <-> Interface
  • Client <-> Connection
  • Client Data Handling
  • Client Map Handling
  • Client NPC Handling
  • Client Multi-player Handling
  • Client Multi-player Battling
  • Client Multi-player Trading
  • Client Account Registration
  • Client Account Login
  • Client Hack Prevention
#2
Can you upload what you have right now?

Server & Client stuff please.

I can reformat the VPS and put the server on that for us so you dont have to leave your comp on constantly chris.


Also - I would like to do some of the 2d rendering stuff. (Map creation, NPCs, AI (artificial intelegence), stuff like that )
#3
Organization is needed! Each person can work on the same classes by developing independent functions! But we all know that, do we?
#4
Well, we could use an SVN.

Or split up the project so that every person does a certain thing.
#5
"Client <-> Connection" We'll need the server information for that. If you keep it on your computer and leave your computer running we'll need your IP + the port you are using for the server, else if you use what Sk8er offered, host it on the VPS so we can just use that plus then we can modify it as much as we need.
#6
I don't think the server is done, or near being finished. Unless he started working on it before he mentioned the project here.

Anyways, Chris will be in charge of putting everything together, so whatever we make we should all have access to it here so we can critic and optimize the codes. :P
#7
Riddle I've been working on this project for 1 week.

I've already got all that (With your help with exp, and chad's with natures,) plus it can handle stable connections and other stuff.
#8
Thought you should know Chris. There are some problems with the .net Framework that the C# program is being made in. If the user does not have the framework installed it gives them an error thus you might either have to make a program that auto installs it or just tell them to. Either way.
#9
Chad wrote:
Thought you should know Chris. There are some problems with the .net Framework that the C# program is being made in. If the user does not have the framework installed it gives them an error thus you might either have to make a program that auto installs it or just tell them to. Either way.


I realized that.

The client will have a proper error message for that case.
#10
Or we could use C++ for the client? But C# seems so much easier to develop in. :P
#11
I think we should use C#. It's easier and I think it would be better because I guess we can all just code it faster?
#12
Well, I'm having problems running the current code with MSWinsockLib. So I was just thinking of switching MSWinsockLib to Sockets, which is part of the standard library for C#.
#13
1.) Use LocalPort. If you use remote port it'll throw errors
2.) Use a port thats not open. 2406.
#14
Chad wrote:
1.) Use LocalPort. If you use remote port it'll throw errors
2.) Use a port thats not open. 2406.


No, I mean that there's no MSWinsockLib in my library. It doesn't exist. I'm running Windows 7, that might be the reason.
#15
Install Visual Basic 6 Enterprise edition and it might fix it? Or download the vb6 library files.
#17
Nah Riddle I'm using the old controls :P

Sorry for the absence took a break over the weekend.

Development will pick up again.

Update;

Client <-> Server connection is working

Test Client is built!
#18
Nice.

I'm sorry I haven't been able to help much. School is priority. :P
#19
Can we get an update on exactly what you've done or what you're doing?
#20
I'm doing mass edits on the Socket class files.

I made a client hat connects to the server.

The server creates an instance of Game_Winsock.

Each instance handles all received packets for that user and anything that needs to be sent to that user.


I also am working on the packet interface, I have finished the first packet (Version Check.)

When the client opens it connects to the server, as soon as the connection is established the client sends the packet "00 + Client_Version" And when the server receives it is checks if the Client_Version is the same as the Client_Version set to be the latest on the server. If the Client_Version sent by the client is not the latest it returns the packet "00 + 0" if it is the latest it returns "00 + 1".

All packets are hexed and flipped before being sent.

So for example the clients version packet if the version was 1 would be;
"313030" (100)

Because it was flipped and hexed.
#21
how about instead of sending hexed packets which would be a great Idea you encrypt the functions with numbers instead.
Example;
challenge other person code would be 102195

or some other kind of code.
#22
Chad wrote:
how about instead of sending hexed packets which would be a great Idea you encrypt the functions with numbers instead.
Example;
challenge other person code would be 102195

or some other kind of code.


Each packet is a compiled set of data.

First two bytes is the header. (0x0000)
After that is a set of data.


The server and client have customized sets of handlers for each packet, verification's etc.

All data passes from Client <-> Server is editable. But if edited the data will be processed to the point where if edited, there would be no profitable outcome.

For example let us look at map to map movement.

Say user is in Map 1 and he needs to get to Map 5 but he would need to go through Map 2-4 just to get to 5. So he thinks why not edit the portal from Map 1 to Map 2 to take him to Map 5. The server will see this packet and check it against possible Maps to be moved to. If the user is trying to move from Map 1 to Map 5 (which the server will recognize is impossible,) the server would automatically boot/ban the user for hacking



If that did not make since I'll give you another example, lets look at wild Pokemon encounters.

So lets say on Map 1 you can only encounter Pidgeys and the user sends a packet from that map saying he encountered a Charzard, the server will check possible encounters and if it is possible to encounter that Pokemon on that Map, if it isn't the server will boot/ban the user.



So truthfully "Security" on packets does not need to be advanced for that much it needs basically no protection, the only reason I used hex packets is because it is an easy encryption and I have a lot of experience working with hex packets.


Now the reason we use Headers is because we can easily identify the packets.

For example;

Server -
Client Version Check is "00" ("0x0000")

Client -
Server Version Validation is "00" ("0x0000")


It will not always be the same number, because one process may contain multiple unique packets to properly work.



Another reason this helps is because it severely prevents simple hacks such as "Money Editing," we can prevent users from generating money even through Cheat Engine because the client always confirms amounts back to the server. And even if you spoof the packets eventually it will end with the sheer fact that if the server says you have 100 currency you can only spend 100.
#23
What Chris said is possibly the most annoying type of cheap security any MMO can have. Annoying to people trying to cheat, of course.

However, it works rather well.
#24
Riddle wrote:
What Chris said is possibly the most annoying type of cheap security any MMO can have. Annoying to people trying to cheat, of course.

However, it works rather well.


Yep. :P

Makes the majority of hacks LOOK like they are working, while in the end they had and never will have an effect.

There are a large possibility of possible hacks, all of which can be patched as they come.

Basically I am making it so that everything that is saved and permanent is handled 100% server sided.

Where only temporary data is showed to the client.

:P
#25
Might as well patch the Client side editing as well because if you can edit your gold amount just by using cheat engine you know people are gonna make hacking videos and scam members. Although the hack is not real.
#26
Chad wrote:
Might as well patch the Client side editing as well because if you can edit your gold amount just by using cheat engine you know people are gonna make hacking videos and scam members. Although the hack is not real.


That is extremely difficult. Unless we do some weird calculations to store client sided data. At least to my knowledge.
#27
Update;

Added some anti dll injection scripts. Not sure why, though it would be fun.
#28
XD

I guess it might protect against some types of bots (those that need to be injected into the program).
#29
Riddle wrote:
XD

I guess it might protect against some types of bots (those that need to be injected into the program).


My intent was to prevent cheatengine to load itself into the memory. But I need a better way to do it.

I am thinking about using a CRC64 encryption of all values stored.

So basically.

string Money = CRC64.Encrypt(999);

And it'll be something like "arj483ggi4l1"
#30
Can i has the mysql db and shizz? I kinda need it to run or build anything -.-
#31
Sk8er wrote:
Can i has the mysql db and shizz? I kinda need it to run or build anything -.-


There is no need for it atm I am working on Client Server interface.

I'll tell you if I need anything done.
#32
Maps are going to be in XML format for easy editing.

<root>
<map id="">
<info>
<name value="" />
<width value="" />
<height value="" />
</info>

<tiles>
<tile pos="" layer="" image="" />
</tiles>
</map>
</root>




For example here is a map with a floor layer of grass that is only 1 tile.

<root>
<map id="0000">
<info>
<name value="Test" />
<width value="1" />
<height value="1" />
</info>

<tiles>
<tile pos="0,0" layer="0" image="0,0" />
</tiles>
</map>
</root>



Information;

Pos : Map cords.
Image : Cords of tile on tileset.
Layers : 0-2 (Floor, Above Floor, Above Character)

Width : Actually is amount * 16.
Height : Actually is amount * 16.
#33
Hungers for an update. :(