[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: Scripting / Modding Moderators, Moderators for English X Forum

Post Reply
DIGSIN
Posts: 395
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: 1230
Joined: Wed, 6. Nov 02, 21: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: 384
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: 395
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: 384
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: 1230
Joined: Wed, 6. Nov 02, 21: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: 384
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: 1230
Joined: Wed, 6. Nov 02, 21: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: 395
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: 384
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: 395
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: 1230
Joined: Wed, 6. Nov 02, 21: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, 10: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: 1827
Joined: Thu, 12. Oct 06, 16:30
x3tc

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: 384
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.

Post Reply

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