1.1, 1.2, 1.3, and 1.4 should be doable.
1.1: Towny has an option to regenerate explosion damage, although the speed might be too fast for what you need.
1.3: You could have almost ready to explode TNT summon an invincible invisible armor stand, then after it explodes, have the armor stand /setblock and then kill itself.
1.4: You can /summon Item entities with different amounts. Also, you could use /replaceitem to directly change hopper contents.
2.1: That would be difficult to do and probably wouldn't be too accurate without a sample size large enough to cause major lag on the server.
3.1: Remember, the Overworld void is blue until you are in it. You could use end portals or gateways, but those are very laggy.
3.3: I have built something similar and can explain how to set it up. Also, we could do two passes, one that loses, say, torches, and places the anchor block, then another that places the torches correctly.
Alex wrote:
Regarding 1.1, 1.3, and 1.4: you're giving me way too much credit. I don't know if any of that is possible, and if it is, what it would take to implement it.
2.1: I have no idea how scoreboards work.
3.3: Possibly, but again. I have no idea what's involved in this.

I'll chat with command about what would be entailed and we'll tell you the necessary command(s), and you can decide if or which ones to do.
Edit: Command's post is above mine. Smile

Alex wrote:

3.1: I don't have any objections. I won't add any end/void blocks because that didn't work very well last time. Granted, this would be a smaller area but I still don't want to cause any unnecessary lag.

Nah, I'd just punch through the bottom of the map in that quadrant.

Also, little progress update... the randomizer on the Borg cube now functions as intended. The randomizer itself is a dispenser filled with shulker boxes filled with enough items to emit from 1 to 7 signal strength, feeding into a redstone recoder, that activates only the torch corresponding to the signal strength. Those torches connect to either of the 3 cannons on the Cube, or any combination of the cannons.
I then set up a redstone t-flop, that every so often sends a pulse through the system, causing a new torch to be selected.
On the first test, the system caused the cannons to break. I realized that the current cannon design, required a normal length pulse to first trigger the propellant, and then on the falling end, trigger the projectile... but since the recoder creates a constant pulse, the falling edge wasn't activating until way later, causing the projectile to explode in the launch bay. I fixed this issue by adding a rising edge monostable before power reaches the entire cannon circuit, with a pulse extender after it. The system now works like a charm.

Also, can each ship be moved in 5 blocks? As in each ship 5 blocks closer to the other one? This would allow ships to fill 3 or 4 of the dispensers on each side to target the front of the enemy ship, and fill the 4th or 5th to reach more rear sections.
commandblockguy wrote:
1.1, 1.2, 1.3, and 1.4 should be doable.
1.1: Towny has an option to regenerate explosion damage, although the speed might be too fast for what you need.
If that speed can be altered, it would work. Towny is only slightly too fast. If we want to save a command block, that could work.

commandblockguy wrote:
1.3: You could have almost ready to explode TNT summon an invincible invisible armor stand, then after it explodes, have the armor stand /setblock and then kill itself.
1.4: You can /summon Item entities with different amounts. Also, you could use /replaceitem to directly change hopper contents.

Smile

commandblockguy wrote:
2.1: That would be difficult to do and probably wouldn't be too accurate without a sample size large enough to cause major lag on the server.

I had an idea to take a vertical slice of the saucer. Say, an area from left to right, about 10 blocks back from the front of the saucer, from the top to bottom of the saucer only, and about 3-5 blocks deep. Calculate the remaining % of iron blocks in that section. If the % is between 60 and 90% say Minor Hull Damage. If it's 59% or less, say Major Hull Damage. This should only be about like... a few hundred blocks to check on each ship. For the ship v. ship event, you'd need to be scanning both. For the Ship v. Cube event, you'd only need the player ship.

commandblockguy wrote:
3.1: Remember, the Overworld void is blue until you are in it. You could use end portals or gateways, but those are very laggy.

I just punched out the bedrock at the bottom of the world in that one area and it looks nice and black and dangerous. Smile

commandblockguy wrote:
3.3: I have built something similar and can explain how to set it up. Also, we could do two passes, one that loses, say, torches, and places the anchor block, then another that places the torches correctly.

That'd would work. Another solution occurred to me. The other day, when comicIDIOT repasted one of the large ships after it took 8 hits of damage, we experienced virtually no lag. Apparently, the paste happened in masked mode. I wonder that if we set up a ship V. ship event in one place, and then behind it, set up a ship V. cube event, and regenerations happen in masked mode, we might actually not have to worry about lag too much. Command blocks might still rebel against the copy on the principle of being so large though.

In other news, I have the Borg cube's AI functional and after testing, shut the Cube down (supplied a redstone source to the left side of the t-flop (gotta be careful about the TNT near there though). To test the AI, and the ability of the new ships to hold up in combat, I had tifreak paste the beta of the new ship in front of the Cube, and I activated the AI. Bear in mind that the beta ship has less armoring around the cannons than the new ships do. At the end, I detonated the Core of the new ship. If the ship had been the size of the old ships, it would have been completely swallowed, but relative to the size of the new ships, a small section was damaged. To rectify this, I ran a conduit of TNT forward slightly, connecting to a 3x3 of TNT that runs up the back of the saucer. This will cause a bit more damage. I posted a video of the Cube and Beta Ship test.
https://www.youtube.com/watch?v=117TEhDdEUA
As the video begins, the ship has already sustained several minutes of bombardment, and the starting shot knocks the central cannon offline. While exposed, the redstone to the side cannons is still intact. Tifreak then regens the ship again so we can get a full battle on the replay (0:17).
5:40: Forward cannon destroyed, port and starboard still online.
10:09: Port cannon destroyed, starboard still online (it takes 3 direct hits to sufficiently damage it).
12:28: Significant hull damage, but starboard cannon is still fireable. Amazingly enough, at this point weapons can still be fired from the bridge as that circuit is still intact.


Needed Distances between Structures

Ship v. Ship:
Current Distance: 84
Needed Distance: 76.
Move each ship 4 units closer.

Ship V. Cube:
Needed Distance: 105.
Announcement

As the major constructive work in the Star Trek world is done, I have set up a scavenger hunt within the Star Trek world. This pre-event is intended to allow you to follow a series of clues that take you on a guided tour of the ships and learn how to use them. You will even have a chance to test fire the ships, as they are protected from damage for the time being by towny. This event will start, hopefully after comic places the portals leading onto the two colored ships.

This pre-event will run for five (5) days, starting from tomorrow and ending Friday, and I hope to have the first full scale match in the new ships next weekend. The loot chest will be refilled and moved once daily, and the clues will be reordered, and changed from time to time. Hope you guys enjoy the pre-event.

Also, when doing this, note that I have supplied the necessary item keys needed to get all the way to the warp core. DO NOT BREACH IT. The intent is to let you explore, not damage.

RULES:
1. Do the clues in order.
2. No elytra and flying right to the end.
3. Once you find and take the loot once, please don't take it again.
Update

- Lord_Charlemagne was the first to solve the scavenger hunt, which is, for the time being, incomplete.
- I added two routes to the hunt.
- I built an observation spire (for players who wish to watch the match, but not play). Now we just need two-way portals to it. Should we also copy the spire to the PvAI lane?
- Can we copy small sections of the ships, like part of the bridge or part of a nacelle and so on, and paste them to the sea floor, as though they are broken ship fragments that have sunk. I could then use them as loot locations.

- Can we get /t set perm build on within the ST town (players need the ability to repair their hull). At this point, only destroy should be off.
Update
I did a bit of research. If we forgo allowing the Borg Cube to regenerate, we can use this to do regeneration of damage, post battle:

Towny Documentation wrote:

Wilderness Regeneration

A simple wild_revert_on_mob_explosion option. Will regenerate explosions on a timer. As of Towny 0.79.1.0 You can now add any entities here you want explosions to revent for in the wilderness (includes Creeper,EnderCrystal,EnderDragon,Fireball,SmallFireball,TNTPrimed). These settings are copied to the individual world files, so you must make changes per world. * Disabling this feature is done in the in the towny\data\worlds\worldname.txt @ usingPlotManagementWildRegen=true * or by using '/tw toggle revertexpl' while standing in the world you want to toggle it in. * Disabling this feature for new worlds is done in the config at new_world_settings.plot_management.wild_revert_on_mob_explosion.enabled You can configure how quickly the blocks will regenerate, specifically how much time in between each block being reverted. * The timer is changed in the towny\data\worlds\worldname.txt @ usingPlotManagementWildRegenDelay=5 * The default for new worlds is set in the config.yml at new_world_settings.plot_management.wild_revert_on_mob_explosion.delay

We might be able to set this setting to a large amount of time, like a half hour or an hour. As the documentation states, these settings have to be updated per-world, which would perfectly keep this from propogating to other worlds. If we can get this working, towny would regenerate the explosion damage after some time, eliminating the need for command blocks. We would need to enable reverting for TNTPrimed, and set the time to say.. an hour. I'm not sure if this would lag extensively, but as towny seems to revert the damage slowly, I can't see why it would.
Edit: This seems to only affect the wilderness.

Also, can we please get the permissions and explosion and PvP flags set in that world ASAP. I can't have any events until that is done, and some people seem to be getting antsy to play.

Also, Alex, when you have some time to, could we experiment with outposts? Towny's documentation (same source as above) seems to suggest we could create an outpost. Typing /towny prices on the server lists the outpost cost as 1000d, suggesting that it is doable. An outpost counts as part of your town, so the only limitations on the size of the outpost would be the town's balance and its plot availability. Doing this would stop me from having to poke you every time I need to make a change in that world's build/break/pvp/explosion settings.

If we can get all of this done, the only command blocks we'd need is to start the Cube's AI from a distance... a total of 1 or 2.
Acag said that it would be too much of a hassle to change every plot to arena manually. He suggested an update to the plugin, but that would either make the plugin overpowered or introduce a special case for one town.
I have an alternative solution using command blocks that should be faster to set up than updating a plugin.
Inside a repeating command block:

Code:
sudo comicIDIOT (the command to set the plot you are in to arena)

Power this only while you are in the Star Trek world.
Go into spectator mode, and fly into every chunk you want to change to arena. F3+G shows chunk walls to make it easier to get each one.
When every chunk has been changed, remove the command block.
commandblockguy wrote:

Inside a repeating command block:

Code:
sudo comicIDIOT (the command to set the plot you are in to arena)

When every chunk has been changed, remove the command block.

The complete command would read as follows:

Code:
sudo comicIDIOT plot set arena
commandblockguy wrote:
Acag said that it would be too much of a hassle to change every plot to arena manually.


Well, I originally said that in a PM. Acag was just relaying the info Razz

Quote:

Code:
sudo comicIDIOT plot set arena


I am not in favor of this. Sort of similar to this reason. It's something I can set up for myself when I'm on next but I won't be be letting another user sudo as me, or any other admin/mod/OP.
Yea, we meant to have you do it as yourself. :p And remove it when done. Also, im on now, if you have a few seconds to finalize backups of the ships before tomorrow Smile

Also, someone placed a random dirt block on the Blue ship, right outside the front of the bridge, trying to jump up. Only you can break it now :p. That needs removing prior to backup.
The sudo command:
    Only runs when that player is online
    Requires the player listed to have permissions to run whatever command is listed
    Only runs the command listed in the command block (plot set arena)
    Can only be run by OPs and command blocks

It basically would just let you run a command as if you typed it, on a clock. As long as you pick the correct command and prevent other users from controlling the command block, you have total control over what commands are run. There is no possibility that any other command will be run.
The name sudo is a misnomer, it forces a certain player to run a certain command, based on permission nodes. It does not allow non-OPs to send whatever commands they want and have them run with admin access.
Ok, based on the first match event in the new ships, I have some comments and some things we should do.

Firstly, these new ships hold up incredibly well in combat. I had a bit of an advantage in terms of loot, due to having placed it myself (which I propose a solution to mitigate down below), but I was outnumbered 2-to-1. I had a payload of 32 TNT to fire. After I exhausted my entire supply of ammunition, the two crew quarters decks were smashed, the item keys were destroyed (but there is a way to get around that if you figure it out), but apart from that, my enemy still had some combat ability. This is exactly what I intended.

However, there were a few hitches:

1) You can no longer Ender Pearl to the other ship. It's just too far away. Can't pearl up from the water either. I'd rather not tell players that they can go back to the spawn platform and then walk into the other ship, bc that puts them on the enemy ship right by the warp core. So I propose portals be placed in the SIDE walls of the transporter room of each ship, that transport players to the top, front of the saucer of the enemy ship. This way, they still have to fight their way in. So we'd have walking to the back of the transporter to go back to the spawn platform, and walking to the sides to go to the enemy ship's forward hull.

2. Whoever places the loot has an unfair advantage in the event. We could ask someone not playing to do it. Or an admin/mod. Alternatively, commandblockguy has offered to create a command block script that, when activated, fills the loot chests with stuff based on a loot table. This loot table would consist of:
- Lots of TNT. Stacks of it. These cannons require it!
- Sword or bow.
- Arrows. Rare chance of tipped arrows.
- Armor. Usually iron, but less frequently diamond. Rare chance of enchanted armor.
- Iron blocks, usually in groups of 8 (for hull repair)
- Rare chance of assorted combat potions.
- Rare chance of totems of undying.
- Foodstuffs

What do admins/mods think of the two suggestions?
Update

So I'm currently undertaking another redesign of the ships... trying to reduce the size, compact the circuitry, focus more on PVP than puzzle solving for Warp Core entrance, and a few other things. One of the questions I have is: In the new designs, we have five torpedo modules as opposed to three in the prior design. I CAN actually fit up to 7 torpedo modules (and still occupy less space than the prior design does). How many people WANT 7 torpedo modules?

Some other things I'm adding is the ability to fire all cannons, or individual ones, from the bridge. Unlike in the prior design where you needed to alter what you're firing from below. I also plan to add a simple AI you can activate from within the firing area, so you can focus on other things. This AI will be positioned in a somewhat vulnerable area... so don't rely on it to carry you through the fight.

Lastly, does anyone have any suggestions for other features to add?
So, Acag requested that I write a command block contraption for mechanics for Star Trek vs Star Wars. Here's an annotated version of what I came up with.
Initialization (Run this once before placing any other command blocks):

Code:
scoreboard objectives add objOwner dummy
scoreboard objectives add capTime dummy
scoreboard objectives add toCap dummy
scoreboard objectives add held dummy
scoreboard objectives add int dummy
scoreboard players set -20 int -20
scoreboard players set 60 int 60

i am using the scoreboard like a map data structure here. I also define the constants -20 and 60 because for some odd reason I can only do math besides addition and subtraction with map elements.
At each round, for each capture point:

Code:
scoreboard players set (point name) objOwner (team NUMBER)

This resets ownership of capture points.
At each round:

Code:
scoreboard player set held Team1 2
scoreboard player set held Team2 2

This is a counter for how many points each team has. You can test against this to see if a team has won.
Finally, this bit will repeat while the game is running. Each line gets its own command block, and each command block is pointing into the next. The first command should be in a repeating command block, and the rest in chain command blocks. A ? means that that command block should be conditional, and do not include the ? in the actual command block. Do not put comments into command blocks. This controls one capture point. To add additional ones, add another group of command blocks with Obj1 replaced with Obj2, Obj3, etc.

Code:
scoreboard players remove Obj1 capTime 1
#By default, the capture amount decreases
scoreboard players test Obj1 objOwner 1 1
#Check if this is owned by Team 1
?execute @a[team=team1,x=-1277,y=5,z=-102,r=5] ~ ~ ~ scoreboard players remove Obj1 capTime 1
#If so, have all players on Team 1 decrease the capture amount
scoreboard players test Obj1 objOwner 1 1
?execute @a[team=team2,x=-1277,y=5,z=-102,r=5] ~ ~ ~ scoreboard players add Obj1 capTime 1
#Also have all players on Team 2 increase the capture amount
?execute @a[team=team2,x=-1277,y=5,z=-102,r=5,c=1] ~ ~ ~ scoreboard players add Obj1 capTime 1
#If there are any Team 2 players on the capture point, stop the capture amount from decreasing
scoreboard players test Obj1 objOwner 1 1
?scoreboard players test Obj1 capTime 1200
#If capture amount exceeds 1 minute (1200 ticks)
?scoreboard players set Obj1 objOwner 2
#Switch ownership of point
?scoreboard players set Obj1 capTime 0
#Reset capture amount to 0
?scoreboard players remove Team1 held 1
#Decrease the number of points Team1 holds by 1
?scoreboard players add Team2 held 1
#Increase the number of points Team2 holds by 1
#This is the reverse of Team1
scoreboard players test Obj1 objOwner 2 2
?execute @a[team=team2,x=-1277,y=5,z=-102,r=5] ~ ~ ~ scoreboard players remove Obj1 capTime 1
scoreboard players test Obj1 objOwner 2 2
?execute @a[team=team1,x=-1277,y=5,z=-102,r=5] ~ ~ ~ scoreboard players add Obj1 capTime 1
?execute @a[team=team1,x=-1277,y=5,z=-102,r=5,c=1] ~ ~ ~ scoreboard players add Obj1 capTime 1
scoreboard players test Obj1 objOwner 2 2
?scoreboard players test Obj1 capTime 1200
?scoreboard players set Obj1 objOwner 1
?scoreboard players set Obj1 capTime 0
?scoreboard players remove Team2 held 1
?scoreboard players add Team1 held 1
#End repeated section
scoreboard players test Obj1 capTime -10000 0
#We don't want capture time to go over 60
?scoreboard players set Obj1 capTime 0
scoreboard players operation Obj1 toCap = Obj1 capTime
scoreboard players operation Obj1 toCap /= -20 int
#Convert to seconds
scoreboard players operation Obj1 toCap += 60 int
#Subtract from 60
scoreboard players test Obj1 capTime -10000 0
#If capture amount is 0, remove the counter from the display
?scoreboard players reset Obj1 toCap
I'm slightly against this. TPS is still an issue and until we can figure out our existing TPS bottlenecks I feel like adding more events to be ran/checked every tick would be counterintuitive.
It's only checking against players and doing basic math and memory operations, so it shouldn't cause that much lag. The AI of a few passive mobs would probably have more impact on the server than these commands, and if lag is actually an issue you could modify it to run every second or some other arbitrary value.
Alex wrote:
I'm slightly against this. TPS is still an issue and until we can figure out our existing TPS bottlenecks I feel like adding more events to be ran/checked every tick would be counterintuitive.

commandblockguy wrote:
It's only checking against players and doing basic math and memory operations, so it shouldn't cause that much lag. The AI of a few passive mobs would probably have more impact on the server than these commands, and if lag is actually an issue you could modify it to run every second or some other arbitrary value.

command actually informed me in discord the other day that that series of commands would cause less lag than a hopper chain of equal length.
That claim currently remains untested due to computer issues. It's probably correct, but I can't be sure until I get some replacement parts later this week.

Also, it's important to clarify that I said backed up hopper chains, which cause significant more lag per tick than empty and flowing hoppers.

The biggest lag causer server side is mobs that have AI. Killing or lobotomizing animals in spawn chunks or creating a mob switch would probably be the easier way to reduce tick time.
I recommend watching ilmango's recent SciCraft episode, Witch Farm Lag Busting, which shows the relative impact that mobs have on tick rate by using gnembon's carpetmod (which is not Bukkit compatible).
Well, friends, I'm happy to announce that a brand new ship for this event is nearing completion! This ship has a number of cool features that will be explained in this post. Firstly here is a picture of the new ship:


This ship is obviously designed closer in appearance to the Enterprise C or D, and is named the CMS Enderprise-D, CMS meaning Cemetech Minecraft Ship.

The first significant change to the new ships is the warp core lock. No longer do you have to steal warp core keys or enter a glitched combination. You now simply have to toggle 4 switches to open the doors. The first two, however, work a bit differently. It takes about 30 seconds from the time you toggle the lever to the time you actually activate that switch. You need to defend that switch for that time, or risk losing it. If a defender untoggles any of the switches before you make it through the door to the Core, the door will close.

A second, and related, change in the new ships is the addition of Sentry Hallways leading to Switches 1 and 2. These are automated defenses. The hallways launch potions from the side walls and arrows/fire charges from in front of you. They also sound an alarm when someone enters them, alerting the defending team that someone is attempting to access the Core. It is against match rules to remove items from the dispensers in these hallways. The Hallway may be indefinitely disarmed to allow defenders to stock the dispensers, or it may be temporarily disarmed via a button to allow a defender a time limit to run through without getting hit.

A third change is the addition of compartmentalized ship access for different teams. The portal to board the ship for the defending team will bring you to the bridge of this ship, not the transporter room. The ladder descending from the bridge allows the defending team to enter the ship on Decks 1 - 3, even behind the Sentry Hallway defenses. This allows a defending player to get in front of an attacking player almost everywhere. The only place to re-enter the area is behind the Sentry Hallways... toss your ship's keycard into the hopper and the door should open. Enter the area, then press the button over the dropper to return your keycard. The door will seal behind you.

A fourth and final change is the addition of a shield system. This shield uses a command to delete all TNT within a radius roughly equal to that of the saucer, which runs on a timer. This timer is controlled by a hopper clock that initially has 10 items, providing a roughly 4 second delay. This means that every 4 seconds, incoming TNT will be deleted. To protect your own cannons, when you shoot, your shields are paused for roughly 10 seconds to allow the firing sequence to complete safely. During this time, you are vulnerable to enemy attack. Also, every time the command successfully deletes TNT, another item is added to the hopper clock, slowing the clock down by about 0.4 seconds. (So after deflecting one volley the shields iterate every 4.4 seconds, after the second volley it becomes 4.8 seconds, after the third it becomes 5.2 seconds, and so on). This serves to emulate shields degrading as they take damage.
  
Page 5 of 5
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement