Bukkit

Sure. Do you know of an upload site I could use?

As well, with this setting, where-ever a cannoball hits leaves a patch of snow on the ground. Nothing happening.

By setting "force tnt event" back to true, Cannons no longer work in general. The projectile is launched, an explosion animation and sound is triggered, but ultimately no block is destroyed.

in WG, all kinds of explosions are not blocked. Creeper explosions break blocks, regular TNT breaks blocks, this is all tested and true. However, cannon projectiles do not break blocks anywhere.

This is fixed by turning "force tnt event" from true to false. However, now cannon projectiles will explode and damage WorldGuard regions, despite having TNT: deny and creeper-explosion: deny set.

Seems like a very serious problem.

Using your R.03 build, TNT does not break terrain. TNT in and of itself does break terrain, but TNT as a projectile in Cannons does not work at all.

@DerPavlov

great thnx R0.3 solved problem!

i use R0.2 the last - I think better )))

@DerPavlov

shoots exactly perpendicular to the gun barrel

link http://ci.ecocitycraft.com/job/Spigot/321/

A default gun shoots at angles of 30 degrees to the left. And I can not get it to shoot straight.

Spigot craftbukkit-1.4.5-R0.3-321

On the note of a web interface, having the MySQL support is more then enough. Any web programmer should be able to create their own custom interface to fit their needs with minimal effort since MySQL is a natural part of any dynamic web language.

Personally I will be using PHP to create one if you get this running and am willing to put up the source for others to use and/or use it as a guideline to make their own custom one from.

^_^

If you use basic rules that all cannons have to follow you could set it up as a cuboid set up.

So say that the cannon has these settings that are optional :

isCannon : true/false isMortar: true/false

This would tell if the cannon was facing up or facing a direction, then we add the basic settings that are needed to define a cannon in the file such as :

cannonMaxLength : X cannonMaxwidth : X cannonMaxHeight: X cannonBodyBlock: BLOCK fuseBlock : BLOCK

This would allow scalability to thickness of the cannon and show where the core is that the program needs to look for to make sure a cannon of type X is the correct schematic. You would need to have the fuse of course be on one end and not the other so I would have it check the length one direction over the other, of course checking that the longest travel distance (ex 3x3x8 cannon would check and see one direction was 8 in distance, so this is the cannons front to back direction) then make sure that it is farther from fuse to tip then fuse to barrel to define exact direction. Of course this would not be an issue with the isMortar setting as it will always fire up we would just need to look for the nearest airblock on the y-axis.

Now if we used a sign that has to be placed on the cannon to trigger the event of checking the schematic, say on line 2 and 3 we have them put the following text :

[CANNON] [SCHEMATIC]

then we do not have to tie down the listener looking for the fuse block and we can check that there is indeed a cannon there of X type schematic. If the schematic is not followed properly it could either send a fail message or what I think would be cool have a backfire event be used like if you had misfired a gun.

Now because we used a sign to define the cannon we could allow a restone circuit going to the sign cause a block update on it and see its a sign, look to see if our text formatting is on said sign, and reinitialize the cannon defining event, because it updates the block we could have it silently check the schematic again so no "You've made a cannon" text would show and as its redefining on redstone update it would be viable on movement such as with movecraft or worldedit etc.

If we have the sign check if the cannon was previously defined before we could make that redstone update also fire said cannon if there was previously ammo loaded into the barrel making it seem to the user that you have to "prime" the barrel when its moved which is fairly realistic (and they don't really see whats going on in the background) and then fire the cannon with a second pulse (since after the first one we check for and redefine the cannon if it was moved).

Since our core barrel was previously defined with a height width and length with a direction to be fired we can now design around the cannon and its said design to make it feel how we like, and because our sign is now redstone controlled we can control where the trigger and what trigger type we have is!

From here we can add advanced effects from a said cannon type that are not tied to its actual design, here are some ideas :

cannonKickBack cannonKickBackEffect1 cannonKickBackEffect2....... and so on cannonCoolDown cannonMaxGunpowder cannonMinGunpowder cannonMaxFireSpeed (possibly the scale at which gunpowder multiplies the ammo types fire speed)

etc etc etc.

Hope this gives you some ideas! Ambe

Sorry if I was not clear enough I kind of went on a tangent.

The idea was to do away with the yml file all together, storing your plugins settings into the database as a choice instead of using flat files (yml). Since the plugin only needs to read the settings once and store them in memory it should make little to no difference in speed switching to a database to store settings like this.

The idea of different gun/ammo types was that earlier you were thinking of allowing custom cannon configuration. You can configure a cannon type and have the ammo that is allowed to go into that type of cannon have different properties based on the cannon type that fired it.

Example : Cannon A is a basic cannon, TNT is an ammo it uses, TNT will act like a cannon ball when fired from this type of cannon.

Cannon B is a mortar, TNT is also an ammo it uses, TNT will act as an explosive that rains fire down on its target when fired.

Basically allow people to make their own configuration to define new types of cannons, then apply certain effects to the cannons to make them custom. From there have an valid ammo list that can be configured for each cannon type and how they will behave when fired from said cannon type.

If this was set up in this way, and the cannon settings defined in a database instead of using a yml file as is explained above, admins could customize their cannons or define whole new cannons even through their website and then just run a reload config command in game or on their console to have the plugin check for the new settings in the database.

As such they could also set up a PHP or other type of script on their website to show the schematic for the new cannon type the chose to make so that players can build it with out having to manually write a post or tutorial on their custom cannon. The script could include the ammo properties and valid ammo for that cannon type as well.

I hope this is a bit more clear on the idea, if not let me know, Ambe