bb_
-
Posts
262 -
Joined
-
Last visited
-
Days Won
3
Posts posted by bb_
-
-
There seems to be a bunch of errors before this one. These are about missing templates. Probably not too relevant, but doesn't harm fixing.
I suspect you did add the `simulation/data/civs/Adrestia.json` file? What is the value of `Code` you put in?
What is the value of `g_Players[g_ViewedPlayer].civ`? You can get that by adding a `warn(uneval(g_Players[g_ViewedPlayer].civ))' just prior to the codeline the error comes from.
Also there might be more errors too (which don't seem to fit in the screen). No worries: you can find all errors in the logs (see https://trac.wildfiregames.com/wiki/GameDataPaths where to find them).
-
It has been so good having you around @Stan. Feeling bad now I wasn't there much for the last 2 years almost. Meeting at FOSDEM and staying at your place on @Imarok and my crazy cycling trip has been a pleasure especially.
Going to miss you certainly, but all the best. And be sure to be welcome around any time.
-
4
-
-
-
As @Freagarachsaid committing the art makes arcanists' live easier (and as a consequence mine too). The art was made by Lion Kanzen (see the ticket).
-
2
-
-
Wait for the autobuild tomorrow morning, or revert to rP26521.
-
20 hours ago, Stan` said:
With @bb_ secondary attack patch it should be possible.
Actually not. Certainly one needs the secondary attack patch for it, but more is required. We also have the #4000 issue. Ships are using buildingai for their attacks and there the ranged attack is hardcoded. So for ship ramming one also needs some fix in that direction.
-
Don't particularly like the new default cursor. The old one could have been a weapon-head too, but one could sell it as a pointer too, making it a very universally used icon. The new one is a weapon however you look at it. I don't want a weapon on my screen when selecting a tree!!
Besides that: the new cursor is way oversized. Making it feel very clunky too work with. The same comment applies to the new attack cursor (the image is fine there, just make it smaller).
I would propose to restore the old default cursor and use the new default for attack-walk instead (that red line is not making things prettier).
-
3
-
-
For the record, this happens since https://code.wildfiregames.com/rP26393.
-
Delete your savegames, they have an outdated entry.
-
-
I does, since the females are all trying to reach the same point in the field and only moving around eachother, to find a free spot, onces they bump into eachother. Then obviously they need to turn and reaccelerate.
-
4 minutes ago, Stan` said:
maybe better value can be found.
The better values are having some realistic turnrates, instead of the almost insta turns that happen in current svn.
What is seen as "clunky" movement, is not caused by turnrates or accelerations at all, they merely highlight the actual issue. Which is "units bumping into eachother all the time".
-
2
-
-
36 minutes ago, Emperior said:
2. Can we get warning ingame for hosts with pointed out IP of the ddos? So we can copy it and somehow block it?
That the whole point of "Distributed Denial Of Service". It is many many IP's trying to connect to your server. All requests are blocked (since nothing is listening), but the shear blocking is sucking the bandwidth. Probably the initiator is not even part of the ddos.
38 minutes ago, Emperior said:1. Can 0ad devs hide hosts IP or visable only for hosts who is actuall provider of the match?
AFAIK, that is already the case. Do notice that someone who wants to join *needs* the IP, since it cannot join otherwise (if you want to send a postcard to someone, you will need the address...).
-
This is very much expected. In multiplayer the game needs to be synchronized over the internet. In order to do this, any command you send needs to be shared with all clients before processing it. More precisely, a client need to send the command to the host, then the host shares it with all clients. Hence when you give a command it is only executed a little while later. IIRC this "delay" is hardcoded to be .6s (or .4s?, whatever). In future we might implement having this time "dynamic" i.e. it would be as low as possible depending on the used network connections (this also related to the idea of "variable turnlengths"). This would make the game more responsive in some situations, in particular two computers on the same network.
However do notice that there will always be some delay. In particular, if you are playing with someone on the other side of the globe, you will have at least .133s delay (we need to travel from the client to the host and back, so basically travel a full circumference of the earth). Simply by the laws of special relativity (nothing can move faster than the light). Likely this will be even higher, since your signal probably will travel slower and with some detour.
-
2
-
-
IIRC relics are spawned near gaia entities on the map. I read from your post, there are no gaia ents. So then the relic code will error saying it can't find a spawnpoint.
Maybe a solution would be to add some triggerpoints on the map (these are invisible for the player). Would need to test if that really works.
-
1
-
1
-
-
On 08/12/2021 at 12:05 PM, Stan` said:
Do note however that they are considering dropping subversion as mentioned by @s0600204 here. Source: https://d.i10o.ca/tmp/phabricator-future/
For the second link, I suppose you refer to:
Quote2021-06-02 18:03:08 <epriestley> A fork also creates an opportunity to make the project at least slightly more manageable: you could drop Subversion and Mercurial support, drop like 5-10 applications that see very little use (e.g., Releeph is broken; Phortune is unlikely to be useful for a non-commercial maintainer). You could drop Arcanist entirely.
It seems that epriestly (the old maintainer of phab) is just posting some suggestions on what one could do. It doesn't seem to contain any evidence that svn is/will actually be dropped. Not sure what the official line is (I heard some conflicting info from @Freagarach on irc). Would be good to figure out.
On 08/12/2021 at 12:05 PM, Stan` said:Also, that ironically, our git repo is about 10GB (5GB .git and 5GB actual files uncompressed for a given revision) while Phabricator is currently taking 138GB and growing. Last time I deleted 10GB worth of logs.
This is an unfair comparison. A git repo contains far less than a phabricator instance: think of all discussions, attachments of whatever kind, non-committed patches etc. The fair comparison would be to compare the size of vcs's (git, svn etc.) with size of development tools like phabricator. If anyone has some data on either of these, please add them to the thread.
On 08/12/2021 at 4:18 PM, wraitii said:For what it matters, if we could have a single tool abstracting gitlab PRs, GitHub PRs, phabricators diffs & so on, I would be very happy
Not the only person asking: https://secure.phabricator.com/D8775?id=20822. Also may I add https://www.tuleap.org/integration/tuleap-gitlab-integration-why-and-how-to-use-it and https://docs.gitlab.com/ee/integration/github.html. Feel free to list similar pages for other solutions.
-
1
-
-
Thanks for everyone posting their input. I have updated the posts at the top of this thread. Also I made a short list of the limitations in our current setup. Feel free to yell if I miss points. Between the listed points I feel there is some overlap.
To start with the top point (not that there is any particular order, feel free to comment on the other points too) "Phabricator not being maintained anymore". If we want to migrate, we can migrate anywhere. @dave_k already posted some ideas on possible systems before:
Obviously there is also the Phabricator fork, Phorge. And surely there are more.
What are everyone's thoughts on these? Are there migrate scripts available for any of these? Do we loose any data currently in phabricator? What features do we loose? What do we gain? Can the trac or forum data be somehow incorporated. How does it work with external linking to the current phabricator pages. How does any choice relate to the feature list at the top of this thread?
-
1
-
1
-
-
6 hours ago, Stan` said:On 25/11/2021 at 8:10 PM, bb_ said:
How does that work with versioning of the binaries? And with clones?
https://dzone.com/articles/git-lfs-why-and-how-to-use Basically it would solve the size issue on the server
Don't think you answered my question. How does git-lfs work with the versioning history of binaries? And does a clone automatically inherit the linkage?
30 minutes ago, hyperion said:it seems a debate svn vs git
It is NOT. I tried to make in the first post clear what this thread is about, namely gathering ideas, wishes etc. regarding VCS.
-
1
-
-
I distilled a feature list from the posts above and will continue doing so. Please yell if I wrongdo anything here.
Some questions from my side:
8 hours ago, Stan` said:Re binary files support could use this https://git-lfs.github.com/
How does that work with versioning of the binaries? And with clones?
8 hours ago, Stan` said:- Co-authoring of commits
- Submodules? With different access
Can someone elaborate on these? what these are? why we would care? etc
10 hours ago, Freagarach said:Pull requests?
I am not sure if I understand the exact feature one is after here. "Being able to say 'this patch is ready to be merged'"?
Lastly my own requested features:
First and foremost, I find that all code, art and anything else must be in one and the same repo. Obviously there must be a clear directory structure. But for some patches (the secondary attack patch #252, is just one example) it is required to change both code and art at the same time. Having to propose different patches for different repo's, will make life a lot harder.
We have been around a long time, the world around us will change and we don't know what will happen. Therefore I will strongly plea for keeping sovereignty. Make sure everything is available in a self-hosted variant. Using third-party services is perfectly fine with me, however we should depend minimally on them. Whether it is to avoid a total collapse of the service, changes in the service itself, or changes in the terms, it shouldn't matter us. We should be able to continue, and at any point be able to decide to stop using any service.
To make things secure and reliable, I would recommend to have a third party back up which is usable as is, preferably using a different vcs. This will make sure that if our one server or vcs collapses, we can continue, using the other at will.
A VCS should work, for everyone from anywhere. There should be a minimum of potential restrictions on joining deving. This means that the vcs should work on many platforms, be free of (third party) account registrations, have a simple workflow with straightforward commands (also understandable for ppl who never used a vcs before).
Dev version testers should be made easy to test: we need them and they might not be as experienced as devs when it comes to handling code bases. Therefore precompiled binaries (autobuilds) should be directly available in the repo. This might also help devs on some platforms.
-
3
-
Some current limitation:
- Phabricator not being maintained anymore
- To much sysadmin time
- Many different systems used
- No full GUI workflow
- Highish threshold for new contributers
Post reserved to gather pro's and cons of different solutions.
-
I try to keep track here of all feature requests. Please yell if I wrongdo anything.
List of feauture request fro VCS
- Low sysadmin efforts (at most as high as phabricator currently) (Stan, wraitii)
- Security (dave_k)
- Proper binary handling (Freagarach, dave_k)
- All code art etc. in one place (bb, dave_k, Freagarach)
- Longevity (dave_k)
- Used in mods and other FLOSS projects (Stan, Locyneah, samulis)
- Companies involved are FLOSS minded (dave_k)
- Partial checkouts (Freagarach)
- Possibility to self-host (locyneah, bb)
- Reliable (dave_k)
- No branching (Freagarach)
- Branching (locyneah, maroder)
- Possible to work completely remotely (locyneah)
- Back up on devs machines (Freagarach)
- Public in production third party back up using different vcs (bb)
- Possibility for bots (elexis)
- Easy export of data (dave_k)
- Autobuild in repo (maroder, bb)
- Easy rebasing (maroder)
- Incorporate gitlab PR, github PR and phab Diffs in one system (wraitii)
- Usable by everyone from anywhere (bb)
- Simple straightforward workflow (bb)
- Low threshold for new contributers (Stan, bb, dave_k)
- Supported in maintaned platforms (Stan)
- 2FA (dave_k)
- Including (parts of) other (third party) repo's in ours (submodules) (Stan)
- Easily properly credit authors of patches, even if they don't have direct commit access (Stan)
- GPG signing of patches, tags and pull requests (dave_k)
- Support for GUI based workflow (samulis)
Features not directly related to VCS
- Low number of different systems used (maroder)
-
This thread is meant to gather and streamline the discussion regarding our choice of version control system. Discussion appeared to be in several places. I did my best to gather all relevant material, but feel free to add any missing information.
We currently use svn, this has been working ever since 2004.
Some earlier discussion about the lobby bots:SpoilerCurrently the svn bot code is hosted in the svn repo (source/tools/lobbybots/). @Dunedan imported the code in the 0ad github instance at https://github.com/0ad/lobby-bots and proposes to remove the code from SVN in https://code.wildfiregames.com/D4155. Below the discussion in the revision:
bb said:Don't understand why we would want to move our code from our self-hosted server to any other random platform. What is wrong with having it in svn? If someone wishes to use the the git-mirror, feel free.
Search the forums for discussion but couldn't find.Notice that only few devs have access the the new git and the code gets spread around more, making it harder to track all changes. Also there is no phabricator/trac or the like instance on it. Seems like it is making deving only harder.
Why is this tool special so it gets an own git, shouldn't we do it with every tool then? Makes the mess even bigger.
stan said:Indeed it was not discussed publicly I believe, as I had a really hard time reaching to @user1
It was discussed with @implodedok and a bit with @Itms. The idea was to not put more strain on the server as the CI is already bringing it to its knees and instead rely on a third party (here github for the CI)
First reason is that while development of the lobby is linked, it actually lives its own life and evolves at a different pace and to my despair it's not actually completely versioned
This is actually a good step towards the engine split.
bb said:There is no trac phabricator/instance
If you mean to track tickets/ make comments on pull requests you can do that too on Github.
Unlike all the other tools this one is actually used in production .
bb said:stan said:The idea was to not put more strain on the server as the CI is already bringing it to its knees and instead rely on a third party (here github for the CI)
How is this required to reduce the stress on the CI? Keeping 20-odd files in our svn repo won't hurt that much. If we want the bots to ignore these files, let them (though we have the bots for a reason so we better use them when we need to).
Also what happens if github goes offline/kicks us (maybe not likely, neither impossible), we loose our code? What if gitHub puts restrictions on what we do, do we then abide? Why give away the sovereignty we have? Why let the codebase fall apart, literally?
Now some third party CI might be free, probably many proper things we currently host ourselves are going to be expensive (now the SPI reports says we don't have to worry to much about our finances, I think we can spend our money better)stan said:First reason is that while development of the lobby is linked, it actually lives its own life and evolves at a different pace and to my despair it's not actually completely versioned
Say if I were to implement a new system of ratings, I did need to change the bots (as I need to compute the ratings) as well as some gui (i.e. I need to show the new rating). Having several repo's makes developing such a feature much harder, so is not wanted.
We have files in our repo which haven't been touched in the last 10 years or so and files which are changed every month or so. That is completely fine. So if these files are developed evolve at a different pace: fine. What is the problem? I suppose during CF we shouldn't change the lobby bots either (if there are bugs with them, we need to lift CF for them: fine). Even the more reason to keep them in the same repo.stan said:This is actually a good step towards the engine split.
Splitting the engine doesn't mean having several repo's. In fact we shouldn't have the engine in another repo than the vanilla game or anything else we develop related to 0ad. If we want to split stuff we need to work with directories within the repo: having a separate directory for tools like this within our repo is perfectly fine with me, storing it in source might indeed not be ideal.
Even if we need several repo's, we should host them ourselves.bb said:There is no trac phabricator/instance
stan said:If you mean to track tickets/ make comments on pull requests you can do that too on Github.
So we as developers need to look at yet another place for patches, instead of keeping everything in one place.
stan said:Unlike all the other tools this one is actually used in production .
So are the translation scripts and probably others too.
wraitii said:bb said:Also what happens if github goes offline/kicks us (maybe not likely, neither impossible), we loose our code?
I think this is absurdly unlikely at this point, but even if GitHub deletes the repose unilaterally, git makes it so that we'd very likely have recent-is mirrors on several dev computers & on the lobby server itself. I don't think this should be a concern.
bb said:Why give away the sovereignty we have?
'Cause Phabricator is dying, see https://wildfiregames.com/forum/topic/42181-phabricator-is-no-longer-being-maintained-upstream/
Also sovereignty is essentially kept per the first point.bb said:Why let the codebase fall apart, literally?
Other arguments:
- It's a good way to gain knowledge about GitHub usage, which will help should we decide someday to migrate somewhere else.
- the person who wants to work on this code wants to work on GitHub because it's easier for them
bb said:Say if I were to implement a new system of ratings, I did need to change the bots (as I need to compute the ratings) as well as some gui (i.e. I need to show the new rating). Having several repo's makes developing such a feature much harder, so is not wanted.
It's a quite realistic prospect to change the rating calculation without changing the rating display, and vice-versa.
The actual hard problem is deployment, and since we don't actually deploy the bots synchronously with SVN, we'd already have a lot of trouble if you wanted to implement a new system of rating.bb said:Even if we need several repo's, we should host them ourselves.
The logic of 'we should do it ourselves' just creates more work for everyone and means we have a laggy Phabricator CI that's not maintained instead of a fast, easy-for-beginners GitHub CI, to be honest.
bb said:wraitii said:bb said:Also what happens if github goes offline/kicks us (maybe not likely, neither impossible), we loose our code?
I think this is absurdly unlikely at this point, but even if GitHub deletes the repose unilaterally, git makes it so that we'd very likely have recent-is mirrors on several dev computers & on the lobby server itself. I don't think this should be a concern.
Even if unlikely not impossible. So we will be dependent on a few persons who have the code. Also this doesn't save all comments and discussions.
wraitii said:bb said:Why give away the sovereignty we have?
'Cause Phabricator is dying, see https://wildfiregames.com/forum/topic/42181-phabricator-is-no-longer-being-maintained-upstream/
Phab will keep running as long as we keep it running on our servers. Also I saw there were efforts to fork it.
wraitii said:Also sovereignty is essentially kept per the first point.
The first point doesn't keep our sovereignty at all.
wraitii said:bb said:Why let the codebase fall apart, literally?
Other arguments:
It's a good way to gain knowledge about GitHub usage, which will help should we decide someday to migrate somewhere else.
If we were migrating (which I would oppose, enfin), we did be migrating to a self hosted git, at the least. With moving to github we do NOT gain any experience on this.
wraitii said:the person who wants to work on this code wants to work on GitHub because it's easier for them
So he can use the git mirror, fine, just commit the patches in the SVN. If the mirror bot needs to run more often than once a day, that shouldn't be much of an issue. There is also the option of git-svn. And if one wants an own mirror on github of this piece of the code, I won't object.
wraitii said:bb said:Say if I were to implement a new system of ratings, I did need to change the bots (as I need to compute the ratings) as well as some gui (i.e. I need to show the new rating). Having several repo's makes developing such a feature much harder, so is not wanted.
It's a quite realistic prospect to change the rating calculation without changing the rating display, and vice-versa.
Even more realistic is to change both (e.g. team rating etc.).
Compare it to the following case: our art and code mostly behave independently. Artists can do their thing, coders do their thing. However in the secondary attack patch, I need a lot of code AND some new cursors. Having them together makes it possible to have one patch only for testers to test it. So even though most of the time the art and code are independent, since there are cases they are not, we should keep it in the same repo as it makes things easier.wraitii said:The actual hard problem is deployment, and since we don't actually deploy the bots synchronously with SVN, we'd already have a lot of trouble if you wanted to implement a new system of rating.
Moving to git doesn't help even a 1% on this problem. We probably need more devs who have access and more lobby mods and stuff like that. Anyway out of scope.
wraitii said:bb said:Even if we need several repo's, we should host them ourselves.
The logic of 'we should do it ourselves' just creates more work for everyone and means we have a laggy Phabricator CI that's not maintained instead of a fast, easy-for-beginners GitHub CI, to be honest.
So just keep it in the same repo??? Sounds like the easiest solution for all.
wraitii said:bb said:Even if unlikely not impossible. So we will be dependent on a few persons who have the code. Also this doesn't save all comments and discussions.
Er, we technically depend on a few persons now. If the servers were to crash irrecoverable and backups didn't work, we'd lose everything as well. Point is, I don't think this is much of an argument either way, though there are pros & cons for both.
bb said:Phab will keep running as long as we keep it running on our servers. Also I saw there were efforts to fork it.
AFAIK none support SVN, unfortunately. And well, it's true, but it'll also keep all its security flaws (if any) & its general slowness & never get any new feature.
bb said:If we were migrating (which I would oppose, enfin), we did be migrating to a self hosted git, at the least. With moving to github we do NOT gain any experience on this.
That's if we migrate to a self-hosted git, which is not necessarily the best option.
Anyway, I don't have a very strong opinion either way on this particular diff.
Below an excerpt from an e-mail Stan has send round a while ago to all staff members:
SpoilerI am finding myself in front of an issue with the lobby. Despite all my efforts to improve communication and contribution to the lobby, it seems to remain the same blackbox it has been for a long while now at least since elexis stopped working on it.
- The code source in the repository is not representative of the production code.
- The offense reporting is completely transparent which made a few players mad.
- We have a very long time of response when issues arise in the lobby. For instance the Ratings bot was kicked from the lobby because it said some offensive player name and it took at least a day to report it. The certificate almost expired recently, and the vm configuration was blocking the automatic renewal.
- People are reporting being harassed on the lobby
- There are lot of smurf accounts with are in violation of a ToS we can not enforce.
- The knowledge of how the VM is setup is not to be found anywhere;
- You need admin access to moderate the lobby.
To remedy this I tried to open the discussion with user1, migrated the repository to github to separate the workflow and to alleviate some stress on the servers had we been to
As bb pointed out in this diff I have not communicated well on the lobby matters and a few things happened behind the scenes as I was trying to focus the discussion into the biggest actors of the lobby.
As some of you may know the lobby underwent a huge rewrite for A24, and it took a while to get the code committed to the repository. It was only committed after A24 came out.
To try to make the contribution to the lobby easier we migrated the code to Github, after discussing the possibility of self-hosting it with Itms and implodedok and rejecting it because we did not want to put more strain on the server with extra CI which is currently still hogging the server's resources and forcing us to change all the disks every year.
Dunedan took on to write pipelines and tests to automate everything so we would only have limited maintenance to do. But so far none of it has been reviewed and the code on the lobby VM might be really different. This has been a terrible contribution experience, and still is.
In January we wanted to extend the lobby VM disk, to be able to log more things and to stop it from constantly running out of space. It took about three whole months to get the necessary access to do it. After doing the lobby did not restart properly, and players didn't have any ranked games for two days.
A bit later after Dunedan was given access to the lobby VM he was able to renew the certificate in extremis before it would fail all clients. Now that his access is limited again to the scope of the of bots, he won't be able to do anything when, in 13 days the TLS-certificate of the lobby is expires again.
I'd like to hear your thoughts about how we can improve the current situation.
A relevant related topic is
On November 24 2021, a discussion on IRC:
Spoiler(06:12:06 PM) molgrum: the main thing for me is you are running Trac instead of Github.
(06:12:12 PM) molgrum: I can use Trac with LibreJS.
(06:12:23 PM) molgrum: I'm originally a dev for Quakeworld.
(06:12:35 PM) molgrum: but they use Github so I can't dev for them.
(06:12:36 PM) Freagarach: We're using Phabricator now.
(06:12:51 PM) Freagarach: @wiki Phabricator
(06:12:51 PM) WildfireBot`: http://trac.wildfiregames.com/wiki/Phabricator
(06:13:34 PM) Freagarach: Why can't you use GitHub?
(06:13:39 PM) Freagarach: If I may ask.
(06:14:18 PM) molgrum: Freagarach: it's broken with LibreJS unfortunately.
(06:14:39 PM) molgrum: I can't run the code and Github heavily relies on non free JS.
(06:14:56 PM) molgrum: of course, I could send patches outside of Github.
(06:15:02 PM) Freagarach: Ah.
(06:15:09 PM) Freagarach: Let me search for LibreJS.
(06:15:10 PM) vv221: Stan, I am around
(06:16:35 PM) vv221: Freagarach, I think LibreJS is a Web browser extension preventing the execution of JavaScript unless said scripts are published under a libre/free license.
(06:16:47 PM) vv221: molgrum, is that right? ↑
(06:16:55 PM) Freagarach: Yep, I read it, thanks.
(06:17:02 PM) molgrum: vv221: yes.
(06:17:13 PM) Freagarach: Can you use code.wildfiregames.com?
(06:17:27 PM) Stan: vv221, imploded1k: is asking me to choose between a rpm based distro
(06:17:42 PM) Stan: And a debian based distro for setupping gitlab
(06:17:57 PM) Stan: With a preference for rpm
(06:17:58 PM) molgrum: Freagarach: it looks promising.
(06:18:08 PM) vv221: Freagarach, it seems that code.wildfiregames.com is usable even with no JS at all.
(06:18:15 PM) vv221: (at the cost of a couple features of course)
(06:18:21 PM) Stan: vv221: Might not pass the registration phase
(06:18:28 PM) Stan: I think there is a dumb recaptcha
(06:18:49 PM) Stan: But once you're registered it's good
(06:19:19 PM) Stan: Also if you have any recommandation for the vm specs for gitlab
(06:19:38 PM) vv221: Stan, the only GitLab setup I have experience with is specific to Debian. I don’t know how it is distributed for rpm-based distris, but I suspect it is using the Omnibus all-in-one "package".
(06:20:02 PM) Stan: (Initially I wanted to use the same vm as trac and phabricator but seeing it keeps failing kinda makes me scared)
(06:20:11 PM) vv221: I can check the specs of the VPS that used to host ./play.it GitLab forge, but right now it is running on my day-to-day computer
(06:20:24 PM) Stan: vv221: And that's bad because it bundles too much stuff?
(06:20:45 PM) Freagarach: https://about.gitlab.com/devops-tools/gitea-vs-gitlab/
(06:20:59 PM) Freagarach: Says you need .5Core 4GB memory.
(06:21:25 PM) vv221: That’s bad (to me) because I do not trust the GitLab team to maintain GitLab + Postgresql + nginx + etc. And trust the maintainer of all the distinct JS packages and Ruby gems it relies one.
(06:22:12 PM) vv221: With the Debian-provided packaging, I’m putting most of my trust into an organization and an infrastructure I already worked with for years.
(06:22:27 PM) vv221: Of course, it works because I trust Debian in the first place
(06:23:45 PM) vv221: Stan, my VPS is 4-core / 8GB RAM / 160 GB storage. But in my experience it is ~twice as big as what I really needed.
(06:24:08 PM) vv221: Keeping in mind that ./play.it is a low-traffic software project, with very lightweight repositories.
(06:25:19 PM) vv221: Right now ./play.it forge is on my gaming computer, so 8-core / 18GB RAM / 42 gazillion bytes of storage ;P
(06:26:14 PM) Stan: We have a very heavy svn repository which I will have to migrate to git
(06:26:31 PM) Stan: I was thinking of starting by building the fcollada library
(06:26:45 PM) JCWasmx86: So if I understand you correctly, you are migrating from Phabricator to Gitlab
(06:26:48 PM) Stan: Using gitlab ci to get familiar with it and artifacts
(06:26:48 PM) vv221: I did a quick check, 4GB RAM might be too little. It is already using almost that here.
(06:26:55 PM) Stan: JCWasmx86: That's my plan
(06:27:01 PM) Stan: But I might hit a wall
(06:27:36 PM) JCWasmx86: Is there anything I can help with? (I use linux on the desktop daily, but I have no experience for linux on servers)
(06:28:28 PM) Stan: Well my biggest problem is migrating everything to gitlab
(06:28:37 PM) Stan: There seem to be tools for phabricator
(06:28:47 PM) Stan: But nothing we actually use on phabricator
(06:28:55 PM) Stan: Not sure about trac
(06:29:13 PM) Stan: And i know you can run a jenkins instance on gitlab but i don't want to do that
(06:29:36 PM) Stan: And the final problem is migrating the repo to git
(06:29:41 PM) Stan: In a not dirty way
(06:30:00 PM) Stan: Aka not like the github and gitlab mirrors we have
(06:30:16 PM) Stan: We would have no windows binaries for linux users for instance
(06:30:26 PM) Stan: They'd be an artifact from gitlqb
(06:30:33 PM) Stan: Which should be easy to download
(06:30:46 PM) Stan: Because the goal is not to make life harder on windows
(06:31:48 PM) JCWasmx86: Ah well, I understand. Converting the tickets from trac should be able using the trac API to extract and the gitlab API to make issues
(06:32:22 PM) JCWasmx86: The wiki could be more difficult with all the history/diffs
(06:33:48 PM) vv221: I’m not sure if this info could help: GitLab wikis are actual git repos.
(06:36:45 PM) Freagarach: So we're going from SVN to GitLab, because there are many potential contributors on GitHub? Sorry for asking nasty questions. ^^
(06:38:30 PM) Stan: Freagarach: No we're going from SVN to Git because Phab won't support svn anymore doesn't get updates, and is hard to maintain
(06:38:41 PM) Stan: And we're going to a self hosted gitlab
(06:39:17 PM) Stan: Not gitlab.com nor github.com because apparently it's important that we keep our sovereignty in case big companies collapse
(06:42:43 PM) Stan: Tell me if I sound insane
(06:43:42 PM) Stan: Also I'm migrating everything to gitlab (jenkins and trac) because experience shows that development time is more important than sysadmin time given the current state of the team
(06:44:00 PM) Stan: And if we're (or I) gonna have to maintain something I'd rather have people I can ask like vv221
(06:44:17 PM) Stan: And also limit the maintaining to installing updates
(06:46:17 PM) vv221: Well, we probably won’t have less maintenance issues this way… but at least we can hope to have them only once (on ./play.it side or 0 A.D. side) and can warn the other or share the resolution.
(06:49:21 PM) Stan: I mean if I ask you why my gitlab is acting out vs why is my phabricator acting out you might have more insights ^^
(06:53:39 PM) vv221: No doubt about that
(07:08:10 PM) Stan: But yeah the migration is scaringly huge
(07:08:18 PM) Stan: And I'm not in the best state[cut]
(07:23:22 PM) ***bb still owes you guys a forum thread on VCS choice
(07:25:08 PM) Stan: Indeed although I guess it will mostly end in dead silence
(07:25:50 PM) bb: could be true, still any choice whatever it is should be documentedWhat I did like to hear from everyone (staff, contributors, svn testers etc.): What is required from the version control system and CI? Which features are required? And what is only nice to have? Please list your wishes in this topic, preferably ordered in priority.
What are the current limitations and what are possible solutions for that? What are the pro's and cons for them?
-
3
-
1
-
I guess I found the culprit: the cost/Resources/wood entry must be a nonnegative integer, following the cost schema. Since you multiply with 1.2, this will be interpreted as a decimal (even though 1.2*30=36). So I suppose you can fix it by explicitly setting the value in the children instead of using the operator (maybe using the add operator still works). Another option is to try to fix the operators in this case.
-
1
-
-
2 hours ago, wowgetoffyourcellphone said:
Tried it. Neat.
WARNING: Failed to draw cursor 'action-attack-noprojectile'
Yeah, that is arcanist being a @#$%. Please download the icon manually and put it in the correct place. Sadly can't do much about it. (When committed this issue is gone)
-
1
-
Publish new map
in Scenario Design/Map making
Posted
Hi and welcome Baelish !!
You are already in the right place to share your map. Just attach it to your post here on the forums. The map (I presume it is a scenario/skirmish type map) consists of two files. one .xml and on .pmp. Maybe https://trac.wildfiregames.com/wiki/GameDataPaths will help you locate the two files. Just zip them and attach them.
In order to use them in MP all players should download the map and place it in their local maps directory. The map should then show up in the gamesetup and you can use it.
Out of interest: how did you create the contours of the map? Did you use a hightmap of some kind? In that case, what is the source of your hightmap?