***NOTE: THIS POST CONTAINS SPOILERS***

Dunno- my guess is that it's a bug in 1.2's XML code where a line's not executing. You can find out which script it is fairly easily- remove all of the 000_whatevers (those are all ships, and I know they're working), and then go through the scripts, removing them one by one and checking to make sure that the modifications occur correctly.

Or you can add debugging lines to the end of each script, adding dummy lines to a dummy INI saying that "such-and-such script has executed". I'm pioneering that in 1.3, which is a good debugging technique that should help people do a better job with XML mods.

But... there's a final issue here, which is that 1.2 contains modified SP Missions. So does 1.3, at this time. The reasons for doing so are very simple: there are a number of "vanilla" FL Missions which are in dire need of improvement, such as the well-known problems with the Bundschuh raid on the Nomad/Rheinland shipyards, where if you aren't extremely careful, you fly outside the radius of the Mission zone, and therefore fail the Mission. I've always hated those sorts of artificial problems with games, so I fixed them in 1.2, and improved the fixes in 1.3. These are pretty minor alterations to the Missions that don't really change their fundamental structures, but as one of the goals of the XML Toolkit project was to correct many of the flaws in the original game... I put that change in.

Using Alternate OpenSP will overwrite those files, which is a bit of a problem, if you don't run it as a seperate mod, like OpenSP Lite... which is how I envisioned it being used- Toolkit includes the SP game, in full, because players like that, and I wanted to show modders how they could improve the SP campaign without destroying it, much like Slivik's extensive efforts to correct/re-write many of the THNs in TIE Universe so that certain Cutscenes would look right. Alternate OpenSP was not designed to be directly integrated with XML Toolkit Mod- these projects have seperate, differing goals. At any rate, I will think about issuing an "Alternative Version" of the Toolkit Mod with Alternative OpenSP built in. I'm still considering whether there is another method of achieving "full" OpenSP, with Faction alliances able to be altered, custom Factions working correctly, etc., etc. etc., but so far as I can tell, this is going to require some user-friendly method of modifying Restart.fl...

Thanks for the suggestion; good idea (to have a dummy line written by each xml file). I've noticed that little errors in XML files can trigger errors at places you totally won't expect them, so it might indeed appear that there's a little error that doesn't really hurt by itself but somehow gets activated by the options script.

I deleted the mission files from the Toolkit, and replaced them by those of Alt OpenSP. There's no problem with that (apart from the problem I described, but I don't think the mission files are the cause -- I don't see how they should keep xml files from being not performed by FLMM.)

Actually I should work the other way around: have Alt OpenSP as a basis, and the Toolkit as an example on how to expand it.
____________________________________

EDIT: Surprising (but on the other hand, somehow logical) debug result: NONE of the scripts, except for the options script (starting base & money) are executed. I even put a debugging line in script.xml itself, which is not written to the dummy ini (I used engine_good.ini).

Oh well. The dummy mission files (the OpenSP part) seem to work fine.

Edited by - Moonhead on 9/8/2005 11:35:18 PM

@Moonhead:

I will have to take a look at the "choice" script issue, but I'm thinking that FLMM might execute "choice" scripts in a funky order, or won't let other XML scripts execute afterwards. Dunno yet.

As for whether Alternate OpenSP should be built into XML Toolkit... no! The SP campaign is very important to a lot of players, and I want people to be able to play through the game if they want. Removing that choice takes a lot out've the game, imho. XML Toolkit is aimed at both players and mod devs... and quite a few mod devs are interested in having the SP campaign be playable- this is a big request with players of FL-universe mods.

When I get done with XML Toolkit Mod 1.3, I will push into a new direction with all of this. I will build a "bare-bones dev kit" mod that features as close to zero FL content as possible, which will include Alternate OpenSP as a base, and see if I cannot finally empty Mbases.ini and many of the other INI files out more-or-less completely. It'll be... kind've the "anti-SDK". Then I'll probably recode WOS B2 so that it sits on top of that and finally release it, running the way it was always meant to, as a true TC. Which should be very, very exciting- I have a feeling that I can get rid of all of the errors that have stopped people from building ambitious TCs and really make things interesting.

@ Argh

I wasn't trying to push you to get Alt OpenSP into the Toolkit Your goal with the Toolkit is clear, and admirable. Was just trying out to merge them myself, and as you are the author of both, you are the man to ask about it.

Seems like it's best to build a separate customized Alt OpenSP for a Toolkit-based mod (or in fact any script-based mod), so that the options script won't conflict with the others.

The XML scripting is cool anyway. You can even use it to expand mBases.ini, using the script-generated string resources for the individual_names; I hadn't expected that (saves you a LOT of effort setting up people in custom bars). Too bad you can't use it for the bases' ids_infos (these come in pairs and the 1st one of them is referenced twice -in the Star System's ini and in infocard.ini - so you have to use a custom dll for that, and fixed reference numbers.)

You undertake a lot!! I liked Warriors of the Sky, it was a crazy idea. It was rather crashy when I tried it though, which might have had more to do with my system and state of my FL install (I didn''t do clean installs at that time). Must say I haven't really looked into any further because I've always been more into the space thing.

Actually, you can make XML scripts put out DLL entries with specific IDs. I was going to demonstrate this with custom Factions at some point, but never got around to it...

---

Actually, you can make XML scripts put out DLL entries with specific IDs. I was going to demonstrate this with custom Factions at some point, but never got around to it...

---

You mean there's a way to have the same (really the same, not just identical) script-generated DLL entries at more than 1 place? Like, in a star system's ini AND in InfocardMap.ini?? If so, would you mind giving the proper XML-script syntax, if it's not too much trouble (it's okay if you don't wanna.) ?

(You can ofcourse workaround by just generating the first ids_info of a pair, activate the mod, see what the ids_info ref number turned out to be and script that in InfocardMap.ini, together with a generated string resource, but that's lame...)



Edited by - Moonhead on 9/11/2005 3:50:36 AM

---

Actually, you can make XML scripts put out DLL entries with specific IDs. I was going to demonstrate this with custom Factions at some point, but never got around to it...

---

See, always learn something new from this guy....

How would you make the XML script edit a .dll? I mean, as much as I've seen, that would be very hard to pull off.

---

How would you make the XML script edit a .dll? I mean, as much as I've seen, that would be very hard to pull off.

---

It doesn't as much edit a DLL but makes FLMM adding a custom one (flmm.dll) - we're talking about the DDLs for ids_names and ids_infos here.

examples:

ids_name = 0 ;GENERATESTRRES("Beam"

ids_info = 0 ;GENERATEXMLRES ("<?xml version="1.0" encoding="UTF-16"?><RDL><PUSH/><TEXT>AST XTech Cruise Engine Mk1</TEXT><PARA/><TEXT> </TEXT><PARA/><TEXT> Top Speed (theoretical): 53.4</TEXT><PARA/><TEXT> Energy Drain / sec: 0</TEXT><PARA/><PARA/><POP/></RDL></xml>"

See all the ship XML files from Argh's XML Toolkit mod to see how to implement it.

Oh, well, I knew about that, thanks anywise. The way it sounded, it was like you could edit resource.dll or something.

Yeah I thought that you'd knew that, but it wasn't clear from what you wrote... and I was in a good mood and thought "better take the risk of telling what's already known, than let a person wadering in the dark"

However, I'm still curious what Argh means with "putting out DLL entries with specific IDs"and if it means you could put properly set-up bases to a mod by using scripts exclusively...