This Week In Veloren 126
This week, we get an overview of changes to how development will be done on GitLab. Lots of new models were added, and we say farewell to a longtime core developer.
- AngelOnFira, TWiV Editor
Thanks to this week's contributors, @Snowram, @XVar, @xMAC94x, @imbris, @tygyh, @aweinstock, @juliancoffee, @Yusdacra, @drunkonhotcoco, @Slipped, @nwildner, @teenjuna, @Danacus, @a1phyr, @SWilliamsGames, @zesterer, @Sam, and @AldanTanneo!
@Songtronix did a lot in preparations for Airshipper 0.4.3:
- The server now validates a lot of things before publishing, and the server and client should now stay in sync
- Windows 7/8 support is back (unexpected or badly formatted error) courtesy of @Capucho's PR
- Many other fixes
@Songtonix is taking leave from the development of the project this week as well. @Airshipper has been moved to the Veloren org on GitHub. He'll still be around as a player, but must focus his energy on other work and education. The core team is very thankful for his work, and wishes him the best with his future endeavors!
@Snowram added 2 new species to compensate for the lack of wool, an alpaca (model by @Gemu) and a llama (model by @Snowram), also added mammoth and ngoubou species (models by @Gemu)
@Snowram also substituted the cultist's loadout with warlock/warlord armour that was unavailable for players. The cultists now look more fierce and meaner. A buffed up version of the husk was also added for mini-boss rooms: the Husk Brute (models by @Gemu)
@Sam worked on adding durations to potions and food (and this will also be easily extendable to other item uses). What this will mean is that consumables are no longer instantaneously used, limited only by how fast you can spam a button. Now you will need to drink the potion or eat the food. @Slipped has made animations for both drinking and eating.
@aweinstock ported the dungeon generator from the sampling-based approach to site2's CSG generator, making it easier to modify.
@juliancoffee made a MR which sorts crafting tabs in logical order and splits recipes from Dismantle and Material tabs.
The cultist predicament by @juliancoffee
Mind flayers were a little worried about their cultists being too weak. Someone even said that cultists are weaker than ants from Myrmidon dungeon! What nonsense! Reforms were needed, everyone knew that. So best darksmiths worked on new armour. Orichalcum? Good choice, if you want to get hit, but cultists should be smarter than that.
Dragonscale? Better, but still has less protection. While you can hit harder with it, you lack stamina. Sunsilk solves this issue, but only if you consider a bunch of silk the armour. Cultists are best, they deserve to have this all! And the darksmiths come up with the answer.
Smith's chef-d'oeuvre gives its owner strength of any possible armour. Mind flayer also get a better weapon with the flamethrower of such power so they hardly can handle it themselves. But a single piece of metal and heat of fire doesn't win fights alone. so mind flayers gathered the best warriors and gave them power consumed from weaker ones (so that mind flayer don't need to waste their corrupted spores...).
GitLab repository changes by @xMAC94x
Veloren's community is open and volunteer-driven. We welcome new contributors from all walks of life in our mission to build the best game we possibly can. Currently, we hand out 'developer'-level permissions to contributors on the main Veloren GitLab repository.
Long-term, this situation is untenable and will need reevaluating: GitLab's permission system is crude and doesn't allow us to control access permissions across branches, meaning that contributors have more permissions than are necessary to do their work.
The obvious alternative to this workflow is to have contributors fork the repository and contribute by upstreaming to the main repository through merge requests. However, this comes with some disadvantages:
- Collaboration between multiple contributors is harder: contributors must decide to work on a specific lead contributors fork, and will require permissions to do so, as well as adding the fork as a remote locally
- Continuous Integration (CI), the system for testing changes to the codebase before merge, will need to be manually set up for each fork.
For these reasons, we're going to be trialing a third solution: a dedicated 'contributor' repository where contributors can work on features as they do on the main repository today, but will open MRs against the main repository when features are complete. The main repository will be used only for branches authored by core developers, and the main branch/release tags.
What this means for you
For contributors, the change in workflow should be minimal: the only change you'll need to make is to switch the URL of your 'origin' remote locally, and remembering to open an MR with the main repository when you feature is ready for review. All permissions, CI-related things, etc. will be handled by us. Shortly after a transition period, we will deactivate the developer rights on the main repo and ask you to switch to the
veloren/dev/veloren repository permanently.
For developer this means you need to change the remote URL.
git remote set-url origin email@example.com:veloren/dev/veloren.git
We are happy to hear your feedback and questions in the respective channels 🙂
What exactly are the security concerns?
We will publish them in a blog post once we this change is complete, to avoid tempting potential exploits.
Will I still be able to use my Fork?
Yes: the dev repo is optional. Feel free to continue forks, though we do recommend you join the dev repository in order to make your life easier.
I have an ongoing MR on the veloren/veloren repository. What do I need to do?
Nothing will happen to core developers and team leads, they will keep access to the main repo until their MR is merged or closed. If you made the change in on your fork, this will also be the case. If you made the change on the main repo but are neither a core developer nor a team lead, please contact me (@xMAC94x). If you are currently working on a branch, please push that branch to the dev repository, using the same name.
How do I join the dev repository?
We have already invited all members of
veloren/veloren to the dev group. If you are not yet a member, apply here: https://gitlab.com/groups/veloren/dev/-/group_members and ping one of the core developers.
Should I now
fork, open issues on the
veloren/dev/veloren repo instead?
No, please use our main repo
veloren/veloren as the project's 'ground truth'. Only use the dev repo for development purposes.
How do I open Merge Requests (MRs) now?
When you open a new MR in the dev repo, it should automatically have the target
veloren/veloren/master. This means that the process should not differ in practice.