Will custom 3d objects have a hit box of some kind or they will be 'immaterial'?
If yes, how will it be determined? Automatically from the object geometry? Provided separately by the modeler?
Will it allow 'hollow' shapes with internal space / holes?
An emblematic case of cross-posting... 
Thanks to @red51 for his reply.
For the dedicated server, I share @zfoxfire concerns and fully agree with his cautions: the possibility of plug-in enabling / disabling should not be in the hand of 'regular' players and probably it should not even be in the game at all. It could be an external command, via some kind of console (not the in-game console) or RCON, accessible only to the server owner.
A plug-in reload feature would already go noticeably in this direction, though.
(As an aside, commenting on @zfoxfire observations, as far as I understand it, there are no client-side plug-ins; plug-in are only loaded server-side; even if the user has some plug-ins installed in his local RW copy, they are loaded when a local world is entered (i.e. when the local, implicit, 'server' is started), but are ignored when going multi-player; at least, this is how the current LUA framework works and I assume it would be the same for the Java framework).
Oh, hmmm, well... (just taking time...) I already said elsewhere that, for me individually, update rate is fine; I would even delay -- to group them in bulkier changes -- individual small updates, at least those which require a re-installation of servers (as most do, BTW).
But I also understand that this is just me; other may have other perspectives and a different perception of time. Also, obviously if the mass of the target audience "out there" perceives the game development as going too slow, a vicious circle of bad reviews and less sells which will ultimately affect the development itself (even programmers have to eat, occasionally...). Even if community feddback can be useful and stimulating, it is ultimately the responsibility of the dev team to combine / optimise the deve resources with the update rate.
Also, as @zfoxfire already said, the new API is a first but important step for plug-ins and add-ons which might change RW quite a lot, if not immediately, at least in perspective.
I would also not underestimate the 'active' possibilities even of this first new API: it will not be so "static" as @ArcaneDesmond fears, as it will allow to translate and rotate custom objects; combining this with a simple proximity detector code and the possibility to interact with custom objects (like the [F] keys does now) will result in potentially very active scenery objects; it might be surprising how much can be done with 'simple' translations and rotations, if one does not limit himself to thinking only in terms of bone animations and light 'special effects'.
If we get a subdirectory dedicated to the plugin, you could essentialy write a class to handle the configuration file. It would contain a method to generate a config file off of a template inside the jar[...]
Yes, I know I can do all of this. But, again, more code to write, debug and maintain, etc etc... Added complexities in exchange of what? Where are the advantages?
I understand it is way too early for implementing anything of this kind, but I'll start venting the idea, so that it does not fall through...
A plug-in manager would be nice to have, tentatively with the following basic functions:
*) list of all installed plug-ins, possibly with title, version and contact URL / e-mail of the author
*) choice to enable / disable each plug-in (without actually uninstalling it)
In single-player, it could be an option in the top menu (parallel to "Single Player" / "Multiplayer" / ... options) or of the "Settings" dialogue box(es). I believe the requirement to be out of any world in order to change the status of a plug-in would be perfectly acceptable.
With a dedicated server it would be probably more complex, but a way to enable / disable individual plug-ins without restarting the server would be great.
P.S.: I think it is better to keep this purely local functions separate from other functions which would access external resources, like a plug-in downloader/installer. To discuss the latter, it would be better to open a separate thread.
Lol, the stephen hawking bit was tongue in cheek.
As was my comment about it (but being a programmer's tongue -- or a programmer's cheek, who knows --, probably it went unnoticed..)
I didnt realise i would need a programming degree to add models
You don't need a programming degree. If someone plans to come to Italy (let's make a less exotic example, this time...) and wants to interact with peoples here, he doesn't need a PhD in Italian Language and Literature. But he should not expect that a two-page leaflet would explain everything he needs to know about Italian language and customs. If he does, he should expect to make a lot of errors, to waste time, to lack opportunities and so on. Some lessons of Italian would help...
Same (or similar) here. No need to attend a one-year academic programme; but some solid ground to build upon is needed.
The jar just contains the default configuration
This is a small detail but I believe it illustrates nicely my point. A config file can surely be placed inside the .jar itself.
However, a default config file can largely be auto-documenting; but, if it is placed in a place where the average user would not even think to look for it (inside the .jar), an additional, text file should be added to document how to create a custom config file and what to put in it. And we are back at square one!
Consequences:
*) we still have an external file;
*) the developer has one more file to maintain;
*) code needs to be added (and debugged, maintained, ...) to look for two different config files in two different places.
To me this seems a loose-loose situation. Where is the win?
seriously can someone write a tutorial and use words that "normal" people can understand,
This is a request which pops up regularly, so I am not replying specifically to @ozmods, but perhaps a bit more in general (so, ozmods, please do not take the "you" as specifically addressed to you).
It greatly depends on what you mean by "normal people" and what your background is.
Take for instance a request like "can someone write a tutorial and use words that "normal" people can understand about how to have a conversation in Chinese?" If you have a good command (or are a native speaker) of Viet, things may be relatively simple (ignoring writing, of course...), if you only have a limited knowledge of Tibetan, it will require definitely more details and time; if you never learned another language, well, it is going to take a looooong time, and a lot of patience and perseverance...
Programming languages are languages (of a specific kind); indeed, natural languages are more complex and less rigorously defined, but there are things in common to both, so the analogy has some ground (and many limits, of course).
1) If you have a good command of Java, you only need to learn the peculiarities of a RW plug-in in respect to Java programming in general. And this is mostly covered by @red51 posts at the top of the Plugin Discussion section (there are uncovered aspects, but mostly because the API itself is not finalised yet).
2) If you have a good command of a language widely used and not abysmally different form Java, like C++, you need a crash course focused on learning the differences (specifically, there are good tutorials about the C++-to-Java transition) and then 1).
3) If you only had a limited exposure to some non-object oriented and non-strongly typed language or to some scripting language (like Javascript or PHP; note that HTML is NOT a programming language at all) or have no programming experience at all, then you need a 'real' course on programming in general and about Java specifically, then 1). There are good, free, tutorial collections (almost equivalent to a course) on the net; but expect that the time needed to gain any proficiency is measured in weeks, at best.
There are no effective short-cuts. If you take one today, you will spend more time later by fixing errors you would not have done or understanding why these errors happen and from where (lack of foundation concepts).
I would like to add a few models to RW but if its going to take an engineering a computer science and Stephen hawking to do it, then I have no chance lol.
Nobody in this community is Stephen Hawkins (or at most only one person could be him, assuming he plays RW), still many peoples can contribute nice -- and working! -- plug-ins. The more one knows of the topic, the better/easier/faster it will be, of course; but nothing of this is outside the grasp of an average person.
As an aside: if someone has no experience of programming at all, this might be the occasion to discover a life-lasting interest. But chances are that this someone is not really interested in this approach to things and might find it surely doable, but repulsively boring and devious.
Sorry for turning this into mostly a dialogue (luckily @ArcaneDesmond post adds at least a third voice).
If your assets distributed change over time, you need to bump your version number
Assets which changes at the user side, like setting files.
I think its reasonable to expect that if the person using the mod just wants to use it out of the box then they can just install it. The directory creation and whatnot should not be done unless[...]
Perhaps when RW boots up, it scans the plugins and automatically creates the subfolders based on the jar names. [...]We have to view installing mods almost like operating a toaster appliance. You buy the think and plug it in and it just works.
Precisely! Which, IMHO, is not the direction your proposal seems to go, with a lot of optional steps, potential requirements on RW start-up sequence and scanning, on file naming and so on. I expect the majority of plug-in will not fall in the single file scenario, so all these complexities will be usual, not the exception.
OTOH, download the ZIP, unZIP it into a new sub-directory of "plugins" of its own, and it's done (a sub-directory which may be already present in the ZIP itself)!
If I want to rename the sub-directory (because the dev named it "APr100" and I want to call it "Area Protection version 1.0.0" or vice versa or for any other reason), no problem, it still works. I make a typo and write "Area Potection" instead, no problem, it still works.
Every plug-in is given its own space (its own directory) and it manages as it want / likes / needs. Less requirements to force upon (and document and explain to) the dev; less operations to explain to the user; less things which can go wrong.
I probably miss something important, but it seems to me you are placing additional requirements and then need to add additional level of complexity to work around these requirements. Which would be fine if these requirements bring great advantages, but I fail to see such big advantages. Maybe things can be simpler...
Maven is a much smarter built tool than Ant. [...]
As I said I trust you on this, as I lack any direct experience. The important point was the following sentence, though:
I would prefer if the plug-in specs define an intended result / structure, rather [than force] some specific way / tool / process to achieve it.
The problem with putting everyting on github is I imagine we would have lots of mods in the works. That cannot be put under a single git repository. Git is one repo per project. A git server dedicated to the entire community (whether it be paid for by the community or by JIW) could be more cost effective. Each mod writer has their own repo or repos. And they can control write accesss to their repo
I am not a share holder of github! It is just a tool I used a lot. Github public repos are free and any user can have as many of them as he want. So, a hypothetical user "RWPluginCommunity" could have an unlimited number of different repos, one for each plug-in. As long as they are public.
I think I understand your points and I surely agree with some of them. However, I am still not convinced about some of them and/or I have some comments.
A) The directory structure:
keeping all assets in one jar is very common practice for making a jar.
Indeed! But it only works for assets distributed together with the .jar and which do not change over time, it does not work for assets which do change over time or are added at user side.
Practically all the plug-ins I plan to make or have thought of fall in one or both of the above categories. I am sure the 'simple' scenario occurs too, but the structure has to accommodate plug-ins of any complexity and behaviour.
Regarding the elevator scenario, [...] Your instructions can say you can optionally make the subfolder and have the folder contain the config file and user provided model.
Oh no! Nobody reads instructions (except you, me and some other on this forum, of course... 
), Windows users never pay attention to file/directory name case, everybody can make mistake... The less steps are required by the user and the most obvious each operation is, the smaller the probability of errors and problems. The simpler, the better; and "one plug-in, one directory" is hard to beat as simplicity and understandability.
And, in general, having each plug-in separated from any other and with all its components along it seems to me clearer, cleaner and easier to understand and to put into practice (incidentally, the requirement you seem to propose of .jar file name matching sub-directory name is another thing which can easily go wrong).
Placing the jar outside a subfolder makes it a bit easier to update jars (all jar files immediately under the plugins directory) or a way to quickly restore a plugin behavior (wipe the subfolder).
Yes, probably it makes easier to fix some errors; I believe that preventing or reducing errors in the first place would be better, though.
__________
B) Maven & NetBeans: I have never used either, as I'm in the Eclipse / Ant congregation 
(or :evil: , who knows...?), but I assume learning new tools is not an issue. In general, though, I would prefer if the plug-in specs define an intended result / structure, rather some specific way / tool / process to achieve it.
__________
C) Central repository/-ies:
C1: From the user perspective, as I said right above, one of the better ways to manage plug-ins would be if RW accesses and presents to user a list of installable plug-ins, to be downloaded and installed (and UNinstalled!) with the proverbial "single mouse click".
How the repository backing this list is organised, whether some quality control is assured or whether some requirements are made to appear in this list (and which ones), I believe are questions better left to the dev team to decide, according to the general application structure, dev resources and priorities, whether Steam (and Steam Workshop, in case) make requirements or assumptions and so on.
C2: From the plug-in developer perspective, a general repo for plug-in source code dev would surely be nice to have.
*) This can be as simple as a public github repo (which are free) or more structured (I don't think github public repos allows to restrict access to individual sub-directories).
*) It may be started and run by JIW (at several level of involvement depth) or it may an independent initiative (a few similar initiative already exist).
*) It may be totally independent from C1 (develop here and move to C1 when ready to ship), which would reduce the signal/noise ratio during development or it may be integrated in several ways and at several levels with C1.
As the "meat" of this repo would be largely supplied by the community (or by the pug-in developer sub-community), opinions / indications from JIW are important, but some kind of consensus from the (sub-) community should also be reached (maybe implicitly by participating or not to it).
You are welcome. Glad the problem was solved.
Deal! 
Thanks for your patience and support! 
I suggest we consider using Maven to build and distribute our plugins.[...]
I personally manage a a few different maven repos at my job.[...]
each snapshot is built, deployed to maven, and available for testing. anyone who wants to examine the jar deployed will always get the latest 1.0.0-SNAPSHOT as snapshots contain many builds, each with an internal timestamp
About snapshots: The thing nice about snapshots is that they are incremental but keep the same version.
[...]
Distribution: I have never used Maven repositories, so I'll rely on your judgement for this.
However, If I understand correctly your description, I am not sure I would like the general audience to have automatic access to non-release versions (snapshots); I am rather pretty sure I would NOT like it; pre-releases should circulate only among selected (by the author) testers who are reputed to be reliable.
This may look like a personal preference, but if a way is provided / suggested / documented by "the game" to unconditionally distribute pre-release versions, unaware users will flood the fora with questions, complains, rantings about "game problems" which are actually plug-in development issues. I fear a significant reduction of the signal/noise ratio here, as well as an unnecessary increase in user support load and a largely unjustified "bad press" for the game.
Ultimately, in the best of possible(?) worlds, RW itself will provide from within the application to a list of distributed, installable, plug-ins (accessing in whatever way is considered efficient a repo of whatever kind) each with a title, a short description and an e-mail/URL of the developer to send enquiries to, the whole with a BIG notice that JIW / RW bear no responsibility and provide no warranty about those plug-ins.
_______________
Directory structure:
The only reason we would need subfolders is if there might be user custom configuration so for example:
and elsewhere:
[...]For assets, it might be a requirement to put them into the jar file[...]
So to recapitulate this, I *guess* the best approach is having all plugin jars just into one single folder (the "plugins" folder), third party libs (I think most plugins don't use any third party libs at all) may go to a "libs" folderFor assets, it might be a requirement to put them into the jar file
I beg to disagree. As I already explained elsewhere, my *guess* is that the "rule" easier to understand, to implement and less risky is "one plug-in, one sub-directory", regardless it consist of just one single .jar or has several files, assets of whatever kinds and so on.
Ancillary files may be of many different kinds, not only built-in assets or libs or config properties. There might be localisation files, user-provided assets (for instance, for my elevator plug-in, I plan to provide one default elevator cab 3D model, but allowing the final user / server owner to provide their own, if they can / want), user-defined quest / achievement descriptions, etc, etc, ...
So, the "put them into the jar file" requirement is going to be too restrictive and the plug-in should be free to arrange the contents of "its" sub-directory as it likes, possibly with further levels of sub-directories inside it.
I am sure I am forgetting some other important point, but it is late in the night and neurons start to overheat...
As soon as I'll be at my dev machine, I'll try to reproduce the error.
As as first indication, I would guess that by editing the file, it has been corrupted somehow: there isn't and there shouldn't be a character 239 in line 1 of gps.lua.
However, as character 239 may be part of an UTF-8 BOM, I suspect you saved it with some text editor which added to the text some encoding of its own. The file has to be pure text.
About files and directories, I have replied here, trying to keep the discussion about this topic all together.
About repositories, I believe this a topic important enough to have a thread of its own, doesn't it?
It just seems that for mods that do not require the user modifying settings that simply dropping in a jar would be convenient. Whatever configs info can just be read in from inside the jar. The zips can still work as discussed earlier.
I know this is still being finalized but I was just thinking that for certain mods that dont require external configuration files, it might be convenient to drop a jar directly into the plugins folder without any unpacking.
@zfoxfire posted this here, but I am replying here as an attempt to keep all contributions about this topic together.
Placement: I agree that it, in the specific case of single-file plug-ins, placing the file in the main "plugins" directory would be easier. I am not sure it would be globally easier, though. Having a rule with sub-cases or exceptions is more complex and error-prone that a single-sentence rule:
"Each plug-in shall placed into its own sub-directory under the "plugins" directory, unless it is a single file, in which case it can be directly placed in the "plugins" itself".
is not easier to read, to remember and to put into practice than:
"Each plug-in shall placed into its own sub-directory under the "plugins" directory".
Unless, the rule will be to have only single-file plug-ins, in the form of a ZIP-ped file, which will be placed in the main "plugins" directory.
File type: whether to natively support ZIP files or not -- in addition to OR instead of .jar files -- is a decision which the dev team can make, having in the mind the general structure and economy of the app.
Personally, I would NOT push this option, though. The ZIP file has to be expanded, sooner or later. This can happen in memory each time the application starts up, resulting in greater memory occupation and slower start-up time.
Or it can be done once, the first time the application finds a "new" plug-in ZIP in the standard "plugins" directory, extracting into a specialized destination directory. This raises some issues as well, though.
*) It might be hard to decide when a plug-in is "new": how to detect a new version of a plug-in with exactly the same the ZIP file name, in order to update the destination directory containing the expansion? Has to application to keep track of file time stamps too?
*) What if "myPlugin_1_1.zip" is added to the "plug-ins" directory? How the application can decide that this a new version of "myPlugig.zip" and delete the expansion of the previous version?
*) Having both the ZIP file and its expansion may lead to confusion and/or to sync problems due to manual updating the latter without updating the former too (we ALL did this this kinds of things, didn't we?)
So, unless there are other compelling reasons, I would not suggest supporting ZIP at all.
Of course, this does not affect distribution: plug-ins could still be distributed as ZIP files; it would be the care of the user to expand them into the appropriate (sub-)directory.
Under this respect it would be useful to encourage authors to distribute plug-ins in ZIP files already providing their own sub-directory directly in the ZIP file (so that these ZIP files could be expanded directly in the main "plugins" directory, without directly dealing with sub-directories).
@zfoxfire: possibly I intended a little more than simply "reasonable" given the context (dev team size, etc.) or given the habits of decades ago (which I experienced directly, but I also got accustomed to technology advances...); rather, reasonable for the community.
The suite of small(er) and quick(er) updates after the water update put "out of business" a number of servers (either owners slow in updating, or providers making a mess of it, ...); the server I frequented the most at that time had active and friendly admins, a nice community and so on; after remaining down for several days twice (provider's fault with the updates), most people left, and finally even admins felt less motivated.
I know that some servers are excellently baked by owners/admins who do a very good job of keeping the server working, the world entertaining etc (resulting in a good presence of players). But it should not be a "job", neither for the admins or for the players... at least not yet, while the programme is still under heavy development.
Even on the single player side, a constantly moving target is not necessarily the best option, as user support becomes more complex (regardless it is provided by JIW or by the community) and users felt irritated by things which "do not work" (mostly because they do not read the explanations... explanations which also get dispersed in many announcements and threads). In fact, many of us are still learning how to use the water in terrain design (me included)!
For instance, an update, say, every week would quickly result in a mess: servers never working, players not aligned with the last version, nobody knowing what is new and what was already there, flood of posts in the fora asking for the same details again and again...
So, I believe an update rate not very fast paced is (mostly) positive for the community. Perhaps, there are ways we as a community can adopt to counteract the feeling of being stuck this may occasionally produce on the most impatient (and sometime unreasonable) users.
I am not sure to understand, but probably the programme message has to be taken literally: you need to have a blueprint item in one of the quick slots (1 - 5) of your inventory and to equip it (selecting that quick slot) in order to be able to use a blueprint file.
If someone makes a plugin that does the job i don't see any point in reinventing the wheel, unless it can offer some far better advanced options
world edit can just about all be done now with the built in creative mode oO i dont see the point in remaking it oO not fully anyway.
i guess we will just have to wait and see, i think this time round theirs more users keen to get involved
Possibly I'm having a senior moment, but I do not understand if your remark is directed to my post immediately above yours.
Generally speaking, all current LUA scripts will have to be re-written in Java, as they will stop working when sooner or later the LUA framework will be phased out. This can be a simple 1-to-1 porting, but my dev experience suggests me that porting is rarely linear, often one sees a better way to do the same thing, better thing(s) to do or rough corners to cut and the result is often somewhat different. Also, the wider potentialities of Java may suggest additions to and/or generalisations of the structure of an existing app.
