"MekaSuit discussion"

per https://github.com/aidancbrady/Mekanism/issues/2840 armor was mentioned
armor repaired only by energy!
please add some options better then dark steel and other flux jetpacks. a few requests here

night vision uses power..
running fast
a glider option? ( would love this as a option for the normal jetpack )
jetpacks can run based on power or hydrogen.. if h2 then the tanks hold ALOT more but use ALOT more then normal ( have to use more to lift the weight of armor?  :)  ( this could be a GUI option to upgrade/change out and have options to swap out to make the armor better protection or better against blast/projectiles etc)
helmet can create O2 for underwater use. uses power :)
weapons have options to use gas or power... :)

Suggestion to rename thread to "MekaSuit discussion"

Smart Moving support?

whats smart moving?

Mod interaction suggestion: Support for GC, adding some kind of gas tank with O2 should provide oxygen to the player.

@Mementh:

whats smart moving?

SM adds new movements and animations to the player model: https://www.youtube.com/watch?v=xPoSqmWK_Os, but it's not a simply task for the developer to add.

@XFactHD thats a good idea for early game.. O2 options? then have something that makes the o2 and h2 from water in the air normally?
@EzerArch smart moving looks good for non first person ..  or watching others.. i would put that as LOW priority honestly since your saying its hard to work

As i went across this i couldn't leave this blank, but as i came here i was a bit disapointed by the simplicity of the thing. I was thinking that the armor should be more interactive or modular , else it would just be any other armor like any mod would put out there. Now what do i mean by modularity, Switching modules often make the armor upgradeable but with a cap. with this you can have multiple choice. You can let the player choose what he really needs on the armor. Does he need more inventory space for mining or hunting or even looting ? he could have an exo upgrade where there could be more space to transport things, does he need more attack power ? You could create a module for that. Does he need to have tanks on his back to transport a ton of liquids and gas? You can make something for that too. - this can extend and go very far and have a lot of new to it. You can constantly change it to make it what you like the most out of it

i was wondering tough if you could also make the suits have compatibility with the pneumaticraft helmet suit

A option for using some High pressured gas instead of regular burning fuel in jetpack, (Faster flight speed) also it shouldn't burn but just leave a mist or fog.
Helmet could have O2 underwater generator upgrade or Solar panel upgrade,
Antenna that maybe could work to be able to communicate with robit and tell him to teleport to your location.
Getting hit by lightning due to it would be a great surprise.
Chest piece could have a electrical discharge when player is hit with 10 second cool down and how much power it should use should be able to be set. so if someone wants to drain their entire battery in 1 discharge, or a few. let them do so.

+1 for making it modular.  I also think it could be dynamic and could be changed by swapping out parts in the field.  For instance, say you were using a jetpack in the traditional sense; flying around.  That would require a rocket booster pack (in the Jetpack or "back" slot) and hydrogen fuel (in a gas tank slot).  Say you wanted to go swimming in an ocean you found, and you happened to bring your Hydro-Jet converter and an Oxygen tank.  Switch those modules out and you have quick underwater propulsion and a lot of air to breath.
That would let the MekaSuit have many powerful abilities without letting it have all the powerful abilities all the time and become too OP.
My short list of ideas:
Armor slot (all pieces)

Accepts the appropriate physical armor (supporting Vanilla and Mekanism armors.    Can also accept Energy Shields (possibly multiple tiers), which take away from power reserves rather than any durability loss.

Helmet: (several other good ideas already mentioned)
-Airtight - Requires a filled oxygen tank to breath.  Can suffocate on land, but also allows use underwater.  Possibly Galicticraft compatible.
Legs:

Powered Legs (or similar. Again, tiers?).  Lowest tier will cancel out any slowness debuff from adding too many modules (heavy stuff), and higher tiers provide speed boosts.  Use small amounts of power.
Jump boost?

Boots:

Basically Free-Runners.  Step assist and Fall Damage avoidance.

Chestplate:

Energy Slot (maybe allow all peices to take small Energy Tablets, but only the chestplate to take huge Energy Cells).
Gas Tank Slot - Stores actual gas tanks that can be switched out quickly.
Back slot - Stores various upgrades
---- Chemical Jetpack
---- Energy Jetpack
---- Hydro-Jet (Under Water booster)
Auxiliary slot (or slots) (similar to back slot)
--Large:
----Wings - Make jetpacks go where the player is looking rather than strait up, and allows gliding.
---- On board Robit - Probably super OP, but robits already exist.  Pretty much this will give the abilities of a Robit the user (portable crafting grid, powered furnace, chest, and anvil).
--Small:
----Portable teleporter?
---- Magnet?

Well you still want default armor on it. Else Why not just equips something that gives you speed and protection already?

Because armor would be easy.  Ideally, the would be a fairly-cheap framework item to apply this onto, and then use basic armor for the protection.
This "function first, protection later" is similar to most mods with jetpacks, including mekanism.  The Basic jetpack doesn't provide any protection, and you can make an armored version for the cost of a chestplate or more.
I'm second guessing that slowness debuff idea.  The only mod that I've seen do something similar is Modular Powersuits, and I'm starting to see that my idea is getting a little to close to theirs on the whole.

I still feel the armor should be make with at least some obsidian ingots, so it could at least have some protection by default. But the armor could be specialised into it. into defense and attack. range or close range etc...

@VT-14 Else the "mekasuit" just turns into Modular Power suit with less power and utils. Again there can be many modules with limited modules.
() Now i wonder will the armor need a new model @aidancbrady  ?

I'm second guessing that slowness debuff idea. The only mod that I've seen do something similar is Modular Powersuits, and I'm starting to see that my idea is getting a little to close to theirs on the whole.

I would prefer a clear distinction between MPS and MekaSuit. I think MekaSuit can be as good or powerful as MPS. Just needs to have a different approach to avoid feature overlap. If MekaSuit is just a lighter/nerfed version of MPS armor, what if I have both installed, why would I then use MekaSuit?
Inspired on this Lego sculpture:

The T34-L Power suit is designed to increase the strength of the pilot. The suit is mostly used for lifting heavy stuff and is not designed to be used in combat, since the pilot is not armored for frontal attacks. The arms of the suit are connected with sensors to the pilot's arms. http://sparkytron.deviantart.com/art/T34-L-Power-Suit-275715250

I'm considering this:

MPS mod is designed for (direct/active) combat and exploration.
Mekanism mod is rather industrial and mining.

MekaSuit would be designed to aid the player with mining, industrial activities and protection (passive combat). The armor would be fusion of the current tools and wearables, that is:

Obsidian armor (main frame)
Flamethrower
Atomic Disassembler (would also allow you to mine areas from 1x1x1 to 5x5x5)
Gas Mask and Scuba Tank
Free Runners
Jetpack? (since I'm considering a heavy mecha-like armor, it could be nerfed into a Jump Assist: short-lived jet busts with cooldown can suspend you for a few seconds letting you jump as high as 6 blocks and cross wide gaps, in a Rocket Knight fashion: https://youtu.be/FLAaePOxUeY?t=57s)
Liquid transfer (portable tank + pump + plenisher): you can pump liquids from machines and environment into an internal storage and discharge them elsewhere. Aim at a machine, tank or liquid pool (e.g. a lava pool) and hold down rightclick to pump, change mode, aim to elsewhere, hold down rightclick to "plenish".
Logistical transfer: same as liquid transfer. Equipped with a vacuum cleaner to collect drops from the floor.
Energy transfer: idem.

New features:

Night vision
Block mover: select a box-area (up to 7x7x7) to cut blocks and paste them elsewhere. For that day when you notice you have build your reactor in a wrong spot and need to move it. Same works for chests and machines with inventory. Slows down your movement.
A tinker table or armor stand where you can build the MekaSuit, install modules and the tools listed above, repair and recharge the armor. Can be connected to a universal cable, please.
The armor can be 3 or 4 blocks tall? For science. (Just noticed Meka is close to mecha)

IcieFlake
I like the idea of a NOS boost system that a high pressure deal would give but not for regualr flight
Love the helmet having upgrade options for O2.. and a option when not using to recharge/pull in O2 from enviroment for power?
VT-14
I like the idea of modules and swapping :)
but i don't feel it should have a booster/flight diffrence.. just one for flight and one for moving underwater.. helmet having a O2 system thats compatable with galacticraft ?
I do like the idea of the leggings and armor being heavier and debuffing but i feel thats going to cause issues if someone mixed and matched.
the back slots and amor options i feel are good.. traditional armor/energy shield  is swapping and good.
I like the idea of a set of wings built in :)
EzerArchi don't like the idea of a huge suit/vehicle option.. just feels wrong/too big
I feel the flamethrower is not good. how would you use it ?
I see it as a defence option and utility.. so scuba and such
Also consider I know some part of the community don't use those tools because they have better options..

I like Ezer ideas but also i truly think the suit could also have the abilitiy to be purely for combat to. This is the hole point of modularity choosing  what you need.

I love these ideas. Mekanism is one of the better tiered tech mods out there and offers a wide range of options with increasingly more difficult builds. I'd honestly like to see a framework [think Fallout power armor frame] with modules as others suggested. The thing is, I'd also like to see a tech mod actually have armor that can roll up against high end stuff like Blood Magic bound armor. The problem with BM armor is that it really is only a single tier. By the time you can make it, you can generally make any of the sigils to socket into it so you do it once and done unless you are one of those folks swapping sigils all the time. ;)
With proper tiering.. the "frame" that the user wears could be very low level and the modules for it [armor, abilities, etc] would scale up in requirements as they scale up in power. I do agree with Alexis that while the idea of industrial/mining spec suit could be unique[ish], it does limit the options and let's be honest... wide-appeal isn't a bad thing. If it's tiered like most stuff in Mekanism is, it'll have to be decent for anyone to spend the time to make it.
Ability-wise you got the usual:

jetpack
glider
hill-step
haste
jump boost
fall damage prevention
element protection
air supply [underwater breathing]

.... I'm gonna stop because I'm echoing Ezer's post now. :)

I like the idea that someone mentioned about having a suit that has limited upgrade slots per piece. It lets you customize your armor to fit your needs at the same time while keeping you from making an armor that has everything leaving you with nothing to fear in the game.

If we could get two armor pieces in the interim to match the current Armored Jetpack, Free Runners, and Atomic Disassembler, I would be quite happy for a while :)

If the MekaSuit is going to be primarily aimed at industrial use, I would suggest a few more features for it:

A "straight line towards player" block placing feature similar to the FortressCraft Evolved Build Gun and Thaumcraft 5 Wand Focus: Building. Would be incredibly useful for running cables and stuff, or even just building platforms.
A built-in wrench, hopefully with some more of that lovely crossmod compatibility Mekanism is famous for. (Maybe a way to pick up IC2 machines losslessly?)
A bore of some sort for terraforming that can mine in a configurable AoE (maybe scalable from 1x1 to 9x9, with power requirements to match?
Built-in energy bank to charge tools.
Movement speed boost and step assist.
An upgrade to add integrated diving equipment.

That is true. With some mods and atomic disslodger i can make a 1x1 tunnel
as fast as IC2 suite allows me to run
'Kinda' overkill but fair late game update to be able to make a 9x1 tunnel
as fast as the suit allows you to move forward, with right config of
augments.
2016-04-15 15:50 GMT+02:00 DaMachinator<EMAIL_ADDRESS>
If the MekaSuit is going to be primarily aimed at industrial use, I would
suggest a few more features for it:

A "straight line towards player" block placing feature similar to
the FortressCraft Evolved Build Gun and Thaumcraft 5 Wand Focus: Building.
Would be incredibly useful for running cables and stuff, or even just
building platforms.
A built-in wrench, hopefully with some more of that lovely crossmod
compatibility Mekanism is famous for. (Maybe a way to pick up IC2 machines
losslessly?)
A bore of some sort for terraforming that can mine in a configurable
AoE (maybe scalable from 1x1 to 9x9, with power requirements to match?
Built-in energy bank to charge tools.
Movement speed boost and step assist.
An upgrade to add integrated diving equipment.

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
https://github.com/aidancbrady/Mekanism/issues/3108#issuecomment-210471108

I think that having digging would require the atomic dissassembler to have upgrades .. esp for enchants which i feel it would need.
having a wrench would be nice
I do like the idea of having a massive power bank/reserve thats swappable?

Mekanism has always had nicely scalable tiered solutions for just about everything.

it would be cool too if we could have an array of plasma based weapons just like the atomic disassembler and a gun using plasma. We could sure use that massive amount of power now.
However, I think something like this should be an addon to mekanism since it seems so big.

I really can not wait till this gets added. Its going to be so much fun to mess around with.

Anything to usurp Modular Power Suits and its addon(s). Honestly I'd rather go with something/someone who's more willing to listen to feedback and keep things flexible rather than continuing to build on dead API's and incompatible with shaders or render mods.
That said, my two bits:
I'd prefer something utilitarian that lets me focus on building, versus fighting. Like autofeed (yes im that lazy), integrated sprinkler for putting yourself out when you do something dumb, and letting me work under water for extended periods of time.
While I like MPS, its OP. It has balances to handle some of the OP-ness, but I find my self ripping it out of the pack because it gets abused.
It needs to start simple, but grow with you as you do. Not a high-end start point either.

I've got a couple of ideas for some upgrades:
Helmet only
{
Night vision - gives player night vision
Infra-red vision - makes nearby entities appear to have the glow effect (1.9)
X-ray vision - makes a chosen block look like glass
Trap Detector - highlights all explosives, pressure plates, and string in red
Automatic consuming - automatically eats any food in inventory when hungry
}
Chest only
{
Force field generator - cancels any damage taken dealing less than 8hp
Induction matrix - stores a controllable amount of energy
Regenerator - gives player regeneration effect
Aqua-lungs - allows player to breathe under water
{
Leggings only
{
Speed upgrade - gives player speed effect
Jump upgrade - gives player jump boost effect
Swim upgrade - triples swim speed
Torch placer - places a torch when light level falls below specified minimum
}
Boots only
{
Jet boots - allow player to hover and fly straight up only
Soft soles - makes no noise when walking
Shock absorbers - reduce fall damage by 80%
Spawn sprinkler - sprinkles an invisible powder that mobs can't spawn on
Angel placer - places a chosen block below the player (useful when flying)
{
Generators (for any piece)
{
Combustion generator - generates 3KJ/second using coal and creates a lot of heat
Respiration generator - generates 500J/second using sugar
Cryogenic generator - generates 100J/second and freezes nearby water
digestion generator - generates 300J/second using any food
}
Heat resistance (for any piece)
{
Coolant tank - removes 2% of heat per second per upgrade
Coolant vent - removes 3% of heat per second per upgrade, malfunctions in nether
Coolant fan - removes 5% of heat per second per upgrade and uses energy
Fire resistance - gives player fire resistance effect when suit is overheating
}
Miscellaneous (for any piece)
{
Invisibility plugin - gives player invisibility effect and makes armor invisible
Energetic gravity deflector - removes 200g of weight from the suit and uses energy
Spiky plating - gives suit the thorns enchantment
Robit garage - allows player to deploy a robit anywhere
Mekasuit controller - allows player to activate and de-activate any upgrades while in use
}

I didn't see this thread before i posted my power armour suggestion as part of a larger post in the DefenseTech github, and i love the idea's being thrown around so here's the power armour related excerpt from my post ( found here : https://github.com/aidancbrady/DefenseTech/issues/30 )
Also before reading take note that this was written with Defensetech in mind for combat related ideas, so some of the 'add-on's ' might be more combat focused then the stuff already in here.
[ Power Armour ]
I'm not talking like the traditional Numina-powered suits of Armour, more like Edge of tomorrow or Elysium exo-suits , with as cool models as possible that would add more of a infantry-based side of defense or offense for players, which i think is a cool idea because the majority of defense tech and its predecessor's content is in majority, static base-designed defenses and offenses. The actual technology to build this would require processes from mekanism to manufacture i'm sure, and would be in majority manufactured from steel for the majority of the parts, with some form of circuitry to complement it.
note: the suit's once built would be held in a "suit rack " similar to iron man's gear, and displayed similarly , this plays into some of the attachments and would have ports on the sides for oxygen , and power to be pumped in. Similar to Fallout 4's power armour rack , from here the suit can be modified as required , as long as its powered ( under the assumption the rack inserts the modules for you )
note : Some upgrades are "internal" and make no physical difference on the suit, but major upgrades like batteries, or power swords or certain helmet upgrades would change aspects of the physical suit model.
note : when a suit runs out of durability all of its attachments bar plating are rendered useless, slowness is applied to the player plus blindness if an enclosed helmet is installed. They can be repaired with a shapeless recipe including each part, circuitry , steel and whatever other elements deemed necessary. Note-Note : Or they could be placed in the armor rack and auto-repaired for a chunk of power?
Attachments :
portable radar add-on, similar to the Aliens universe motion detector for mobs and players but also detects in coming missiles, or EMP towers if upgraded.
Agility boosters , attachments added to the leg section of the suit which allow a 'step-up' bonus or increased speed, jumping etc
strength boosters , attachments to the torso which increase the physical strength of the wearer to the point where he/she can break blocks below diamond level with ease and gains a permanent powered knock-back bonus.
Uni-Wrench add-on, a wrench attachable to the torso section that has cross-mod capability.
Missile commander , a helmet and torso attachment set that allow's - when used with the portable radar to use missile strikes from a pre-determined launcher in a manner similar to 'Call of Duty's' predator missiles.
Various Batteries , a set of tiered batteries powering the above and below sets of attachments.
Exo-doc , a built in but invasive ( permanent reduction of health by a heart? ) medical assistant whom automatically heals the user and can be upgraded for faster speed of healing in one or more tiers.
Armour plating , fairly simple but increases both the durability of the exo-suit and the wearer, with dampening upgrades to increase the user's health by a few hearts whilst wearing the suit.
Auto-caller, a radio transceiver hooked into the Suit's stationary rack that automatically call's the suit to the wearer and attach's itself in place of whatever armor the user is currently wearing ( forces armor into inventory or ground , and may require chunk loading capability. )
Ferro-magnets , a set of magnet's attached to the leg's and boots that allow anything not bolted down to be drawn towards the player.
weighted boots , a set of boots which allow the player to walk along the bottom of the ocean unhindered.
Oxygen supply , a tank of oxygen equipped to the torso with respective breathing apparatus's equipped to the helmet that allow breathing in vacuum's or under-water provided oxygen is given.
"Venom Drones" , minute robot's launch-able similar to an ender pearl that can attach to walls, roofs or the floor ( adding blocks that prevent this? ) , which can be used as remote camera's.
"Venom Uplink" , an interface with customization placement on the HUD that allows remote viewing and cycling through view's of " Venom Drones " ( looking-glass API )
Power sword , an automated hydraulic attachment with swords that allows the use of a normal sword in a manner similar to a bayonet but with increased puncture damage due to piston-powered pushes. attached on torso
Enclosed helmet ( original helmet is like a frame ) , a set of metal plates shaped to spec that allow the cosmetic closing of a suit, but to little functional change bar possible increase in durability and damage reduction.
Engineers wrench , not an attachment but a powered multi-tool that allow's the changing of attachments in the field, so long as its powered and with a cool down/ installation time per
attachment.
E.W.P , the Emergency Wind-up Power-supply is an attachment to the torso and leg's which either allow's a player to click and generate a set ( but minute ) portion of energy per click, or to walk / run and generate an even smaller amount of energy per block moved.
Pheromone generator , a capsule attached to the helmet which makes the player "invisible" to mobs which are hostile.
Enclosed suit , similar to the enclosed helmet plating this attachment cover's the respective torso, legs and boots in metal plating , although its unsealed for a moderately increased durability of the suit.
Reflective plating , an upgraded enclosed suit, this system incorporates several layers of silver and glass in a lacquered "plate" which can reflect high-energy lasers and energy-based weapons.
Ablative plating , an alternative upgraded enclosed suit , this system encorporates micro-plates of high-density metal , which when linked together sacrifice increments of durability in chunks to prevent damage from shrapnel, explosives or other ballistic dangers.
Hazmat plating, an upgraded enclosed suit that includes biological seals , this system incorporates hazmat-grade seal's made out of rubber and steel wire underneath thicker-cut metal plating , which prevents external potion effect's( negative or positive ) , radiation and fire( at the rapid cost of durability. )
Shoulder mount , a socket attached to the torso which allow's further mounting of weapon systems.
Rail gun , a militarized array of magnets that launches ballistic rounds at high speeds - must be powered.
Missile launcher, fires lower powered missiles once loaded towards a manually aimed target or used in sync with the missile commander attachment to fire missiles towards remote targets.
auto loader, an attachment to the back of the of the torso which auto-load's ammunition from
an internal reservoir into weapons systems, not powered.
Shock dampeners , these allow higher powered missiles ( mid tier ) to be fired from the suit.
Improved servo's , high-power magnet array's replace traditional hydraulic array's in the leg's and arm's, increasing speed , strength etc but also allow vertical scaling of surfaces.
Battlefield power jack , this baby allows the player , when interfacing with any machines to input a set portion of power into their suit or to output a certain portion of power to any machines when shift-clicked.
Note : this would be done with a GUI that has sliders etc
Defensive technologies and Offensive technologies :
Note that , i know there is a post request for this kind of idea already but expanding on the concept on several fronts.

SO MANY IDEAS not enough time to do more than skim them all
Suit built largely around building, construction, and logistics.
###GENERAL:

Tiered suit and components: Basic, Advanced, Elite, Ultimate
Some components will have less than 4 tiers and a minimum frame tier
Maximum total component weight by suit frame tier.
Frame cannot use components of a higher tier than it. Cannot put an Elite speed boost module in an Advanced mekasuit frame, but an Advanced speed boost will go in an Elite mekasuit frame.

###SUIT FRAME:
Powered by 1) hydrogen fuel cell (would require oxygen supply underwater) or 2) directly inputting RF.
Either way, should be able to add more fuel/MekanismJoule storage at the cost of increased weight.
Without any modules, it gives the player some vanilla armor points.
If it runs out of power, it slows player movement speed in proportion to weight, with a base slowness level per tier. If speed boost modules are installed, movement is made even slower in proportion to module tier - higher tier modules make you even slower.
Why make speed boost modules incur an additional slowness penalty when unpowered? Presumably they use hydraulic, pneumatic, or electrical actuators. So when they lose power, not only do you need to lug the heavy suit around, you also have to force the actuators to move as well.
###COMPONENTS:

Component
Tiered?
Purpose

Boosted Actuators
Yes
++ move speed

Jump Jets*
Yes
++ jump height

Step Actuators
No
++ step height

Shock Absorbers
Yes
-- fall damage

Pressurized Helmet*
No
respiration effect

Armor Plating
Yes
regular damage reduction

Plasma Field*
Yes
projectile damage reduction

Enhanced Plating*
Yes
magic damage reduction

Active Cooling*
Yes
gives fire resistance

van de Graff Unit
Yes
gives Thorns

Ion Thrusters*
Yes
give MekJ-powered flight

Hydrogen Thrusters*
Yes
give Hydrogen-powered flight

Solar Generator*
Yes
generate power from sunlight

Gas Generator*
Yes
generate power from flammable gas

Minaturized Fusion Plant*
No
generate power from tritium/deuterium fusion

Feeding Tube
No
autofeed

NanoMedics*
Yes
regeneration, cures negative effects

Item Vacuum*
Yes
item magnet

Starred Component Explanations
Jump Jets: Require hydrogen, upgrades increase jump height and efficiency. Lowest tier uses x amount of hydrogen to jump an additional 2-3 blocks. Subsequent tiers increase jump height and use less hydrogen per block.
Pressurized Helmet: Requires oxygen.
Plasma Field: An invisible plasma sphere around the player that slows incoming projectiles. Upgrades increase damage reduction, final tier negates it (vaporizes projectiles).
Enhanced Plating: Requires SOMETHING (not sure what) enchanted with the Protection enchant. Higher tiers require higher enchant levels.
Active Cooling: When taking fire damage (or if you have a mini fusion plant installed) absorbs the heat into an internal buffer instead of damaging the player. Dissipates a fixed amount of heat per tick from the buffer. Higher tiers dissipate more and have a larger buffer. If the buffer fills, the cooling module cannot absorb more heat and thus no longer protects the player from fire damage.
Thrusters, in general: Upgrades decrease power/fuel use and increase flight speed. Each level has a maximum suit weight it can lift. Speed and power/fuel use are dependent upon suit weight. Go ahead and try adding more thrusters. You'll probably find the huge increase in power/fuel consumption is not worth the extra lifting capacity and speed.
Ion thrusters: Cannot lift much, but can fly for a long time and have a higher base speed than hydrogen thrusters.
Hydrogen thrusters: Can lift a LOT, but have lower flying times and are slower.
NB: Top-tier hydrogen thrusters installed on a suit with nothing but power and a few hydrogen tanks will be faster than top-tier ion thrusters installed on a suit that approaches its maximum weight.
Solar Generator: Upgrades increase efficiency (power generated per unit weight)
Gas Generator: Upgrades increase possible fuel types and efficiency (power generated per unit weight)
Minaturized Fusion Plant: Very heavy. Top-tier suit frame only. Generates a lot of power. Requires D/T Fuel to operate, and requires an Active Cooling Module to be installed and a ridiculous amount of power to start. If the Active Cooling Module overloads, it will meltdown, killing the player and destroying the armor.
NanoMedics: Two tiers.
First tier gives Regen I and can cure blindness and nausea, and requires the Elite suit frame.
Second tier gives Regen II and can cure all negative effects that drinking milk can.
Item Vacuum: Tiers increase range.

@DaMachinator, your suggestions have my approval. I'm beginning to brainstorm how I'm going to approach this and your ideas follow along almost exactly with how I'd want to go about this project.  I'll keep you all posted with my plans.

There's this free-to-play video game called Firefall and it features soldiers in mostly-modular power armor. A year or two ago there was this mechanic where your suit has only so many CPUs available and could only carry so much weight. Each component (jetpack, servos, weapons, abilities, etc...) had a certain weight and used a certain number of CPUs. You could offset the weight by using modules that used an additional CPU. This forced you to min-max damage, speed, survivability and ability capabilities. This could be an interesting system to incorporate into the MekaSuit to prevent OP setups and encourage creativity.

There's this free-to-play video game called Firefall and it features soldiers in mostly-modular power armor. A year or two ago there was this mechanic where your suit has only so many CPUs available and could only carry so much weight. Each component (jetpack, servos, weapons, abilities, etc...) had a certain weight and used a certain number of CPUs. You could offset the weight by using modules that used an additional CPU. This forced you to min-max damage, speed, survivability and ability capabilities. This could be an interesting system to incorporate into the MekaSuit to prevent OP setups and encourage creativity.

That was my idea with the tiered weight mechanic with the additional restriction that certain items REQUIRE certain tiers. I like powerful items, as long as the effort needed to get them is commensurate with their power.

The problem is you start looking like MPS. MPS has few drawbacks other than weight which can be overcome by more power assistance. You get the idea.
While everyone will counter my argument, its OP. Period.  I have had players do this on a regular basis just to troll the owners.
Boosts must be reasonable. No faster than a boat/horse. I've already specified why. It cripples servers when people go exploring.
Frankly we need more uses for refined glowstone and obsidian ingots.

So replace weight with any arbitrary word of your choice that doesn't sound like MPS and makes sense.
I agree, most servers and even individual PC's cannot keep up with the increased speed. (Pregeneration helps, but you can still go too fast.)
Also, what CAN go 50 m/s that isn't endgame (Botania globetrotters sash, Chromaticcraft Lumen Dash)?

It's honestly silly to have that kind of speed in any circumstance and have it consume next to no power, or have the ability to regenerate the power from simply moving. This is currently possible with MPS.
Weight and heat generation (forgot that addition) is your only serious limitation. Power consumption is a joke for MPS. So a multi-layer approach to penalties.
CPU cost, and power grid usage thrown in there with weight makes you really have to think about what mods you want to carry around. Just so you cant walk around with 500Kg of gear and get away with it.

I've got an idea for another limitation! SPACE! (as in volume, not the
universe).
So the helmet part of the armor can only ever have enough space for 5
(because 5 materials is used for building it) upgrades/modules. The
chestplate 8, leggings 7, and boots 4! This would be impossible to change,
therefore the player has to take choices on which modules (s)he will need.
If the player wants more, then two suits will be necessary, meaning twice
the effort.
On 25 July 2016 at 04:58, Joseph Harder<EMAIL_ADDRESS>wrote:

It's honestly silly to have that kind of speed in any circumstance and
have it consume next to no power, or have the ability to regenerate the
power from simply moving. This is currently possible with MPS.
Weight and heat generation (forgot that addition) is your only serious
limitation. Power consumption is a joke for MPS. So a multi-layer approach
to penalties.
CPU cost, and power grid usage thrown in there with weight makes you
really have to think about what mods you want to carry around. Just so you
cant walk around with 500Kg of gear and get away with it.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/aidancbrady/Mekanism/issues/3108#issuecomment-234831255,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ASgRZOJ4Wsu5r825CvgsJAkHr3sAVLF5ks5qZDRNgaJpZM4He1Ro
.

Also, DaMachinator, I've gone over your suggested list (and others). I cant help but feeling that looks almost carbon copy of MPS.
Might I suggest dumping RF/J/EU powered jets. It really makes things very stupidly easy for people who have energy to throw away.

Yes, it is like MPS in many ways. There are only so many ways to do this - I was not trying to intentionally copy MPS, just thinking of what I would like in an exosuit oriented more towards utility than combat.
Weight: An arbitrary limitation for balance reasons that makes sense to me.
Move speed and jump jets should have the same effect as the corresponding vanilla potion (jump boost I-IV and speed I-IV)
Step assist is based on freerunners.
Pressurized helmet is based on the existing diving helmet.
Armor plating is vanilla-type armor.
Plasma Field through VDG unit are based on vanilla armor enchants and each tier should have the same effect as the corresponding level of that enchant, except for active cooling, which I already described.
The idea behind ALL the thrusters was that suits with more modules/stronger frame require more lifting power to sustain flight, and a suit with less modules can go faster than a suit with more modules using the same rockets.
Ion thrusters would be considerably weaker (not strong enough to lift a suit frame with full modules of the corresponding tier) but have considerably longer flight times. This idea is mostly from Space Engineers but not a 100% copy since SE ions barely work at all in the atmosphere.
The solar and gas generators are supposed to be based on the Advanced Solar Panel and the Gas Generator, respectively.
The miniature fusion reactor is based on the big Mek fusion reactor, but the idea is from Factorio's exosuits. The requirement for the cooling module is for balance reasons.
Nanomedics are the only name I could come up with that didn't sound like I was copying someone else. The only reason I suggested them is because with the modset I play with everything is dangerous.

Do forgive me if I'm trying to tear things apart here. Its constructive and I'm not trying to upset you.

Move speed and jump jets should have the same effect as the corresponding vanilla potion (jump boost I-IV and speed I-IV)

I wholeheartedly agree. The boost should be fixed tiered values and not a linear user selected value (aka slide bar).

The miniature fusion reactor is based on the big Mek fusion reactor, but the idea is from Factorio's exosuits. The requirement for the cooling module is for balance reasons.

I'm down for this as long as there is a limitation. A fuel buffer filled with D-T fuel be required for operation (tiered). Preferably it cannot be field serviced (changed out). Give you a reason to use the personal teleporter.

I dunno. The major players in fancy armor fall out like this in 1.7.10:
Blood Magic. Super OP armor that takes sigils to make it even more OP including things like haste and projectile deflection.
IC2 - Quantum Armor. Basically EU fueled armor with a built in jet pack and options for underwater breathing, self feeding, sprint, etc.
EnderIO - Dark steel armor which has options for all sorts of things
Botania - TerraSteel armor which has health regen even when hunger not full plus other mods that can be added
MPS - well discussed in this thread already
RotaryCraft - bedrock armor, probably he most OP of all armor available as its nearly impossible to die ever
That's probably the main ones I see used often from mainstream mods. Of those, all but MPS and RC have made the move to newer MC versions including 1.10 which is where Aidan has said Mek is going once he gets 1.9.4 stable. Making an OP suit of armor isn't exactly rare and there's so many mods that do it now (above and otherwise) that it's kinda moot.
Point being, this will continue to be the norm. What's the main focus of Mekanism tho? I would argue it is not combat. There's a couple items for combat but Mek isn't a combat mod.
The big question to Aidan would be his overall direction of the mod. If it's not combat, I think the Mek suit discussion narrows easily to that of utility.
What's that mean?

Mining augments (drills! See Actual Additions mod for a great still example)

Building augments (more block placement reach, ability to place multiple blocks ala builders wand, ability to swap blocks ala ender tech exchangers)

Quality of life (auto feed, oxygen, flight)

Don't see it really needing combat anything. Maybe diamond armor level protection by needs Mek joules for power like really any other tech mod armor. Modular so you can upgrade pieces (think Draconic Evolution with its book slots), and just plain useful for building your base and gathering resources to support that.
Just my thoughts. Plenty of combat armor out there both in 1.7.10 and newer. Not nearly as much utility armor. Having an alternative to just "pick favorite OP armor and add an angel ring for flight" would be nice. Sure you don't have to do it but think of all the servers you've played on, that's pretty much the norm. :)

On Jul 25, 2016, at 11:38 AM, Joseph Harder<EMAIL_ADDRESS>wrote:
Do forgive me if I'm trying to tear things apart here. Its constructive and I'm not trying to upset you.
Move speed and jump jets should have the same effect as the corresponding vanilla potion (jump boost I-IV and speed I-IV)
I wholeheartedly agree. The boost should be fixed tiered values and not a linear user selected value (aka slide bar).
The miniature fusion reactor is based on the big Mek fusion reactor, but the idea is from Factorio's exosuits. The requirement for the cooling module is for balance reasons.
I'm down for this as long as there is a limitation. A fuel buffer filled with D-T fuel be required for operation (tiered). Preferably it cannot be field serviced (changed out). Give you a reason to use the personal teleporter.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

Since when did the Quantum Armor let you fly? The Gravitation Suit from the GraviSuite addon does, but not the Quantum Armor.
It is quite possible to die in RoC armor. I know, I did it. Multiple times.
There's also the Wyvern and Draconic armor from Draconic Evolution, which just got completely redone - I don't know how they work any more - and the Infinity Armor from Avaritia, which is a joke mod.

And PE gem armor.

It's got a jet pack so you can fly. Includes hover mode iirc. It's not creative flight if that's what you're asking.
Spaced off DE. Also an uber combat armor set. Only died once in Bedrock and was due to a a turbine incident. :)
Anyway my point specifically was that there is so much over combat armor out there that I don't feel Mek needs to join that crowd unless Aidan is wanting to move the mod to more combat in which case I can think of quite a few other supporting things he needs to add wth that. :)

On Jul 25, 2016, at 12:41 PM, DaMachinator<EMAIL_ADDRESS>wrote:
Since when did the Quantum Armor let you fly? The Gravitation Suit from the GraviSuite addon does, but not the Quantum Armor.
It is quite possible to die in RoC armor. I know, I did it. Multiple times.
There's also the Wyvern and Draconic armor from Draconic Evolution, which just got completely redone - I don't know how they work any more - and the Infinity Armor from Avaritia, which is a joke mod.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

Spaced off DE. Also an uber combat armor set. Only died once in Bedrock and was due to a a turbine incident. :)

My method of PvP'ing anyone with DE in bedrock involves a quad of bedrock industrial coils, an EMP Weapon, and a gravel gun.

Spaced off DE. Also an uber combat armor set. Only died once in Bedrock and was due to a a turbine incident.
I got the chicken one >:) That was amusing.
Bedrock is an absolute pain to get. It requires a huge tech tree (and investment) to be established before you can get it. Coils have been changed to make life far more difficult to do that kind of setup. As far as RoC goes, I'm unimpressed with bedrock armor, but I will use it if that is the only endgame set available. The author of RoC has been approached to update.
Yes, Quantum armor does have flight (Not the nano armor which is black). It is not enabled by default on some versions. You have to turn it on with a key combination. This armor is aggravatingly difficult to make due to changes in UU-Matter. If you have RoC installed, this becomes slightly easier with iridium being a 2% chance of yield when processing silver ore. While many argue that its the best, many of the twilight bosses have the ability to do some serious damage to you.
As like all of your other mods, please make it possible for modpack creators /server owners to disable modules.

There should be a way to get an elytra mode on the jetpack.
How to get the upgrade:
You'd have to get an elytra and then use it to craft the "Elytra Upgrade" and then take that and your jetpack and use the "Upgrade table" to install the upgrade.
How it would work:
Pretty simple; "Elyta mode" works the same as a normal elytra except you can use the jetpack to give you a speed boost for the cost of fuel.
The Upgrade table:
Allows you to install upgrades onto your tools/armour. Would later be used to apply and remove upgrades for the MekaSuit.

only a minor change to allow some stuff to make sense:
the suit contains both a hydrogen and an oxygen tank.
then you could:
breathe the oxygen underwater
use the hydrogen (and the oxygen) to use the jetpack in the air (saying we use the O2 of the air doesn't count)
use both together for underwater movement (and maybe underwater flamethrower :D)

As a recent convert to Mekanism, I'd like to add my 0.02 here :).
Building on the theme of choices in how you build you suit, how about an "obsidian" path, and a "plastic" path. Obsidian gear already a feature of high-tier kit, and plastic production is cool, and needs more uses. (You could even add more fancy high tech composite materials)
Obsidian parts are the stompy combat-oriented option. High protection, damage/knockback boosts, but high fuel use and limited speed upgrade.
Plastic parts are the high-tech ninja approach. High speed, fast flight, high efficiency, with space for lots of Quality-of-Life enhancements.

With the $0.02 from fans of the mod I personally don't like the idea of flight in the suit. The lego model up top gave me this real heavy vibe I liked for the feel for a industrial themed mod. So give the suit jump jets and maybe temporary hover so you can control where a improved jump lets you go better but not flight. Leave flight for a magic mod integration where the other mod lets you reduce the weight of the suit untill the jump jets can lift the suits weight.

I am just reading through this thread now, I really hope this is something that is going to be added. Maybe even making current things (such as the jetpack) upgradable with a gas efficient upgrade or a elyta upgrade would even work.

For anyone still tracking this, MekaSuit is now officially in development. Feel free to post any additional ideas and I’ll consider them.
Sometime in the next few days I’ll write up how the suit is being designed to provide some more context.

Basicly some meka suit ideas like the many other ideas on this discussion, though i will be trying to keep it within the theme of mekanism, within the realm of posibility,  close to what the recent github commits are like, and i will exclude the more obvious items liem speed, jump boost, and night vision
General features/non specific features i would like:
Suit config options
Basicly the ability to lets say mayke that five tall jump into a 2 block tall jump without unequiping upgrades (maybe more energy efficiency given for loweing it but keeping the upgrades?)
Suit power gen options besides the "solarpannel on the head" (solar panel on head is cool too)  basicly having the ability to have a mini bio fuel or gass burning gen that runs off of gas or fuel in the armor or inventory
Option gui
Theres gonna be alot of features in the suit (i hope) and the keyboard doesnt have the room to control all those features. Solution: pop up gui. Nothing fancy, very much like the usual mekanism gui thats like a large chest, pops up from ome key and then you select the peice that has the module then turn that modules on off or even change its mode
Some upgrade ideas:
Diffrent levels of the electrolysis upgrade?
At level one you can get back air bubbles, at level two you can refill your suit jet pack,
Level 3 maybe refiling held items? Faster jetpack refill??
Vison upgrades
Idk a particular order of when and how to implement these in a order on the helmet but:
Zoom (shift + ctrl?)
The water vision thing (goes a long way due to the 1.14 update)
Mob detection overlay? Basicly highlights a mob in your vision even if its through a wall (Please! No glowing effect it drops my fps like someone from wrestle mania)
Jetpack upgrades
Forward movement (even while hovering)
Fall into lava detection (danger activation) (activates hover mode when about to fall into lava)
Faster up acceleration
Elytra????? (Straps elytra like wings or larger wigs to the jet pack to allow for eleytra like flight with a jet boost?
Boots
Faster swim (both the depth strider and dolphins grace swimm speed boosts)
Pants:
Pockets for holding items like torches and food for your off hand (scroll and set key to switch off hand item?)
Chest plate
Charge held items from suit buffer
Honesty thats all i have, for now... I dont want to post amillion ideas and cause your eyes to glaze over and i dont want to post ideas not too fitting with the plan
Anyways have a good day or night


chore(master): release 1.2.6

:robot: I have created a release beep boop
1.2.6 (2023-05-24)
Miscellaneous

deps: update dependency phpstan/extension-installer to v1.3.1 (2850d9a)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/wayofdev/php-cs-fixer-config/releases/tag/v1.2.6 :sunflower:


Replace system header macros with const variables

Coverage remained the same at 75.692% when pulling 2836a0ac2c9acad62119aa95653c72a8de0a5fbb on system-header-moder-cpp into 8e88bcfb01baac081910fadf7061cb9501134484 on master.


Repeating letter in answer (eg H in HUNCH) notified in YELLOW plus GREEN

If the answer word has a repeating letter (e.g. MUMMY, PUPPY, HUNCH, CIRCA) there is a confusion for the user if they guess only one of the letters in the correct position.
If only one of multiple instances of same letter is correct in the guess, let us make it green in the table(because it is correct), but yellow in the keyboard(because it is incomplete)
Sounds like a reasonable addition ?

@DrJohnDavis @ZachEdwards7, I'd actually rather leave this as is, I think it would be too big of a hint to tell the user that the letter is used again when they've only guessed it once.


T2.0a - Guidance and support section interim page

http://iati.surge.sh/page-templates/02a-guidance-support
This is the head page for the Guidance and Support section.
It will eventually be replaced by https://trello.com/c/i8w4TsyOa nd https://trello.com/c/3UF3nVNA
This page has the following model:

title
intro
sub title
content (rich text)

This page then lists its immediate subpages as three main blocks of content each comprising of:

Title
Image
Summary (rich text)
Button label

We'd probably build this out to pull in all the content from each subpage.

This is an interim page for the Guidance section.
Should have the image hero variant we use for section headings and the model would be something like this:

title
intro (textarea)
image (image)
content_editor

Then the template shows the sections below it, which in this case are shown in the sketch.
When we have the Knowledge Base created and maybe the Data Guide then this page will be replaced with https://trello.com/c/i8w4TsyO and the content moved to this template: https://trello.com/c/3UF3nVNA
From Trello card: https://trello.com/c/4CiCC8qh/119-t20a-guidance-and-support-section-interim-page

Now implemented. Closing issue.


How can I send an image?

Hey , How can I send an Image, I was trying to found the correct function but it is really hard to find.

Is there any update on this case?

any update on sending images or video?

I need to send an image too. Did anyone discover how to do it?

is this hard or impossible ?

Hi guys,
I found a solution but may be it not a good solution. You can automate the whole. For this you can do like...

Go to the screen of whom you want to send images: (Note : I'm using this according my req. you can use another approach to go there.
ph = '919874563210'
strs = 'https://api.whatsapp.com/send?phone=' + ph
search_xpath = '//*[@id="input-chatlist-search"]'
driver.driver.find_element_by_xpath(search_xpath).send_keys(phone + Keys.ENTER)

Click on attachment on whatsapp using :
driver.driver.find_element_by_xpath('//*[@id="main"]/header/div[3]/div/div[2]/div/span').click()

Search the upload button like..(Note: Please change XPATH accordingly)
element = driver.driver.find_element_by_xpath('//*[@id="main"]/header/div[3]/div/div[2]/span/div/div/ul/li[1]/input')

Use the function to send images (Note : file_path -> '/home/Desktop/image.jpg')
element.send_keys(file_path)
time.sleep(1)

If you have image URL in that case you can download image first using and then use above help.
folder_path = '/home/Desktop/'
URL = ['image1_url', 'image2_url']        (Please put your URL here)
def download_images_with_url(URL):
for index, url in enumerate(URL):
file_object = str(index) + '.jpg'
file_path = os.path.join(folder_path, file_object)
try:
urllib.urlretrieve(url, file_path)
except Exception as e:
print(e)
Surely it will help to send an image.

any news about this?

Hey guys, I am sendind images now.
There are too many things to do to send images using JS:

Upload the file to Whatsapp Server
Receive the URL with whatsapp Server Validation
Send the image to the group using the validation URL plus other params.

So I Gave up.
And I decided to take a different route, actually it is the same @bansal95 was explaining. I create a full script to send the images in selenium.

Fill the search text with the group or contact I want to send the image
Click on the Clip icon.
Fill the File Input with the location of the image
Click on the send button.

I hope it helps,

Would you kindly share or implement the Implementation? It would be a great
Feature for this API
Btw, in this way it would also be possible to Senf any Kind of different
Attachment (just Change the click on attach file). That'd be nice to have,
maybe we can Work Something Out
Greetings
Am 21.02.2018 12:44 vorm. schrieb "gwilches"<EMAIL_ADDRESS>
Hey guys, I am sendind images now.
There are too many things to do to send images using JS:

Upload the file to Whatsapp Server
Receive the URL with whatsapp Server Validation
Send the image to the group using the validation URL plus other
params.

So I Gave up.
And I decided to take a different route, actually it is the same @bansal95
https://github.com/bansal95 was explaining. I create a full script to
send the images in selenium.

Fill the search text with the group or contact I want to send the
image
Click on the Clip icon.
Fill the File Input with the location of the image
Click on the send button.

I hope it helps,
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/mukulhase/WebWhatsAPI/issues/23#issuecomment-367161443,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGhecaYIdfW1gF_GU0eoi53_2Xk0VJKmks5tW1jngaJpZM4P_sKr
.

@m2datacenter @gwilches If you can send the script that'd be awesome.

@gwilches  can get a email to contact please? @gwilches

@gwilches could you please share your solution?

I can send image in a simple way. Just send the image to the clipboard and with the chat open, paste. Then click on the submit button

@wallysonn can explain more this solution?

@wallysonn could you please explain your solution?

@gwilches : Can you please share the code ?

I wrote the following code in puppeteer . Sometimes it works and sometimes it doesnt
 driver.then(async driver => {         driver.page.waitForSelector("div[title='New chat']", {visible: true}).then(async selector => {             await selector.click();             driver.page.waitForSelector("input[title='Search contacts']", {visible: true}).then(async value => {                 await value.type("8414988803", {delay: 2});                 driver.page.waitForSelector("#app > div > div > div.MZIyP > div._3q4NP.k1feT > span > div > span > div > div._2sNbV > div > div > div > div > div > div", {visible: true,}).then(async selector => {                     await selector.click();                     driver.page.waitForSelector("div[title='Attach']", {visible: true}).then(async selector => {                         await selector.click();                         driver.page.waitForSelector("button.GK4Lv", {visible: true}).then(async selector => {                             // await selector.click();                             const inputHandle = await driver.page.$("#main > header > div._1i0-u > div > div.rAUz7._3TbsN > span > div > div > ul > li:nth-child(3) > input[type=\"file\"]");                             await inputHandle.uploadFile(path.resolve(__dirname, "..", "driver", "jquery.js"))                             driver.page.waitForSelector("#app > div > div > div.MZIyP > div._3q4NP._1Iexl > span > div > span > div > div > div._2sNbV._3ySAH > span:nth-child(3) > div > div > span", {visible: true}).then(async selector => {                                 await selector.click()                             })                         })                     })                 })             })         })     })

I have implemented the code in puppeteer . Please someone port it to selenium
public async sendDocument() {         await this.page.bringToFront();         var selector = await   this.page.waitForSelector("div[title='New chat']", {visible: true});         await selector.click();         // await driver.page.waitFor(100);         var selector = await         this.page.waitForSelector("input[title='Search contacts']", {visible: true});         await this.page.evaluate(() => {             jQuery("input[title='Search contacts']").prop("value", "")         });         await selector.type("8414988803");         await this.page.keyboard.press("Enter");         var selector = await this.page.waitForSelector("div[title='Attach']");         await selector.click();         var selector = await this.page.waitForSelector("button.GK4Lv");         const inputHandle = await this.page.$("#main > header > div._1i0-u > div > div.rAUz7._3TbsN > span > div > div > ul > li:nth-child(3) > input[type=\"file\"]");         await inputHandle.uploadFile(path.resolve(__dirname, "..", "driver", "jquery.js"));         var selector = await this.page.waitForSelector("#app > div > div > div.MZIyP > div._3q4NP._1Iexl > span > div > span > div > div > div._2sNbV._3ySAH > span:nth-child(3) > div > div > span");         await this.page.keyboard.press("Enter");         var selector = await this.page.waitForSelector("div[title='Attach']", {visible: true});         await this.page.waitFor(500);         return await selector.click();     }

Here is the code in puppeteer
https://gist.github.com/parthibd/96b7b8d61636dce12b22db4b940c592c

Someone please port it to selenium.

@kevinkit @mukulhase Please look at the code

Actually, I just looked a little bit at the WAP given from Whatsapp and found that there is a"sendMedia" function in Javascript implemented.
It can be found with:
window.Store.Wap.sendMedia
I think this is they way to go, since it will automatically be updated and not depend on css or html paths and names.
However, I was not able to reverse engineer this function or its parameters, since I am far far away from the javascript world.

Hello,
Is there any built in functionality for sending any image or file to any contact, I have tried above methods but it throws an exception
Thanks in advance

Hi guys,
I did like @bansal95  suggested, I know this isn't the best way to do it but at least it works just fine although, I'm having a little problem with large files (+20 megas), getting the error of maximum Heap size of Java. Here is how I did it:
phone = 'XXXXXXXXX'
#This is the Header of the input where you look for the contact, its in portuguese
search_xpath = '//*[@title="Procurar ou começar uma nova conversa"]'

driver.driver.find_element_by_xpath(search_xpath).send_keys(phone + Keyss.ENTER)
#This part clicks on the attachment button
driver.driver.find_element_by_xpath('//*[@title="Anexar"]').click()
time.sleep(1)

#Gets the photo/video input, you can alter the last li[1] for other type of input
element = driver.driver.find_element_by_xpath('//*[@id="main"]/header/div[3]/div/div[2]/span/div/div/ul/li[1]/input')

#Make the input visible
driver.driver.execute_script("arguments[0].setAttribute('style', 'block')",element)

url = "http://pm1.narvii.com/6448/92e4dd26d8b6bf69e23c4eb9b417b9ea53bc25a1_00.jpg"
file_path = "/app"
filename = "galocego.jpg"
fullfilename = os.path.join(file_path, filename)
urllib.urlretrieve(url, fullfilename)
element. send_keys("/app/galocego.jpg")
time.sleep(2)

#Clicks on the send button
driver.driver.find_element_by_xpath('//*[@id="app"]/div/div/div[1]/div[2]/span/div/span/div/div/div[2]/span[2]/div/div').click()

I placed a text next to the image, but I'm not able to break the line, the \ n 'does not work, could someone help me?

Verifica se passou "\n" ou '\n' e não inclua espaço antes do "N".

esse espaço foi o tradutor que colocou ... desculpe ...

Como você está enviando? Se estiver inputando o texto dentro campo de legenda do html, tenta trocar o \n por , pois ali não é um input, e sim uma DIV com habilitação para edição de conteúdo!

era pra sair por < br >, dei o espaço aqui pois ao enviar o comentário ele sumiu rsrs

elem = driver.driver.find_element_by_class_name('_2S1VP')
time.sleep(2)
elem.send_keys(caption)
ele interpretou o  como se fosse uma string  "ola  mundo"

Removed comments due to language violation.

@wallysonn
elem = driver.driver.find_element_by_class_name ('_ 2S1VP')
time.sleep (2)
elem.send_keys (caption)
I am sending this way, if I put the  it interprets as 'hello'  'world'

@WilliamCampolina please format your code in the future

@kevinkit stop fresh

@wallysonn Excuse me, I do not know what that statement is supposed to mean. Please elaborate

@wallysonn Do you send images?

@WilliamCampolina  yes.

Do you send caption with image?

@WilliamCampolina yes. Submission with the function available right here in the API. I just made some adjustments.

@WilliamCampolina use this function: window.WAPI.sendImageFromDatabasePicBot

@wallysonn I'll take a look and try to use ... do you have a telegram?

A brief explanation to use this function window.WAPI.sendImageFromDatabasePicBot

DATABASEPICBOT is the name of a group that will be used as your image repository.
picId is the id of the image. This id is a word that you will enter in the caption of the image when it is sent to the group DATABASEPICBOT.
chatId is the recipient's id<EMAIL_ADDRESS>caption is the image caption.

There is a server in Discord where we talk about WhatsApp WEB API.

https://discord.gg/vwrKec6

@wallysonn new function -> https://github.com/mukulhase/WebWhatsapp-Wrapper/pull/300

Hey,
Here is the code for send media file(like image) just by convert file to base64 (**here is url for convert image to base64 https://www.base64-image.de/ **) and use this function<EMAIL_ADDRESS>"file base64 string", "test messsage", null, null);
https://gist.github.com/phpRajat/a6422922efae32914f4dbd1082f3f412

https://github.com/mukulhase/WebWhatsapp-Wrapper/issues/23#issuecomment-355776501


dev branch

Per request of @nsheff added a dev branch to the project, based on 045ae81. Deployments using .travis.yml have been updated as well for automation. Build/deploys are taking ~60 seconds. Follow Travis-CI here
DEV/Development Branch

http://dev.refgenomes.uvasomrc.io/
http://dev.refgenomes.databio.org/ [DNS required]
http://dev.refgenomes.uvadcos.io/ [DCOS preview - in testing]

MASTER/Production Branch

http://refgenomes.uvasomrc.io/
http://refgenomes.databio.org/
http://refgenomes.uvadcos.io/ [DCOS preview - in testing]

Merging Upstream:

Minor tweaks and changes can be done via merge.
New features / testing / UAT should be done via PRs.

To Do:

[ ] Update DNS for dev.refgenomes.databio.org point as CNAME to dev1.uvasomrc.io.
[ ] Continue testing of Traefik LB per #23 to determine move to DCOS for both branches. This includes Redis data migration, if required.

Proposal:  We typically use dev for pushing unpolished changes, so we should think differently for this rep. We use a new branch, 'sandbox', for temporary storage, untested changes, stuff we're doing locally.  When we're ready to deploy that to the dev server, we PR into dev. final release is the PR from dev to master.
The only thing about this is that I'm used to dev being like what I call 'sandbox' here, so maybe I've shot myself in the foot with these names... open to ideas/thoughts.

In other words, maybe the second 'developmental server' deploy should actually have been called something else ('staging'?) just for consistency with other projects?
No big deal here, just brainstorming.

If you're worried about changes inadvertently going into the test deployment, you could keep dev conceptually "dev" and make the test reployment something like deploy.

@vreuter has a good point -- master is easily (for my automated fingers) a branch I might accidentally push to, so an alt naming convention might be of help.
As for dev, staging, master levels, feel free to name it whatever you like -- I think 2 server-published branches is sufficient. (Remember when we had 3 levels for LOLAweb? It felt like too much.)

Ok I think we all agree on concept but not on name:
the dev branch should not have an associated test server
the test server should be on a different branch. We have 3 suggestions for name of that branch:

sandbox
deploy
staging

is there a community standard here?
the staging server would then be staging.refgenomes.databio.org (or deploy.refgenomes.databio.org or whatever we decide to name it). it should be named the same thing as the branch.
We will develop onto dev as normal. when ready to test, we PR to X, which deploys to x.refgenomes.databio.org.
What is X? Everyone vote. @michalstolarczyk

by my searches, staging seems to be the accepted name for this type of setup. http://guides.beanstalkapp.com/deployments/best-practices.html
the staging branch, and staging.URL are used to test a deployment before merging to master. So, staging has my vote.

I'm fine with staging

staging is good. And @nsheff there is no universal convention here -- different shops seem to have their standard and they stick to it. It makes sense to them, but might be very different next door.
Likewise, relying on master (Git) or latest (Docker) for the canonical / production version-branch is the way to go, or totally frowned upon.
If we don't yet have a staging branch here I will create one, launch that in DCOS, and set up automatic deployments.

@michalstolarczyk -- should I create staging based off of the dev branch you've been working on? Or from a fresh new branch off of master?

Let's create a fresh one from master

Okay, that's done. A clean staging branch has been created and pushed, with Travis snapped in correctly. One push has deployed automatically so I think we're all set.
The site has been loaded in DCOS, under these names:

http://staging.refgenomes.uvadcos.io
http://staging.refgenomes.databio.org

@nsheff could you please create a CNAME record staging.refgenomes.databio.org pointed to loadbalancer.uvadcos.io?

DNS is in place now, and the pieces of a working staging branch appear to be all set.

yep, appears to be working. thanks!


Add a pwm option to the RGBLED and Motor constructors

...along with the other necessary changes required, to allow them to optionally be used with non-PWM-capable pins.
IMHO this is the 'proper' way of implementing the change suggested in #301

[Current coverage][cc-pull] is 73.48%

Merging [#303][cc-pull] into [master][cc-base-branch] will increase coverage by +0.89%

File gpiozero/mixins.py (not in diff) was modified. more

Misses +9
Partials 0
Hits -9

@@             master       #303   diff @@
==========================================
  Files            28         28
  Lines          4154       4340   +186
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
+ Hits           3015       3189   +174
- Misses         1139       1151    +12
  Partials          0          0

Powered by Codecov. Last updated by 8f0ab67
[cc-base-branch]: https://codecov.io/gh/RPi-Distro/python-gpiozero/branch/master?src=pr
[cc-pull]: https://codecov.io/gh/RPi-Distro/python-gpiozero/pull/303?src=pr

Please merge #312 before merging this, and then I'll update this PR as appropriate.

#312 merged so this is now showing a conflict

PR now rebased and updated.
It may look like this PR is removing test_output_pwm_pulse_background and test_output_pwm_pulse_foreground, but in this morning's merge-fest they somehow got added twice (I guess I must have had slightly-different implementations of the same test function in two different PRs or something).

No prob - and yes, I think this probably the correct fix to #301 (though I still think #219 is a great idea too - I just don't have time to dig into it thoroughly right now).

Anyway, I'll merge this and we can consider #219 later when I'm back from picamera!

Thanks for merging! Now to rebase all my other branches... ;)


Set client reference in EnrichIntegrationFromRemoteConfigStrategy

Fixes #65

Coverage remained the same at 76.786% when pulling 49461660d2614cbf130cb788f458fd5e0cd1c996 on fix-client-reference into 409f49e33d6d2c2fbc7656625893951d5835730c on master.

@typerandom can you review please?  I also ran the express-stormpath test suite with this branch, and everything passes.

Looks good to me!

any movement on this?


Dont throw error for disabled camera

I have a camera which I power off at night by disabling the PoE. The tileboard throws an error 'Unable to fetch image', which is technically correct.
I would like to have a switch to not throw an error, but simply display some text that the camera is not available in the tile.

You can add ignoreErrors: true to CONFIG


Cleanup deps

remove unused dependencies
add ng2-modal to webpack dev and test for exclude in source-maps

There were the following issues with your Pull Request

Commit: 1d988f21dbc21cfed48aeffca4912154f8d6a90d
Your subject line is longer than 50 characters

Guidelines are available at https://github.com/fabric8io/fabric8-ui

This message was auto-generated by https://gitcop.com


Cluster topology not refreshed on MOVED redirect

Cluster topology not refreshed on MOVED redirect for node connection
RedisClusterNode node = redisClusterConnection.getPartitions().getPartitionBySlot(SlotHash.getSlot(ID));
        StatefulRedisConnection<String, String> nodeConnection = redisClusterConnection.getConnection(node.getNodeId());
        RedisAsyncCommands<String, String> commands =  nodeConnection.async();
        commands.setAutoFlushCommands(false);

...

with automatic refresh enabled:  ClusterTopologyRefreshOptions.builder().enablePeriodicRefresh(Duration.ofMinutes(10)).enableAllAdaptiveRefreshTriggers().build()
when the cluster keys distribution changes (e.g. relocating a key from one node to another), lettuce is not refreshed automatically:
 io.lettuce.core.RedisCommandExecutionException: MOVED 9670 ...

        <dependency>
            <groupId>io.lettuce</groupId>
            <artifactId>lettuce-core</artifactId>
            <version>5.0.4.RELEASE</version>
        </dependency>

manual invocation of io.lettuce.core.cluster.RedisClusterClient#reloadPartitions solves the issue

Shouldn't the cluster topology be refreshed automagically in this case?

A refresh task should be scheduled in that case. Can you enable debug logging for io.lettuce.core.cluster.ClusterTopologyRefreshScheduler to see what happens there? Logger io.lettuce.core.protocol will also show additional details but depending on the load this might be too much noise.

There seems to be no useful info in those logs :(
Tracing back the code on the io.lettuce.core.cluster.ClusterTopologyRefreshOptions.RefreshTrigger#MOVED_REDIRECT const we get to this point in the code which does a command instanceof ClusterCommand check but the actual type is AsyncCommand - I see no similar handling for AsyncCommand type

I missed the fact that you're operating directly on a node connection. Typically, Lettuce calculates slot hashes and dispatches commands through the cluster connection which uses ClusterDistributionChannelWriter. We use the topology to route the command to an appropriate cluster node that handles the slot hash.
The underlying assumption here is that commands are routed to the right host based on the command key (slot hash). When using node connections directly, we don't react to MOVED redirections at all as these are just plain connections without routing. We cannot tell whether MOVED happened because Redis Cluster was reconfigured or whether the key isn't handled by the cluster node at all.
That being said, we're doing the right thing by not issuing topology refresh. Direct interaction with cluster nodes comes with more power and requires the calling code to react to responses.

how to solves the issue, I find this bug in my project.


Allow to "freeze" gpio type state

1. Changing pin state
Today a gpio pin can be turned into another mode using for example let pin = pin.into_push_pull_output(); or let pin = pin.into_alternate(). This can also be done multiple times for example:
let pin = pin.into_floating_input(); // Configure as digital input
//use as input...

let mut pin = pin.into_push_pull_output(); // Reconfigure the same pin, now as an output
pin.set_low();

let pin = pin.into_analog(); // Reconfigure as analog input
// perform AD-reading...

This is of course very convenient.
2. Same pin, Multiple peripherals
Some analog peripherals like for example the comparators need their input pins to be set in analog mode. Since the pin is set to analog mode it should also be possible to perform AD-readings on it at the same time as the comparator is connected.
This may for example be useful for having near instant over current protection while still allowing regular AD-readings all on the same pin.
3. Peripherals
When setting up a peripheral such as the comparator, the input pins are typically provided by value, thus consuming the pin. This to ensure that no one else will change the mode of the pin.
The problem
Currently 1 and 3 works, but not 2. Changing peripherals to take a pin by reference and store the reference would prove quite cumbersome since the pin would have to live as long as the peripheral and not be moved etc.
Only having having the init function take a reference and then not storing it would not prevent the user from then changing pin mode after peripheral init.
Proposed solution
Add type parameter F to the pin types which may be one of the following types:
- pub struct $PXi<MODE> {
+ pub struct $PXi<MODE, F = IsNotFrozen> {
     _mode: PhantomData<MODE>,
+    _frozen_state: PhantomData<F>,
 }

```rust
/// Type state for a gpio pin frozen to its current mode
///
/// The into_alternate/analog/{x}_input/output can not be called on a pin with this state.
/// The pin is thus guaranteed to stay as this type as long as the program is running.
pub struct IsFrozen;

/// See [IsFrozen]
pub struct IsNotFrozen;

The type parameter default to IsNotFrozen so as to keep backwards compatibility and 1 from above works as before. However once the user knows they will want the pin to stay in a particular state for the rest of the program, let pin = pin.freeze(); may be called. Which returns the same type but with IsFrozen this disabling the into_alternate/analog/{x}_input/output methods.
This then allows peripherals init to take the pin by reference (assuming F=IsFrozen) and not having to hold on to it. (only done for some of the peripherals so far)

@AdinAck do you have any input on this?

I have also been thinking about this!
It's really quite unfortunate that references to ZSTs are not ZSTs themselves, otherwise I believe holding references would have been the correct solution, the lifetime troubles could certainly be worked out.
However, since we cannot do that without introducing significant overhead, this is a clever solution. I can't tell if it's complete though...
I believe that the notion that a peripheral shall be owned by one thing and one thing only is an invariance that should not be broken. Seeing as the goal of the HAL is to maintain a certain parity with the hardware, what if instead we change the HAL pin structs a bit to reflect the hardware? Clearly comparators have an additional special access to select pins.
So the pins could have channels:
struct PXi<Mode> {
    ch1: PXi1,
    ch2: PXi2,

That way, it can be used like so:
let pin = gpiox.pi.into_input_pull_up().split(); // `split()` will only be implemented for inputs

// i don't know either of these peripheral interfaces
let adc = p.ADC.constrain(pin.ch1);
let comp = p.COMP.constrain(pin.ch2);

Conversion methods (into_x) will not be available on the channels, so the pin is effectively frozen. The inverse of split() can be provided as recombine() (this is an idea I've been playing around with as a standard for all split peripherals):
let pin = pin.common.recombine((adc.reset_and_release().1, comp.reset_and_release().1)).into_push_pull_output();

pin.common is inspired by the PWM interface.

I'm still thinking about all this, so it's all in flux. I think this better adheres to the design patterns already present in the HAL, but maybe it's too complicated, let me know what you think. I am not against your proposal, it's certainly a step in the right direction nonetheless.

Example of how IsFrozen applies to other peripherals:
let gpiox = p.GPIOX.split();
let px1 = gpiox.px1.into_analog().freeze();
let px2 = gpiox.px2.into_floating_input().freeze();

let (dacx_ch1, ..) = p.DACX.constrain();
let dacx_ch1 = dacx_ch1.freeze(); // dac channel must be frozen for use with comp

let exti = p.EXTI.split();
let (comp1, ..) = p.COMP.split();
let comp1 = comp1.constrain(&dacx_ch1, &px1); // requires both sources are frozen
let comp1 = comp1.freeze(); // now even the comp itself is frozen for use with EXTI

exti.ch2.constrain(&px2).enable(); // requires `px2` is frozen
exti.ch23.constrain(&comp1).enable(); // requires `comp1` is frozen

This example also demonstrates an improved and more consistent EXTI interface.

There should also be a Frozen trait which can be added as a requirement to source traits.
Like for comparators:
pub trait PositiveInput<C>: Frozen {
    fn setup(&self, comp: &C);
}

So the pins could have channels: [...]

What about something like:
fn split<const N: usize>(self) -> [Channel<N>; N] {
    todo!()
}
fn recombine(..., channels: [Channel<N>; N]) -> ... {
    todo!()
}

The user is free to split into however many channels they want. The channels then remember how many siblings they are so that we can require them all when recombining

What about something like...

A fantastic idea! I will need time to think about this :)

Ok here's what I've come up with:
What we're dealing with here is a new way that peripherals interact with each other. In this case, EXTI, COMP, and ADC are observing GPIO. To facilitate this, consider:
struct Observed<P, const OBSERVERS: usize> {
    p: P,
}

A struct to hold peripherals which are to be observed.

struct ObservationToken<P> {
    _p: PhantomData<P>,
}

A struct to represent a registered observation of a peripheral.

trait Observable {
    fn observe<const N: usize>(self) -> (Observed<Self, N>, [ObservationToken<Self>; N]) {
        (
            Observed { p: self },
            core::array::from_fn(|| ObservationToken { _p: PhantomData }), // this may be introduce overhead, will have to investigate
        )
    }
}

A trait providing an interface to make peripherals observed.

Usage:
let (pin, [ob_exti, ob_comp, ob_adc]) = gpiox.pxi.into_analog().observe();
// pin type is `Observed<PXi<Analog>, 3>`
// ob_* type is `ObservationToken<PXi<Analog>>`

exti.source(ob_exti).enable();
comp.source(dac_ch1, ob_comp);
adc.constrain(Sequence { .., third: ob_adc }); // very pseudo

let (_, ob_exti) = exti.reset_and_release();
let (_, ob_comp) = comp.reset_and_release();
let (_, ob_adc) = adc.reset_and_release();

let pin = pin.release([ob_exti, ob_comp, ob_adc]);

pin.get_level(); // we can use the pin in software again

The key to my reasoning for this design is these peripheral interfaces only need to "lock" the observed peripheral configuration, and do not invoke any of its methods because the interaction is purely via hardware. Only software interfaces should borrow peripherals by reference.
So HAL interfaces will look like:
fn constrain<INP, INM>(rb: COMP1, inp: ObservationToken<INP>, inm: ObservationToken<INM>)
where
    INP: PositiveInput,
    INM: NegativeInput,
{ .. }

Since the HAL never uses the software methods (really it shouldn't anyways) the usage of ObservationToken explicitly shows the hardware relationship. (The name may be poor but of course, that can be worked out).
This whole design philosophy relies on the invariant fact that up to one instance of any peripheral type exists.

Still more thinking to be done, some holes to patch, please let me know your thoughts.

I made a quick test in godbolt and rust playground and I think the usage of core::array::from_fn does not add overhead.

let (pin, [ob_exti, ob_comp, ob_adc]) = gpiox.pxi.into_analog().observe();
// pin type is `Observed<PXi<Analog>, 3>`
// ob_* type is `ObservationToken<PXi<Analog>>`

exti.source(ob_exti).enable();
comp.source(dac_ch1, ob_comp);
adc.constrain(Sequence { .., third: ob_adc }); // very pseudo

Just trying to wrap my head around this :) Is pin here more or less the same as a frozen pin from my first proposal? So all pin.into_{x} disabled but the pin is otherwise the same as normal with pin.is_high etc available and adc readings possible, assuming the pin is in analog mode?
Or is it more locked down than that? If so, then what use do we even have for pin besides keeping track of the number of observers? Is this better than the observers themselves keeping track of how many siblings they are? Thus removing the need for the Observed it self.

let (_, ob_exti) = exti.reset_and_release();
let (_, ob_comp) = comp.reset_and_release();
let (_, ob_adc) = adc.reset_and_release();

let pin = pin.release([ob_exti, ob_comp, ob_adc]);

pin.get_level(); // we can use the pin in software again

What does "use the pin in software" mean? Was pin.is_high() disabled until now? How about software triggered adc readings, is that "software"? Or am I supposed to use ObservationToken even for software triggered adc readings?
Lots of questions... Just trying to wrap my head around what consequences something like this would result in. :)

Is pin here more or less the same as a frozen pin from my first proposal? So all pin.into_{x} disabled but the pin is otherwise the same as normal with pin.is_high etc available and adc readings possible, assuming the pin is in analog mode?

Kind of, since it's of type Observed<..>, we should probably use AsRef for convenience:
impl<P, const N: usize> AsRef<P> for Observed<P, N> {
    fn as_ref(&self) -> &P {
        self.p
    }
}

This is great because methods like is_high are available and all mutating functions set_high are not available (why should they be?).

How about software triggered adc readings, is that "software"? Or am I supposed to use ObservationToken even for software triggered adc readings?

A software trigger of the ADC would not be the same as calling set_high for example on a pin. An ADC conversion only mutates the ADC peripheral state, the ADC is just observing that pin. The HAL interface for the ADC being used on certain pins should only have an ObservationToken to the pin since the measurement does not require calling any pin methods, is_high, set_high, etc.
In conclusion, if I understand your questions correctly:

should pins be usable by software while observed? yes, immutably
should HAL interfaces for peripherals which use other peripherals but don't invoke their methods have access to those methods? no, they should have an ObservationToken

It could be argued that one should be able to mutate a peripheral while it is observed, this would be useful for testing, not production. I feel that additional interface is misleading and extraneous, but I could understand the desire for its presence.
Also, I share your concern for introducing this interface, it's a rather sizable change, I agree it is important to make sure this idea is absolutely the correct decision, so I appreciate the questions! :)

You know, adding an impl for AsMut is dead easy, might as well add it as well!

[...]I agree it is important to make sure this idea is absolutely the correct decision, so I appreciate the questions! :)

Thanks a lot for your input on this :)

Also, I share your concern for introducing this interface, it's a rather sizable change,[...]

Correct me if I am wrong, but a lot (perhaps not all but still, a lot) of this should be possible to do in a backwards compatible way by still allowing the owned(not splitted) peripheral/pin in places where a Observer or Observed are expected, right?

Hm, I'm not sure! Only one way to find out, I'll test it out and see what happens :)

Ah, yes. We can implement Into<ObservationToken<Self> for all peripherals, so old code will still work.

See #157 for an attempt at implementing that idea

Some random thoughts:
Side note, it would be quite interesting to see what could be done with a system like this for the rcc and its consumers. At the very least i suppose that would allow a safe way to change clock frequency once tokens from all consumer are collected without risk of forgetting any peripheral that might not like the clock settings to change.
However doing something like that well is likely not trivial, perhaps requiring something more fine grained? Would if the RTC is clocked by the LSE then changing other parts of the clock tree should not affect the RTC etc.
Side note to the Side note. Thera are probably a lot of interesting things that can be done to the rcc system more generally. Lots of weird hardware limitations with the different steps in the pll system having different max frequencies etc. Unless am completely misremembering I believe the max frequency for the ADC is 60MHz but only if you just use one of them, if you use more then I think just north of 50. The hrtim has a minimum input frequency of 100MHz. There are probably lots of more weird things that would be interesting to see if it would be possible to check for at compile time. Then there are different limitations depending on input voltage etc.
What if the user could use a const fn to generate a clock config that was checked at compile time, that config was then applied at runtime. Perhaps one could even have multiple configs in different constants and it would be completely safe to dynamicly change between them(assuming it would be possible to solve both things above).

Side note, it would be quite interesting to see what could be done with a system like this for the rcc and its consumers. At the very least i suppose that would allow a safe way to change clock frequency once tokens from all consumer are collected without risk of forgetting any peripheral that might not like the clock settings to change.

I have been thinking about this for many months and believe that it is the perfect opportunity to flex why Rust is so good for embedded.

However doing something like that well is likely not trivial, perhaps requiring something more fine grained?

I am working on a system that procedurally generates type-enforced peripheral access interfaces and have some examples where this works and stops the developer from forgetting to enable peripheral clocks before usage. gpio example.
I am very excited to begin reasoning about clock speeds in the type system.

What if the user could use a const fn to generate a clock config that was checked at compile time, that config was then applied at runtime.

This is something I have done in the past in stm32g0xx-hal:
const PLL_CFG: rcc::PllConfig = rcc::RawPllConfig {
    mux: rcc::PLLSrc::HSI, // 16MHz
    m: 1,                  // /1
    n: 16,                 // x16
    r: 4,                  // /4 = 64MHz
    q: Some(2),            // /2 = 128MHz
    p: None,
}
.validate();

This is working code using my fork of stm32g0xx-hal.

g0xx-hal stuff

Nice! I will take a look at that :)

gpio example

Very nice! Great to have that level of protection all the way down
How/does this interact with svd-files or does this require every peripheral to be manually specified?

How/does this interact with svd-files or does this require every peripheral to be manually specified?

No SVD, they are always riddled with errors from the vendor, which is why we patch them so much.
It is so much easier to just scroll through a datasheet and type in the register/field offsets.
Some brief examples:
#[block(
    base_addr = 0x4800_0000,
    entitlements = [super::super::rcc::ahb2enr::gpioaen::Enabled],
    auto_increment,
)]
pub mod gpioa {
    #[register(auto_increment)]
    mod moder {
        #[schema(width = 2, auto_increment)]
        mod mode {
            #[state]
            struct Input;
            #[state]
            struct Output;
            #[state]
            struct Alternate;
            #[state]
            struct Analog;
        }

        #[field_array(range = ..13, schema = mode, read, write, reset = Analog)]
        mod modeX {}

        #[field(schema = mode, read, write, reset = Alternate)]
        mod mode13 {}

        #[field(schema = mode, read, write, reset = Alternate)]
        mod mode14 {}

        #[field(schema = mode, read, write, reset = Alternate)]
        mod mode15 {}
    }

The beginning of the description for GPIOA.

#[block(
    base_addr = 0x4002_0c00,
    entitlements = [super::rcc::ahb1enr::cordicen::Enabled],
    auto_increment,
    erase_mod,
)]
mod cordic {
    #[register(auto_increment)]
    mod csr {
        #[field(width = 4, read, write, reset = Cos, auto_increment)]
        mod func {
            #[state(entitlements = [scale::N0])]
            struct Cos;

            #[state(entitlements = [scale::N0])]
            struct Sin;

            #[state(entitlements = [scale::N0])]
            struct ATan2;

            #[state(entitlements = [scale::N0])]
            struct Magnitude;

            #[state]
            struct ATan;

            #[state(entitlements = [scale::N1])]
            struct CosH;

            #[state(entitlements = [scale::N1])]
            struct SinH;

            #[state(entitlements = [scale::N1])]
            struct ATanH;

            #[state(entitlements = [scale::N1, scale::N2, scale::N3, scale::N4])]
            struct Ln;

            #[state(entitlements = [scale::N0, scale::N1, scale::N2])]
            struct Sqrt;
        }

The func field of CORDIC.

Remember all those crazy types and traits and structures that occupied 1200 lines of code to enforce the CORDIC's hardware invariances? Now they are described in 30 lines of code.
Reading the datasheet is trivial, and this macro statically validates a lot in case mistakes are made.
I'm worried my design of this system doesn't scale but I just keep implementing peripherals and adding things as needed. Hopefully eventually it will encapsulate everything.

How/does this interact with svd-files or does this require every peripheral to be manually specified?

No SVD, they are always riddled with errors from the vendor, which is why we patch them so much.

Yeah, cant say I disagree

It is so much easier to just scroll through a datasheet and type in the register/field offsets.
Some brief examples:
[...]
Remember all those crazy types and traits and structures that occupied 1200 lines of code to enforce the CORDIC's hardware invariances? Now they are described in 30 lines of code.

Yes :) Wow!

Reading the datasheet is trivial, and this macro statically validates a lot in case mistakes are made.

Very nice

I'm worried my design of this system doesn't scale but I just keep implementing peripherals and adding things as needed. Hopefully eventually it will encapsulate everything.

I think this might be related to https://github.com/stm32-rs/meta/issues/4 .

I think this might be related to stm32-rs/meta#4 .

Very interesting! I'll read this and see if there's anything I can contribute to the conversation, thanks!

I'm worried my design of this system doesn't scale but I just keep implementing peripherals and adding things as needed. Hopefully eventually it will encapsulate everything.

Thinking about scaling as in getting something like this to work on many families in the future. As is discussed in the linked issue, there are a lot of devices with a lot of peripherals... Do you think it would be possible and make sense to somehow get this to work with the pacs of today(lots of it which after all the patches of stm32-rs works quite good, yet without all the nice magic type safety things)? Would it even be possible to add the entitlement info and whatnot (sorry have not quite wrapped my head around it) to svd2rust's yaml format so this could be added in peripheral by peripheral while still making use of all the things we already have?

Would it even be possible to add the entitlement info and whatnot (sorry have not quite wrapped my head around it) to svd2rust's yaml format

This was my first approach before bailing and making proto-hal. It is certainly possible with a great deal of effort.
My motivation for creating proto-hal is selfish in nature. I want to use it and want it to work exactly how I say. Slowly grossly bandaiding onto the monster that is svd2rust sounds no fun! But that may very well be the best way to improve HALs in general. Just not for me.
So far implementing peripherals with the macro has been very easy and quick, so I'm not really worried about redoing work already done in other HALs/PACs, but maybe I'll run into issues soon.

One perhaps not great idea but at least low effort way would perhaps be if your pac types implemented From<CorrespondingStm32RsPacType>? Then the two pacs could be used side by side in case yours was missing a peripheral

Hm, yeah. Some adaptor between the two would be nice. I'll think on that, thanks!

This observation-thing feels like it could be useful for other hals and perhaps not only parts from stm. Would it make sense to put src/observation.rs into its own crate to reduce duplication and make it easier to make crates that work with different hals?

Would it make sense to put src/observation.rs into its own crate...

Yep! I already have it in proto-hal along with other structures I am messing around with for designing HALs in a standardized way.
It's in the stasis file. I moved on from the "observation" naming scheme because since the beginning we've known that's not the best name. For example if we consider the output level of a pin to not contribute to the state of that pin, then an ObservationToken would allow you to mutate the pin. It's a bad name. Which is why I moved on to Entitlements.
Peripherals are entitled to states. Obviously I am using this for far more complicated peripheral interface generation stuff in macros, but the rest of proto-hal is just for HALs in general and the "observation"/"entitlements" stuff is useful all the same.

The reason I created proto-hal in the first place was because I didn't think the maintainers of embedded-hal would be very open to changes, but if you feel otherwise, really that's the ideal place for entitlements.

I just migrated over most of the important design features to stasis.

Would it make sense to put src/observation.rs into its own crate...

Yep! I already have it in proto-hal along with other structures I am messing around with for designing HALs in a standardized way.
It's in the stasis file. I moved on from the "observation" naming scheme because since the beginning we've known that's not the best name. For example if we consider the output level of a pin to not contribute to the state of that pin, then an ObservationToken would allow you to mutate the pin. It's a bad name. Which is why I moved on to Entitlements.

Oh my bad, sorry I did not get that Entitlements was the same thing as ObservationToken :). Makes sense

Peripherals are entitled to states. Obviously I am using this for far more complicated peripheral interface generation stuff in macros, but the rest of proto-hal is just for HALs in general and the "observation"/"entitlements" stuff is useful all the same.
Ah, ok
I would be open to moving these structures to their own crate all by themselves if you really want. But I feel like it makes sense to keep them in proto-hal amongst the other HAL utilities.

Already seems to be quite broken out, no need to break it out further
The rough gist from what I have seen so far(which is not a lot) is:

proto-hal/proto-hal - Has some types and stuff like the entitlement system and other useful things for gpios etc.
proto-hal/macros - Has macros to generate a safe pac that uses the entitlement things
proto-hal/stm32/g4 - Uses the above to specify a safe pac for the G4 family, or something slightly below a hal?

Is that somewhat accurate?
Very interesting stuff :)

Is that somewhat accurate?

100% accurate!

Very interesting stuff :)

I agree! Thanks for all your help!