Oh oh! I decided to go with NWE and...

[DungeonMaster]

Installed dev version. I got the same error as in the free version and had to comment it out.

Also it says in the Admin info section:

Installed engine version: 1.1.5

Latest version available: 1.1.6

So the one I downloaded is not the latest?

[a_bertrand]

As said since the beginning: the free and the dev version are exactly the same. Simply the dev have access to the marketplace which let you download / upgrade the modules from within the admin page as well as upload your own one. The fix and the port to 1.1.6 of the free / dev will hopefully come in the coming days.

[DungeonMaster]

Just to update this thread:

1. I will like to thank Kyle for the push, he gave me a Dev. license that helped me to understand the system better.

2. I will like to thank a_bertrand for answering my questions by Email and helping me make up my mind to go with a FULL license.

3. I am excited to do some work on this and get it running but my boys will just not give me peace enough to do it. I have not dived into the code yet but I can tell you this is a great system compared with the many I have used in the past.

This is just to say Thanks.

[a_bertrand]

You are welcome.

[KyleMassacre]

No problem, im excited to see what you come up with

[DungeonMaster]

I've gotten the chance to do a lot of testing with the system and it is just what I wanted and should make transferring content from my defunct systems easy.

Of course I do have some concerns:

1. There really needs to be more documentation for modules. For instance in Admin there will be info about updating a module but it does not say how the update will affect it. There is no picture and the descriptions are very sparse.

2. How would Core file updates affect me if I did any editing to them? Will there be a show of what was changed or will I have to try and work outside of the core in order to grow with the updates? This same question relates to the core modules as well.

3. Module regrets - if you install a module and then later need to remove it I notice there is no remove option I guess because of the hook concept and dependencies. Modules should state in what way it will affect your files and what changes will be made so you can undo them.

[KyleMassacre]

Those are some valid concerns and maybe alain can make a little change log atleast on the main site. And you can rest assure that my modules dont touch core or have anything to do with them :p. Rule of thumb that I found out on submitted a few modules is that we do not touch existing tables that would be bad practice anyway so with that said I guess its safe to assume that you dont write over existing files and I hope that puts you at ease a little

[DungeonMaster]

No, no this is not about singling out your mod, these are general comments. I am actually using a test run and just installing, updating, pressing buttons and just being a 'child' with it so when I do start with the real thing I'm not surprised. Some of what I said above I had actually observed long before I decided to go with NWE.

[a_bertrand]

1) We need more info about module upgrades, we should also have screenshots or other for each modules to show exactly what they are.

2) Normally you should NOT edit any of the core files. Why? Because if you do, you will basically have an hard time in case of core upgrade. So before trying to dig inside core file editing, tell us here what you need. I'm quiet sure you normally will be able to solve your issue with a normal module.

3) Un-install usually simply involve in deleting the module directory, you may have to still delete the tables by hand. Why is there no delete module? Because I'm somewhat unsure about how I want to implement it.

[DungeonMaster]

1. Perhaps you can make it a requirement for submission and review what is there already

2. I will keep that in mind though when I'm on a roll I do not like to stop and request something especially because a mod could take months to receive.

3. I've tried that (deleting) but some modules still leave many footprints that can affect your overall site hence my emphasis on description and a list of affected files.

Thanks for your answers.

[a_bertrand]

1) Not being my full time work, things are implemented when I have time, and depends of how important those are ;)

2) As said, you should not need any modification of the core. If you do, then I did something wrong or you missed one of the existing feature. That's why you should ask before simply modifying the core. It's not prevented and you are fully allowed to do so, simply if you do it, you will loose the option to upgrade to future versions as easily.

3) None of the modules leave footprints beside user variables, configurations keys and tables. None of which should have any impact on the speed. No modules are allowed to modify anything outside of their own module directory,

so simply scanning the module directory should tell you which files are in ;)

[KyleMassacre]

1) We need more info about module upgrades, we should also have screenshots or other for each modules to show exactly what they are.

2) Normally you should NOT edit any of the core files. Why? Because if you do, you will basically have an hard time in case of core upgrade. So before trying to dig inside core file editing, tell us here what you need. I'm quiet sure you normally will be able to solve your issue with a normal module.

3) Un-install usually simply involve in deleting the module directory, you may have to still delete the tables by hand. Why is there no delete module? Because I'm somewhat unsure about how I want to implement it.

3) since there is a disable feature already in store we can "assume" that dropping a module from the directory should have relatively no harm on existing modules. The only problem I see is functions possible from another module which can be avoided if using the function exists function which I think should always be used when developing a module and your are using something thats not from your lib, variables: which I believe can be safe if you use runhook() and if not maybe look into that.

But I was thinking that maybe another xml field that we can use to define all tables that has nothing to do with the table editor that will scan your db for the tables and remove them like that?

[a_bertrand]

I was thinking of scanning the install.sql file to create automatically the drop table. However, I wonder what happens if another module relies on that table, or if you would actually want to keep the data.

[Uridium]

Greeetings ;)

[DungeonMaster]

Tables should not be an issue unless they actually modify core tables.

Lets take the verify Email module as an example. (No Kyle nothing about you, just an example). I installed it - locked me out. Could not do anything because I did not get the verify Email. I then deleted the module via FTP and the lock was still there! So in some cases simply just deleting a module does not remove what it can 'do'. This is just an example. Hence another reason to emphasize descriptions.

[a_bertrand]

Has nothing to do with the module in this case as the lock is due to the user table which lock you down to a single function. So even after un-install you would still be locked. In any other case you can simply delete the module directory and the module is gone. NONE of the modules are allowed to modify core tables nor core files.

[DungeonMaster]

BUT - it still disables Admin with an undesirable result. The illustration is that the module IS capable of doing something that can render someone's install frozen regardless of it being core or not.

Keep in mind that the idea you are proposing is the ease at which NWE can make installing modules, etc. Not everyone knows how to go in, uncomment, alter codes, edit files, change databases, etc.

Please see this as constructive input and not as criticism.

[KyleMassacre]

The comment is my fault and no offence taken I just forgot to remove it when I submitted.

A scan of the install.sql is a nice touch and you mentioned dependent tables which can be an issue. Now I wanna go back to xml, (which im not really good at) and maybe add a field in there for dependent tables and maybe cross reference other xml files/sql files and just do some sort of compare and contrast to see if it is needed or not when you uninstall? I know it would be a chore if possible but since we are kicking around ideas here and there.

@Illusions: welcome back long time no see

[a_bertrand]

Dungeon: un-installing, comment or do whatever you want would not have solved the issue as the issue is in the database: NWE offers the option to lock the game to a particular file/function, for example in case of combats. Until you unlock it (or edit the table by hand) you will not be unlocked. No matter how much you delete / uninstall a module.

Here, having a module which is not buggy, and knowing a bit more of the engine is the key.

I will not rush to implement a useless function without thinking. BTW how can you un-install if you are locked out ;)

[DungeonMaster]

a_bertrand you are only reinforcing my points:

 

Dungeon: un-installing, comment or do whatever you want would not have solved the issue as the issue is in the database: NWE offers the option to lock the game to a particular file/function, for example in case of combats. Until you unlock it (or edit the table by hand) you will not be unlocked. No matter how much you delete / uninstall a module.

Exactly hence this needs to be documented with mods.

 

Here, having a module which is not buggy, and knowing a bit more of the engine is the key.

Actually, when a module is downloaded from your site it is assumed you checked it for bugs and "locks" or you don't test them? This will help me ascertain what level of trust I should give to third party mods.

 

I will not rush to implement a useless function without thinking. BTW how can you un-install if you are locked out

Not sure what that is supposed to mean but if you read the Verify Email thread you will see I brought up that point. Prior knowledge about something saves time for the end user.

I think I may be running in circles here with suggestions and since I do not have much time I will stop there.

[a_bertrand]

So what you mean is that each module should have documentation? Well we have a wiki, whoever feel he/she has time for it is allowed to add content to it. Being for his/her module or for the main code.

Now, if you don't allow any bugs, fine, but then you should maybe change and not do programming, as in any code you will have bugs ;)

Overall Dungeon, for me you start to look like somebody which expect to NOT spend any time on anything and expect to have somebody else do the work for you. You will have to learn the code of the engine at some point, as well as the code of the mods you install, otherwise how do you expect to be able to add your own mods, fix bugs, or whatever? And if you lose time to speak with us, fine... I start to feel the same too...

[DungeonMaster]

You know what, I've read many of the posts here and I have seen you battling with a lot of members some of it can be quite heated at times, now I understand why. Could be culture, could be language difference, could be the lack of understanding through a limited communication interface but it does not matter as I know my purpose in presenting my suggestions and it is not what you presume or assume. Needless to say I'm sure you may have an answer for this too as some love to have the last 'word'. Good luck with that.

[KyleMassacre]

sorry to dig this grave up but I just had a thought. like I said in a previous post about using the config.xml to display other module information for example we can use something like this:

<?xml version="1.0" encoding="UTF-8"?>
<configuration xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:noNamespaceSchemaLocation="http://www.nw-engine.com/modules.xsd">
       <module version="1.0.0" name="Restore Stats" author="Alain Bertrand"
               description="Restore some of the stats over time. The configuration is on the stats themselves." />
       <variable name="statsLastCheck" />
       <dependants>
               <engine version="1.1.6" />
               <module name="home" version="1.0.3" />
       </dependants>
</configuration>

then possible on install or update if those modules listed or the engine version listed isn't up to date then it flags you and aborts update or install. would that be doable?

**side note**

don't mind the xml it was just used as an example I'm not entirely sure that it meets requirements :p but you get the point

[a_bertrand]

Yes that's something we should put in. That would allow to make sure you have the right modules to make your module work as well as the right engine core. I will look into it for the next release (as well as the delete user).