Author Topic: General Discussion  (Read 3789055 times)

0 Members and 8 Guests are viewing this topic.

Offline rudistoned

  • Full Member
  • ***
  • Posts: 229
Re: General Discussion
« Reply #795 on: June 23, 2013, 12:13:46 PM »
loading traits from several character files some pseudo traits could be duplicated, so make sure to use warnings.
This will definitely happen. At the very least, the result will be that we'll have two characters with a shared trait that gives different stat boni. Less than nice.

Offline DarkTl

  • Hero Member
  • *****
  • Posts: 4737
Re: General Discussion
« Reply #796 on: June 23, 2013, 01:02:05 PM »
Yup. That's why I wound prefer to use another, pseudo type of traits, that exclusive for the character or for the whole pack, but means nothing for other parts of the game.

Offline rudistoned

  • Full Member
  • ***
  • Posts: 229
Re: General Discussion
« Reply #797 on: June 23, 2013, 01:16:28 PM »
We would still get this situation. The only benefit to the pseudo-trait approach is that we have a guarantee that nothing will break due to two traits with the same name.
How about this solution: The last trait loaded wins. We allow only one trait with a given name. If the game loads another trait with said name, the new trait overwrites the old trait, meaning that all characters carrying this trait end up with the stat bonuses of the new trait. This would encourage character creators to only give traits to their characters that no other character would have.

Offline DarkTl

  • Hero Member
  • *****
  • Posts: 4737
Re: General Discussion
« Reply #798 on: June 23, 2013, 01:34:09 PM »
When the game loads characters and their pseudo traits, it could mark them respectively. Or if it's too difficult to code, pack makers could do it. Since pseudo traits have nothing to do with real ones, they could use a slightly different id system.
In the case of Konan it could be something like
Quote
   <ptrait
      name="Paper Jutsu"
      character_id="Konan"
      desc="Bla-bla-bla">
« Last Edit: June 23, 2013, 02:00:25 PM by DarkTl »

Offline rudistoned

  • Full Member
  • ***
  • Posts: 229
Re: General Discussion
« Reply #799 on: June 23, 2013, 02:06:53 PM »
I'm not worried about the implementation. It's not difficult to have two objects with the same name. I'm worried about the players, who will see several traits with the same name that give different stats bonuses. That's confusing.

Offline DarkTl

  • Hero Member
  • *****
  • Posts: 4737
Re: General Discussion
« Reply #800 on: June 23, 2013, 02:25:32 PM »
If pseudo traits will be strictly attached to their characters with character_id field, it won't be a problem, unless you have two different characters with identical names and traits (and it's a strange situation). They don't have to be global, so they shoudn't even exist outside of the one character's data.

Pardon my pseudographics:
/--Konan--------------------------------/
/                   Trait name                 /
/------------------------------------------/

It's true that there might be several traits with the same name that give different stats bonuses. If you think it will be confusing, we could call them somehow else, like perks or something, and make a separate interface for them.
« Last Edit: June 23, 2013, 02:38:22 PM by DarkTl »

Offline Xela

  • Global Moderator
  • *****
  • Posts: 6893
  • "It's like hunting cows"
Re: General Discussion
« Reply #801 on: June 23, 2013, 04:04:22 PM »
Fecking took me 3 hours to track down error in girls assign screen (caused once again by Matt's refactoring). When the hell are we gonna stop messing with code that already works?
Like what we're doing?

Offline DarkTl

  • Hero Member
  • *****
  • Posts: 4737
Re: General Discussion
« Reply #802 on: June 24, 2013, 12:11:21 PM »
If you mean my idea too, then if we eventually will use pseudo traits for decorating the game, they defenitely should have nothing to do with normal traits system, to not mess with it under any circumstances at least. Let's regard them as extended description, not real traits.

Offline Xela

  • Global Moderator
  • *****
  • Posts: 6893
  • "It's like hunting cows"
Re: General Discussion
« Reply #803 on: June 24, 2013, 02:41:07 PM »
If you mean my idea too, then if we eventually will use pseudo traits for decorating the game, they defenitely should have nothing to do with normal traits system, to not mess with it under any circumstances at least. Let's regard them as extended description, not real traits.

No m8, I didn't mean the traits. Just got really pissed off yesterday.
Like what we're doing?

Offline rudistoned

  • Full Member
  • ***
  • Posts: 229
Re: General Discussion
« Reply #804 on: June 24, 2013, 03:30:59 PM »
Sounds like a terrible bug. What was wrong?

Offline Xela

  • Global Moderator
  • *****
  • Posts: 6893
  • "It's like hunting cows"
Re: General Discussion
« Reply #805 on: June 24, 2013, 04:53:39 PM »
Sounds like a terrible bug. What was wrong?

Was actually a very small issue that took a long time to trace.

Since my original code was working flawlessly I assumed that Matt tested the screen after he applied his changes ( like 3 or 4 weeks ago, that did not add a single thing, just made the code look slightly better/more professional).

So assuming that everything works, I've added what was needed to the code and went testing it, finding that it doesn't work as intended and assuming that fault was with the code just added, I tried rewriting it over and over again. Nothing worked so I reverted back code that was there before I made the changes and realized that it did not work either (or worked correctly with one brothel only), but even then I couldn't understand what the hell was wrong because everything seemed like it should have been working just fine so I've started to doubt that it was working before Matt got there... It took me some time to confirm that my original code did work and in the end I figured out the problem, fixed it and added new code but the trouble is that what should have taken 5 - 10 minutes, took 3 - 4 hours.

Another thing that pissed me off that it's not the first time this has happened, Matt comes on, changes the very core of how we handle access to data in the game, fixes just the errors that throw Error messages and disappears while I have to deal with new bugs that are very hard to catch and gotta get used to new code and all that not to fix actual errors (since the original code was working at all places to begin with).



PS: You've actually added realistic improvements to the game (Event, Calendar, Tags) and when you change something in working code, we discuss it first and you snipe out all new bugs that come with it. Matt is still a 0 in department of adding new stuff to the game (although I am really thankful for git/sf).

===============================================
PS2: We should set some guidelines on how to proceed when one of us wants to rewrite code that's already there. As far as I am concerned, any additions to the game should just be added without any talk and all new game elements can be written in any coding style/paradigm but when we're talking about rewriting code just for the sake of better code cosmetics, we should discuss what/why/when/who first.
« Last Edit: June 24, 2013, 05:21:32 PM by Xela »
Like what we're doing?

Offline rudistoned

  • Full Member
  • ***
  • Posts: 229
Re: General Discussion
« Reply #806 on: June 24, 2013, 06:46:01 PM »
We should set some guidelines on how to proceed when one of us wants to rewrite code that's already there. As far as I am concerned, any additions to the game should just be added without any talk and all new game elements can be written in any coding style/paradigm but when we're talking about rewriting code just for the sake of better code cosmetics, we should discuss what/why/when/who first.
Fine with me.


Thank you for the explanation :-)

Offline Xela

  • Global Moderator
  • *****
  • Posts: 6893
  • "It's like hunting cows"
Re: General Discussion
« Reply #807 on: June 25, 2013, 04:33:17 PM »
Fine with me.


Thank you for the explanation :-)

====
BTW: The problem came from using a variable set in label's while loop to iterate in screens GUI (brothel is this case). Bad idea and we should never do that again :)
« Last Edit: June 26, 2013, 04:17:29 AM by Xela »
Like what we're doing?

Offline rudistoned

  • Full Member
  • ***
  • Posts: 229
Re: General Discussion
« Reply #808 on: June 26, 2013, 05:59:03 AM »
I'm afraid I have no idea what you are talking about  :(

If you want to, you could get the offending lines of code from the repository history and post them in the code review thread. I just looked at the history of the girl assign screen, but I could find nothing that seemed to match your description, probably because I don't understand what you mean.

Anyway, the important thing is that the bug is squashed  :)

BTW, I made good progress on the image tagging tool today. Since we decided to have uncategorized tags, I have to adapt the tool to accept those again. I did that today, and so far I have not been able to find bugs beyond those I already fixed. Tagging single images works. Tagging multiple images should probably also work, but I had no time to test it so far. Now its time to decide how the XMP tags will get imported into the game.
 
« Last Edit: June 26, 2013, 06:06:04 AM by rudistoned »

Offline Xela

  • Global Moderator
  • *****
  • Posts: 6893
  • "It's like hunting cows"
Re: General Discussion
« Reply #809 on: June 26, 2013, 06:49:32 AM »
If you want to, you could get the offending lines of code from the repository history and post them in the code review thread. I just looked at the history of the girl assign screen, but I could find nothing that seemed to match your description, probably because I don't understand what you mean.

Then you can understand the problem I've had :) There was nothing wrong with Matt's code from the Python perspective.

As you prolly have figured out by now, game is coded this way:

1) All logical game elements are coded in pure python. We access, display and change those in RenPy labels.

2) User interactions:

- We jump to a RenPy 'label' (labels are RenPy's way of running the game, instead of the usual main game loop you'd expect to find in Hentai Sims, we simply jump labels until we run out of them (we can obviously keep jumping to the same label any amount of times))
- In that label, we set up background and call screens (screens are coded in RenPy's screen language), at the same time we lock game's flow in a while loop.
There is a number of things that are not smart to include in screens, mainly because screens are being refreshed on all user interactions, once every 20 secs (If I recall correctly) or even many times per second if game requires them to. Another thing is that certain functions (like action calls from buttons) are not searching for variables on the same namespace as the screen first (very unusual for Python).

Problem was here:
Code: [Select]
                        for brtl in hero.brothels:
                            if brtl.highlighted:
                                $imgType = im.Scale
                            else:
                                $imgType = lambda *args: im.Sepia(im.Scale(*args))
                            vbox:
                                null height 20
                                text(u'{size=-10}%s' % brtl.name) align(0.5,0.5)
                                use rtt_lightbutton(img = imgType(brtl.img, 240, 150), return_value = ['brothel', brtl], tooltip = 'Send %s off to work in %s and choose from available actions.' % (chr.name, brtl.name))

In precious revision brothel was used to iterate instead of brtl
Code: [Select]
for brothel in hero.brothels: and at the same time we also had brothel variable in the label and while loop namespaces:

Code: [Select]
label girl_assign:
    scene bg wood
    hide screen girlProfile
    show screen pyt_girl_assign

    python:
       
        if isinstance(chr.location, Brothel):
            brothel = chr.location
            brothel.highlighted = True
            brothel_selected = True
        else:
            brothel = None
            brothel_selected = False

        while True:
            result = ui.interact()

            if result[0] == 'brothel':
                for brothel in hero.brothels:
                    brothel.highlighted = False

                brothel = result[1]
                brothel.highlighted = True
                brothel_selected = True

so this bit of old code:
Code: [Select]
return_value = ['brothel', brothel] didn't actually return a brothel that came from iterating over hero.brothels in the screen (something any Python coder would expect, it actually works exactly like you'd expect something in Python to work since rtt_lightbutton itself is defined on the same namespace as label (it is in fact for all intent and purposes a separate screen itself), but it is still a bit confusing) but instead returned whatever brothel variable was set to in the label. As you can imagine, this is in no way a problem with one brothel but a rather nasty issue with multiple brothels that doesn't throw an Error making it very hard to catch.

In any case this is what I believe was wrong with the code and in the end it's like you've said:

Anyway, the important thing is that the bug is squashed  :)


BTW, I made good progress on the image tagging tool today. Since we decided to have uncategorized tags, I have to adapt the tool to accept those again. I did that today, and so far I have not been able to find bugs beyond those I already fixed. Tagging single images works. Tagging multiple images should probably also work, but I had no time to test it so far. Now its time to decide how the XMP tags will get imported into the game.

It's your call, json is prolly a better bet since we can freely access it to view tags but pickle will serve just as well. This is entirely up to you. I am planning to do some work on guard jobs today as well.
« Last Edit: June 26, 2013, 07:18:30 AM by Xela »
Like what we're doing?