I found a nasty bug:

Find a Bug? Have a Problem? Like to Suggest a Feature? Do it Here

Moderators: g3nuin3, SpeedWing, WhiteHat, mezzo

I found a nasty bug:

Postby esco » Sun Sep 12, 2010 3:38 am

I have the newest version of MHS installed on 2 computers that I work on the hack with; at the moment I have externals declared in 2 different formats:

the old one: extern SHORT actionfrozen = { "", 0x0064e260 +0x003951e0};

and the new one: extern SHORT actionfrozen = { "epsxe.exe", 0x097420+0x54c020};

I intended to convert them to all the new format I am using so that in the future if I want to make the hack compatible with other emulators, I just change the exe (except if one uses DMA, then it would require a slight bit more work). The problem is this:

When going between the 2 PC's, variables that use the "old" method work fine; but ones that use the "new" one don't. For the scripts that don't work due to this "new" format I just literally open them, type in a single blank space, reclose the script, and then it works for some unknown reason. I can literally put the space anywhere, or a comment anywhere,or etc.
anywhere and it then works. Have you seen this bug before Spiro?

P.S.The exe is always at 400000 on both PC's; as expected.
Esco.... the name says it all. New Yorikan for life.
User avatar
esco
NULL
 
Posts: 148
Joined: Mon Sep 18, 2006 2:25 am
Location: Florida, a.k.a. the US's version of hell!

Re: I found a nasty bug:

Postby L. Spiro » Sun Sep 12, 2010 4:45 am

It is not a bug and has been mentioned before.
When you start MHS it is not attached to a process and so any extern that uses a module name will resolve to 0.
externs that use module names must be declared inside functions so that the module name will be resolved each time the function is called (this is extremely fast in MHS as it uses a cached and sorted internal buffer).


L. Spiro
Our songs remind you of songs you’ve never heard.
User avatar
L. Spiro
L. Spiro
 
Posts: 3129
Joined: Mon Jul 17, 2006 10:14 pm
Location: Tokyo, Japan

Re: I found a nasty bug:

Postby esco » Sun Sep 12, 2010 7:00 am

L. Spiro wrote:It is not a bug and has been mentioned before.
When you start MHS it is not attached to a process and so any extern that uses a module name will resolve to 0.
externs that use module names must be declared inside functions so that the module name will be resolved each time the function is called (this is extremely fast in MHS as it uses a cached and sorted internal buffer).


L. Spiro


So basically, just put any variables I have in any function, and I am good? Done; but then how exactly am I supposed to use the same variable in 3 or 4 functions with re-declaring in each one?

P.S. It still sounds like a bug to me; or shoddy programming. :P
Last edited by esco on Sun Sep 12, 2010 7:16 am, edited 1 time in total.
Esco.... the name says it all. New Yorikan for life.
User avatar
esco
NULL
 
Posts: 148
Joined: Mon Sep 18, 2006 2:25 am
Location: Florida, a.k.a. the US's version of hell!

Re: I found a nasty bug:

Postby L. Spiro » Sun Sep 12, 2010 7:10 am

But it is logical.
Scripts are compiled when you start MHS, and at that time there will be no target process.
The only way to remedy the problem is to recompile scripts every time you attach to a process, but you of all people should know that this could cause a large delay when attaching, and this could happen frequently, and since MHS tries to automatically open processes after detachment this could cause a system-wide problem.
The lesser evil of the two possibilities is the solution that is implemented.


L. Spiro
Our songs remind you of songs you’ve never heard.
User avatar
L. Spiro
L. Spiro
 
Posts: 3129
Joined: Mon Jul 17, 2006 10:14 pm
Location: Tokyo, Japan

Re: I found a nasty bug:

Postby esco » Sun Sep 12, 2010 7:23 am

L. Spiro wrote:But it is logical.
Scripts are compiled when you start MHS, and at that time there will be no target process.
The only way to remedy the problem is to recompile scripts every time you attach to a process, but you of all people should know that this could cause a large delay when attaching, and this could happen frequently, and since MHS tries to automatically open processes after detachment this could cause a system-wide problem.
The lesser evil of the two possibilities is the solution that is implemented.


L. Spiro


Oh wow, I see your point. But in that case, why does it take so long to load and compile anyway? I don't seem to have that issue in class with massive c scripts way bigger than my insignificant little 1.5 meg file.

Right now my big question is how exactly do I use the same variable in 3 or 4 functions with an exe listed, without re-declaring the variable in each function? Is there a way to do this? If not, I am just going to have to take out the exe. and just add in a +400000 instead to the pointer address declaration.

Or is there a way somehow from one of the menu's to set it so all declared variables add 400000 automatically when loaded?
Esco.... the name says it all. New Yorikan for life.
User avatar
esco
NULL
 
Posts: 148
Joined: Mon Sep 18, 2006 2:25 am
Location: Florida, a.k.a. the US's version of hell!

Re: I found a nasty bug:

Postby L. Spiro » Sun Sep 12, 2010 8:10 pm

#1:
Because they have teams of people led by someone who specializes in compiler optimizations. The language I am making now will compile much faster as a result of my own gained experience since then, but still might not be as fast as theirs.

#2:
You are right to worry about copy-paste code. If you go the straight-forward route of simply copying the global to a bunch of local places you will die cold and lonely under a bridge.
Your concern should rightly be that if you ever decide to change the address, you would have to change them all.
The solution is to make a macro that is the address.
Code: Select all
extern eMyValue = { E_MYVALUEADDRESS };

The macro E_MYVALUEADDRESS can be defined to include both the module name and offset.

The shortcut of replacing the module name with 0x00400000 makes your address less realistic, but since it does not actually cause a real problem functionally it may be worth it if it saves you too much time.

#3:
No.


L. Spiro
Our songs remind you of songs you’ve never heard.
User avatar
L. Spiro
L. Spiro
 
Posts: 3129
Joined: Mon Jul 17, 2006 10:14 pm
Location: Tokyo, Japan

Re: I found a nasty bug:

Postby esco » Tue Sep 14, 2010 11:27 am

L. Spiro wrote:#1:
Because they have teams of people led by someone who specializes in compiler optimizations. The language I am making now will compile much faster as a result of my own gained experience since then, but still might not be as fast as theirs.


???? I thought you had memhack on hold? Are you planning on putting out something even better? :shock:

You are right to worry about copy-paste code. If you go the straight-forward route of simply copying the global to a bunch of local places you will die cold and lonely under a bridge.


ROFLMFAO! I am so using that line. :D

Your concern should rightly be that if you ever decide to change the address, you would have to change them all.
The solution is to make a macro that is the address.
Code: Select all
extern eMyValue = { E_MYVALUEADDRESS };

The macro E_MYVALUEADDRESS can be defined to include both the module name and offset.

The shortcut of replacing the module name with 0x00400000 makes your address less realistic, but since it does not actually cause a real problem functionally it may be worth it if it saves you too much time.


I'm not sure I understand how using a macro will help with this issue? If I declare a global one with the exe, it brings me back to the issue of it not working until I go in and out of the script and make a small change. But I may at some point find a use for a macro.

However, I did find a way to do it using a constant and the 0x400000 value + the offset value:

Code: Select all
//exe = 0x54c020(this is the offset address)+0x400000(this is the address of the emulator executable. In this case epsxe.exe). Sum is in decimal format, not hex.

const LONG exe = 9748512;

extern SHORT pauseall = { "", 0x03c9a4+exe};       //address comes out to 0x9889C4

I tested this, and it fixes the issue. I wanted to leave the exe in for presentations sake, but fuck it. I would only be thinking of adapting it for maybe 2 other PS emulators (the other 2 best ones) and by using this I can easily edit all my script in a few minutes using replace in the code editor. Since I just have to change the value stored in the constant exe (which is always near the very top of my code).

You see: I am finally learning stuff here. :)
Esco.... the name says it all. New Yorikan for life.
User avatar
esco
NULL
 
Posts: 148
Joined: Mon Sep 18, 2006 2:25 am
Location: Florida, a.k.a. the US's version of hell!

Re: I found a nasty bug:

Postby L. Spiro » Thu Sep 16, 2010 10:43 pm

I am not working on MHS.
The language I am making is a cross-platform high-level shader language. Write a shader in my language and it will compile in DirectX, OpenGL, Nintendo Wii, and PlayStation 3. And the next generation of machines. Like Cg but better.

Your constant is doing the same thing my macro was suggesting you to do.


L. Spiro
Our songs remind you of songs you’ve never heard.
User avatar
L. Spiro
L. Spiro
 
Posts: 3129
Joined: Mon Jul 17, 2006 10:14 pm
Location: Tokyo, Japan

Re: I found a nasty bug:

Postby esco » Sun Sep 19, 2010 3:31 pm

Sounds like you are working on something huge man, good luck with it. I actually put out as a small demo of my hack, here is the link to the page with all of the info: http://www.chapelofresonance.com/forum/ ... ntry211623

As you can see, I mentioned your name on that page. Without you, none of this would be possible man. 8)
Esco.... the name says it all. New Yorikan for life.
User avatar
esco
NULL
 
Posts: 148
Joined: Mon Sep 18, 2006 2:25 am
Location: Florida, a.k.a. the US's version of hell!


Return to Bugs/Problems/Suggestions

Who is online

Users browsing this forum: No registered users and 0 guests