[LIST] Streamlining X3 with ease of use modifications

[Teleth]

[The custom ware] should be working correctly. The T file overwrites the #EMP ware number.

Yeah, I just figured that out a couple of hours ago. The system is simple enough. I guess I did not understand t files well enough when I first tried to understand EMP.

With that piece of the puzzle in place, EMP is making more sense to me now.

But why did we both initially have problems with the custom ware?

Re: Changes: It looks as though you changed the t file and three lines in setup.jd.delivery.lv.xml. Is that right?

I made hundreds of changes and reverted hundreds of times; there's no use asking me haha.
What should be changed:

T file:
<t id="1412">
anything referencing 1312 was changed to 1412

setup.jd.delivery.lv.xml:
add ship custom command: id=1312 to 1412

setup.deliver.jd.install.xml:
anything labelled {?} or EMP_112** to "Upgrade kit"

That should cover everything I believe. It is not even worth documenting. (only that it is now using command 1412.. it's not my job to update other's mods however, so I leave it up to the creator to sort out when/if they return to the script)

On a side note, CSecG, Version 1 works with AP/XRM. Version 3 seems to use non-EMP wares and adds them manually; I'm not going there in my current game.
I'm going to modify V1 a bit, remove the debug stuff from menus and reduce the energy cell production slightly, I will also add weak cell production to TS/TP/TM class ships. Modification of V1 will only be posted here however as I don't have the author's permission.

[DrBullwinkle]

setup.deliver.jd.install.xml:
anything labelled {?} or EMP_112** to "Upgrade kit"

Ooh... is that really right?

That is what I did, and I always assumed that would work only on *my* game. Otherwise, why would it be broken?

It is not even worth documenting.

It is *always* worth documenting. Has nobody ever mentioned that to you?

For example, I have to merge your changes with mine. A comment with your initials would have made that easier. However, Exscriptor's diff view worked. This time. But it might not be sufficient if either of us had made major changes.

I agree about CSecG 3. Most of LA's latest versions are unfinished. I use v2, but v1 should be fine. He has not been around recently... probably found something interesting to do in real life. He did register his blanket permission in the 3rd Party Permissions Index, so feel free to update his stuff. Just say, "thank you".

[Teleth]

setup.deliver.jd.install.xml:
anything labelled {?} or EMP_112** to "Upgrade kit"

Ooh... is that really right?

That is what I did, and I always assumed that would work only on *my* game. Otherwise, why would it be broken?

I assume it is because EMP used to work slightly differently, otherwise I really am not sure.
You're welcome to dig further but I have more mods to tweak.

I'm sure someone will complain if it doesn't work haha. It's a string identifier rather than an ID now so I don't think there's any way it could break other than having other wares named 'Upgrade kit'.

[DrBullwinkle]

It's a string identifier rather than an ID now

What do you mean by "string identifier" and "ID"? They seem the same to me (=11313). What are your definitions?

I assume it is because EMP used to work slightly differently

Perhaps. I think the mechanism for EMP is the same; only the number of wares has changed.

The real code in MCSI .xml's is still a bit of a mystery to me. If I understand correctly, the game ignores the sourcetext and sourceplaintext tags, and works directly from the codearray tag. If we compare that, then the changes that you and I made changed an integer from 1048814 to 1048816. We both made the exact same change to the ware.

So, even though it appears as "Upgrade Kit" in the Script Editor, the "real" value is an integer. The string "Upgrade Kit" is the same in all three versions (yours, mine, and LV's). But the string itself is just there for humans.

I think.

Sooooo.... what, exactly, did we change?

[Teleth]

It's a string identifier rather than an ID now

What do you mean by "string identifier" and "ID"? They seem the same to me (=11313). What are your definitions?

Yeah by the looks of it, it totally is not a string. The CDATA is probably what is displayed in the editor, while the XML arrays are the *compiled* code.

Sooooo.... what, exactly, did we change?

I really don't want to break out winmerge to find out; but didn't we just change the ware identifier 1048814 to 1048816?

edit: perhaps 1048814 is illegal with the new EMP? if 1048814 is just a randomish identifier, it would be a bit odd if both of our installations came to the same id conclusion. You aren't running AP right?

[DrBullwinkle]

The CDATA is probably what is displayed in the editor, while the XML arrays are the *compiled* code.

I believe so, yes.

didn't we just change the ware identifier 1048814 to 1048816?

Probably, yes. I suppose that could be consistent with the idea that EMP changed. It is encouraging that our independent changes produced identical results.

As you said, we should get some feedback from testers.

[DrBullwinkle]

perhaps 1048814 is illegal with the new EMP?

Or maybe just different.

You mentioned ZA_EMP_11293_BLANK_WARE_CUSTOM5_7. I, too, saw that in-game before I fixed the ware.

When I look at 0999-L044.xml, I see that 11313 should be ZA_EMP_11293_BLANK_WARE_CUSTOM7_7. That could be consistent with 1048814 vs 1048816.

if 1048814 is just a randomish identifier, it would be a bit odd if both of our installations came to the same id conclusion.

Or, in other words, it is probably not random. Yeah, I agree.

You aren't running AP right?

Right. I am still waiting for the non-Steam version.

[Teleth]

There are now two versions of the re-balance.

Rebalance of Logain's E-Cell Generator Version 1

Generator speeds
------------------
M6/M8: 8/minute was 20/minute
TS/TP/TM: 6/minute was 0/minute
M7: 10/minute was 30/minute
M2: 12/minute was 40/minute
TL: 10/minute was 35/minute
M1: 40/minute was 40/minute

It's possible they are still too high but won't be outproducing your solar plants anytime soon. I decided to keep the carrier generating at high levels as it fulfills support roles.

Rebalance of Logain's E-Cell Generator Version 1-II
Version II features a lower production speed, ensuring energy cells are still an important commodity for long distance jumping. Carriers are still highly productive.

Each generation cycle is two minutes long, rather than one minute.
M6/M8: 3/cycle
TS/TP/TM: 2/cycle
M7: 6/cycle
M2: 8/cycle
TL: 6/cycle
M1: 40/cycle

To give an example of generator speeds in version II:
M6 will extend jump range once every eight minutes.
M2 will extend jump range once every six minutes.

Right. I am still waiting for the non-Steam version.

If you weren't aware (you probably are), there is a no-steam executable for X3AP, unless you were after the DVD or don't have highspeed broadband.

[DrBullwinkle]

CSecG: Sounds good. I forget what I did not like about v1, but you probably fixed it.

Awareness: Yes, I am aware, but it doesn't really solve the major issues, does it? In any case, it is a forbidden topic, so probably best to talk about something else.

[Teleth]

Awareness: Yes, I am aware, but it doesn't really solve the major issues, does it? In any case, it is a forbidden topic, so probably best to talk about something else.

Why is it a forbidden topic if it is offered on Egosoft's website?

edit: http://www.egosoft.com/download/x3ap/bonus_en.php

[DrBullwinkle]

Why is it a forbidden topic?

Beats me *shrug*. It just is. Discuss what is wrong with it and they will lock the thread.

[Teleth]

Hmm, in commemoration of fixing mods, I propose I don't play the game and continue to add more!

I've moved from editing RandomSectorManagement to the unfocussed jumpdrive sector. Would like to restore Kha'ak encounters here among other things.

The MD script looks particularly vexing.. I honestly have no idea how Egosoft worked with this stuff, it's worse than assembly.
Maybe I should start by trying to modify the generics.. provided I can find where they are stored of course.

DrBullwinkle, are there any other good mods that come to mind that you would like to get working?

[LordGaara]

Hey guys,

Just a couple of suggestions.

Complex Cleaner/ Modular Complexes by Gazz. I am getting some kind of a compatibility issue with AP2.0 + XRM.

and concerning some salvage and fun as you requested Teleth:

Debris Repair and Utilization:
http://forum.egosoft.com/viewtopic.php?t=232573
There is some kind of model issue which prevents it from working in AP2.0+XRM as far as I understand.

Would like to restore Kha'ak encounters here among other things

Awesome!

Cheers,
Martin

[Teleth]

Hey guys,

Just a couple of suggestions.

Complex Cleaner/ Modular Complexes by Gazz. I am getting some kind of a compatibility issue with AP2.0 + XRM.

Are you sure its either AP/XRM?
It says in the XRM post that: This mod is 100% compatible with Complex Cleaner.
What exactly is wrong?
I don't use CC because I have FDNL, and intend to spread my factories over 3 sectors.

Debris Repair and Utilization:
http://forum.egosoft.com/viewtopic.php?t=232573
There is some kind of model issue which prevents it from working in AP2.0+XRM as far as I understand.

I did have a look at this earlier, but it seemed a bit incomplete, I'm also not really far along enough in my game for it. Model issues are completely outside of my expertise also. Do you have a link to the post that identifies the problem? or know a bit more about it?

It's safe to say I still know next to nothing about X3 modding but I'm getting there..

[DrBullwinkle]

I propose I don't play the game and continue to add more!

Yes, that sounds logical.

The MD script looks particularly vexing.. I honestly have no idea how Egosoft worked with this stuff, it's worse than assembly.

I suppose it helps if you are fluent in German and guys like Xenon_Slayer and Ketraar are just down the hall.

I find it quite foreign, myself. Some of that is due to the fact that the docs do not adequately discuss how to write a script. The MCSI manual is awesome, but the MD manual leaves many questions unanswered.

Interestingly, some people that you would not think of as serious programmers seem able to handle the MD. Perhaps they have less to un-learn?

A special-purpose MD editor would help. XML was designed to be a data transfer language, for machine-to-machine communication. It was never intended to be written with a text editor. That just complicates the already-different-way-of-thinking that the MD requires.

Also, most of the MD scripts that I have seen have been lightly documented (or undocumented). That does not help the learning curve.

the generics.. provided I can find where they are stored

THAT is something that I can help with:

director\3.01 Generic Missions.xml

are there any other good mods that come to mind that you would like to get working?

As a matter of fact, yes. I have wanted to do major surgery on Logain Industries Light Support Drone Carrier (LSDC). I have hacked it enough to make it work, but it has an architectural flaw that I have yet to solve properly. It also has a lot of weird complications that I want to remove.

My Griffon (from the Final Fury plot) was just aching for the proper software to support its drone-carrier intended role. My hack does the job, but it would be easy to abuse.

So it needs work, but it should be do-able.

Another thing that I would like to see is a different cut at RRF/IR/MBRR. I like the part where there are more challenging reactions to the player's actions, but I hate the NPC-vs-NPC performance drain, and I hate the fact that those scripts do more to make race relations challenging than they do to make combat challenging. However, I have the feeling that that project might be quite a big one. And, for sure, I do not know enough about race relations to even attempt it.

[LordGaara]

Yes, I am sure about CC. I get some sector and XRM stations/shipyards names as <invalid>. The above stations are invisible and untargetable in the nav menu, but I can trade with them using the Trading System Extension.

Regarding the Debris repair, here is what TECSG wrote:

As for Debris, there is (unfortunately) no correlation between the ID of the debris and the (original) ship/station it is supposed to represent. I did see there was a 'repair debris' script, but this just used hard-coded values which were (unfortunately) incorrect a lot of the time. There is also the issue that some of the models used for the debris (the Titan Mk. 1 from X3R for example) are no longer available in TC/AP.

I should also mention, there is unfortunately no way to scan for ship/station debris, all of the 'get ship/station/object' commands ignore debris

That's all I know on the matter.

Cheers,
Martin

[DrBullwinkle]

about CC. I get some sector and XRM stations/shipyards names as <invalid>.

Sounds like an installation issue to me. If XRM has the Complex Cleaner model in TShips, then you would want to install only the script from CC. But I don't use XRM, so I cannot test it to be sure.

[Teleth]

Yes, I am sure about CC. I get some sector and XRM stations/shipyards names as <invalid>. The above stations are invisible and untargetable in the nav menu, but I can trade with them using the Trading System Extension.

Does sound like an installation issue.. particularly if it is just XRM stations and sectors invalid. Complex cleaner is probably really uhh.. complex so I don't think I can be of assistance with it. If I can find the time maybe I will give it an install and see what goes wrong.

As for Debris, there is (unfortunately) no correlation between the ID of the debris and the (original) ship/station it is supposed to represent. I did see there was a 'repair debris' script, but this just used hard-coded values which were (unfortunately) incorrect a lot of the time. There is also the issue that some of the models used for the debris (the Titan Mk. 1 from X3R for example) are no longer available in TC/AP.

I should also mention, there is unfortunately no way to scan for ship/station debris, all of the 'get ship/station/object' commands ignore debris

That's all I know on the matter.

Sounds like it needs quite a bit of digging to fix, and that the original mod has its fair share of problems. The mod sounds reasonably interesting so I may take a look, it is probably not a small task to fix it however..

As a matter of fact, yes. I have wanted to do major surgery on Logain Industries Light Support Drone Carrier (LSDC). I have hacked it enough to make it work, but it has an architectural flaw that I have yet to solve properly. It also has a lot of weird complications that I want to remove.

I did take a quick look at this but for some reason didn't give it a shot, I 've chosen Automated Carrier Software for my carriers. I would love to use real drones, but they just not supported well in X3. I have no idea why they are so hardcoded.
LSDC does look quite interesting, and rather sophisticated. It's probably a nightmare to work on.
Could you explain some of the problems with it?

I need to make an actual choice as to what I am going to work on hah.

[DrBullwinkle]

ACS is probably fine. That is in my "maybe later" folder, but I have not gotten around to it yet.

LSDC does have some basics that are pretty good.

[LSDC is] probably a nightmare to work on.
Could you explain some of the problems with it?

Yes, it is a nightmare. Mainly because it is undocumented.

But also because LA is not an experienced programmer. He was a prolific scripter for a couple of years, but he made a lot of noobie mistakes that a real programmer would have avoided. "Project Death by Feature Creep" among them.

Things to be fixed:

- On-board drone production is a good idea but far too complicated to be of much value. Needs to be streamlined. And, by "streamlined", I mean re-written.

- Rules of Engagement (RoE): Good idea, probably. Again, implemented with too much complexity. Needs streamlining. And, by "streamlining", I mean...

- Drones will continue to engage until they die from time-out. Needs to be fixed; probably by the task that runs on the drone.

- The biggest issue is that, if one drone dies, then it will launch every drone it has on board, and will keep them launched until they all die from time-out. That, in turn, leaves our scrappy little frigate essentially unprotected. Rapid Griffon death is the usual result.

The problem is caused by some "doubling logic" which launches two drones for every one that is killed. It is almost a good idea, because it compensates for any misjudgment in the RoE. However, once it begins launching doubled drones, it never stops. Also, the implementation does not differentiate between combat death and time-out death.

It needs a rule limiting the maximum number of drones in the "sky" at any time. This turns out to be a more complicated problem than it might seem, at first glance.

As far as I can tell, the entire logic for this needs to be rewritten.

The code does some things nicely, but it is not so easy to follow, due to poor naming conventions, spaghetti code, and lack of documentation.

If you are interested, I can pull together my hacks and upload them. But if you prefer ACS, then I will be interested in hearing how that works out, as well. Personally, I see the two scripts as fitting different roles. ACS is carrier management, which could be good for the player ship or in-sector operations (as well as OOS). LSDC is a drone carrier, which is ideally suited to OOS patrols. (And my hacked version really is awesome at that.)

[Teleth]

Okay well I took a look at the debris mod and it seemed functional at a basic level.. only problem was I couldn't find any debris in X3AP/XRM! It's either seriously rare or I need to switch to high view distance...

Gonna take a look at the griffon + LSDC and see how it goes for me.

edit: so far it's really good at destroying the framerate in-sector haha.