Lufuclad v19

Lufuclad v19

Added a new enemy to Lufuclad, and some animations since the last version posted here.

As for my normal projects, things are going slow but steady. Overall things are okay, though health is still a bit of a factor. I may put Aster on Steam soon, if only because there isn't really much reason not to.

Looked at a few different sprite artists as far as helping out with stuff, or for future collaborations. I really underestimated how difficult it would be to find artists that could actually do most of the stuff I'd want. I figured a trip to pixel joint would be all that it'd take, but it really is difficult to find people who have experience doing a game's worth of sprites, and wouldn't require any input.

Not much else to report on. Things are slow, life is too fast.

Lufuclad v11h

Download v11

Updates
- Added Dive move for dominant H. Press V to use. (currently only works on Slug)
- Added ability for H animations to have layers
- Slug H animation
- Misc changes

Notes
After using the H-move on an enemy, press C or up to thrust, and down or X to back out.

Lufuclad v7-H

Link to v7

Updates
-Worked on H animation code (poses work with each other.)
-Added Goblin enemy
-Added Goblin animation  (It can also re-use the slug's)

Lufuclad v5-H

I'll update this blog any time there's an H update, however everything else that isn't an H update will be posted here.
https://www.lufuclad.com/

Version 5

Updates
-H animation. (For now happens during knockdown)
-Beginnings of stamina system.
-Bunch of misc stuff.
-Various H animation changes.

Still figuring out how exactly stamina will work. Added the basics though. It will change a lot as other mechanics are added, such as parrying. It will also be easier to figure out once I have some enemies with more movement and attack options.

Lufuclad update 4

Link to v4

I added the ability to add your own color palette for the player. Colors can be added by adding more vertical columns to the file included in the game's folder.  (Which can currently be swapped using the 4 and 5 key).

Most of the updates this time have been behind the scenes stuff, such as making it so that the order of drawing can be controlled, along with a bunch of other random stuff. In the process of trying to improve collision stuff I broke it, so I'll have to fix that later.

As usual, ignore what appear to be bugs since at this point they are just things I didn't have time to address.

Updates:

-First step of house

-Basic enemy death

-Color swapping

-Change to zoom

Also, I did a bit of work on making a separate blog for the game. Later on I will use it to list upcoming features, do votes on stuff, etc.

Lufuclad update 3-H

After doing some logo attempts (I posted some of them on Twitter), I've decided to go with Lufuclad as the title. Just couldn't get Restengear to look good, even though it looks fine on paper.

Link to Version 3

This update is still working towards actual gameplay bit by bit. Like I said initially, every second update will have some H, even if it's something simple. In this case I did the basic grab, since it will tie into a few of the mechanics. It's one of the many "function" poses that will be in the game that every enemy will have, which is why it's simple. In the future it will probably have climax stages, though.

Also, whenever the update contains new H, I will add an H to the post title.

Updates

-Enemies can now do the "grab" animation that will lead into a lot of the animations

-Struggling was expanded on, though it's still temporary.

-Added basic blocking functionality

-Added temp knockdown frame for when HP is depleted.

-Hp 

-Attack collisions.

Also, I was a day late on this one. In the future I will shoot for sunday updates, so I'l try to work on the game mid-week rather than at the end. (I only got to work on the game for half of sunday, which is why it ended up late.)

Title

Which title should I use for the ongoing game?
Restengear
Lufuclad

https://strawpoll.com/hf9azefs

Ongoing update 2

Update - 2

-Programmed initial auto-mode for animations
-Added zoom.
-Did initial work for hit-numbers and damage.
-Started work on UI elements for future updates.

Most of the additions at this stage will be much different later on, so don't worry about feedback on them at this point. (For example escaping animations will be much different looking).
Things like the zoom function will be possible to toggle, and you will have more control over them.

I will probably be making a blog for this game like I did for my animations, since there may be polls, and I want it to be obvious when I did updates, have a place for versions, etc.

The way I'm rolling out updates is that there must be an update every 1-2 weeks. However there MUST be new H at least every 2 weeks. So for example in this case there was no new H, so next week will include new H in some form or another. Later on H can be every week, once more of the gamey stuff is already done.

Ongoing first update.

Update - 1

-Added prototype enemy with H animation.

-Programmed some of the H controls

-Added some sounds.

No game loop yet, but you can mess around and H the first enemy. 

This demo demonstrates what manual animation controls will be like, roughly.

Normally, animations will play automatically, with the player only having some control.

However, I plan on making it so that if the player initiates an animation where the protagonist is dominating the enemy, the player will  thrust manually. (though it will also be possible to set it to auto, for those who want it.)

I also plan on making it so you can play as any enemy, male or female. This will either be in the form of transformations, or simply as an extra mode. In this mode, you will have manual control over dominate animations.

For now, the controls are as follows once grabbed:

Down: Insert/thrust

Right: Initiate climax. (later this will have conditions or be based on stuff)

Up: Pull out.

Don't worry about bugs for now.

All animations will function this way, and some will have extra controls, depending on what the animation is. 

Collisions, tiles

The work on the onoing game was mostly tile and collision work.
You may have noticed that in the pose mockups, the ground was stretched. This is because larger enemies may need more space in order to position all entities involved. It also adds a few more options for small enemies as well, with the addition of depth

This also meant that I had to add a drop shadow, since otherwise platforming can look very "detached". Ended up being a little complicated since the collisons are tile based, and I had to make sure something so simple wasn't going to have a huge performence hit.

However the question now is how wide should the ground be, exactly. For now I'm sticking with the width in the top image, however I may change it later. The problem is that it can look a little weird once you get into floating platforms and such, and then you have to worry about the visual depth of tiles being above you.

I also spent a lot of time overhauling collisions in general. It will now be possible to have slopes of different sizes and shapes, which was not possible before. (It's also like 3X as fast, which is also good.)

Because I spent a lot of time working on the collisions (which is the same code used in all my current games), I may spend a couple extra days this week to get out the first  real version. Will more or less just be enemies spawning infinitely until you're defeated, since there aren't any other mechanics yet.

Once that version is done, that will mark the first real update, and then from that point they will follow the 1-2 week update schedule (where every update must be playable and contain H.)

Anyhow, that's all for now.

Pose system.

Currently figuring out how posing will work.

Like I've said before, the player will have unique animations with every enemy while naked.

However, while clothed the player will use generic poses across all monsters, as seen above.

Female enemies will also use these poses, so that male and female enemies can all H each other.

The hard part is figuring out which poses to use, since some poses offer more possibilities than others. For example, the first pose can be used horizontally or vertically, or flipped, to get different variations. As long as all the parts match, the sprite can be rotated and positioned through code, which means I only have to animate 1-3 poses per enemy.

So basically, I need to decide on some sort of system. For example, let's say the male and female pose in image 1 are "F-A" and "M-A".

F-A can be flipped vertically with M-A. 

Both variations can also be rotated 90 degrees

In total, there would be 4 variations.

However, depending how M-A is drawn, other poses can work in the same way. For example, the animal girl's above pose works in the same situations as F-A, despite being a different pose.

So...is this animal girl's F-A, F-A2, or F-B?

While it works in the same situations, it has possibilities that F-A's doesn't such as the face-sit pose seen with the goblin.

In other words, can F-A be anything so long as it works with the same male poses, OR, do I just have a wider range of poses in the map?

And also if there is variation, I will likely have to choose between male or female to have variation. If the male poses are always A-B-C and specific, then female poses can be anything as long as they each work with the male poses. Yet at the same time, the player will probably be more interested in having more variations for monsters, since they will be seeing the player's animations the most.

Collisions. Beat up a goblin.

Did the main work on attack collisions. Leads to some funny interactions when you dial the attack speed up to 11. 

No H yet but soon. Wanna make it so you can get hit and defeat the eney, then H.

http://www.mediafire.com/file/ky0yk8jgpl9cqkp/example.rar/file

Ignore weird inconsistencies in the controls, not really done with them yet.

Main thing was just getting the attacks programmed. Won't work on defending until after the first H is added, probably. Also will make it so knockback is effected by attack charge. Or at the very least damage will be. 

In the loop

Been working on main games for the most part. Not moved in completely but enough to work all the time.

Starting tomorrow I'm going to start working on the ongoing game consistently. (The plan in the beginning is around 2 days per week, main game for the rest.) Then a new version will be uploaded every 1-2 weeks.

Tomorrow I'll animate the first enemy and an H animation so that the first real update has some content, and H content can be added as game mechanics are worked on. In the beginning it will be little more than enemies spawning that you can fight.

I'm still not entirely sure what I want to do for combat. I keep flip flopping between feeling like single/double attacks with blocking and parrying are enough, and feeling like it would be dull pretty quick. With boring attacks, the game would have to be driven by the desire for loot, but the question is if that's worth sacrificing fun combat for.

I've considered a few options;

1. Say fuck it and just have more moves and animations. Just have clothing and weapons added less often but make them all high fps.

2. Switch to something like martial arts, and have faster, more creative combat and moves. Have the attack swooshes change based on "style", which would take the place of weapons.

3. Have classes of outfits with entirely different move-sets. Each class can only use it's own moves. Changing your outfit would essentially be like changing the game you're playing, and prevent committing to one, however this would make the looter style more difficult unless outfits break, or some other design cheat is used (If one class has the double swing, and another class has a shit ton of martial arts moves, people probably wouldnt ever want to use the more boring one).

4. Stick to the double hit attack, and just focus on adding simple weapons and clothing that dont add much, but have a lot of them, driving the looter/rogue-lite nature of the game.

5. Abandon the notion of looter outfits almost entirely, and have a shit ton of moves. Outfits could be limited to non-combat actions (For example if you equip a bathing suit, you only have a kick, etc)
Trouble here is choosing a main outfit. (Or 1-3, if there are at least a couple.)

Regardless, I'll go forward with the basic attack as it is, since the main goal right now is to get the H train rolling.

Attack stuff

Moved in to the new place,

I have my desk set up, so I'm back to work.

Was messing with a new weapon today, and seeing what could be done with the swoosh effect in code.

If it's slow, It's possible that elements like the speed of the swoosh and it's coded movement could be tied to a stat or skill.

Top: fast swoosh.

Middle: Slow swoosh with partial X movement

Bottom: Slow swoosh with extreme X movement.

(Note, the player movement is the same in each, only the swoosh effect is different)

Only problem with making it a stat is that it can't really be applied to every weapon to the same effect. For example in this animation, the second swing can't move forward, otherwise it looks weird. Instead it has to move backwards.

This can be fixed somewhat by giving the swoosh an offset , however this would be a bit difficult to make automatic, since the offset depends on the speed, and the size of the actual swoosh effect.

I probably won't utilize it as a stat. Instead I'll probably just settle for using it on certain weapons to make them more distinct from one another, and to add a bit of smoothness to normal animations, like in the second image.

The speed of the swing could also technically be affected by a stat or modifier, since the slower the animation, the longer it stays out and is active. Though being out longer also means that it doesn't hit in front of you as fast. Maybe it could be something like stances you can switch between. (Not visual in the idle though, since that would be a lot of work.)

Anyhow, will get back to work on main games tomorrow.

Next time I work on the ongoing game I'll be working on the first enemy.

Ongoing game world stuff.

One day till internet..forgot about phone data tethering so using that now.

Anyhow.

Been thinking about how the world will work in the ongoing game. Before a lot of the randomized rogue-lite stuff is added, I think it's important to have a world that is dynamic and changes in interesting ways to begin with.

Initially I figured it would boil down to things like

-There are orcs
-There are bug enemies
-There are trees
-Orcs cut down trees
-Bugs lay eggs in trees, so attack orcs.
etc

Because the game will not be a huge single screen, it will more likely be more akin to a boardgame with spaces. Each entity is like a piece that moves each turn (every time you sleep). So for example when the day begins, if orcs and bugs are on the same space, highlighting the space would show that they are fighting. Upon entering the space yourself, the game would read what pieces are in the space (be they resources, or enemies), place them in the screen based on what they're doing, and then the player's actions dictate the outcome of that action.

So for example if a space with orcs says "cutting down a tree", if the player does nothing, the next day this action will complete. If there's another entity that conflicts with this, it may not. Basically, every "piece" would be more like a group, and they would have very specific roles.

Then I started thinking about individual interactions. For example, lets say there's a large monster you can't beat. If you take away 25% HP, what happens? Does it just come back the next day? Instead, I think it would be better if the game keeps track. Monster is hungry > seeks out food. Monster is low HP > avoids other entities. This would make it a bit easier to have dynamic interactions that don't rely on a very specific rock-paper-scissors setup. For example, orcs may have a higher chance of being drawn to trees, but how much can vary. This would make dynamic interactions easier because behavior would still be possible to learn, yet the chaos caused by individual variance would prevent a status quo from going on forever. 5 Orcs may go to the same tree tile, but 1 of them may prefer lakes, so it goes a different way.

The other advantage is that the player could drive interactions between entities. Entities could be made passive by giving them items and befriending them, befriended entities could fight or befriend each other (or fuc). Whether the player fights everything or tries to befriend everything, the movement and introduction of new entities should throw a wrench into any plan. In the background entities will always be killing each other, moving, etc, and the player cant be everywhere at once.

Keeping track of stats should be fairly easy, since every time an entity is created it would be assigned a number (which other entities use to refer to it). An entity's stats would then just be lists; for example love would be a list of 6 values if there are 6 entities.

5
10
3
12
5
2

Where the index is the entity number, and the value is the value of the stat. An interaction would go something like:

entity 0 see's entity 1 (decide on action)
entity 1 is fighting (entity 6)
love stat 1 is (5) love stat 6 is (2)
attack (entity 1)

There would be a lot more calculating to do when deciding what an entity does in a turn (since every entity has to do stuff), however because everything would only happen when you sleep, it could be done without worrying about the game being slowed down to a crawl.

Anyhow, enough babbling for now.

Control test 2

Second control test testing double swing.
Test 2

In general, if something looks wonky, you can assume it wont be that way in the actual game.

Speed would change based on the weapon, but there would also be ways of speeding up attacks with abilities or items since it's done in code.

Still not sure which I'll go with between this and the single swing. Haven't animated jumping variation yet. Also made it so blocking is faster when done during an attack so that parrying and the like will be possible.


Anyhow, will be moving in a day or two now. Will be glad to have the whole thing over with.

Control test

There's no gameplay yet, but because I said I'd update the game before it's in a "complete" form, I figure I may as well let you guys test the controls as they progress.

The control test can be downloaded here

I ended up going back to a single swing attack, added blocking, as well as a back and forward dash.

I'm still thinking about what the default controls will be, since there will also be

- Spells

- Picking up and throwing objects.

I could technically do away with the back dash entirely if I feel like it's a waste of a button. Forward dashing could technically fill all the same roles, although double-tap dashing back and then attacking forward would be more difficult than backdashing and attacking.

Alternatively, the back dash could be done by pressing down + a direction, and blocking could ignore facing direction, but if anything I think that might feel off.

Life stuff

Medical procedure went okay so health is better for now.

Will be moving in a few days. Once I've moved in to the new place I'll go back to working on my current main project, with the ongoing one on the side. In the past few days I've been doing stuff here and there for the ongoing game between moving stuff since it's mostly quick and easy stuff, in the beginning.

Attack frames

Had the urge to work on the attack animation. There was something I wanted to try, and while I'm not fully recovered yet, working is a lot easier than packing, for now.

Anyhow, the other day I posted this attack animation that I made for the ongoing game. Basically it would be used for every weapon, with different weapons being drawn over the frames, and different speeds being used for different types.

Problem is it's a lot of frames (9, not counting the idle frame). Because I have to do a sprite for every set of clothing, it's best to limit the number of frames. I also started to think that it might be a bit boring to just have a single hit attack.

So I tried animating an alternative mockup, with the goal of #1 limiting the frames, and 2# making it a multi hit that could loop.

I managed to get it down to 6 frames, where the actual animation would be done in code, and frames are re-used. The weapon animation itself would then be more frames than the base animation. 

Depending on the weapon, the swing can also be slightly different, using the same frames.

I may also add other attack frames that can be used to for special attacks. I could probably get away with doing 1-2 frame attacks that use the attack animation's startup and ending frames to smooth them out.

Anyhow, that's all for now.

This month

Some status updates.

Had a medical  procedure done at the beginning of this month that took me out of commission. If you've tried to contact me in that time and I haven't responded, I apologize. I'll be going back over messages and such. 

I'll be moving near the end of this month, so once I'm able to move around more (hopefully in a few days), most of my time is probably going to be taken up with packing, so it's unlikely any work is going to get done this month.

FetchApp stopped accepting my (still functional) credit card for some reason, so the games can't be purchased on my site at the moment. I'll be contacting my bank to see what's up and get that sorted out soon.

Stuff

Sorry that I haven't shown much lately. Looking at apartments, houses, doing other misc stuff, packing.

I'll program an enemy and do an H animation for the ongoing game soon. So far I've been doing some stuff here and there, but I need to keep in mind that the point of this is to update it regularly, and make it playable, even in the early stages. Initially I'll probably focus on adding content, and it will be more of a "playground" with H and stuff to interact with, as the real gameplay mechanics are slowly added. 

Metagame, stats.

First off, if I didn't respond to your comment, don't worry; I read all the comments, and consider those about mechanics.

Anyhow.

One of the biggest roadblocks in deciding on how the metagame will work is the conflict between the desire to make a Roguelite (permadeath, highly randomized, short play sessions), combined with the satisfaction of casual progression of Harvest Moon, and have H content which isn't overtly risky to experience.

My current plan is to have multiple concurrent runs that can go on at once, in the form of different worlds that are linked to each other.

Starting world

Essentially, you would begin the game in a fairly casual world. Not all the content of the game would be available here, and while it would be possible to be defeated, it would not be possible to "lose". H could be experienced casually. The farming element would probably also be more pronounced.

In this world, you would find seeds which could be planted to create "standard" worlds.

Standard world

Standard worlds would be randomized, and could contain most of the content of the game. Some elements would be luck based, and it would be possible to "lose" here. While these would be individual "runs" that could be won or lost, the purpose of them would be up to the player.

For example, if the player is currently doing a run in one world to "defeat the cave demon", they may create a new world with the sole intention of finding an item that will make it easier to defeat the cave demon, without risking the other "run". Some items could be transferred between runs, meaning that difficulty could be controlled somewhat if the player is having a hard time.

"Losing" would be possible, but would not come in the form of literal gameovers. Losing to the Cave Demon might severely limit the player's combat capabilities, or change them. So while it will have been "lost" as a run to defeat the cave demon, it can still be used to experience other content. Most enemies would probably not limit the players capabilities, and would simply set them back in resources. Getting to a point where you are at the mercy of the world's situation yet can't get the resources you need to get out of it would be the closest thing to a gameover, and at this point the player could either abandon the world, or do another run in the hopes that they will get resources to send over. (For example, losing to an enemy might curse you, and you're unable to undo the curse while cursed, yet another run may yield the anti curse item.)

Content you experience in standard worlds would be added to the starting world, albeit without the rewards. That way it can be experienced on a more casual level.

Special worlds

Other worlds could be one-off concepts. For example if I feel like doing a linear scenario, it might be done this way. Or, special worlds might be standard worlds with modifiers that change the overall nature of the run. For example one world might have the modifier of all female enemies, or the inability to use magic, but have stronger melee, etc.

There's also the possibility of making "active" worlds, that progress while you're away. Might lead to a type of gameplay that's more about "fixing today's problems" as opposed to actively playing. These runs might be used to set up farms that yield resources on a more consistent basis, but would become more about managing them with risk/reward, compared to the casual world which would only be low level items.

Stats

Some hud concepts I was messing with.

One of the things I've been thinking about is whether to use hearts or not.

The Binding of Isaac makes amazing use of hearts as a resource and risk/reward gameplay. However, the downside is that they don't scale with large amounts of health/ leveling up as well as a number represented by a bar.

One of the solutions I've considered is to have a sort of incremental health system using hearts.

Imagine that you have only one heart, and each heart can contain four quarters.

If you have 100 HP, and get hit by an attack that does 30 damage, it would round up to half a heart, and take away 50hp.

Essentially, there would be two stats. You're actual HP, and the number of hearts, which determines the increments of damage you can sustain. As stats, it would probably be something like HP/endurance.

This way, HP could level up, but you could still do resource management where some events cost you a heart container.

Of course, the main problem with this is that it's not exactly very intuitive for the player. 

Anyhow, that's all the rambling for now.

Deciding on shared poses

In the ongoing game, there will be two main types of animations:

Nude animations:

These animations would not have clothing variations, and only happen when nude. The player's pose and animation would be detailed and unique. Every enemy would have at least one of these.

Shared/generic animations:

The player's pose would be one of two generic, short animations. The poses can be flipped or rotated in order to fit the pose of the enemy. Because these animations would all use the same player part, every outfit would have these two poses, and thus would show up in all generic animations that use them.

Right now I'm trying to decide on those two poses. So far I've determined that the one in the top right is fairly practical given how much it can be rotated. It could be used for most generic sex.

The other pose would need to be used for things like groping, or enemies removing clothing, so it's a bit more difficult to decide on. These are some of my experiments with various poses.

Run animation, clothing layers.

More or less settled in to the new place.

I Had a week or so where I had to stop working. The same day I took some pills prescribed by a docter for something else, I had what felt like weird circulation problems. Turns out it was a muscle problem due to the hard floors in the new place, of all things.

So with that, I'm back to work again.

As far as the on-going game is concerned, I've mostly been working on some of the stuff that will be shared with other games. That includes the dialogue system, the animation/sound editor, and a couple other things.

I've also been messing with the run animation here and there, since it's one of the most important things to get right before doing clothing. Trying to decide how I want the head movement to be.

I'm also still trying to decide how I want to handle clothing layering. My initial plan was that clothing would come in the form of entire outfits, as opposed to individual pieces. This means that an alternate outfit sprite would include the body itself, as opposed to layering individual clothing sprites over a nude body.

One of the advantages to this would be that the clothing would not need to "fit" the body, and the body could be modified to fit the clothing. For example, if the character wears a dress, the stride of the running animation could be modified to be be a bit more dainty, or allow for whatever the clothing is, like this.

In either case, you're risking rework later on. If clothing changes the body, then if you want to change the face, you need to change it in every outfit. However, if you want to change something about the body, you risk it not fitting existing outfits.

If clothing includes the body, you could also have the style of animations be entirely different. For example if you have a more "seductive" outfit, then a crouch animation could be a lewd kneel as opposed to a "combat ready" stance of knight armor. Whereas if clothing is a separate layer, then modding is also more doable, since you could modify the player sprite and still have all the clothing fit. The middle-ground would be that there are base sprites for different things (seductive, combat, normal, etc), however this would still lock you down to specific templates, and mixing certain kinds of clothing would be more work unless they are also locked by type.

Not sure yet. I'll probably do the base sprites, and then I'll probably decide once I've tested out an outfit or two.

Moved into new place

Moved into my new place. Still settling in but I'm back to working.

Right now I'm programming a text engine for use in the ongoing game and others.
Basically I want all dialogue be stored in external .txt files, which are then parsed in-game.
That way the game can be easily translated, as well as modded in some ways, depending on the game (since in-game functions can also be parsed through the text).

In general, it's just easier to write something like this,

1
Looks like a trapdoor.
If I had the key, I might be able to open it.

It should be somewhere on this floor. 

As opposed to this

name[0] = "Girl"
message[0] = "Looks like a trapdoor."+"\n"+"If I had the key, I might be able to open it."
name[1] = "Girl"
message[1] = "It should be somewhere on this floor."

I'm still trying to figure out how I want everything to be formatted. For example, multiple scenes could be contained within one txt file, or different npcs and any branching dialogue could be separated into different files. Either way has situations were it might be difficult to keep track of, over time.

I also have to decide how certain things will look when writing. For example I need to decide which symbols will be used to denote certain functions;

# denotes that a number can be entered.

#   Use name associated with number until another name is used.
#> Put portrait image for corresponding name on the right.
#< Put portrait image for corresponding name on the left.

[p]#   Choose portrait image for the character who is speaking.
[d]#    Dialogue number.
[d>]#    Go to corresponding dialogue.
[f]#    Set flag to true.
[f?]#    Check if flag is true.
[e]#    Call event.

An example of an interaction would look something like this, (Assuming you use portraits and stuff, otherwise it would look like the one above.)


///////////////////////////////////////////////////

1<
2>
[d]0
[f]0  

1
[p]0
I'm here to buy something. 

2
[p]20
Do you have a membership card?
If you don't have one then you can't shop here. 

[f?]10
[d>]1
[d>]2 

///////////////////////////////////////////////////

[d]1
1
[p]1
Yes, I have it. It took a lot of work to get it. 

2
[p]21
Then take a look around.
[e]10

////////////////////////////////////////////////////////

[d]2
1
No I don't. 

2
That's a shame.
;

That said, I haven't really decided for sure yet what all the functions should be.
I won't be using all of them in every game.

Anyhow, that's all for now.