Pyrel dev log, part 3

[Derakon]

What kind of operations can a StatMod do? Just addition and multiplication? Or is it more of an "arbitrary function" sort of thing with an input and an output?

They have built-in support for addition and multiplication, and they can also link to an arbitrary function. The results of all these operations are added together to get the overall modifier.

So if you have two entities with the same speed, the one that's first alphabetically gets to go first? That just seems... wrong... Maybe just pick one at random instead?

Not just the same speed but also the same energy. So long as you generate monsters with random energy (could be between -1 and 0 if you want to ensure the player goes first) name should practically never be a problem.

I've heard of mixins before - I thought they were more along the lines of mixing code in several different languages to accomplish a task, though? What you describe sounds more like interfaces in C# and Java, except that (perhaps) you can combine two or more mixins to get the full functionality of a class, without actually having to inherit from said class in whatever is implementing the mixins...

Nope, what you heard is wrong.

Mixins are similar to interfaces in a way, though. Interfaces say "Inherit from me and you are required to implement these functions." Mixins say "Inherit from me and you automatically implement these functions."

[ekolis]

Hmm, "added together"? Do you mean literally added, or just applied sequentially? What about order of operations?

[Derakon]

Literally added together, so order of operations isn't an issue.

Did you read the earlier post on enforcing a tier system to stat mods? Every tier of modifiers is only allowed to take into account prior mods if they have a strictly lower tier, thus there's no issue of circular dependencies or concern about ordering.

[ekolis]

Added a couple mini-patches to the patch queue - one of them (finally) fixes the message window sizing issue, while the other just adds a batch file that's useful for testing on Windows!

Are you notified of new patches added to the patch queue? I'm getting a bit annoyed with Bitbucket lately at all the missing/broken features...

[ekolis]

Literally added together, so order of operations isn't an issue.

Did you read the earlier post on enforcing a tier system to stat mods? Every tier of modifiers is only allowed to take into account prior mods if they have a strictly lower tier, thus there's no issue of circular dependencies or concern about ordering.

Oh, sorry, I must have missed that one!

So let me get this straight - the stats API calls a modifier's code, and instead of REPLACING the current stat with the return value of the modifier, it just adds it to the current stat value? So if I just returned the current value of the stat from a modifier function, it would not mean "no modifier", but instead it would mean "double the stat"? I guess that makes it much easier to deal with order of operations!

[Derakon]

So let me get this straight - the stats API calls a modifier's code, and instead of REPLACING the current stat with the return value of the modifier, it just adds it to the current stat value? So if I just returned the current value of the stat from a modifier function, it would not mean "no modifier", but instead it would mean "double the stat"? I guess that makes it much easier to deal with order of operations!

Correct.

Regarding your patch queue, no, I'm not notified of changes to your repo, since I'm not subscribed to it. You'd have to submit another pull request. However, doing everything via patch queues doesn't seem like the right way to go, to me. I don't think you're running into "missing features" so much as differences between how Git and Mercurial fundamentally work.

[ekolis]

Unfortunately, there's no way to submit a pull request from a patch queue.

I was not just talking about patch queues but also other missing/broken features, of which I can't think of any at the moment, but I've submitted issues to site/master about them!

edit: and using an actual forked repo seems like too much of a nuisance, since to keep it in sync, I have to manually pull from your repo and push to mine - I can't just tell the repo to base itself off the latest version of what you've got!

[Derakon]

Unfortunately, there's no way to submit a pull request from a patch queue.

Which is a sign that you probably shouldn't be using a patch queue.

I was not just talking about patch queues but also other missing/broken features, of which I can't think of any at the moment, but I've submitted issues to site/master about them!

edit: and using an actual forked repo seems like too much of a nuisance, since to keep it in sync, I have to manually pull from your repo and push to mine - I can't just tell the repo to base itself off the latest version of what you've got!

That doesn't really sound any different than how development was going in Angband when I was contributing work. You pulled the latest from master, made your change, and then submitted a pull request back to master to push your changes back in. Automatically rebasing off of master sounds like a recipe for disaster -- what happens if master conflicts with your changes?

It really sounds like the problem is that you're not using Mercurial correctly. Of course it doesn't work. Sorry to be blunt.

[Magnate]

ekolis: I'm just getting to grips with hg, and have a few issues with it (bookmarks/branches being the main one), but one thing that doesn't seem to be broken is

1. git fetch official
2. git merge official/master
3. git checkout -b newbranch
4. (do stuff)
5. git push origin newbranch
6. (submit pullreq)

- that's the standard process for updating to the latest master, creating a brand new branch, and then pushing it and submitting a pullreq. The hg workflow is basically identical (with the caveat that I *think* I'm supposed to use bookmarks instead of branches for this kind of temporary branch).

Sorry if I'm not understanding your difficulty, but happy to help if I can.

[ekolis]

Well, I guess the issue I was having wasn't really keeping my local repo in sync with the repos on Bitbucket; it was more of keeping the two repos on Bitbucket in sync with each other, since Bitbucket doesn't seem to let me sync them via the web interface! So I have to go through several extra steps to sync them manually (pull from whichever is newer, then push or submit a pull request to the outdated one), as opposed to just clicking a button to do that automatically. I guess I could write a batch file to automate it, but I still think it's weird that I have to go through a local repo to automate a process that could be done entirely on bitbucket's servers!

[Derakon]

If your remote automatically pulled from my remote whenever it was updated, then you'd suddenly find yourself unable to push to your remote because of conflicts. Or alternately, you'd push fine but your remote would be in an unusable state because it had pulled code from my remote that resulted in a broken program when combined with your changes. You really want to know when your remote has changed -- automating that is bad juju.

[Magnate]

If your remote automatically pulled from my remote whenever it was updated, then you'd suddenly find yourself unable to push to your remote because of conflicts. Or alternately, you'd push fine but your remote would be in an unusable state because it had pulled code from my remote that resulted in a broken program when combined with your changes. You really want to know when your remote has changed -- automating that is bad juju.

I have to say, I've never found the de-sync between my 'origin' remote and the official remote to be a problem. (If github does have a button to sync the two, I've never used it.)

My own 'master' branch lags way behind official/master. I don't find that a problem because my 'master' isn't used for anything - I do all my work in branches, a new branch for each fix or feature. Every now and then I push an update to origin/master for the hell of it, but anyone following my repo knows that it's a fork of the official repo and shouldn't expect anything from my master branch.

I'm not yet sure if I can replicate this workflow in Pyrel, but I'll have a go.

[Derakon]

mtadd wrote a curses frontend for Pyrel! So if getting wxWidgets working was a problem, you can now just run Pyrel straight from the commandline by doing "python pyrel.py --ui=CURSES". Thanks, mtadd!

On that note, it seems clear that a lot of UI functionality should be refactored into a "UI base". A lot of the logic about displaying prompts, handling commands, etc. will be the same for different UIs that only differ in how they handle display. I hadn't worried about this when working on the wxWidgets frontend, a) because it didn't make sense to refactor when I only had one use case, and b) because I was thinking about not wanting to force Pyrel to be a grid-based UI controlled by the keyboard (for example, you could plausibly have a paper-doll equipment system with a Diablo-style inventory instead, without changing the mechanics of gameplay at all).

However, since the vast majority of frontends will be grid-based and keyboard-controlled, it makes sense to have a central location for that functionality. Any non-grid/keyboard UI can reimplement what it needs to.

[Derakon]

mtadd went ahead and did the GUI refactor. Thanks again, mtadd! We should now be able to add new front-ends with a minimum of code duplication.

I've implemented basic stat loading and calculation according to the design described earlier in this thread. I still want to extend the same procedure to items, and port over the stats and stat growths defined in p_race.txt, but once that's done we should have a solid framework to start from for any new feature that requires a fully-fleshed-out character.

[Derakon]

Items now use the new Stats system, and I've converted the old data files to reflect that change, hopefully without losing anything important!

I went ahead and changed "finesseBonus" and "prowessBonus" into "meleeFinesse" and "meleeProwess", with the idea being that melee and missile scores would be completely different stats. This should sidestep the problem of not knowing if e.g. that Ring of Slaying on your finger makes you shoot better. It also means that off-weapon combat bonuses can just be tossed onto the player instead of having to modify the weapon. We could extend this to brands (and even to heft, balance, and the dice on the weapon!) but it'd be pretty clunky to have "meleeFirebrand", "missileHeft", etc. modifiers. Plus it'd probably interfere with dual-wielding somehow, not that Pyrel plans to have that.

The next step is probably to create a few player templates. The base one would have primary stats of 10 across the board, and the races and classes would provide the appropriate modifiers. The "skill" stats (perception, magic device, etc.) would need the concept of a player level to be created if they're going to scale properly, but that means coding in experience (and ideally ways to gain experience) so for now let's just leave them at the base values. Then when the player is created we can just apply a couple of templates to have an actual, fully-specced-out character to work with.

Oh, and I should write up a basic 'C' character sheet Prompt so you can check what stats the player has.

Also at some point I need to clean up the Effect system. When I initially designed it its scope was specifically for items that cause special effects to occur when they're used in different ways. This has since been extended to also allow causing main-engine code to branch (e.g. for preventing the allocation of a unique monster), and to causing numbers to be calculated (for deriving stat modifiers). Functionally this means that a bunch of attributes of the Effect class need to be pushed down to individual Proc instances (remember than an Effect is a collection of Procs); I also probably need to change how the Effect goes about calling Procs and possibly make inserting Procs into the data files more succinct.