Wraith

I have another method which I'm probably going to implement for such a thing. What I'm thinking is another <items> container, but <pre-execute> and <post-execute>. Essentially these will get run before and after the display plugin has spawned, so you can hide windows and whatnot before XPlode launches (CMDLINES.TXT, RunOnceEx etc.), or reboot the computer after execution. If people think it's a good idea, I'll implement it, otherwise.........

Personally I'd go the microcontroller route.... I've set one up already that temp controls four voltage-controlled fans - much easier to receive RPM, temp and other status data over serial. And I agree, deciding to add stuff such as a strobe is indeed trivial, if you know what you're doing. Slightly off topic, but seeing the amount of people that don't read stuff in order to work software, I'm not about to start believing they'll have any luck with hardware. Some people just shouldn't be screwing with that stuff. </mini-rant>

As per the reply to he bug report you posted, you need to be using a font that supports the chinese characters. The screenshot I took using chinese characters used MS Mincho as the font. (If I remember correctly.)

>>> Log session start at: 2005/03/30 18:44:29 XPlode4 Adding environment variables #XPLODE# = 'D:\WINSYS\VLK\$OEM$' The *.x4e files need to be in that folder.

The *.x4e files need to be in the same folder as XPlode. XPlode searches the directory in which it's located to find the effects plugins - if you're running XPlode from CD, then the effect plugins need to be in the same folder on the CD too.

My ISP screwed me, and I won't have internet until the 29th of March. Kinda annoying, but I can't do anything about it. Will be back around then (posting from uni)

Yes. You can find info on it in the MSFN unattended guide, and in the unattended forums.

You could start by creating a logfile.

TXTSETUP.SIF: [SourceDisksNames.x86] 1 = %cdname%,%cdtagfilei%,,\i386 2 = "%cd2name%","%cd2tagfilei%",,\cmpnents\tabletpc\i386 3 = "%cd2name%","%cd2tagfilei%",,\cmpnents\mediactr\i386 4 = "%cd2name%","%cd2tagfilei%",,\cmpnents\netfx\i386 Try changing the cd2name etc. to cdname ? Just a thought. I haven't tried.

The only thing that I can think of is that you have Javascript disabled in your IE settings.

You do realise it's /xml:, and not /sml:, don't you?

Looks fine to me. Keep in mind that it's redrawing the WINNTBBU.DLL, not your images. You'll have to read the documentation to figure out how to stop that.

.... you could start by pasting your XML.

I'm not even going to touch this one. EDIT Damnit, I guess I just did, didn't I?

At this stage, implementing multi-tiered items isn't high on my priorities for XPlode4. It *is* on my todo list for XPlode5 though.

By searching in the application switches forum and adapting it to the XPlode syntax.

... Nice logfile there.

I'll probably be adding <pre-execute> and <post-execute> containers in the next release - ones that get run before and after spawning the display plugin. So <hidewindow> can be put beforehand, and <showwindow> after. Obviously it will be able to be used for cleanup too.

That documentation was pre-XPlode4. i.e. it isn't implemented. There's <hidewindow>, <showwindow> in the XPlodeMisc.x4e plugin, but they havne't been implemented.

It's a month and a half off being done. I have other commitments right now. Like moving house.

and the log?

By reading the documentation. From the look of it, you REALLY need to read it, because your XML is completely wrong. You're using the XPlode1 syntax, not XPlode4.

If it's going to take a few weeks to get an XML creator working, then it might be wise to hold off until XPlode5 - I have been planning a whole bunch of changes regarding the plugin system, with embedded documentation being part of it. I had planned to release an XML creator concurrently with X5's release, but if you want to do it, that's fine by me - I can tell you how to interface to the embedded documentation. At this stage, I haven't done any coding, just been doing block diagrams and actually designing the system (designing... anybody do that any more?), rather than jumping in and implementing it, as I have done in the past. It'll be C-style DLL entry points, with unicode strings and DWORDs to pass data back and forward from the plugins. If you're keen, let me know and I'll send some initial info your way.

You'd be better off using a parallel port for that, unless you feel like setting up a microcontroller to receive the serial data and translate it to a digital on/off for a light.

There's no wiki any more. If you need to know about the window.external.* functions, then I'll post the info somewhere over the weekend. (I'm a bit busy at the moment.) You're unable to create *.x4d files at this point in time - because I haven't released the spec, nor have I released an SDK in order to work with them. At this stage I don't feel it's necessary, however if a fair few people request them, then I shall attempt to release an SDK.