General Discussion

[DarkTl]

Yeap, works like it should. Nice.

Also, as you write core, try to separate your thoughts with empty lines, it's really hard to read when it's just one endless wall of script/lines.

So that's why those 16 random empty lines in GM - sex.rpy exist in the last push 
I dunno, it looks good in notepad++, with different colors and stuff.

[Xela]

I dunno, it looks good in notepad++, with different colors and stuff.

It's still not a bad idea to do that.

I am actually fishing for a new text editor to try and increase productivity. I've tried NP++ which is nice but I couldn't get all the stuff that I wanted in under 20 mins so I dropped it I've also tried Editra which I hated and Vim which was too weird and unintuitive.

I am presently trying out Atom which seems nice, intuitive and I could figure out everything that I need in under 10 mins, problem is that I went with a portable version which I expected to work from dropbox folder between desk/laptop according to docs but it did some weird thing where it did not transfer settings and kept increasing it's folder size till it was something like 2Gb, at which point it went into some sort of infinite recursions loop. Right now I am reinstalling a normal version to see if it can do any better cause it looks awesome and does everything I want except that it can't unfold all folded lines selected at once. The only other options I wanna try are ST3 and VS if Atom does the same thing when properly installed, otherwise I'll just stick with JEdit.

[DarkTl]

There are a few guides about np+ at the renpy lemma btw.

[Xela]

There are a few guides about np+ at the renpy lemma btw.

You're right, I didn't know that. It may be worth giving another shot if atom thing doesn't pan out.

[Xela]

But this does look awesome:


It even shows you what files you've edited but not pushed to git yet out of the box

[DarkTl]

Would be even better if there wouldn't be commits aka "git went berserk again" in repo, which are probably caused by dropbox+atom 
Pure git extensions always work for me, unless there is a super complex merging involved.
 

[Xela]

Would be even better if there wouldn't be commits aka "git went berserk again" in repo, which are probably caused by dropbox+atom 
Pure git extensions always work for me, unless there is a super complex merging involved.

Yeap, I use ge as well and atom came after those commits so it got nothing to do with that. They happen when git lock is not released as git or two git extensions are running at the same side on laptop and desktop. I try to check if that's the case but sometimes forget, which leads to issues.

[DarkTl]

I'm using external hdd with renpy+pytfall and all needed portable editors when it's too cold to take laptop outdoors, like right now.

I took a look at Atom, sadly they don't support systems older than win7 (not simply don't support, it just refuses to work), which will limit my options greatly since I work on very different systems from time to time. Unlike np++.

[DarkTl]

I have to say, I tried dark theme in np+, like your screenshots show. I just can't work with it, it totally distracts me 

[picobyte]

thanks for the pointers. I now seem to have something that does autobuy in 0.08 to 0.09 for me. It is intended to behave similar as previously. In essence some logic is stored in auto_buy_items dict early (after loading the items).

Edit:
 I think we may hot loop if we have almost no money and can buy nothing while we have some to buy amount still.

[Xela]

I took a quick glace at the code, you've changed code a lot so I can't tell if it does the same thing or not but it doesn't really have to as long as it is working. One thing that stood out is:

Code: [Select]

                count = self.inventory[selected_item] + 1 if self.eqslots[selected_item.slot] == selected_item else 0
which looks like it plainly sets count to 0 if not item is equipped.

Code: [Select]

                count = self.inventory[selected_item] + self.eqslots.values().count(selected_item)
I think this is a more sound solution, especially since a character can have more than one of the same rings equipped. We'd want to disable characters buying more than one of the same item... 3 is a good amount for rings and 5 is the max amount for consumables.

Problems with methods like this one is that they can be improved/made smarter almost indefinitely. It's really hard to say when to stop improving them... Is .08 secs presently required for a single call?

[DarkTl]

How weird... This is infinite loop:

    $ i = 1
    while i < randint(3, 5):
        $ i += 1
        call city_tavern_thugs_fight
       

And this works as expected:

    $ i = 1
    while i < randint(3, 5):
        call city_tavern_thugs_fight
        $ i += 1

[Xela]

I doubt it, you're prolly doing something weird to i in the label.

[DarkTl]

Indeed. I got used to the loop variable always being local in delphi 

[picobyte]

there are a few issues I overlooked, so more changes for the auto_buy(). Most important, I missed items for chars with 'free' status. There was also a hot-looping in case of little money.
After this performance wasn't as good as before, but a bit more hacks and now I get again somewhat nice figures, 0.08-ish.
I think if we really want performance, we should order and group process chars, but I'm not sure if there really is need for that in practice.
BTW I never seem to get scrolls for Casters. They are present in game/content/db/items_scrolls.json, but it seems they are not yet loaded? probably a known issue..