Author Topic: Verible List  (Read 3346 times)

Offline evecolonycamander

  • Hero Member
  • *****
  • Posts: 602
Verible List
« on: April 18, 2010, 02:06:44 PM »
remember my trainer. well the program that allowed me to make it also allows the user to see any variable that the number is known to so i will post all the variables i have figured out. i will not release however the name of the program unless you are a moderator or a administrator. if you do not like this topic you can ask someone to delete it. i do ask how ever to be warned first by pm so i may save the variables my self first. the first variables will be posted within the week
« Last Edit: April 18, 2010, 02:57:55 PM by evecolonycamander »
''The blight cant get us up here!''
-famous last words
--------------o0o--------------
Outpost 2: EoM project status: Re-planning

Offline Kayedon

  • Sr. Member
  • ****
  • Posts: 378
Verible List
« Reply #1 on: April 18, 2010, 02:53:00 PM »
This topic makes me laugh.
One: Memory Editor
Two: Your constant change of "verible," "varible," "verable," all which are supposed to be "variable."


Humorous spelling errors aside... Did you miss what everyone else said?  
"Trust me, I'm crazy."

Offline evecolonycamander

  • Hero Member
  • *****
  • Posts: 602
Verible List
« Reply #2 on: April 18, 2010, 02:56:59 PM »
What?
 
''The blight cant get us up here!''
-famous last words
--------------o0o--------------
Outpost 2: EoM project status: Re-planning

Offline TH300

  • Hero Member
  • *****
  • Posts: 1404
    • http://op3game.net
Verible List
« Reply #3 on: April 18, 2010, 04:37:49 PM »
So, why are you going to post those variables? The only "use" I can see is cheating. And people are really smart enough to find a program that can do that, if they want to. In fact, I am afraid, anyone could right now search for such a program and find those variables independently. Outpost2 needs some better cheat protection...

Offline evecolonycamander

  • Hero Member
  • *****
  • Posts: 602
Verible List
« Reply #4 on: April 18, 2010, 05:05:14 PM »
so no topic?
Yes
No
''The blight cant get us up here!''
-famous last words
--------------o0o--------------
Outpost 2: EoM project status: Re-planning

Offline Sirbomber

  • Hero Member
  • *****
  • Posts: 3238
Verible List
« Reply #5 on: April 18, 2010, 05:48:57 PM »
NO
"As usual, colonist opinion is split between those who think the plague is a good idea, and those who are dying from it." - Outpost Evening Star

Outpost 2 Coding 101 Tutorials

Offline Hooman

  • Administrator
  • Hero Member
  • *****
  • Posts: 4955
Verible List
« Reply #6 on: April 18, 2010, 07:51:23 PM »
Of course you realize a lot of this information is already basically posted in the programming forum, or is stored in files in the SVN repository. Just in a somewhat less accessible form.

At any rate, modifying those variables with a memory editor is not going to work well in multiplayer. It will most likely desync the game and lead to odd behavior. It might not be obvious at first though.

At any rate, I've been looking into NetFix upgrades, and I've staked out a place where I can run validity checks on packets. This should help catch problems caused by memory editors and make them a lot more glaring.

Offline Sirbomber

  • Hero Member
  • *****
  • Posts: 3238
Verible List
« Reply #7 on: April 18, 2010, 08:21:54 PM »
Quote
At any rate, I've been looking into NetFix upgrades, and I've staked out a place where I can run validity checks on packets. This should help catch problems caused by memory editors and make them a lot more glaring.
Hooman, not that I think that's not a good idea, but considering there are still a bunch of people for whom NetFix doesn't work properly (myself included) maybe your time would be better spent ironing out bugs and improving functionality rather than adding random features?

Also, considering the offending player will just desync and drop out eventually anyways, is this patch really that important?
"As usual, colonist opinion is split between those who think the plague is a good idea, and those who are dying from it." - Outpost Evening Star

Outpost 2 Coding 101 Tutorials

Offline Kayedon

  • Sr. Member
  • ****
  • Posts: 378
Verible List
« Reply #8 on: April 18, 2010, 08:56:47 PM »
Quote
At any rate, modifying those variables with a memory editor is not going to work well in multiplayer. It will most likely desync the game and lead to odd behavior. It might not be obvious at first though.
Change "will most likely" to "will rather quickly" and your sentence is good to go.

ECC, what I meant was, did you miss the other topic where everyone said "No?" Or did you just read passed that - again?
"Trust me, I'm crazy."

Offline Hooman

  • Administrator
  • Hero Member
  • *****
  • Posts: 4955
Verible List
« Reply #9 on: April 18, 2010, 11:48:09 PM »
Quote
Also, considering the offending player will just desync and drop out eventually anyways, is this patch really that important?

Quote
Change "will most likely" to "will rather quickly" and your sentence is good to go.

I think Kayedon picked up on the important point there. With insufficient checking to see if something is valid, the game may continue on without giving any indication that the states have diverged.

As for NetFix issues, I doubt all of them are solvable. Perhaps a few are. In other cases, maybe I can do some more testing with using the NetFix over Ham.
 

Offline Kayedon

  • Sr. Member
  • ****
  • Posts: 378
Verible List
« Reply #10 on: April 19, 2010, 12:12:47 AM »
I fail to see what important point I picked up. All I know is that a memory editor will desync a game, and in my experience it was within the first 5 minutes.
"Trust me, I'm crazy."

Offline Hooman

  • Administrator
  • Hero Member
  • *****
  • Posts: 4955
Verible List
« Reply #11 on: April 19, 2010, 12:36:29 AM »
Hmm. The point being that it might not be quick. The game state will mostly likely eventually differ noticably, but it might not be for a while. That would sort of make people think it worked perfectly, and perhaps encourage them to use the cheat. It may even have some of the intended effects due to lack of checking.

Say, if building units only checked money on hand at the time the command was issued (through the user interface), instead of the time it was executed (after it was send over the net), then anything received over the network might only have been checked by the sending computer, which could be running under cheat code. The state will differ since the cheating computer might think it has lots of money, and always allow stuff to build, while the other computers only know the real negative money state that results. The cheat may work if the other computers never check for negative money states, and just assumes the sending computer never lies. Such code could result in the difference in state never being detected, and so the cheat could function without it's results ever being visible. More likely though, there is some code that does check, but just might not run very often, such as repair code that takes money, and auto stops repairs when money runs out. Once those trigger a difference, that difference will grow into something more noticable. Think of the butterfly effect.  ;)

Essentially you want the checking code to run on all computers in a symmetric way, before the commands are executed, and then you won't have to worry about security and desyncs so much.