Posted by fejoa, Mar 19, 2015 at 5:37 am
Does anyone want to look at implementing Ighalli's god system? To that end, does anyone know whether Ighalli's god system is only a change to the prayer system, or something bigger, like the god system?
Posted by fejoa, Mar 17, 2015 at 7:31 pm
anything relating to ivan you're too lazy to create a new topic for
in forum Tips, Tricks, and Secrets
Did you know you can spawn characters with green hair?
Posted by fejoa, Mar 15, 2015 at 1:51 am
Wiki
in forum General IVAN Discussion
I think the benefit of a belt of carrying is affected by enchantment
Good counterexample Batman. The question remains, should cloaks (of electricity resistance) offer increasing protection (from electricity) with increasing enchantment?
What about cloaks of invisibility? They're basically a boolean invisible/not invisible gear.
Posted by fejoa, Mar 14, 2015 at 10:08 pm
Planning for Release
in forum IVAN Development
Back on the topic of releases. There was some discussion on Github here
https://github.com/Attnam/ivan/pull/21
Seems like the concensus is that Attnam/master is the working space, NOT the "stable" version. Stable versions will instead be released as tags.
I can fork Attnam/master into capristo/master and then make my own changes. After I have tested my changes, I submit a pull request to Attnam/master which is merged in so that everybody else can test.
If I have a larger feature that will take a long time to complete, I can branch my own fork into capristo/FireSystem. Then when I am comfortable with this feature being complete, I should first merge into capristo/master, and then submit a pull request as usual to Attnam/master.
Then to release specific versions, we should use git tagging because that is basically what it was built for and what Github supports out of the box. For example, after my capristo/FireSystem branch has been merged in, we tag this as version 0.51. All commits up to this point are now released as version 0.51 and can be downloaded as a zip. Then if we fix a few bugs related to the fire system, we can release this as 0.51.1. The next batch of bugs is tagged 0.51.2 and so on. Then when we add the next big feature, call it 0.52.
We should stick to semantic versioning as much as possible:
0.51.2
0 - major release
51 - minor release, increment when adding new features
2 - patch, increment when releasing bug fixes which don't add new functionality
That was designed for APIs. I am ok with using a letter to denote the patch instead, e g. 0.51a, 0.51b
https://github.com/Attnam/ivan/pull/21
Seems like the concensus is that Attnam/master is the working space, NOT the "stable" version. Stable versions will instead be released as tags.
I can fork Attnam/master into capristo/master and then make my own changes. After I have tested my changes, I submit a pull request to Attnam/master which is merged in so that everybody else can test.
If I have a larger feature that will take a long time to complete, I can branch my own fork into capristo/FireSystem. Then when I am comfortable with this feature being complete, I should first merge into capristo/master, and then submit a pull request as usual to Attnam/master.
Then to release specific versions, we should use git tagging because that is basically what it was built for and what Github supports out of the box. For example, after my capristo/FireSystem branch has been merged in, we tag this as version 0.51. All commits up to this point are now released as version 0.51 and can be downloaded as a zip. Then if we fix a few bugs related to the fire system, we can release this as 0.51.1. The next batch of bugs is tagged 0.51.2 and so on. Then when we add the next big feature, call it 0.52.
We should stick to semantic versioning as much as possible:
0.51.2
0 - major release
51 - minor release, increment when adding new features
2 - patch, increment when releasing bug fixes which don't add new functionality
That was designed for APIs. I am ok with using a letter to denote the patch instead, e g. 0.51a, 0.51b
Ok so from this it seems I need to make a fork of master, and then make a feature branch (firesubsystem) from the fork. Got it
Edit: So I did this and consolidated the other branches that were swimming alongside my fork. It seems to me that small, self-contained changes should indeed be merged early and often, whereas a larger subsystem should be worked on and tested to some degree before merging into master.
The question is, if I want some testing done, should I release on my own fork?
Posted by fejoa, Mar 11, 2015 at 5:47 am
official website BUGS thread
in forum Website News
Hi Cap, I can't sort the columns in the members list page.
Posted by fejoa, Mar 11, 2015 at 5:42 am
I never noticed before. I agree, anything brain-dead (un-dead or not) shouldn't show up on the radar when you've got ESP.
Posted by fejoa, Mar 5, 2015 at 7:53 pm
Planning for Release
in forum IVAN Development
From what I can tell SDL2 supports scaling the surface/texture, so it may be worthwhile to port IVAN up to SDL2.
Can it do smoothing as well? It would be really awesome to play in different resolutions.
Posted by fejoa, Mar 5, 2015 at 7:18 am
Planning for Release
in forum IVAN Development
Should being covered in blood have a chance to put a fire out? I noticed that after blowing myself up with a wand of fireballs that even after being coated in blood the fire remained lit; until I took the item off.
I'm aware of that one. It's a wrinkle listed here, that needs to be ironed out at some point.
Ok we will follow semantic versioning. It's funny, I think I should have tagged the latest release as 0.50a instead of 0.51a, because it makes it seem like we have completed all our goals for 0.51.
Hey I see that we can attach issues to milestones! Cool ☭
Posted by fejoa, Mar 3, 2015 at 1:49 pm
Planning for Release
in forum IVAN Development
The only problem I have with that is, for weapnos and armor, etc. you can easily identify what they are based on the shape, and the material doesn't matter. For rings, the only way you can tell what kind they are from a distance is the color (material).
Well, then we would need to add the material in the item description.
There was a little discussion on changing the way we commit stable changes and release. The proposal (which I am ok with) is to merge the dev branch into 'master', continuing development by committing future changes from periphery branches to master, and creating releases as stable branches. This workflow seems to me to be more tight knit. Are people OK with merging the 'IVAN051-develop' branch into 'master'?
Posted by fejoa, Mar 3, 2015 at 1:54 am
Flames
in forum IVAN Development
So fellas, which gods should we pray to if we want to put out some flames?