New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Move some repositories to @DaemonEngine. #837

Closed
Viech opened this Issue Nov 13, 2015 · 27 comments

Comments

Projects
None yet
8 participants
@Viech
Member

Viech commented Nov 13, 2015

The following repositories aren't Unvanquished-specific but Dæmon-specific and should be moved to the @DaemonEngine organization so everyone involved in any Dæmon game knows that they're available and can improve them:

  • Chameleon, a texture replacement editor for maps.
  • Sloth, a generator for "shader files" for map textures.
  • crunch, a texture compression tool. (Make it an uppercase c when moving as it's a proper name.)

I'm not sure about the following:

  • daemonmap, sounds like it's Dæmon-specific but from what I know the only feature it offers over q3map2 is navigation mesh generation, which may or may not be Unvanquished-specific. (Currently, bot code is split between engine and gamelogic. Any input, @cmf028?). Depending on what we plan with it, maybe rename to "Unvmap" or strip it down to just a navmesh generator and give it a fitting (animal) name, too.
  • unvanquished-master, sounds like it's Unvanquished-specific but would ideally work for all games running on Dæmon.

This issue is for getting feedback and discussing what to do with the unclear repositories.

Added by illwieckz:

@Viech Viech added the T-Question label Nov 13, 2015

@mbasaglia

This comment has been minimized.

Member

mbasaglia commented Nov 13, 2015

I think someone mentioned that daemonmap has been deprecated, Ingar or illwieckz might know more about this.

@Kangz

This comment has been minimized.

Member

Kangz commented Nov 13, 2015

DaemonMap is only being used to generate navmeshes and is completely broken for other things. Ideally we would want to merge the navmesh generation in q3map2 and trash this repo.

@Kangz

This comment has been minimized.

Member

Kangz commented Nov 13, 2015

I would be in favor of making our master server game agnostic (if it isn't already) and have Xonotic use it. Of course we would add the features that Xonotic require.

Having the same master server will let both games innovate faster. I'm thinking of stuff like global player accounts and stats, achievements, etc. (in the very long term)

@mbasaglia

This comment has been minimized.

Member

mbasaglia commented Nov 13, 2015

Yeah Darkplaces has a single master server (http://dpmaster.deathmask.net/)

@DolceTriade

This comment has been minimized.

Member

DolceTriade commented Nov 14, 2015

We can either deprecate unv-master or deprecate dpmaster. dpmaster has been supported but lacks some of the fancy features of unv-master (stuff added by Benmachine for GPP's features. Server tags/featured servers/etc).

@mbasaglia

This comment has been minimized.

Member

mbasaglia commented Nov 14, 2015

The last commit on unvanquished-master is from 2 years ago...
Is it going to be maintained?

@Viech

This comment has been minimized.

Member

Viech commented Nov 18, 2015

Well, it works! Is there an alternative master server you'd prefer to maintain as the "official" one for Dæmon, @mbasaglia?

@mbasaglia

This comment has been minimized.

Member

mbasaglia commented Nov 18, 2015

I don't have a preference, but if we are going to choose something, we must make sure it'll be maintained by someone, either internally or use a third party solution.

@DolceTriade

This comment has been minimized.

Member

DolceTriade commented Nov 18, 2015

unvanquished-master is maintained by us as required. There has been no need to change it in 2 years.

@Veyrdite

This comment has been minimized.

Member

Veyrdite commented Nov 18, 2015

Would we reconsider changing the master server comms protocol, or keep it the same and just extend it with more /tags/being/sent/ ? I remember someone who wrote a server listing client (for multiple games) had concerns with the proto being changed.

@Viech

This comment has been minimized.

Member

Viech commented Nov 19, 2015

The master server doesn't have this issue – only clients filter by the protocol number as far as I know. However, we could change or extend the query protocol to make it easier for external server browsers. I would argue that if there is no alternative master server to begin with, we could just make this one the official one for now. We can call it DaemonMaster and if we ever adopt or write a new one call it DaemonLeader or so.

If that works then we have

  • Try to merge navmesh generation upstream.
  • Move the master server.

For Sloth and Chameleon I'd say since they belong in Dæmon's development toolchain and also depend on the engine (map and shader format) but not on the game they should be moved. The same is true for Crunch – any objections to moving it @DolceTriade?

@DolceTriade

This comment has been minimized.

Member

DolceTriade commented Nov 20, 2015

No objections here.

@illwieckz

This comment has been minimized.

Member

illwieckz commented Dec 12, 2015

About the navmesh merge upstream, I already did the work some month ago, upstream just need to merge it but since I'm very busy these days time has passed and I probably have to sync my fork with upstream before merge, it's just a matter of time and there is no blocking issue I guess. It just need to be achieved.

I agree it's far far better to push changes like that upstream instead of maintaining daemonmap. Also, upstream is hosted by Xonotic who are kind people. It's better to work with them when it's possible.

@Viech

This comment has been minimized.

Member

Viech commented Dec 12, 2015

@illwieckz nice, can you poke them about the merge again? Would be one repo less to worry about.

@TimePath

This comment has been minimized.

Contributor

TimePath commented Apr 16, 2016

Many of the daemonmap patches @illwieckz created have been merged upstream into xonotic/netradiant, navmeshes still remain (I'm not happy that certain aspects are hardcoded)

@illwieckz

This comment has been minimized.

Member

illwieckz commented Apr 16, 2016

In fact almost all my commits were done to make map contribution to unvanquished easier, but only the navmesh patches come directly from daemonmap. There was another patch to add the unvanquished game to q3map2 I rewrote reading daemonmap source and some unmerged patches by neumond which was not directly copypasted from source (at least copying comments) but it will probably looks almost 1:1 from these two other trees, spaces excluded. Btw, it's true, the only last need for daemonmap is navmesh.

Yesterday Fuma said on IRC:

<Fuma> speaking of bots
<Fuma> recast/detour desperately needs updating

It seems these libs also live in Unvanquished repository (see #935), a submodule for them will help both the Unvanquished source tree and the navmesh integration in q3map2.

@illwieckz

This comment has been minimized.

Member

illwieckz commented Jan 29, 2017

I guess both Chameleon, Sloth and Crunch can be moved without having to wait for the other ones.

@illwieckz

This comment has been minimized.

Member

illwieckz commented Jan 30, 2017

About Daemonmap, it's not a problem if we keep it for navmesh compilation only (perhaps someone have to edit the readme to tell people to not use it for everything else than navmeshes, telling q3map2 from netradiant must be used for everything else than navmeshes).

I currently don't have time for the q3map2 navmesh branch currently and it's clearly a low priority since daemonmap does the exact same job (my navsmesh branch is an 1:1 with no improvement), it can wait, there is no urge.

So Daemonmap can be moved to @DaemonEngine too. If one day some work is done on q3map2 again and the navmesh code is merged, well we will be able to remove it from there, but it's about months or years.

About the master server… it's probably a good idea to put it on @DaemonEngine too. This way, it becomes the reference implementation for Daemon based games if they are in need of a master server.

@illwieckz

This comment has been minimized.

Member

illwieckz commented Feb 12, 2017

Where is the best place for recastnavigation and breakpad ?

recastnavigation is currently stored on @Unvanquished organisation, but it's used as Daemon submodules at @DaemonEngine organization. The navmesh thing will probably moved back to sgame one day, it was included in the engine back in the qvm day due to qvm limitations, see #982. By the way, the recast/detour stuff is also used by q3map2 in its navmesh branch, and to be merged the detour/recast things must be added as submodule first.

So, even if one day all the navmesh thing is moved in sgame, it's still relevant to host recastnavigation in @DaemonEngine organization since it's used by more than one Daemon-related works. Also, it makes sense for Daemon based games (like UnrealArena or Daemon-based Xonotic) to use the same recastnavigation version as ours (with same tweaks) if they want to use this kind of technology too. @DaemonEngine is a good place for shared Daemon-related stuff, even if it's a game dependency and not an engine dependency: it's a Daemon-based game dependency that can be shared with other Daemon-based games.

Same question comes for the breakpad fork we maintain, it's an engine thing, it's probably better to put it on @DaemonEngine organisation too.

If someone reuse Daemon as submodule for its own project, it looks weird the Daemon source tree relies on Unvanquished specific things.

@Viech

This comment has been minimized.

Member

Viech commented Feb 12, 2017

I agree with @illwieckz, recastnavigation should move to @DaemonEngine as long as daemon depends on it and potentially longer, if other projects also start using it. breakpad, however, should only move if it's readily usable with pure daemon, that is if using it is as easy as setting a cmake flag. If it's not that easy to use yet, I'd rather keep it on @Unvanquished for now, as we should not clutter @DaemonEngine with unfinished/half-working stuff like we did with @Unvanquished.

@slipher

This comment has been minimized.

Contributor

slipher commented Feb 16, 2017

There's nothing inherently Unvanquished-specific related to Breakpad AFAICR. It's only needed for engine crashes, not ones in VMs. It can be enabled or disabled with a CMake flag. And I would guess that changing the URL of a submodule is painful... It is still not implemented for OS X though.

@illwieckz illwieckz changed the title from Move some repositories to @DaemonDevelopers. to Move some repositories to @DaemonEngine. May 10, 2018

@illwieckz

This comment has been minimized.

Member

illwieckz commented May 10, 2018

Github now allows to transfer repositories across owner, redirecting old urls.
I just transferred Sloth and Chameleon, too bad we moved crunch the fork&delete way but for future transfer it would be better.
Thanks to that transfer and redirect mechanism we can probably move the recastnavigation and breakpad submodules too.

@illwieckz

This comment has been minimized.

Member

illwieckz commented Oct 27, 2018

I just transfered daemonmap: https://github.com/DaemonEngine/daemonmap

@illwieckz

This comment has been minimized.

Member

illwieckz commented Dec 1, 2018

So, unvanquished-master is the only remaining repository that had not received any care yet, what to do with it?

Edit: well, the last one from the list in initial message, there is still recastnavigation and breakpad too.

@slipher

This comment has been minimized.

Contributor

slipher commented Dec 1, 2018

Well does anyone have concrete plans to use it for something besides Unvanquished so far?

@illwieckz

This comment has been minimized.

Member

illwieckz commented Dec 1, 2018

that's my main concern for unvanquished-master, I'd say to not make the move of unvanquished-master a requirement for closing this issue, and it doesn't close the door for a future move.

for breakpad, it's clearly an engine thing, so it has to be moved.

for recastnavigation, there is the question about bot navigation having to be part of engine or gamecode, currently there is part of bot code in engine (the code requiring recast, precisely) so technically it's today recast is an engine dependency, some people would ask why not move the whole to gamecode but I'm not sure we can and perhaps some wanted features can't be moved entirely to gamecode. The future of that recast code is to also generate navmeshes from bsp at runtime and cache them in user's cache dir and we want the engine rendering minimaps from such navmeshes, so I guess there will always some bot stuff in engine so we can move recast in @DaemonEngine organization.

@illwieckz

This comment has been minimized.

Member

illwieckz commented Dec 2, 2018

Moved recastnavigation and breakpad, unmarked unvanquished-master as a requirement, done.

@illwieckz illwieckz closed this Dec 2, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment