1mpre55 / Infection

0 stars 0 forks source link

Various Infection Info #3

Open ebear1 opened 11 years ago

ebear1 commented 11 years ago

Please scroll lower to see the main portion of this page.

Pastie:

http://pastie.org/7111467

This is the first error produced from testing.

ebear1 commented 11 years ago

I can't even get the plugin started on my server...

ebear1 commented 11 years ago

BTW: I'm using Spigot for my server, should I not be?

1mpre55 commented 11 years ago

OK, it seems like you're using Java 6 and I compiled against Java 7. I suggest you update Java. If you can't update, here is a Java 6 version of the plugin, but I still recommend that you update Java because Java 7 introduces a lot of new features and fixes security issues.

ebear1 commented 11 years ago

I have Java 7 and I re-downloaded it just to be sure. I'm going to see if I have the error again. Could it be because I'm using Spigot? I'm not sure. I'll let you know if I continue to have the error. Thanks for the reply!

1mpre55 commented 11 years ago

Did you try using this version of the plugin?

It shouldn't be because of Spigot, it seems like Spigot claims to support Bukkit API and that's the only thing Infection requires. However, if above doesn't work, try downloading CraftBukkit (1.4.7-R1.0 or latest 1.5.1-R0.1) and test it with that.

The java.lang.UnsupportedClassVersionError is thrown when JRE (the environment that Spigot/Bukkit is running in) tries to load a class (compiled code) that was compiled with an incompatible version of JDK. For example, in Java 7 there is a new feature that allows handling multiple exceptions in a single catch statement. I used this multiple times and it worked fine when I ran it with Java 7, but if I tried running it with Java 6, it would result in the same error that you got because Java 6 does not support that feature. Now I switched to using Java 6 compiler and I had to modify some of the code removing that feature so that it compiles with Java 6. I hope that makes sense, it's OK if it didn't.

You're using a Mac, right? Apple has it's own version of Java, which could cause this issue, but if you are sure that you have the latest version of Apple's Java and it's compatible with Java 7, it shouldn't be a problem. However it'd helpful if you run java -version in the terminal and send me the output.

ebear1 commented 11 years ago

Okay. I have run that command as you have asked, and the output of the console is here:

http://pastie.org/7164187

I don't know exactly what that is telling me, but if you do, that's all that matters for now... :D

1mpre55 commented 11 years ago

_Java(TM) SE Runtime Environment (build 1.6.0_43-b01-447-11M4203)_

You're running Java 6 build 43, which is the latest public version of Java 6 that oracle released. Unfortunately, it seems like you cannot get Java 7 if you're running Mac OS Snow Leopard (10.6) or below. The good news is that we now know what the problem is. If you're not running Lion (or above) you don't have to update because I've switched to using Java 6 compiler, so tell me if this works or not. All future jars that I release will also be compiled using Java 6.

ebear1 commented 11 years ago

Sure. I'm just wondering if since I'm running Mountain Lion (v10.8.2) if I can update to Java 7. It's ok if I can't, I'm just happy we can get this done. Thanks.

1mpre55 commented 11 years ago

Yes, download Java 7 build 17 here.

ebear1 commented 11 years ago

oh. I'm going to stick with Java 6 build 43.

1mpre55 commented 11 years ago

ok

ebear1 commented 11 years ago

I'm also wondering what the commands for the Infection plugin are. There's no /infection help...

ebear1 commented 11 years ago

That's my last question, then I'll begin in-game testing.

1mpre55 commented 11 years ago

yeah, use /inf admin game and it'll display a help message. I will add more commands and help messages later

ebear1 commented 11 years ago

Thanks!

ebear1 commented 11 years ago

Is there an ingame command to create games?

ebear1 commented 11 years ago

Also, are there other /inf s?

1mpre55 commented 11 years ago

There is no way to create new games in-game... yet. I don't think that's as useful as being able to actually play, so I'm not planning to add that atm. Yes, here is a complete list of commands (/inf == /infection btw):

ebear1 commented 11 years ago

ok. My next question is me asking you HOW you create arenas. Without me being able to do such, I will not be able to test it much farther than just trying out the various commands, the error I found is in an issue.

1mpre55 commented 11 years ago

Currently, you have to edit arenas.yml file. I will add a way to create an arena from WorldEdit selection and add spawns with commands, but for now, I'm sorry, you have to enter the coordinates manually.

ebear1 commented 11 years ago

Do you know when you will have the commands and that stuff implemented? I'm looking forward to being able to create Arenas with a WE selection. It would make it MUCH easier. Is there a /infection reload? Other than that, I'm preparing to set it up now. My friend is just creating the spawn now...

1mpre55 commented 11 years ago

Well, I'm going to get started on WE selection thing next, after I implement a few game rules, because without that all the convenience of WE selection thing is useless.

ebear1 commented 11 years ago

Cool. Do you know when the commands including the In-game arena creation will be finished? I'm looking forward to that!

Also, how would I format the /inf changeteam with permissions. The thing is, there can only be one zombie in Infection, but the way it says in the rules.yml files is that players can change teams, eventually making it 9:9 or something instead of 17:1. The zombie selection should take place when the game starts. In one of the config files, there should be a setting so the game can have a countdown time after a minimum number of players join the game. These thing should all be able to be set. One more thing, I think that the players would have to stand where they spawn pre-game, that way everyone has a fair chance of moving around no matter what time they join. The last request I have is if we can make a way to implement signs into the joining of a game, in the format that I have attached... That'd work well. Screen Shot 2013-03-29 at 4 53 48 PM

On a totally unrelated note, I'm having some problems with DisguiseCraft. It won't launch with my server. Should I contact the authors of that plugin for information on why that is?

1mpre55 commented 11 years ago

I'm not sure when the commands will be finished, hopefully soon. About the teams, good question. Right now I'm making the platform that will allow a lot of various game rules. For example, with this design you could have multiple survivor teams that will compete with each other on who can stay alive the longest. You can even throw some regular teams in there. Regular/default teams contain the general team mechanics that apply to all kinds of teams, like kill/death/score counters and respawning rules. There are also spectator teams where players will automatically be hidden from other teams when they join that team. Each type of team can have it's own additional options. Zombie teams currently have a disguise option that you can see here (it will disguise players as zombies using DisguiseCraft). So what I'm going to do is add options to zombie and survivor types of teams that will prevent players from switching to that team. Do you have any suggestions for what that option should be named? Alternatively you could just deny infection.changeteam.game-name permission node to the players so that they can't change their team in that game.

ebear1 commented 11 years ago

Thanks. I was wondering what you had planned for that. I like the idea of people with different teams, but the thing would be the spawns and team v. team fire. You'd have to protect survivors from firing upon other survivor teams. We'd also have to find a way to set the various teams' spawns. They should be able to either be the same spawn, or have their own spawns. You would have to configure that when setting up the arena. The person setting up the plugin would have to know which order the spawns will be set in. An example of this would be:

/inf setspawn

Executing the command once would make it the universal spawn, and all teams would spawn there. Executing the command 4 times would make a spawn for the teams in the following order: Blue, Red, Green, Purple. If the game is played with only one team, the players would all spawn at the spot the Blue team spawns at. The order would be crucial.

Another cool feature would be for zombies, they WON'T see the team colored name tag, so instead they would see the "Potential Danger" of the survivor. The survivor's name tag would change color depending on how many kills they've clocked. For example: A survivor with 10 kills would have a Dark Red name tag, while a survivor with 2 would have a Dark Green. The colors would cycle from Dark Green to light green to yellow to bright orange to orange to bright red to dark red, dark red being the most kills. People should be able to set the color of the name tag depending on how many kills. Again, zombies will NOT see the team of the survivors, which takes away the possibility of Biased Gameplay. The survivors, however should see the one "Alpha Zombie" (Originally chosen zombie) in a changeable color. An example of the Potential Danger config:

#Leave blank for the color not to be included. Note you can NOT add more colors.
#Use a <number>+ to represent all numbers higher than that.
Dark Green:1
Light Green: 2
Yellow: 3
Bright Orange: 4
Orange: 5
Bright Red: 6
Dark Red: 7+

Obviously, I'm no expert with these kinds of files, but that's what I made. Again, all the survivors would see is the color of the other teams on name tags. Survivors should also have a piece of wool pertaining to the color. The last thing would be to pick the colors. My visioning is: Blue, Red, Green, Purple. There'd only be those four teams configurable, and you could just write "False" if you do not want the team to be implemented.

Another thing, you should be able to go into a file to adjust what kind of game you want it to be, whether it be TEAM_BATTLE, or ONE_TEAM mode (I made those names up :smile: ). In a different file, you should be able to specify the rules for the different game-modes. There should also be an option for it to alternate which game-mode the arena uses.

Also, do you like my idea for the signs, and if so, will you be able to implement that? Again with the zombie teams, the game only selects One zombie at the start of the game, and that is called an "Alpha Zombie". That's not a global term, but I feel that it fits the idea. The survivors that get infected are also zombies, but they're not the "Alpha Zombie". The question is to find out how to implement priorities into the choice of the zombie.

1mpre55 commented 11 years ago

Zombies will be chosen like this: when the game starts, all zombies will be moved to the survivor team they were in before being infected (in the last game) or if last survivor team cannot be found, they'll be moved to a random survivor team in that game. After that, each zombie team will choose a number of players from all survivor teams based on it's options (starting number of zombies, try to balance survivor teams, how many priorities to consider, etc). This way it won't matter how many or what teams are in that game. I was going to add an optional lobby to arena's config, but your idea sounds great. Signs idea sounds great too, especially since it'll be pretty easy to do that in code.

Team vs team pvp: another option that I'll have to add to team's options. Something like:

team1: type: survivor prevent-damage-to: - team2 team2: type: survivor will prevent team1 from inflicting damage to players in team2, but not vice versa. Similar with teams seeing other teams.

Game rules are configured in rules.yml and then those sets of rules are applied to either the game or individual teams. Arena can't be locked to a single game mode, but games can switch it's rules based on the arena by using it's events system.

I've already done the team spawns, although I don't like the way it works right now. I would like your advice on this. As you can see in arenas.yml under spawns (currently there is only one type of spawns but I plan to add area-based spawns in the future) all spawns are grouped and groups are named. Each team will choose a groups of spawns when the game chooses it's next arena. However I can't decide on HOW the teams will distribute the spawns between themselves. Team colors are already implemented, but I'd like them to be optional, so that's probably not a good idea to use that here. Numbers would seem to work better, but games do not number it's teams. And it's not a good idea to do that since teams like spectators might choose to create and use it's own spawn groups instead of taking one of arena's. So what I was going to use was add a team option with a list of spawn groups that that team will attempt to get, or failing that will choose one randomly. And while that's the best system that I came up with so far, it seems to be both confusing and complicated to use.

1mpre55 commented 11 years ago

Btw, the way that colors are currently implemented is through team options in games.yml. As you can see a team can ignore that option and then the color of the nametags will not be modified.

ebear1 commented 11 years ago

It does sound complicated. I was thinking of saying something like writing the spawn # per team. The thing is once you set the spawns, you should be able to assign the spawn based on the order the spawn was set. For example, I should be able to assign the regular spawn as the first one I set, the Blue team spawn as the 2nd one I set, and so on. That would create an easy way to regulate the spawning.

ebear1 commented 11 years ago

Spectators should ONLY be able to spectate, rather than be able to modify the map. I think that should be /inf spectate . It should not count as a team. Other than that, do you like the name tag coloring options I wrote? I think that would be a cool feature that you can easily enable/disable.

ebear1 commented 11 years ago

There really shouldn't be a /inf changeteam command, for the command would just act like a toggle (zombie, no zombie). That's what I'm looking for, but in a sense that you can nominate yourself to become zombie. Also, is there a way that we can use the priority system for the zombie choice? If anything, it should be /inf zombie. :smile:

ebear1 commented 11 years ago

I really think that once you make the in-game setup commands, I could use /inf setspawn to set the spawn. It would be organized similar to the SG plugin:

spawns: '1': '1': x: 40 y: 66 z: 24 count: 24 '2': x: 39 y: 66 z: 30 '3': x: 37 y: 66 z: 36 '4': x: 33 y: 66 z: 42 '5': x: 27 y: 66 z: 46 '6': x: 21 y: 66 z: 48 '7': x: 15 y: 66 z: 49 '8': x: 9 y: 66 z: 48 '9': x: 3 y: 66 z: 46 '10': x: -3 y: 66 z: 42 '11': x: -7 y: 66 z: 36 '12': x: -9 y: 66 z: 30 '13': x: -10 y: 66 z: 24 '14': x: -9 y: 66 z: 18 '15': x: -7 y: 66 z: 12 '16': x: -3 y: 66 z: 6 '17': x: 3 y: 66 z: 2 '18': x: 9 y: 66 z: 0 '19': x: 15 y: 66 z: -1 '20': x: 21 y: 66 z: 0 '21': x: 27 y: 66 z: 2 '22': x: 33 y: 66 z: 6 '23': x: 37 y: 66 z: 12 '24': x: 39 y: 66 z: 18

That would create easy organization, given the zombie spawns are random, they don't really need to be mentioned.

The arenas, however could be organized the way you have it currently listed. The only hard part is the spawns.

1mpre55 commented 11 years ago

I see no advantage in using team colors instead of team names to determine spawn groups. But both of these systems will make it impossible to have teams in different games with same color/name to spawn in different spawns in the arena. Or to make different teams spawn in the same spawns group. Oh and btw, area spawns will act the same as spawn groups do now. I'm also planning to make spawn groups that will consist of other spawn groups and you'll be able to set different chances to each one of the internal groups. It probably sounds confusing now, but you'll see it better once I'm done with it. Your team color options would work well for the games you currently have planned, but you or other admins may wish to do more in the future. I think that it works better the way it's set right now. You can have teams with no color and you can have multiple teams with the same color and even set your own RGB colors (because dyed armor supports it). Spectators will not be allowed to modify the map, and it'll be customizable for other teams. However, the advantage of spectators being in a team is that it'll be easier to manage all spectators and more importantly, some of the code will be reused leading to fewer bugs in the future. All spectator teams will be hidden by default, so they won't show up in the teams list. And yes, I'll add /inf spectate [game] command. So even though spectators will be in an actual team, it won't be obvious to the players.

ebear1 commented 11 years ago

I'm saying that you should have per-arena controls. It's no root system. Also, people should be able to set the team names in the arena config for per-arena play. The RGB color thing you mentioned works well. Also, you should add an option for prefixes in the names of players depending on which team they are on and which arena they are in. It would allow for recognition of the different players depending on their arenas and teams. You could also modify if in the chat it shows the Arena name, the team name, or both. I'm just wondering if there's a way to make it so survivors see the team color name tags, and zombies see a player danger indicator.

Btw: Did you like the idea I had about the player damage indicator? If so is it possible for the zombies to see ONLY that on survivors and survivors not to see a potential danger of their comrades, but for them to ONLY see the team color on the name tags. I'm talking about 2 totally different views of the names, but for different teams.

ebear1 commented 11 years ago

Can you add to the zombie kit: A potion effect of Jump Boost V and a way to make it so they don't take fall damage. I want the zombies to be able to jump REALLY high and for them to take no fall damage from the fall. Thanks! :kimono:

1mpre55 commented 11 years ago

OK, I think I know what to do with arenas and spawns. I'll make it asap and give it to you to try.

Prefixes: great idea.

Not completely sure what you mean by player danger indicator. It IS possible for a player to display a different nametag to different teams (including different nametag colors). If that is what you mean, then it's definitely a good idea, but I'm not sure where the configuration for that should go. Hopefully you'll be able to help me with that later on.

I'll add the zombie kit, but first I'll need to add more features to the kit system. Currently kits can only contain items. If you want I can add potion effects (options: type, amplifier and time) and experience. There isn't anything in Minecraft that cancels fall damage, so if adding boots with featherfall:10000 to the zombie kit won't work for you, I may add a perks system later. However I'm much more interested in making core features (like linking teams to different spawns in different arenas) than these additional features.

ebear1 commented 11 years ago

The thing I don't like is how I can't give Feather Falling as a potion effect. I'm wondering if there's a way for me to still do the booties enchant thing, but if the boots are not invisible to the other players, it'd look pretty weird. If you can't do that, I might want to recommend you to make a setting in the config, where players can enable/disable fall damage for the zombie team (as a game mechanic). Thanks for the input, though!

1mpre55 commented 11 years ago

There is already a way to add enchantments to items in kits, see current zombie kit in default kits.yml. Boots are not invisible, but I'll add a "dye" option later, which may help. However, featherfall does not cancel all fall damage, even when it's a really high level. So I'll probably add it as a team option at first and then move it to some kind of a perks system.

ebear1 commented 11 years ago

What I'm asking is for a completely different mechanic that works with the code to enable/disable fall damage for the zombie team. Is this even possible?

1mpre55 commented 11 years ago

Yes. I'll do it... eventually.

ebear1 commented 11 years ago

ok. Thanks

Also, do you know when the whole thing as we've been talking about here will be finished?

ebear1 commented 11 years ago

Ok. I just tried to setup an Arena. For me to do this, do I specify the Arena coordinates and spawns in arenas.yml, then specify the game in games.yml? If that's what I have to do, I'm not doing the right thing. Could you please help me with this?

ebear1 commented 11 years ago

Ok. I found out I had to do /inf admin game enable . I did that, and the server said the game was enabled. When I tried to join, it says "can't join right now". Why is this happening?

ebear1 commented 11 years ago

K. Here's a bug I found. Also, Infection does not TP me to the spawn...

http://pastie.org/7491644

1mpre55 commented 11 years ago

Updated (jar) Here is how everything works right now: When the plugin is being enabled, it loads config files in following order: kits.yml, messages.yml, arenas.yml, rules.yml, games.yml. Kits, messages and arenas are simply loaded from their own sections in the YAML file. Rules on the other hand support inheritance, so if A's parent is B, A forces B to be loaded first and then uses B for default values. I plan to add this inheritance system to messages.yml as well. If there is a loop in inheritance (e.g. A inherits from B which inherits from A) it'll result in an error which will be shown in the console, other rules will be loaded normally. Inheritance will help when creating multiple games with similar rules - instead of copy-pasting all rules you can simply make all those rules inherit from one of them and other rules will simply override the few things that need to be different. There is no limit to how many rules can share a parent or how many parents are between the child and root rules (rules with no parent). Games are what ties everything together. Games contain 2 more kinds of objects: events and teams. All events must specify an arena and time limit (in seconds, -1 = unlimited). Global teams are added to the game when the game is loaded, while teams defined in the event will be added when that event starts and removed when that event ends. Events can also override existing teams' options for the duration of that event. Here is an example of a game:

testgame:
  teams:
    aGlobalTeam:
      type: zombie
      name: Zombies
      color: red
      spawns: zombiespawns
    Survivors:
      type: survivors
      color: blue
      prevent-damage-to: [Zombies]
      spawns: survivorspawns
  events:
    normalevent:
      arena: inf-arena1
      time: 300
      rules: inf-rules1
    specialevent:
      arena: inf-arena2
      time: 300
      rules: inf-rules2
      teams:
        aGlobalTeam:
          color: green
        Survivors:
          prevent-damage-to: [Survivors2]
          spawns: survivorspawns1
        Survivors2:
          type: survivors
          color: red
          prevent-damage-to: [Survivors]
          spawns: survivorspawns2
    anothernormalevent:
      arena: inf-arena3
      time: 180
      rules: inf-rules1
  event-order: SEQUENTIAL
  loop: true

Here is what happens: the first event has 2 teams: red zombies and blue survivors that can't deal damage to the zombies. Second event introduces a new red survivors team and changes zombies' color to green. It also allows both teams to fight the zombies, but not each other. 3rd event reverts all changes to the teams and because the arena is smaller, time is reduced to only 3 minutes. There are a few kings of options and rules. Game and event options can only apply to the whole game or event, for example it makes no sense for different teams or players to play on different arenas or with a different time limit. Team options apply to the entire team, sometimes overriding an event option (like rules and messages). Rules and messages however apply directly to players. While currently there is no way for players on the same team to get different rules (e.g. based on permissions), that is possible in code and I plan to add it in the future. The current system is pretty flexible, but it may be confusing at first. I'd like to add an additional simpler system at some point in the future, you're welcome to design it if you wish.

Should names (game, team, event, rules, etc) be case sensitive? Currently they are.

You should be able to join games after you use /inf admin load , but due to a bug it doesn't let you join until you also use /inf admin start . This was fixed along with the problem that was causing the stack trace you gave me.

Signs work. Using signs is equivalent to using commands. 1st line must be "[Infection]", 2nd line is the action (join, leave, changeteam), 3rd and 4th lines are the arguments you would use with the command (game and/or team). Currently there is no limitation on the creation of the signs.

This is taking longer than I expected because I want to make it flexible from the start so that I don't need to release updates that will force users to re-create the config in the future.

TODO:

ebear1 commented 11 years ago

Cool. I see you've been busy. I look forward to seeing these features. Also, with the games, does the plugin Automatically load the games, or does it have to be a manual thing? Everything else makes sense. Thanks!

ebear1 commented 11 years ago

Also, can you give me a more detailed walkthrough of how to setup an arena? It is really confusing and I can't seem to understand.

1mpre55 commented 11 years ago

Oh, sorry, forgot to cover that. Currently you have to manually input the values in arenas.yml, but I'll add commands like /inf admin arena define (from WorldEdit selection) and /inf admin arena spawns <addspawn/delspawn> (based on current position) or something like that.

ebear1 commented 11 years ago

Ok. Would you give me a run-through of how to setup and manage an arena?

Thanks!

ebear1 commented 11 years ago

Hey. It's been a while. How's it coming?

1mpre55 commented 11 years ago

Sorry, midterms and other stuff. I finished WorldEdit integration and about 3/4 done with objectives. Also TagAPI and DisguiseCraft integration should work as well. Download the new jar here. Games are loaded from games.yml when the plugin is being enabled. The load command is a temp thing I added does just adds the game to the list of the games that can be joined and started. I could remove the load/unload thing to make it easier to understand, but then there admin can't temporarily prevent players from joining a game. Do you have a public server we can use for testing? If not we can use my server. To set up your arena select your arena with WorldEdit and use: /inf admin arena infection1 setcuboid then load and start the game: /inf admin game load infection /inf admin game start infection and finally join it: /inf join infection