RPG

[Bennett 🚀]

So.. this will be possible?

[Simie]

How are you planning to securely communicate with the server side of things?

And also, don't make tables for each forum. Use 3 tables with a column for board ID in each. My report post code makes a table per forum and the database is full of tables with not much data in them.

[Jordan]

Oct 18, 2009 13:52:14 GMT -8 Bennett 🚀 said:

So.. this will be possible?

Will what be possible?

Oct 18, 2009 14:12:39 GMT -8 Simie said:

How are you planning to securely communicate with the server side of things?

And also, don't make tables for each forum. Use 3 tables with a column for board ID in each. My report post code makes a table per forum and the database is full of tables with not much data in them.

To be honest, I haven't worked all that out yet, but that's what I will be working on next. The main reason I started making this was because I wanted to learn php since I skipped it.

And would only having three tables save much space? The items table is going to have a lot of data by default.

[Bennett 🚀]

It being admin editable

[Jordan]

Look at the pictures I posted. ;P

[Bennett 🚀]

Oh, lol

[Charles Stover]

lol @ using a table for each forum. That's certainly _not_ how you do it. A table is supposed to record certain information (e.g. posts, members, etc.). If you have two tables with the same columns, you're doing it wrong.

Oct 18, 2009 12:10:23 GMT -8 Bennett 🚀 said:

Like the Money Hack code It's stored in the Custom Title or Sig

Yeah, but he can't do that if he's storing money server-side. If everything was stored in the custom title or sig, that would increase security (by calculating how much money a person has on each load [posts * moneyPerPost - itemsInProfileField * costPerItem]), but that would decrease functionality, as things could only be bought on screens where the users profile is edittable, and it would decrease/eliminate CT/sig space for the user.

jordan,
The best way I've found to secure information between the two is ecrypted keys. Using a custom encryption function, encrypt whatever the user is identified by (probably a combination of username and ProBoard ID), include a salt, and check the encryption for each action they try to perform.

[Jordan]

Oct 18, 2009 17:48:56 GMT -8 Charles Stover said:

lol @ using a table for each forum. That's certainly _not_ how you do it. A table is supposed to record certain information (e.g. posts, members, etc.). If you have two tables with the same columns, you're doing it wrong.

Alright, thanks. I'm learning this as I go because I've never used php before except for playing with it a few times.

Oct 18, 2009 17:48:56 GMT -8 Charles Stover said:

jordan,
The best way I've found to secure information between the two is ecrypted keys. Using a custom encryption function, encrypt whatever the user is identified by (probably a combination of username and ProBoard ID), include a salt, and check the encryption for each action they try to perform.

Sounds good. I may have you look at it when I get around to putting it together if you have time.

[Bennett 🚀]

-is excited for when this code is released- Will it really take much longer? Just PHP stuff and arranging incoming files? -is jittery now, as I want the code- Lol, this code would have been perfect back when I asked for a Pokemon RPG code

[Jordan]

It will probably be a few weeks since I need to improve my php. The first version I'm going to release will not have fighting because that will come later. It shouldn't be too bad, though, since you will still have player classes and stats, and you will be able to buy items and start a mini economy.

[Simie]

I meant how are you going to stop users from modifying whats being sent to the servers. It would be really easy to change using some FF plugins.

[Charles Stover]

It wouldn't even take FF plugins, but someone just confessed to using TamperData.

You can modify what's being sent, just like you can on ProBoards itself. But if done right, it won't matter what's being sent. If all the items and data are stored server-side, he could just check to make sure the user A) has enough money for the item B) has access to buy the item C) etc.
Just as one would calculate whether or not a user should see the menu to perform an action, he could calculate whether or not to allow the action to be performed.
if ($x && $y && $z) { /* show menu */ }
if ($x && $y && $z) { /* allow him/her to do action requested */ }

EDIT:
And this wouldn't be possible with client-side code, as I was trying to mention before, because you don't know what the requirements are for an action (e.g. for a custom item, the cost wouldn't be accessible, so the user could hack a custom cost if not protected correctly).

[Chris]

Good luck with this Jordan. I went and dug up my old RPG thread/board on SZ and here's some concepts I had:

Modify RPG Profile
About Your RPG
Battle Arena Layout (Video discussing how it works as well)

That's all that's still online unfortunately. >.< Hopefully those still help.

[Simie]

Oct 19, 2009 5:01:55 GMT -8 Charles Stover said:

It wouldn't even take FF plugins, but someone just confessed to using TamperData.

You can modify what's being sent, just like you can on ProBoards itself. But if done right, it won't matter what's being sent. If all the items and data are stored server-side, he could just check to make sure the user A) has enough money for the item B) has access to buy the item C) etc.
Just as one would calculate whether or not a user should see the menu to perform an action, he could calculate whether or not to allow the action to be performed.
if ($x && $y && $z) { /* show menu */ }
if ($x && $y && $z) { /* allow him/her to do action requested */ }

EDIT:
And this wouldn't be possible with client-side code, as I was trying to mention before, because you don't know what the requirements are for an action (e.g. for a custom item, the cost wouldn't be accessible, so the user could hack a custom cost if not protected correctly).

Any user could potentially send data pretending to be another user. ProBoards has the advantage of being able to authenticate the user with cookies etc.

It wouldn't even take FF plugins, but someone just confessed to using TamperData.

For dev purposes only

[Charles Stover]

Any user could potentially send data pretending to be another user. ProBoards has the advantage of being able to authenticate the user with cookies etc.

There is no unbreakable method of this. You can make it harder, but there is no absolute guard against it. To my knowledge, only one person has ever done that with any of my scripts, and they promptly stopped once I'd asked them too, so it was no big deal. Perhaps if ProBoards made an API, all would be well in the Internet kingdom.