[EMP]Extended Mod Pack (2.7 compatible) [Not needed for latest Plugin Manager]

The place to discuss scripting and game modifications for X³: Terran Conflict and X³: Albion Prelude.

Moderators: Moderators for English X Forum, Scripting / Modding Moderators

Post Reply
DIGSIN
Posts: 538
Joined: Fri, 28. Oct 05, 12:37
x4

Post by DIGSIN » Fri, 3. Apr 09, 21:35

EMP needs to be updated to work with V2.

Before i do this i would like your thoughts on expanding EMP

It has been brought to my attention that EMP restricts its use in various ways these are
No cargo space is needed for any wares used
All wares are tiny, so any ship can carry them
There is no notoriety needed to purchase any of the wares added to stations

My plans are to expand EMP with more entries these new entries will solve the 3 problems mentioned above, the existing entries will remain in EMP in order to save any work needed on existing scripts.

I do think that adding new entries will make EMP more useful for these reasons
  • Wares that can only be purchased once the player reaches a certain level.
    Some wares should need cargo space
    Wares that can only be carried by certain ships, EG an M5 cant use a ware that is set as XL)
I am also considering the possibilty of extending EMP to use all the ware files, although this is going to need testing first.

What i need is your concerns, and what you would like from EMP

EMP is a community mod, and as far as i am concerned belongs to the community, i will attempt to do with EMP what it is that you need from it.
(i say attempt, as everything may not be possible)

The majority will rule how EMP evolves.

pelador
Posts: 1399
Joined: Wed, 6. Nov 02, 20:31
x3tc

Post by pelador » Fri, 3. Apr 09, 21:56

Thanks DIGSIN a much needed move towards increasing scope for scripted work.

I realise EMP might need to prescribe a pre-determined number of ware lists that a scripter can potentially select and claim ownership in order to avoid compatibility issues with other developers.

The various parameters in the TwaresT file if changeble will allow full flexibility to developers as how they see fitting to their own work. But I realise and appreciate such optional choice has limits and needs to be manged within a process.

I also think it is in everyones interest to look at the best set-up for a community framework and process that can be of best benefit to all users of EMP to avoid conflicts in this managed process.

The ideal solution would be for users to adjust the TwareT entries customising the values of interest to specifically accomodate their developments, but as useage grows, management, version control and limits in ultimate numbers and perfomance have to be considered. So I realise the need to develop possibly an increased range to do this.

However, considering this may introduce a large number of permutations based on a different range of variants for each field I'm usnsure if it would not suffer the same volume problems to cater for variations as if they were custom entered based on development.

E.g. Cargo class has 6 types, noteriety bands about 12 or 13 and volumes can range from 0 to 1000's. So having a complete list of lots of choices varying these is large to begin with. Thats before addressing price ranges.

So as much as the custom entries seem to be specifically focussed to a development rather than many, and needs managing then I dont see it as being an issue of manging the custom desired process. Taking definition values from users and appending them into EMP in a managed way.

Compatibilty by allowing others to use same id entries is ideally what we are trying to avoid by using a community resource rather than having seperate mods to begin with othr than the need to amalgamate files to combine mods. So the aspect of ownership of ids directly addresses the purpose of the EMP mod. Sharing them goes against what its trying to acheive in my view, but I dont think thats the intention.

Anyhow those are my views (as previously discussed) but understandably we need to have a community framework to achieve the above.

User avatar
Sartorie
Posts: 389
Joined: Sat, 10. Apr 04, 13:05
x3tc

Post by Sartorie » Fri, 3. Apr 09, 23:03

As much as I can understand the urge for new, customized wares to scripters the original EMP was a compromise between compatibility and customizability. Even if it was limited (only spread by reputation and price) it has come a long way and was very usefull.

EMP allows scripts to use wares without them becoming mods and becoming incompatible with each other. But EMP could also be included into bigger mods so these in turn stay compatible with the scripts too.

Now including EMP into a mod could be done in two ways :
1. EMP is included and the mod specific wares are adjusted for it's needs (that is the way XTM did it)
2. EMP is included but mod specific wares are placed after it, so the EMP wares stay untouched

Please remember that the numerical index (line number) in the TWare files is important so if the amount in EMP change the second method (which we are using currently) will no longer work. So if you want any mod to include EMP in the future it needs to stay a) fixed lenght / amount of wares and b) stay as constant as possible

Also there is little gain in adding other wares besides technical wares for scripts and having 1000s of dummy wares is something I personally do not fancy either.

If someone needs more than EMP can offer there is always the possibility to use a mod :)

DIGSIN
Posts: 538
Joined: Fri, 28. Oct 05, 12:37
x4

Post by DIGSIN » Fri, 3. Apr 09, 23:54

I will not adjust EMP in a way that will mean scripters need to adjust their scripts to work with it.

Any new additions will go after the original entries.

As for mods, sorry but the EMP was designed for the scripters not mods. Now before you complain about this please understand, i am currently converting XFP to TC, adjusting EMP will actually cause me extra work for the XFP conversion, i am prepared to do the extra work needed for this.

I have no intention of placing 1000s of extra wares in, as this would risk it becoming processor heavy. If the general consensus is to have extra ware slots within the other ware types, i will attempt to make that work, afterall it is easy enough to filter the different ware types.

Thanks for the feedback so far.

So far it is 1 for and 1 against

PS
EMP is now compatible with v2

User avatar
Sartorie
Posts: 389
Joined: Sat, 10. Apr 04, 13:05
x3tc

Post by Sartorie » Sat, 4. Apr 09, 09:34

DIGSIN wrote:EMP was designed for the scripters not mods.
And I always thought it was designed for the users of scripts ;)

Whatever you come up with stick to it please :)

pelador
Posts: 1399
Joined: Wed, 6. Nov 02, 20:31
x3tc

Post by pelador » Sat, 4. Apr 09, 09:45

Sartorie wrote:
DIGSIN wrote:EMP was designed for the scripters not mods.
And I always thought it was designed for the users of scripts ;)

Whatever you come up with stick to it please :)
Having a community focussed mod accomodating several developments designed to remove potential conflicts is more user freindly to the user base than expecting them to amalgamate mod files and do the work to check for conflicts dont you think?

I'm sure DIGSIN is considering other developers and may adopt sensible contraints. Pretty, sure he wont claim all the id's :wink:

A limited range or pre-defined number even if this occasionally expands would be useful however as it makes it easier to then combine with EMP. Currently there are lots of unclaimed EMP id's that can cater for new values as is but expanding a definable range seems a sensible step also.

Having a managed community resource only makes the updating easier and removes conflicts issues (hopefully) so even if it involves a process it solves many other headaches by using it as a community framework than being independant. Easy choice for me.

User avatar
Sartorie
Posts: 389
Joined: Sat, 10. Apr 04, 13:05
x3tc

Post by Sartorie » Sat, 4. Apr 09, 11:19

The point is TWare mods cannot be merged by users at all because the position of the line (the line number, the index ID) in the file is important - not what you call ID ;) ... if you insert an entry somewhere the index of the ones following it will shift and they have to be manually updated in every script

What you propose is a community pack of wares which will be a steady growing TWare file. Every script / mod has to register it's wares in it and wait until they are included (because they depend on the fixed position inside the file) then that script / mod has to change every reference for these wares in it's scripts to the new assigned ids. And this has to be done before every script release in the future (if he used/changes wares) he would have to wait for the pack to be updated.
Managing this and keeping it up to date will be a nightmare as it will become a big and unsorted pile of wares over time ;)
also you are forcing the users to download the newest version everytime someone changes something etc. and that will be quite a common act as the pack has to be updated quite a lot

Because of this constant change it can no longer be included into other mods as they would have to be built ontop of it and every small change in the pack would require these mods to merge in these changes and release a new version of their mod.

The current EMP has drawbacks but it is very easy to use which makes it (in my eyes) preferable :)

pelador
Posts: 1399
Joined: Wed, 6. Nov 02, 20:31
x3tc

Post by pelador » Sat, 4. Apr 09, 11:25

But you can use the existing index numbers and id's in the emp mod as defined.

So if there is a new expanded list with growth potential (even if room at the moment) then the other values for those references can be overwritten for use.

I'll admit if you expand every time a new ware wants to be added appending to the list and announcing an update wont help other mods or users, as its more work to change the numbers, but this would still need to be done when amalgamating mods anyhow. But if there is a number of pre-defined wares ready for customisation then its a case of altering their other field values.

DIGSIN
Posts: 538
Joined: Fri, 28. Oct 05, 12:37
x4

Post by DIGSIN » Sat, 4. Apr 09, 18:36

Satorie, i think we are misunderstanding each other here, my intention is to add extra ware slots for the scripters to use, i wont be adding in every scripters wares, for the simple reason that i wont have the time needed to constantly update it. These extra wares will go after the slots that are already in the EMP. I will also be checking that every script that uses EMP is not affected by the additions before i release it.

The extra slots will give the scripters a chance to use slots that will require cargo space within the ships, possibly some notoriety before you can purchase them. If it is requested i will place personal slots in for a scripter, but these will be limited.

If we take peladors drone as an example, at the moment there is nothing stopping an M5 from loading up 2000 drones, to me this unbalances the game. If these drones require cargo space, then the player is going to have to Think about what ships they are using.

User avatar
Sartorie
Posts: 389
Joined: Sat, 10. Apr 04, 13:05
x3tc

Post by Sartorie » Sat, 4. Apr 09, 21:13

I think I have to apologize,I am not a native english speaker and when I try to explain things it just seems to add to the confusion :) but I understand what you consider doing.

All I was trying to do was pointing out the implications of a frequently changing / growing EMP will have and why.

Also the EMP was made in 18 blocks with different reputations each containint 20 different priced wares (360 EMP wares total) if you add another var to this e.g. different sizes the wares total will multiply accordingly.

If you are going to make vast changes to EMP I have a simple request too :
Please add 50 ? dummy wares directly after the current EMP ones and add your other changes after them. These 50 wares should be for mods only so the mods can adjust them to their liking and just distribute an adjusted TWareT/EMP along with them. Mods adding/changing wares are already incompatible so these slots can be reused for every mod individually.

As for the drones example - there are creative ways around this too e.g. turning the drones into some kind of upgrade and have every drone launched also consume a normal fighter drone

DIGSIN
Posts: 538
Joined: Fri, 28. Oct 05, 12:37
x4

Post by DIGSIN » Sat, 4. Apr 09, 21:17

Sartorie wrote:
If you are going to make vast changes to EMP I have a simple request too :
Please add 50 ? dummy wares directly after the current EMP ones and add your other changes after them. These 50 wares should be for mods only so the mods can adjust them to their liking and just distribute an adjusted TWareT/EMP along with them. Mods adding/changing wares are already incompatible so these slots can be reused for every mod individually.
Very good point and i will take it into consideration.

pelador
Posts: 1399
Joined: Wed, 6. Nov 02, 20:31
x3tc

Post by pelador » Sat, 4. Apr 09, 21:26

Sartorie wrote:If you are going to make vast changes to EMP I have a simple request too :
Please add 50 ? dummy wares directly after the current EMP ones and add your other changes after them. These 50 wares should be for mods only so the mods can adjust them to their liking and just distribute an adjusted TWareT/EMP along with them.
Yes that would be helpfull, but encourages different mods to use the same ids, potentially causing conflicts, rather than avoiding them. TwareT files can be combined to have more than one mod, aslong as the ids are different.

Having independant mods doesnt neccesarily remove conflicts unless checked for, so whilst the above is helpfull to "independant modders" it doesnt encourage best practice for combining mods.
As for the drones example - there are creative ways around this too e.g. turning the drones into some kind of upgrade and have every drone launched also consume a normal fighter drone
Yes, Pseudo code could be used, same for validations. But I'd prefer to use the balancing characteristics of ware definitions in full. Also it doesnt offer easier scripting solutions to accomodate standard processes.


Sorry, if I may appear to be uncompromising to the suggestions but I'm hoping together we can find the best logical method for everyone with minimal problems and complications like yourself. In short if the 50 extra slots or how ever many helps modders but they need to be aware of defn's and conflict issues then I dont see it as a problem for inclusion.

Loky77
Posts: 110
Joined: Sun, 25. Jan 09, 09:54
x3tc

Post by Loky77 » Sun, 5. Apr 09, 12:57

I don't know if this is possible, when i first looked in EMP i was trying to find product described in game as "upgrade" like the nav software, trading extension etc ... It seems EMP only adds "ware" and not "upgrade".
Wares have some stock, whereas upgrade is just a piece of sofware that is always available for kinda every ship :)
Would it be possible to have some entries to add custom "upgrade" in the game

This is by no mean a request but if you plan to extent EMP, i thought i could put that on the table.

I tried myself to add some entries to have custom "upgrades" and never managed to succeed. maybe some hardcoded thing by egosoft

Thanks

Loky

User avatar
X2-Eliah
Posts: 4369
Joined: Thu, 12. Oct 06, 16:30
x4

Post by X2-Eliah » Sun, 5. Apr 09, 13:32

I am speaking from a basic end-user viewpoint, so if I am speaking nonsense, feel free to ignore this. But maybe it will help anyway.

One problem I see with the EMP mod is that it cannot be installed purely as a fake patch - there are several other mods out there (and more likely will be) that tend to use the same mod enabling thing that is used for this one.. Having the EMP thus allows for some scripts (pelador's drones, for example) while denying the use of some mods..

User avatar
Sartorie
Posts: 389
Joined: Sat, 10. Apr 04, 13:05
x3tc

Post by Sartorie » Sun, 5. Apr 09, 13:46

pelador wrote:Sorry, if I may appear to be uncompromising to the suggestions but I'm hoping together we can find the best logical method for everyone with minimal problems and complications like yourself. In short if the 50 extra slots or how ever many helps modders but they need to be aware of defn's and conflict issues then I dont see it as a problem for inclusion.
Don't worry, like I said I can understand your motives :) thats why I tried to show up the implications different approaches will have.

The X3 engine is not mods (plural) friendly ... if you have 2 mods changing stuff in the same file they will always overwrite each others changes and be incompatible with each other unless you merge them into one mod. This is how the original XFP came into being I believe, merging everything into one giant mod.

pelador
Posts: 1399
Joined: Wed, 6. Nov 02, 20:31
x3tc

Post by pelador » Sun, 5. Apr 09, 14:16

X2-Eliah wrote:I am speaking from a basic end-user viewpoint, so if I am speaking nonsense, feel free to ignore this. But maybe it will help anyway.

One problem I see with the EMP mod is that it cannot be installed purely as a fake patch - there are several other mods out there (and more likely will be) that tend to use the same mod enabling thing that is used for this one.. Having the EMP thus allows for some scripts (pelador's drones, for example) while denying the use of some mods..
If you want to use EMP with other mods feel free to contact me, I can help you with the current aspects of merging TwareT content, might get a bit technical and require some of the various editing tools though. Though might be best waiting to make those choices after this debate, as merging mods requires some self-editing for version control.

I imagine DIGSIN might want to offer guidance for merging with independant mods where these issues occur. I suppose its then a question of wether they are EMP freindly, I'm not a confident modder so dont want to come over the "expert" on finding best solutions to merged content. But I understand the use of the Twares types files however, well enough for custom work anyhow, I hope. :wink:

Modders will also understand the implications of merging content and will consider the issues that are being discussed here, so it's just as good to discuss with the development in question also. Its not my place to dictate or impose how people develop S&M solutions but EMP is designed with a community focus in mind to help avoid the above issues. So with the improvements DIGSIN is suggesting it makes it more attractive for others, especially scripters to use EMP for wares they wish to include (at least on the smaller scale) or design mods with EMP in mind.

Thats my point of view, other modders especially large scale developments will understandably want to remain seperate, having their own managed process, but will consider EMP, currently I know of one main development in mind that will have the strategy to be considerate of EMP including its content. But I cant state for all. Examples of other script work have made themselves EMP freindly also but remain independant. So there is more than one solution to the issues of utilising game content.

DIGSIN
Posts: 538
Joined: Fri, 28. Oct 05, 12:37
x4

Post by DIGSIN » Sat, 11. Apr 09, 17:34

X2-Eliah wrote:I am speaking from a basic end-user viewpoint, so if I am speaking nonsense, feel free to ignore this. But maybe it will help anyway.

One problem I see with the EMP mod is that it cannot be installed purely as a fake patch - there are several other mods out there (and more likely will be) that tend to use the same mod enabling thing that is used for this one.. Having the EMP thus allows for some scripts (pelador's drones, for example) while denying the use of some mods..
Not necessarily X2-Eliah, all the end user needs to do is change the name of the mod to the last number of cat/dat

EG
We are up to number 07 cat/dat, all the end user needs to do is name the mod they wat as 08 cat/dat and then name the EMP mod as 09 cat/dat, this will make the game load up all the cats.dats and overwrite any files with the latest version.

So if a mod already contains a TWare file and is set as 08 when the game loads up 09 cat/dat (EMP) it will overwrite the TWare file with the EMP version.
The only downfall is if the mod requires a certain slot, hence the reason for having xx amount of free slots for the mods to use.

User avatar
ScRaT_GER
Posts: 1962
Joined: Tue, 8. Jan 08, 18:19
x3tc

Post by ScRaT_GER » Fri, 17. Apr 09, 09:35

Hi,

at the moment I am trying to get my script 'Teladi Information Service' to use an EMP-Ware Slot.

There are two things, that just won't work:

1.

My setup script looks like this:

001 load text: id=8300
...
011 $station.array = get station array: of race Teladi class/type=Handelsstation
012 $size.station.array = size of array $station.array
013 while $size.station.array
014 |dec $size.station.array =
015 |$station = $station.array[$size.station.array]
016 |$station -> add product to factory or dock: ZA_EMP_BLANK_WARE_CUSTOM11_2
017 |= $station -> add 1 units of ZA_EMP_BLANK_WARE_CUSTOM11_2
...
020 end


The loaded t-file '8300':

<page id="17">
 <t id="10353">{9,519}eladi {9,508}nformation {9,518}ervice</t>
 <t id="10354">...</t>
</page>


As you see, the product will be added to every Teladi Trade Station.

In t-file '8300' ZA_EMP_BLANK_WARE_CUSTOM11_2 is defined as 'Teladi Information Service'.
So, if I understand it correctly, a ware named 'Teladi Information Service' should be added to all Teladi trade stations.

However this is not happening. In the trade stations I can buy a ware, called 'ZA_EMP_BLANK_WARE_CUSTOM11_2' and only after I first started my script, the ware will rename to 'Teladi Information Service'.
The ware's description is always correctly displayed.

I hope this explanation is understandable and that someone knows the mistake.

EDIT:

I contiued observing the issue and now, while the ware is correctly displayed in the ships cargobay, it is still called 'ZA_EMP_BLANK_WARE_CUSTOM11_2' in the stations cargo bay.
How can that be?

2.

I would like this ware, to be a ship extension, not a trading good.
How can I do this?

Greets,
ScRaT

DIGSIN
Posts: 538
Joined: Fri, 28. Oct 05, 12:37
x4

Post by DIGSIN » Fri, 17. Apr 09, 21:24

Do you have language tags in?

EG
<language id="44"> (44 for English)

<page id="17">
<t id="10353">{9,519}eladi {9,508}nformation {9,518}ervice</t>
<t id="10354">...</t>
</page>

</language>

User avatar
ScRaT_GER
Posts: 1962
Joined: Tue, 8. Jan 08, 18:19
x3tc

Post by ScRaT_GER » Sat, 18. Apr 09, 16:15

Yes I have.

But I think I know why the ware is not named correctly.
The setup script seems to fail in loading the t-file, although it says

load text: id=8300

in line #1.

But not completely, as the ware is 'sometimes' displayed correcty.

Here are some screens. The first showing the wares in a teladi trade station - at the bottom you see 'Teladi Informations Service', which is correct. This screenshot was made, while flying in the universe, directly after loading a savegame.

[ external image ]

The next one was taken after I docked at the station and opened the trade menu. I think you see what happened.

[ external image ]

If I, after that, seperately load the t-file (8300) the names are displayed corectly again.

Anyone knows how that can happen?

Greets,
ScRaT

EDIT:

I contiued observing the problem.

The ware, after it has been named correctly, always is renamed to
'ZA_EMP_BLANK_WARE_CUSTOM11_2' after docking at any station.

If I seperately load the t-file (8300), while I'm docked, and then dock off, the ware name is not changed to 'ZA_EMP_BLANK_WARE_CUSTOM11_2'.
So it only affects the docking.

I'm really helpless. Could it be a script? For testing purposes I have only installed my 'Teladi Information Service'- and my 'Trade Overview'-Script, but none could have such an effect.

Or could it be a hardware problem? To little RAM (4GB) for the t-files^^?

Greets,
ScRaT

Post Reply

Return to “X³: Terran Conflict / Albion Prelude - Scripts and Modding”