near the top of the code i see things like,
btn_dropdown._visible = false;
mcMenuBkg._visible = false;
but I can't find these assets anywhere in the library or in any code, how does this make any sense?
The movie clips in the library that look the same have different names and I can delete them entirely and they still show up when I compile and run, or I can add trace statements into their code and they never get called.
where on earth are these assets defined?
In theory, any clip you see at runtime could be dynamically created, by making an empty MC and drawing in whatever contents you like with the drawing API. However, if you see clips in the library that are similar to what's showing up at runtime, then it's very unlikely that that's happening.
Your first step should probably be another look through the library. Remember that instance names don't have to be the same as MC names; even if something is called "Menu Holder" in the library there might be an instance of it somewhere called "mcMenuBkg" or whatever. But the fact that you can delete stuff without changing the output is mysterious.
So, other possibilities: contents are being loaded externally, or imported via runtime sharing. If feasible, try moving your SWF to a temp directory and running it from there; that should break all loads (unless contents are loaded from a remote URL).
Or, you're looking at the wrong clips in the library. If it's a crufty project there may be unused stuff in there. Try expanding the library wide enough to see the "Use count" column, and select "update use counts" from the library menu. Anything with a count of 1 or higher is part of your FLA's stage content - either it's sitting on the main stage or it's a child of something that is. Clips with a use count of 0 may still be used if they have a linkage ID; they could be created at runtime with attachMovie(). However, for any clip with a use count of 0 and no linkage id, it's safe to assume that it's unused, and irrelevant to what happens at runtime.
If none of that helps, the only things that come to mind are sanity checks... open up everything on the stage and every clip with a linkage id, and check for empty/invisible MCs. Check the Movie's export settings to make absolutely sure the SWF you're checking is the same one being published. And just for grins, open up the "Scenes" panel and make sure that some diabolical fiend hasn't put important content on a separate scene where no sane man would look for it.
Vague answer for a vague question. :D Hope it helps...
You can create movie clips with code dynamically.
This means that you may not have them in your assets if you are unable to find them.
You can create any type of symbol using a constructor out of thin air with actionscript alone.
I would search the code for one of these
var mybutton:SimpleButton=new SimpleButton();
If they're being set to
_visible = false
you won't see them anyway - and as ActionScript 1/2 doesn't do runtime error reporting, the Flash player won't complain if they're not actually there on the stage. If they're not being used, just delete them.
Related
I have a handle to a dynamic library (from using dlopen()). Regardless of why, I don't have access to what the path supplied to dlopen() was, but need the path for another function. Thus, I need to be able to acquire the path to the library using its handle.
I've tried using dladdr(), as I have in other parts of my app, but on macOS / iOS you aren't able to use it to find the path of a library using the handle to the library it only works with a handle to a symbol in the library. I could try adding a "locator symbol" to the library, and accomplish things this way, but I'd prefer not to.
I also tried dlinfo() with RTLD_DI_LINKMAP, but this is apparently not available on macOS / iOS.
I'm surprised at how little information there is out there for this. Many of the solutions out there were not available on macOS / iOS. Others still, were only about getting the path of the current executable, and had nothing to do with the handle.
After a TON of searching, I finally came across some resources saying to iterate through all the loaded images using _dyld_image_count() and _dyld_get_image_name(). I initially decided against this, as it just didn't seem like an unreasonably slow way of doing things.
Eventually, I decided to go with iterating over all the loaded images, as it was the only actual solution I had come across. I googled for examples, and couldn't find any tutorials on the topic. However, I did come across an open source C++ library that implemented the functionality (found here).
I translated it to normal C, and got rid of some excess things (such as stripping the handle). During the testing process, I noticed that the library I wanted was always last in the list (my best guess is that it stores them in the order they were loaded, and since mine isn't a system library, it will be one of the last ones loaded). This guaranteed a slow performance (in reference to the computer - to a human it'd still be nearly instantaneous). So, I did a clever optimization that started the search at the end of the list, rather than the beginning.
This is the final code for my solution:
// NOT a thread safe way of doing things
NSString *pathFromHandle(void* handle)
{
// Since we know the image we want will always be near the end of the list, start there and go backwards
for (uint32_t i = (_dyld_image_count() - 1); i >= 0; i--)
{
const char* image_name = _dyld_get_image_name(i);
// Why dlopen doesn't effect _dyld stuff: if an image is already loaded, it returns the existing handle.
void* probe_handle = dlopen(image_name, RTLD_LAZY);
dlclose(probe_handle);
if (handle == probe_handle)
{
return [NSString stringWithUTF8String:image_name];
}
}
return NULL;
}
It's important to note that this solution is not thread safe, as _dyld_image_count() and _dyld_get_image_name() are inherently not thread safe. This means that any other thread could load / unload an image and have a negative impact on our search.
Additionally, the resource I used questioned why dlopen didn't have an effect on _dyld_image_count(). This is because if an image is already loaded, dlopen does not load a new instance of the image, but rather returns the existing handle for it.
I have a fork of the JavaScriptCore framework, where I have added a function of my own, which is exported. The framework compiles just find. Running nm on the framework reveals that the function (JSContextCreateBacktrace_unsafe) is indeed exported:
Leo-Natans-Wix-MPB:JavaScriptCore.framework lnatan$ nm -gU JavaScriptCore.framework/JavaScriptCore | grep JSContextCreateBacktrace
00000000004cb860 T _JSContextCreateBacktrace
00000000004cba10 T _JSContextCreateBacktrace_unsafe
However, I am unable to obtain the pointer of that function using CFBundleGetFunctionPointerForName or dlsym; both return NULL. At first, I used dlopen to open my framework, then tried using CFBundleCreate and then CFBundleGetFunctionPointerForName but that also returns NULL.
What could cause this?
Update
Something fishy is going on. I renamed one of the JSC functions, and nm reflects this. However, dlsym is still able to find the function with the original name, rather than the renamed.
It's hard to track this down since it's highly dependent on your specific environment and circumstances, but it is very likely you're running into this issue because the system image has already been loaded and you haven't changed the name of the framework.
If you look at the source code for dlopen in dyld/dyldAPIS.cpp:1458, you'll notice the context passed to dyld is configured with matchByInstallName = true. This context is then passed to load which executes the various stages necessary for image loading. There are a few phases worth noting:
loadPhase2 in dyld/dyld.cpp:2896 extracts the ending of the framework path and searches for it in the search path
loadPhase5check in dyld/dyld:2712 iterates over all loaded images and determines if any of them have a matching install name, and if one does, it returns that instead of loading a new one.
loadPhase5load in dyld/dyld:2601 finally loads the image if it wasn't loaded/found by any earlier steps. (It's worth noting loadPhase5check is executed first, since image loading is a two pass process.)
Given all of the above, I'd try renaming your framework to something besides JavaScriptCore.framework. Depending on the install name of both the system framework and your framework, I'd also recommend changing the install name. (There are plenty of blog articles and StackOverflow posts that document how to do this using install_name_tool -id.)
I was trying to run this script done by SethBling, but it gives me this error:
LuaInterface.LuaScriptException: DP1.state
LuaInterface.LuaScriptException: [string "main"]:337: attempt to index field 'neurons' (a nil value)
This is the code
In case this didn't solve your problem try this:
"If you are using a version of BizHawk that is over 2.0, go into the menu and Click Config then follow as such: Customize > Advanced > Lua Core > Lua+LuaINterface. This is why I wasn't able to load." from JaRetroYT over on reddit.
A flamanis posted this comment on youtube. I followed the instructions and got it working.
HOW TO GET IT TO WORK! THIS ALL TAKES PLACE INSIDE THE FOLDER YOUR BIZHAWK EMULATOR IS IN.
Execpt this part: Before EVER opening the lua console on BizHawk,
(If you have, instructions on how to reset your stuff will be at the
bottom) go onto the level you want to have it learn, and when the
level starts up, click on file. Go down and open the menu of save
state, at the bottom click the create named state, and then finally
name it DP1, however put it after all the slashes and whatever so just
delete the gamestate.whatever jargon that it auto names it. After
doing that, either move that file from the SNES/State folder to where
you have your lua file, or the other way around. and then load up the
lua file into the console, and boom you're good.
IF YOU ALREADY TRIED TO RUN THE LUA FILE AND IT ERRORS: You either need to delete your save, or edit the lua file slightly. If you want to do the delete save approach, then go into the SNES folder and then into the SaveRAM
folder and delete your file for the game. THIS DOES NOT DELETE THE
EMULATION, just the save. If you want to edit the lua file, then at
the top, the very top line, (create a new one if you want to, just
make sure it's before any other text) add this: pool = nil that's it.
It will reset the data so that it can run again. You still need that
save state though. You will probably want to edit the file again after
you've started running it and remove that line or it will restart
every time you turn it on.
Alrighty, I said I'd answer this better, and sometimes people do just google randomly for their solutions.
Soo, Bizhawk emulator has a way to run Lua scripts, which is nice.
So Seth's program assumes a few things about how the game is set up, and how the user (that is you) has done certain things beforehand.
The main thing that you need to do beforehand is create what is known as a save state. This is a point in the game that you can instantly reload back to, and how the program restarts the level so that each 'run' is essentially the exact same. This differs slightly from normal games where you 'load' the game, because games back around SMB weren't as 'random' as games now. So saving the game and loading it should give the same exact result with the same inputs every time.
You should create the save state right at the very start of the level. To create this illustrious save state you want to click on the file button at the top of your screen to open the drop down, and then select save state and create a new one. This should create a save state that you can then load to return to that exact moment in the game.
To have the program be able to load your save state to run you can do one of two things
1: Rename the actual save state file name to be just DP1.savestate
2: Modify the Lua file and change the DP1.savestate part to be the name of your save state
Then you just need to move them into the same folder, and you should be golden.
If you attempted to run the file before making a save state, it will have tried to run and errored with attempt to index field 'neurons' (a nil value) or something similar. (It's been a while, it could have stopped on the first run because it couldn't find the save state, so this might just only happen on the 2nd and further runs)
What this means is that it essentially created it's "brain" but left it completely empty. Which is bad. There's two ways to fix this, and they're fairly straightforward.
1: You need to delete the actual game save, otherwise known as the SaveRAM. The file that you need to delete can be found in the folder for whatever console you're running, in Seth's video he was using the SNES, so that's the folder you'd want to go into. Inside that folder is then the SaveRAM folder, you can either just delete that folder, or go into it and delete the one for the game you were running.
2: You need to edit the Lua file to reset itself, all this requires is putting the text pool = nil at the very top. This will then delete the "brain" before anything else happens, which will let the program create a new one. Fair warning: This is not just a one time effect, if you restart the program at this point you will lose your entire progress. What you need to do is after it starts running, stop it and edit the file again, and remove the line you just added. This will stop it from deleting it's "brain" every time the program starts, and you should be able to freely run the game.
I do hope that there are still people who look at Seth's video and wants to make it run themselves, good luck to you guys, and happy gaming.
"If you are using a version of BizHawk that is over 2.0, go into the menu and Click Config then follow as such: Customize > Advanced > Lua Core > Lua+LuaINterface. This is why I wasn't able to load."
from JaRetroYT over on reddit.
Move the savestate and lua script to the main folder for the emulator (where EmuHawk.exe is)
I have seen in quite few places (one example here: http://pascalgamedevelopment.com/archive/index.php/t-1204.html) people doing this.
Embarcadero documentation says nothing about the position of the header in the file/stream after creating the stream.
Conclusion:
Since the documentation does not guaranty the position of the cursor, we should use 'Seek=0'. Even if now the cursor is placed at the beginning of the file, we will never know how this will change in time. Since Embarcadero does not document this, it looks like they reserve the right to change it.
TFileStream.Create just opens file handle and leaves file position where the Win32 put it after the handle was open - at the beginning on the file.
There's no need to Seek to 0 position; you are already there.
I'm encountering this error when I'm running my DirectX10 program in debug mode:
D3D10: WARNING: ID3D10Buffer::SetPrivateData: Existing private data of same name with different size found! [ STATE_SETTING WARNING #55: SETPRIVATEDATA_CHANGINGPARAMS ]
I'm trying to make the project highly OOP as a learning exercise, so there's a chance that this may be occurring, but is there a way to get some more details?
It appears this warning is raised by D3DX10CreateSprite, which is internally called by font->DrawText
You can ignore this warning, seems to be a bug in the Ms code :)
Direct3D11 doesn't have built-in text rendering anymore, so you won't encounter it in the future.
Since this is a D3D11 warning, you could always turn it off using ID3D11InfoQueue:
D3D11_MESSAGE_ID hide [] = {
D3D11_MESSAGE_ID_SETPRIVATEDATA_CHANGINGPARAMS,
// Add more message IDs here as needed
};
D3D11_INFO_QUEUE_FILTER filter;
memset(&filter, 0, sizeof(filter));
filter.DenyList.NumIDs = _countof(hide);
filter.DenyList.pIDList = hide;
d3dInfoQueue->AddStorageFilterEntries(&filter);
See this page for more. I found your question while googling for the answer and had to search a bit more to find the above snippet, hopefully this will help someone :)
What other data are you looking for or interested in?
The warning is pretty clear about what is going on, but if you want to hunt down a bit more data, there may be a few things to try.
Try calling ID3D10Buffer::GetPrivateData with the same name or do some other check to see if there is data with that name already, and if so, what the contents are. Print your results to a file, output window, or console. This may be combined with breakpoints to see where the duplicate is occurring (break when there's already data).
You may (not positive) be able to set the D3D runtimes to debug mode and to break on warnings (not sure if it can do warnings or just errors). Debug your app in VS or your preferred debugger, and when the warning is shown, it will break and you can look at the parameters.
Go through your code and track down all calls to ID3D10Buffer::SetPrivateData and look to see if there are any obvious duplicates. If there are, work up the program flow and see why and what you can do about them (this may work best after you use one of the former methods to know where to start).
How are your data names set up, and what is the buffer used for? Examining one or both may lead you to a conflict somewhere.
You may also try unicorns, they've been known to help with this kind of problem.