cory1492

Glad you got it sorted bello :)though... I'm not sure what you mean by "wrong dashlaunch 3.08" as I'm not aware of any other 3.08 out there

bello: that is working flawlessly for me, I made 16203 with old xebuild for my trinity and installed the release version of 3.07 with no problems, rebooted and started 3.08 from a usb stick, it prompted me to update which I did, then update patches which I did, then shutdown. After reboot it was all up to date. Initially I tested by booting to xexmenu and using that to run the installer from usb, and after that I booted to FSD (current version) and installed the old 3.07 and it's patches, reboot and then from FSD installed the new 3.08 and it's patches... all went fine.

Those of you with freezing issues, what version of launch.xex is running? The main page in installer tells you the version of installer, if you use RB to go to the 3rd page near the bottom it should say "Currently Running"... for example the current release should be, for both installer and launch.xex, 3.08(523) so at the top it would say "DashLaunch v3.08 (523)" and near the bottom of the 3rd page it should say "Currently Running: 3.08 (523)" - it would be very useful to know what both versions are for you. Also the version of dash you are currently using would be good to know. (EDIT: you might also want to include a copy of your launch.ini, whichever one actually shows as active in dash launch installer's ini load/save - who knows, maybe one of the options still isn't unhooking properly.) Does the console freeze when you run the standalone update server xex too? Dash launch installer now relies on the server dll to do things like check current patch sets to see if they need updating. If there is a bug in that code, then the standalone server would also cause a crash. A possible workaround, use the old installer that doesn't have a problem with whatever version you are currently running, tab over to the 3rd page and use the uninstall option. If it doesn't crash (IIRC there was an older DL that had one of the option hooks that wasn't getting unhooked, so unload might cause an issue if you haven't been up to date with 3.07) you should be able to exit or reboot and safely start and install via 3.08 installer (keep in mind, putting default.xex on the root of a usb stick will auto launch it for you if the stick is present when the console boots.) Until I know what version launch.xex and installer you all are using though, I can't really replicate the circumstances here to see where the problem comes from.

First, what is the situation with your hard drive? Has it ever been used in a xbox before? Do you actually have a hard drive in your arcade console? (4G/arcade consoles don't come with a hard drive from factory, you have to add one. And if it's an unofficial one you added after purchase, you have to format it in the system/devices menu before it works for this stuff.) Second, I personally recommend FileZilla client https://filezilla-project.org/download.php?type=client It's free and works great. If you are comfortable with WS_FTP LE though, stay with that as it should work too.

The plugin/all the time web server is at port 9999. (If you go to 192.168.0.100 for F3 server, you need to go to 192.168.0.100:9999 for the one that runs all the time via plugin. At least, this was the problem I had last time someone told me to check there )

You really should attach a full dump of the crashlog from launching one of the actual multidisk games, this will tell us things like - what version of the exe and plugin you are using, and whether the plugin loaded OK - what (if any, possibly out of date) custom skin you are using - the offending code that actually caused the crash and the resulting CPU state when it crashed Just posting little snips of it only confirms that you had a crash, not why, when or where a failure occurred (and thus means the devs have to interact a LOT more with you to try to guess what the problem is, instead of just seeing it right there in the log.) If you are having problems attaching here, or simply don't want this log public stuff it on a private paste site or similar, or upload it somewhere and forward a link through a PM or similar here. That said, if you are using dash launch make sure that you are NOT using the swap.xex plugin, and that you've not enabled autoswap (these will not really play well with the F3 multidisk functions.) As far as F3 goes, it doesn't really matter where you put the games or the names of the folders so long as both disks are in the scan path (judging by the snips of the log, they are found just fine) and that the disks they are on are present when needed.

This is just a somewhat out of date (not much will have changed) rundown on where stuff is loaded to in virtual memory, including the base addresses of a few of the plugin dlls I have handy. Hope this helps someone *kernel/hv/xam/ximedicex 0x80000000-0x81FFFFFF*title space (64k) 0x82000000-0x8BFFFFFF*xam plugins 0x90100000-0x901FFFFF (ie: GamerProfile.dll, MiniMediaPlayer.dll, Signin.dll)huduiskin.xex 0x90f90000-0x90fc6000 (2.0.14696.00)-0x91000000 unofficial xbdmXam.Community.dll 0x91240000-0x9128d000 (2.0.14696.00)aac.xexp 0x91380000-0x913c6000 (6.1.24929.97)hud.dll 0x913e0000-0x9142b000 (2.0.14696.00)XIMECORE.dll 0x91680000-0x916a7000 (2.0.14696.00)deviceselector.dll 0x916d0000-0x916e7000 (2.0.14696.00)Xam.LiveMessenger.dll 0x91720000-0x9174f000 (2.0.14696.00)vk.dll 0x917d0000-0x917e7000 (2.0.14696.00)-0x91800000 ftp dll-0x91A00000 fsd plugin*title space (4k) 0x92000000-0x9BFFFFFF*dash title space 0x92000000-0x97FFFFFFbootanim.dll 0x98000000-0x9809c000 (2.0.14696.00)*natalsu.dll 0x98000000-0x98007000 (2.0.14696.00)*oddupd*.xex 0x98400000-0x98440000 (2.0.14696.00)Dash.NetworkStorage.dll 0x9ac10000-0x9ac3a000 (2.0.14696.00)Dash.Search.dll 0x9ad10000-0x9ad8e000 (2.0.14696.00)Dash.Social.dll 0x9af10000-0x9afdb000 (2.0.14686.00)Dash.Search.dll 0x9b040000-0x9b07f000 (2.0.14686.00)dash.natalpregame.dll 0x9c780000-0x9c809000 (2.0.14696.00)Dash.MP.Purchase.dll 0x9c400000-0x9c428000 (2.0.14686.00)Dash.NuiTroubleshooter.dll 0x9cb00000-0x9cd81000 (2.0.14696.00)Dash.MP.ContentExplorer.dll 0x9b110000-0x9b1ce000 (2.0.14686.00)dash.firstuse.dll 0x9b710000-0x9b75b000 (2.0.14696.00)Dash.Kiosk.dll 0x9b610000-0x9b68e000 (2.0.14696.00)Dash.FieldCalibration.dll 0x9bd10000-0x9bda1000 (2.0.14696.00)dash.NuiFirstUse.dll 0x9d9d0000-0x9db81000 (2.0.14696.00)dashnui.dll 0x9e510000-0x9e839000 (2.0.14696.00)Dash.MP.Core.dll 0x9ebf0000-0x9eca7000 (2.0.14686.00)luaext.dll 0x9ed30000-0x9ed68000 (2.0.14686.00)-0x91F00000 dash launch-0x91F30000 swap.xex*sysupd1ec.dll 0x9f100000-0x9f154000 (2.0.14696.00)livepack.dll 0x9f110000-0x9f1bd000 (2.0.14696.00)dash.ExtraAVCodecs.dll 0x9f7e0000-0x9fb35000 (2.0.14696.00)*MfgBootLauncher.exe 0x9fea0000-0x9feb3000 (2.0.14696.00) A little experimentation to find a space both large enough and which is compatible with the image tools is required.

I honestly don't see how... titles can only be (64k pages) 0x82000000 to 0x8BFFFFFF and (4k pages) 0x92000000-0x9BFFFFFF while the dll is loaded to 0x91800000 with a footprint size of approximately 0x1E000. Without the game to actually check it though, and absent a crash log... there is no definitive reason why it'd cause issues with any game, especially since it runs in system context which the game should not even be aware of.

Hrm I had this problem initially myself with LiNK, but it was because I hadn't enabled pingpatch. If the ping patch isn't effective, you will only be able to join hosted games where the latency is as low as a LAN (basically) but hosting doesn't seem to have this problem. How widespread is the issue though really? I'd think more people would have problems with it if the patch was faulty.

Did you read the descriptions lprot? Or did you just see 'ftpserv' and assume? ; these options are never used directly by dash launch but serve to give the configuration program; a place to keep these values[Externals]; if true, the configuration application will start a FTP server (user/pass: xbox); if not present default is FALSEftpserv = false; if ftpserv is true, this is the port that will be used by the FTP server; if not present default is 21ftpport = 21; if true, the configuration application will start in launch mode instead of options mode; if not present default is FALSEcalaunch = false; if true, temps in installer and in guide (shuttemps option) will be shown in fahrenheit instead of celsius; if not present default is FALSEfarenheit = falseI mean, perhaps you don't have the 'configuration program' running? As to warfighter, there are lot of things that can cause crashes, especially if memory is loaded with other plugins (for example, xbdm plugin, or newer versions of the FSD plugin.) Dash Launch itself is designed to take as little memory as possible, having the ftp server inside it does not work towards this goal and as you have seen can even cause problems with games... so it's not there, it's in a plugin (or in dedicated programs that have much more resources to work with in title space such as in the installer itself, or in xexmenu or fsd.)

He definitely hit the proverbial nail on the head with that one. metalhead: it's not so much greed as it is fear... fear that they won't be able to show shareholders an earnings gain year over year (which may well cost them their cushy job, who cares about the customers?) ... which they have in general done even in a failing economy, by constantly instituting new pay-per fees on what now should be considered an essential service. Bloody cell phone pay per minute and pay per texting got them drooling so much they are putting those same types of fees in services where it can't be economically justified.

mass3n, moulder - both your bugs have been corrected for the next build

I'd bet it's an option that both of you have set that no one else without the problem does, or vice versa, that is affecting BO2 and avatar editor. I've never had a problem with avatar editor, and since the update to fix it no problem with BO2 (on various machines, using different hacks.) What I'm saying here is, lets see if we can actually get your problems sorted by doing a bit of diagnostic troubleshooting - it would prob be handy if you posted your ini files and let us know where you've installed the ini to, and possibly even console info (model, hack type, etc, nothing personal like actual data from the machine's nand) so someone can try to replicate the issue. I'm attaching the ini I use for testing, typically left on a usb stick with that xbdm.xex plugin active while testing. Just a quick run through, the most likely culprits are going to be 1 - old plugins that are not up to date 2 - options: signnotice, autoshut, fakelive, autofake (try toggling these and see if any difference is noted - check my ini, see if I have anything set different than you do and try toggling that as well to see if there is a diff - keep in mind changing options via installer doesn't need a reboot unless it's an option directly related to bootup) Also, for kicks if the above doesn't help, also try enabling parental controls in metro and disable live connections in there, see if that has any effect... I do this on all my machines which could also be a point of difference that when not enabled and when using a live marked profile can cause even a few minutes lag doing certain things. If we can isolate a cause (haha!) so the problem can be reproduced, I'm certain it will get fixed quickly launch_ini_1492.zip

I have gold when I use fakelive on my profile... none of the premium apps complain about needing gold anymore, though they did in a beta version of fakelive (I messed with a flag in my Account inside of my profile to flag it as being gold instead of silver) - the problem is the token server requires an authenticated live connection before you can start using 3rd party things (like sign into youtube to view videos, or request web pages in IE - I can in fact run IE and browse to sites, but they never load or even produce an error to show they aren't gonna ever load.)

Jokerski: I had a similar problem a while back, once my trinity got to a certain temperature it had problems reading/writing the hdd. Also, make sure your ftp client isn't caching folder listings and such. irishdave: it's possible yes, but this splash screen is under control of the community launcher and is mostly just to fill the screen while it sets up runtimes and similar. You ever notice how on a fresh boot of windows, when you try to run a .net exe it takes longer to come up the first time (until windows caches some assemblies)? Xbox is similar, but it doesn't have caching the way windows does. Anyway, the effort would result in a placebo effect similar to deleting bootanim from flash - it seems to go faster, but in reality you are just looking at a black screen for longer.

Could it be that you previously ran that game with a title update that is no longer present on your machine? Or perhaps it's an indie game and you don't have the current indie title update installed?

Try using dash launch installer to unload dash launch (not uninstall), then run the game and see if it has issues still. If it doesn't, then dl isn't the problem... if it does then something in it needs some attention.

You'll have to be a little clearer, what exactly isn't finding the games? The official dash? The built in launcher in dl installer? And how are you putting the games on the hdd? Extracted? GOD? The official dash needs games to be in containers (not iso, not extracted from iso, but converted to a container) in a very specific location before it can find them, like hdd/content/000..000/<TITLEID>/morefolder/thegame - none of this has anything to do with dash launch though.

Yes, the issue appears to be that pirated copies of a game that is not in stores and aren't being played from an actual disk aren't working. Pretty simple, no?

no procyon123, elf is not accepted by dash launch itself, just by the installer's launcher. If it's showing elf in the path boxes when using installer to edit your ini, it is a bug and should be corrected.

extract skin.xzp from the attached file and put it beside default.xex for installer, and it should use that skin instead of the built in one (and thus your language file) - a quick glance shows that you will probably have to add in some returns in longer lines so they don't show up gimped. skin.zip

The default.xex is for installing from "burn your own CDROM", if you are using a usb stick you won't need it. Format your usb stick to FAT or FAT32, copy the folder $SystemUpdate to the root of it (rename it to $$ystemUpdate if you have dash launch option noupdater set to true) and boot with the usb stick plugged in. You should be prompted to update right after the bootlogo - NOTE: this is NOT for updating your system flash from 15574 to 16197, it is ONLY for installing avatar and kinect binaries AFTER you update and reflash your system flash with xebuild. I hope that is clear enough? Judas: yes the nohealth problem is known and will be fixed for the next version. AFAIK the only ver it doesn't work for is 16197.

I'm sure at least a dozen more people will check it out! AT LEAST!