With the default structure:
application
- controllers
- - IndexController.php
- models
- views
- - scripts
- - - index
- - - - index.phtml
- - - - create.phtml
My IndexController.php in my controllers folder would look like:
class IndexController extends Zend_Controller_Action { ... }
If I wanted to add a folder inside like this:
application
- controllers
- - IndexController.php
- models
- views
- - scripts
- - - index
- - - - posts
- - - - - index.phtml
- - - - - create.phtml
- - - - index.phtml
- - - - create.phtml
At what path and what file name do I create the controller for my posts indexAction and createAction? Also, which controller do you extend and how do you name it?
When you create a new action (ie: postsAction()) you need to create a file that matches the name of your action in the controllers view scripts directory (in this case postsAction() exists in indexController)
So what you need is this:
application
- controllers
- - IndexController.php
- views
- - scripts
- - - index
- - - - posts.phtml
- - - - index.phtml
- - - - create.phtml
If you want a structure so that you have /posts/index or /posts/create then you likely want to have a postsController which will contain something that looks like this:
application
- controllers
- - IndexController.php
- - PostsController.php
- models
- views
- - scripts
- - - index
- - - - index.phtml
- - - - create.phtml
- - - posts
- - - - index.phtml
- - - - create.phtml
If you want /index/posts-create as an action in your indexController your will need a directory structure like this - note: When you use an action with camelCase (postsCreateAction()) zend framework converts it to all lowercase with dashes for both the URL and the view scripts.
application
- controllers
- - IndexController.php
- models
- views
- - scripts
- - - index
- - - - index.phtml
- - - - create.phtml
- - - - posts-create.phtml
You may also want to include a default ErrorController - it will be helpful in the future.
if you define your actions camelCase like:
public function showUsersFromSpaceAction()
{
}
your url will be:
index/show-users-from-space
and your view script:
/views/index/show-users-from-space.phtml
Related
Ok so I'm running Rasa 2.0.2 and whenever I try to activate my forms, rasa seems to fail loading them. I'm pretty sure that my code runs properly since it runs on rasa 2.7.0. Also note that through some threads that I read online I knew that older versions of rasa need the utters with a certain naming such as: "utter_ask_name" so I did that and also slots need to be named like this: "slot_date". So I used both of these methods but still came to no success.
Any help?
domain.yml:
version: "2.0"
intents:
- greet
- inform
- subscribe
- bot_challenge
- name
- age
- learn
- book demo
- describe
- describe more
- learn more
- learn less
- date
- time
- firstname
- lastname
- email
- country
- kai101
slots:
email1:
type: unfeaturized
influence_conversation: false
slot_date:
type: unfeaturized
influence_conversation: false
slot_time:
type: unfeaturized
influence_conversation: false
slot_firstname:
type: unfeaturized
influence_conversation: false
slot_lastname:
type: unfeaturized
influence_conversation: false
slot_email:
type: unfeaturized
influence_conversation: false
slot_country:
type: unfeaturized
influence_conversation: false
responses:
utter_greet:
- text: |
Hello & welcome to achatbotAgancy.com! Your one-stop shop to the world of chatbots.
How may I assist you?
buttons:
- title: "Learn about chatbots"
payload: '/learn'
- title: "What do you want your chatbot to do? In a few words describe the purpose of your chatbot:"
payload: '/describe'
- title: "Book a demo to test drive us"
payload: '/book demo'
utter_kuh:
- text: |
What is your email address?
utter_subscribed:
- text: |
Check your inbox at {email} in order to finish subscribing to the newsletter!
- text: You're all set! Check your inbox at {email} to confirm your subscription.
- text: You've been subscribed, the newsletter will be sent to {email} shotly.
utter_i_am_a_bot:
- text: |
I am a bot powered by RASA
utter_my_name:
- text: |
I am KAI The Chatbot
utter_my_age:
- text: |
I was made on June 2 2021 and I'm still being developed on a regular basis.
utter_learn:
- text: |
A chatbot is a software application used to conduct an on-line chat conversation via text or text-to-speech, in lieu of providing direct contact with a live human agent.
Did that answer help your question or do need more information?
buttons:
- title: "No thank you"
payload: '/learn less'
- title: "I am intrested in learning more"
payload: '/learn more'
utter_description:
- text: |
What do you want your chatbot to do? In a few words describe the purpose of your chatbot:
utter_description_reply:
- text: |
Ah yes, we can definitely help with that. May I book an appointment for you with one of my colleagues?
utter_book_demo:
- text: |
Sure. I will ask one of our humans to reach out. May I know:
utter_learn_more:
- text: |
A chatbot is a software application used to conduct an on-line chat conversation via text or text-to-speech, in lieu of providing direct contact with a live human agent.
Did that answer help your question or do need more information?
buttons:
- title: "No thank you"
payload: '/learn less'
- title: "I am intrested in learning more"
payload: '/learn more'
utter_learn_less:
- text: |
Ok great.Well, I am one message away. Don’t be shy.
utter_learn_more1:
- text: |
Sure, I am more than happy to book an appointment for you.
utter_ask_date:
- text: |
May I know the best date that works for you?
utter_ask_time:
- text: |
Great, and what time??
utter_ask_firstname:
- text: |
May I know your first name?
utter_ask_lastname:
- text: |
May I know your last name?
utter_ask_email:
- text: |
May I know your email address?
utter_ask_country:
- text: |
Which country are you in?
utter_done_requesting:
- text: |
Awesome Mr.{slot_firstname} {slot_lastname}, one of my colleagues will contact you shortly on your email {slot_email} to book an appointment on {slot_date} at {slot_time}
actions:
- '...'
- utter_greet
- utter_kuh
- utter_subscribed
- utter_i_am_a_bot
- utter_my_name
- utter_my_age
- utter_learn
- utter_description
- utter_description_reply
- utter_book_demo
- utter_learn_more
- utter_learn_less
- utter_learn_more1
- utter_ask_date
- utter_ask_time
- utter_ask_firstname
- utter_ask_lastname
- utter_ask_email
- utter_ask_country
- utter_done_requesting
forms:
informative_form:
required_slots:
slot_date:
- type: from_text
slot_time:
- type: from_text
slot_firstname:
- type: from_text
slot_lastname:
- type: from_text
slot_email:
- type: from_text
slot_country:
- type: from_text
session_config:
session_expiration_time: 60
carry_over_slots_to_new_session: true
forms.yml:
forms:
informative_form:
required_slots:
slot_date:
- type: from_text
slot_time:
- type: from_text
slot_firstname:
- type: from_text
slot_lastname:
- type: from_text
slot_email:
- type: from_text
slot_country:
- type: from_text
nlu.yml:
version: "2.0"
nlu:
- intent: greet
examples: |
- Hi
- Hey!
- Hallo
- Good day
- Good morning
- howdy
- intent: subscribe
examples: |
- I want to get the newsletter
- Can you send me the newsletter?
- Can you sign me up for the newsletter?
- Can I on your mailing list?
- intent: inform
examples: |
- My email is example#example.com
- random#example.com
- Please send it to anything#example.com
- Email is something#example.com
- intent: bot_challenge
examples: |
- Are you a bot?
- Am I talking to a human?
- is this a chatbot?
- is this a real person?
- you're a bot, aren't you
- intent: name
examples: |
- What's your name?
- What did they name you??
- what are you called?
- What should I call you ?
- intent: learn
examples: |
- Learn about chatbots
- intent: describe
examples: |
- What do you want your chatbot to do? In a few words describe the purpose of your chatbot:
- intent: describe more
examples: |
- I want my chatbot to
- I want it to do something
- I want it to be something
- I want it
- To do something
- want it to be something
- do something
- intent: book demo
examples: |
- Book a demo to test drive us
- intent: learn less
examples: |
- No, thank you.
- intent: learn
examples: |
- I am interested in learning more.
- intent: kai101
examples: |
- Ask me your questions.
- Ask me about the form.
- intent: date
examples: |
- May 31 1999
- 31/05/1999
- July 16 1978
- 16/07/1978
- January 4 1974
- 04/01/1974
- September 10 2003
- 10/09/2003
- intent: time
examples: |
- 3:00 PM
- 8:00 AM
- 16:00
- 8 in the morning
- 4 afternoon
- 12 in the morning
- 4 in the evening
- intent: firstname
examples: |
- Kareem
- Yehya
- Mariam
- Johnny
- Charbel
- Nour
- Hanin
- Hussein
- John
- intent: lastname
examples: |
- Aridi
- Abou Dargham
- Harfouch
- Abou Dagher
- Smith
- Malaeb
- intent: email
examples: |
- My email is example#example.com
- random#example.com
- Please send it to anything#example.com
- Email is something#example.com
- intent: country
examples: |
- Lebanon
- USA
- UAE
- Palestine
- Syria
- Iraq
- Kuwait
- United States
- United Arab Emirates
- Kuwait
- Bahrain
- Saudi Arabia
- germany
I have a few observations to kicktart finding the right answer:
could you please offer more context behind the problem you're facing? What command were you trying, what was the error stacktrace? It would be helpful if you could run rasa shell --debug and post the full debug log in your question.
if you specify the form in domain.yml, you don't need to have a separate forms.yml file as per the docs
if you specified influence_conversation property as false, you don't need to use type: unfeaturized particularly because this has been deprecated. Perhaps these should all be type: text?
how are you using the form in stories and rules? are you able to share the contents of these files too? The formbot example is a good guideline to follow.
I'm trying to follow AWS CloudFormation best practices, and set up lots of little stacks that nest under a parent stack. Mostly, this is working fine; however, in an intermediate stack I've now exceeded the max 60 parameter count. This will only get worse when I go the next level up and aggregate these intermediate stacks into a master parent stack.
The CloudFormation documentation says, "To specify more parameters, you can use mappings or lists in order to assign multiple values to a single parameter." In fact, that exact quotation has been given at least twice here in response to the 60 parameter limit question. However, how does one go about doing that? I can see how the mapping capability could work when you're selecting from a bunch of pre-defined sets of values (e.g., select from these AMI IDs, or these subnets), but don't see how it could work when the parameters are strings or numbers or other user-entered data; and I can't see an example at all of how lists do it.
Does anyone have an example or two of how they've used mappings and or lists to consolidate multiple user-entered parameters into a single parameter?
Edit, per a request in comments, I'm adding more details on what my templates look like. Here is the ParameterGroups section of the parent stack in question. It rolls up nested stacks for "mail storage" (which creates EBS volumes), "mail" which launches a primary and backup MX server and configures Postfix, Dovecot, etc..., and "Roundcube" which launches a autoscaling group of web servers running roundcube. All of this sits on top of another nested stack, "infrastructure", which deploys VPC, Subnets, ELB, NAT, RDS, security groups, and phpmyadmin.
AWS::CloudFormation::Interface:
ParameterGroups:
-
Label:
default: Mandatory Parameters
Parameters:
- Vpc
- NumberOfAZs
- AvailabilityZones
- AMIID
- WantRoundCube
-
Label:
default: Recommended Parameters
Parameters:
- AdminUser
- AdminPubKey
-
Label:
default: Mail Storage Parameters
Parameters:
- SpoolSize
- LogSize
- CreateSwap
- SwwapSize
- EncryptedBoolean
- Cmk
- SpoolDelPolicy
- LogDelPolicy
- MasterSpoolSnapshot
- MasterLogSnapshot
- BackupSpoolSnapshot
- BackupLogSnapshot
-
Label:
default: Primary MX EC2 Instance Parameters
Parameters:
- PrimaryServerName
- VirtualUID
- EC2KeyName
- MailInstanceType
- MailSecurityGroup
- StorageStackName
- PrimarySubnet
- InsertTestData
-
Label:
default: Backup MX EC2 Instance Parameters
Parameters:
- BackupServerName
- BackupMailInstanceType
- BackupSubnet
-
Label:
default: Database Parameters
Parameters:
- DatabaseStackName
- MailDBName
- MailDBUser
- MailDBPassword
- MailDBBackup
-
Label:
default: Postfix Primary Parameters
Parameters:
- Origin
- Banner
- RelayHost
- RootMailRecipient
- InetProtocols
- EnableSpfChecks
- EnableOpenDkim
- OpenDkimDomains
-
Label:
default: SSL Parameters
Parameters:
- CertSource
- AccountEmail
- DNSZone
- DNSSleep
- CertFileDir
-
Label:
default: Dovecot Parameters
Parameters:
- MaxUserConnections
-
Label:
default: Amavisd, SpamAssassin, ClamAV
Parameters:
- SAFinalDest
- SAKillLevelDeflt
- SetMyHost
-
Label:
default: Roundcube
Parameters:
- AllowPasswdChange
- AlternativeIAMRole
- AlternativeInitializationScript
- DnsName
- EnableDebug
- EnvironmentVariables
- Hash
- PublicAlbListenerArn
- RoundcubeDBName
- RoundcubeDBUser
- RoundcubeDBPass
- RoundcubeInstanceType
- RoundcubeSecurityGroup
- Skin
-
Label:
default: AWS S3 Configuration
Parameters:
- MirovoyCFAssetsBucket
- MailS3KeyPrefix
- RoundcubeS3KeyPrefix
- SkelFileDir
- Label:
default: Testing Configuration
Parameters:
- UnknownLocalErrorCode
- XandrosPass
- VivitaPass
- ExternalTestEmail
- SSLDebug
- ADLogLevel
- DisableVirusChecks
- DisableSpamChecks
- DisableServices
-
Label:
default: Postfix Optional Parameters
Parameters:
- DelayWarningTime
- MaxQueueLifetime
- MinBackoffTime
- MaxBackoffTime
- HeloTimeout
- RecipientLimit
- SoftErrLimit
- HardErrLimit
- SpfTimeLimit
I'm happy to post more of the template as necessary, but it's obviously already getting quite long :)
Thanks!
I want my linter to complain about missing type annotations everywhere except for lambdas, because in my opinion it worsens the code readability with little advantages.
For example those statements should raise a warning/hint:
const s = 'my string'; // Specify type annotation.
foo() => 'foo'; // Missing return type for foo.
List bar() => // Specify type annotation.
['bar', 'baz']; // Specify type annotation.
This should not:
<String>['qux', 'quux', 'corge']
.map((s) => s.toUpperCase());
I thinks those are the relevant rules in my analysis_option.yaml :
analyzer:
strong-mode:
implicit-dynamic: false
errors:
missing_required_param: warning
missing_return: warning
[...]
and
linter:
rules:
[...]
- always_specify_types
[...]
If needed this is the full analysis_option.yaml
# Specify analysis options.
#
# Until there are meta linter rules, each desired lint must be explicitly enabled.
# See: https://github.com/dart-lang/linter/issues/288
#
# For a list of lints, see: http://dart-lang.github.io/linter/lints/
# See the configuration guide for more
# https://github.com/dart-lang/sdk/tree/master/pkg/analyzer#configuring-the-analyzer
#
# There are other similar analysis options files in the flutter repos,
# which should be kept in sync with this file:
#
# - analysis_options.yaml (this file)
# - packages/flutter/lib/analysis_options_user.yaml
# - https://github.com/flutter/plugins/blob/master/analysis_options.yaml
# - https://github.com/flutter/engine/blob/master/analysis_options.yaml
#
# This file contains the analysis options used by Flutter tools, such as IntelliJ,
# Android Studio, and the `flutter analyze` command.
analyzer:
strong-mode:
implicit-dynamic: false
errors:
# treat missing required parameters as a warning (not a hint)
missing_required_param: warning
# treat missing returns as a warning (not a hint)
missing_return: warning
# allow having TODOs in the code
todo: warning
# Ignore analyzer hints for updating pubspecs when using Future or
# Stream and not importing dart:async
# Please see https://github.com/flutter/flutter/pull/24528 for details.
sdk_version_async_exported_from_core: ignore
exclude:
- "bin/cache/**"
# the following two are relative to the stocks example and the flutter package respectively
# see https://github.com/dart-lang/sdk/issues/28463
- "lib/i18n/stock_messages_*.dart"
- "lib/src/http/**"
linter:
rules:
# these rules are documented on and in the same order as
# the Dart Lint rules page to make maintenance easier
# https://github.com/dart-lang/linter/blob/master/example/all.yaml
- always_declare_return_types
# - always_put_control_body_on_new_line
# - always_put_required_named_parameters_first # we prefer having parameters in the same order as fields https://github.com/flutter/flutter/issues/10219
- always_require_non_null_named_parameters
- always_specify_types
- annotate_overrides
# - avoid_annotating_with_dynamic # conflicts with always_specify_types
- avoid_as
- avoid_bool_literals_in_conditional_expressions
# - avoid_catches_without_on_clauses # we do this commonly
# - avoid_catching_errors # we do this commonly
# - avoid_classes_with_only_static_members
# - avoid_double_and_int_checks # only useful when targeting JS runtime
- avoid_empty_else
- avoid_field_initializers_in_const_classes
- avoid_function_literals_in_foreach_calls
# - avoid_implementing_value_types # not yet tested
- avoid_init_to_null
# - avoid_js_rounded_ints # only useful when targeting JS runtime
- avoid_null_checks_in_equality_operators
# - avoid_positional_boolean_parameters # not yet tested
# - avoid_private_typedef_functions # we prefer having typedef (discussion in https://github.com/flutter/flutter/pull/16356)
- avoid_relative_lib_imports
- avoid_return_types_on_setters
# - avoid_returning_null # there are plenty of valid reasons to return null
# - avoid_returning_null_for_future # not yet tested
- avoid_returning_null_for_void
# - avoid_returning_this # there are plenty of valid reasons to return this
# - avoid_setters_without_getters # not yet tested
# - avoid_shadowing_type_parameters # not yet tested
# - avoid_single_cascade_in_expression_statements # not yet tested
- avoid_slow_async_io
- avoid_types_as_parameter_names
# - avoid_types_on_closure_parameters # conflicts with always_specify_types
- avoid_unused_constructor_parameters
- avoid_void_async
- await_only_futures
- camel_case_types
- cancel_subscriptions
# - cascade_invocations # not yet tested
# - close_sinks # not reliable enough
# - comment_references # blocked on https://github.com/flutter/flutter/issues/20765
# - constant_identifier_names # needs an opt-out https://github.com/dart-lang/linter/issues/204
- control_flow_in_finally
# - curly_braces_in_flow_control_structures # not yet tested
# - diagnostic_describe_all_properties # not yet tested
- directives_ordering
- empty_catches
- empty_constructor_bodies
- empty_statements
# - file_names # not yet tested
- flutter_style_todos
- hash_and_equals
- implementation_imports
# - invariant_booleans # too many false positives: https://github.com/dart-lang/linter/issues/811
- iterable_contains_unrelated_type
# - join_return_with_assignment # not yet tested
- library_names
- library_prefixes
# - lines_longer_than_80_chars # not yet tested
- list_remove_unrelated_type
# - literal_only_boolean_expressions # too many false positives: https://github.com/dart-lang/sdk/issues/34181
- no_adjacent_strings_in_list
- no_duplicate_case_values
- non_constant_identifier_names
# - null_closures # not yet tested
# - omit_local_variable_types # opposite of always_specify_types
# - one_member_abstracts # too many false positives
# - only_throw_errors # https://github.com/flutter/flutter/issues/5792
- overridden_fields
- package_api_docs
- package_names
- package_prefixed_library_names
# - parameter_assignments # we do this commonly
- prefer_adjacent_string_concatenation
- prefer_asserts_in_initializer_lists
# - prefer_asserts_with_message # not yet tested
- prefer_collection_literals
- prefer_conditional_assignment
- prefer_const_constructors
- prefer_const_constructors_in_immutables
- prefer_const_declarations
- prefer_const_literals_to_create_immutables
# - prefer_constructors_over_static_methods # not yet tested
- prefer_contains
# - prefer_double_quotes # opposite of prefer_single_quotes
- prefer_equal_for_default_values
# - prefer_expression_function_bodies # conflicts with https://github.com/flutter/flutter/wiki/Style-guide-for-Flutter-repo#consider-using--for-short-functions-and-methods
- prefer_final_fields
# - prefer_final_in_for_each # not yet tested
- prefer_final_locals
# - prefer_for_elements_to_map_fromIterable # not yet tested
- prefer_foreach
# - prefer_function_declarations_over_variables # not yet tested
- prefer_generic_function_type_aliases
# - prefer_if_elements_to_conditional_expressions # not yet tested
- prefer_if_null_operators
- prefer_initializing_formals
- prefer_inlined_adds
# - prefer_int_literals # not yet tested
# - prefer_interpolation_to_compose_strings # not yet tested
- prefer_is_empty
- prefer_is_not_empty
- prefer_iterable_whereType
# - prefer_mixin # https://github.com/dart-lang/language/issues/32
# - prefer_null_aware_operators # disable until NNBD, see https://github.com/flutter/flutter/pull/32711#issuecomment-492930932
- prefer_single_quotes
- prefer_spread_collections
- prefer_typing_uninitialized_variables
- prefer_void_to_null
# - provide_deprecation_message # not yet tested
# - public_member_api_docs # enabled on a case-by-case basis; see e.g. packages/analysis_options.yaml
- recursive_getters
- slash_for_doc_comments
# - sort_child_properties_last # not yet tested
- sort_constructors_first
- sort_pub_dependencies
- sort_unnamed_constructors_first
- test_types_in_equals
- throw_in_finally
# - type_annotate_public_apis # subset of always_specify_types
- type_init_formals
# - unawaited_futures # too many false positives
# - unnecessary_await_in_return # not yet tested
- unnecessary_brace_in_string_interps
- unnecessary_const
- unnecessary_getters_setters
# - unnecessary_lambdas # has false positives: https://github.com/dart-lang/linter/issues/498
- unnecessary_new
- unnecessary_null_aware_assignments
- unnecessary_null_in_if_null_operators
- unnecessary_overrides
- unnecessary_parenthesis
- unnecessary_statements
- unnecessary_this
- unrelated_type_equality_checks
# - unsafe_html # not yet tested
- use_full_hex_values_for_flutter_colors
# - use_function_type_syntax_for_parameters # not yet tested
- use_rethrow_when_possible
# - use_setters_to_change_properties # not yet tested
# - use_string_buffers # has false positives: https://github.com/dart-lang/sdk/issues/34182
# - use_to_and_as_if_applicable # has false positives, so we prefer to catch this by code-review
- valid_regexps
# - void_checks # not yet tested
You're looking for the avoid_type_checks_on_closure_parameters lint.
From the docs:
AVOID annotating types for function expression parameters.
Annotating types for function expression parameters is usually
unnecessary because the parameter types can almost always be inferred
from the context, thus making the practice redundant.
BAD:
var names = people.map((Person person) => person.name);
GOOD:
var names = people.map((person) => person.name);
EDIT: It looks like there's an open issue for this. If you're hitting this, go and thumbs up the issue and maybe leave a comment since the team takes those into account when prioritizing bug fixes.
UE version: 4.17
Game state can be initialized in FooGameMode::InitGameState, then what is the purpose of FooGameMode::InitGame and FooGameMode::PreInitializeComponents?
For reference, the callstack seems like this:
UEngine::LoadMap
- UWorld::InitializeActorsForPlay
- FooGameMode::InitGame
- ULevel::RouteActorInitialize
- FooGameMode::PreInitializeComponents
- FooGameMode::InitGameState
(full file: http://pastebin.com/jpTn5wqH)
groups:
Member:
options:
default: true
prefix: '&f[&7Nomad&f]’
permissions:
- essentials.kits.Nomad
- essentials.kit.Nomad
- bungeechat.global
- bungeecord.command.server
- essentials.msg
- essentials.message
- towny.leave
- essentials.mail
- essentials.mail.send
- essentials.warp.list
- essentials.warp
- libsdisguise.disguise.*
- essentials.balancetop
- essentials.balance
- bukkit.command.plugins
- towny.command.town.add
- towny.claimed.owntown.build.*
- ChestShop.shop.buy
- ChestShop.shop.sell
- ChestShop.shop.create
- essentials.plugins
- essentials.ping
- essentials.rules
- essentials.balance.others
- MyPet.command.trade.offer
- essentials.killall
- bukkit.plugins
- bukkit.plugin
- essentials.kit.peasant
- essentials.pay
- ontime.player.*
- towny.chat.town
- towny.chat.general
- towny.wild.*
- towny.command.town.buy
- towny.command.plot.claim
- mcmmo.repair.*
- essentials.ignore
- essentials.money
- essentials.help
- essentials.build
- essentials.list
- essentials.help
- essentials.kit
- essentials.spawn
- essentials.afk
- essentials.r
- essentials.respond
- essentials.talk
- essentials.home
- essentials.tpdeny
- essentials.tpaccept
- essentials.tpask
- essentials.tpa
- essentials.sethome
- essentials.delhome
- auctions.command.start
- auctions.command.info
- auctions.command.queue
- auctions.command.end
- auctions.command.ignore
- auctions.command.bid
- auctions.command.cancel
inheritance:
- Member
Builder:
options:
prefix: '&0[&2Builder&0]&r'
inheritance:
- Member
permissions:
- worldguard.region.bypass.world
- essentials.gamemode.Adventure
- essentials.gamemode.survival
- essentials.gamemode.spectator
- essentials.gamemode.creative
- essentials.mute
- essentials.gamemode.others
- essentials.gamemode.*
- essentials.gamemode
- worldedit.*
Head Builder:
options:
prefix: '&r[&aHead Builder&r]&r' # line 74
inheritance:
- Builder
- Member
- King
Perms For PermX Minecraft Plugin
What is wrong with the file?
Your YAML file starts with:
groups:
Member:
options:
default: true
prefix: '&f[&7Nomad&f]’
permissions:
- essentials.kits.Nomad
- essentials.kit.Nomad
and around line 74 has:
Builder:
options:
prefix: '&0[&2Builder&0]&r'
inheritance:
- Member
permissions:
- worldguard.region.bypass.world
- essentials.gamemode.Adventure
The line:
prefix: '&f[&7Nomad&f]’
starts a string (with the ') that ends on the line 74 followed by an unexpected character. You most likely want to change the ’ at the end of that line 5, as it is probably a typo and should be '.
With that change the file parses correctly.