0002357: Merge skulltag_actors.pk3 with skulltag_data.pk3

Notes
(0012990) AlexMax (developer) 2015-07-22 00:14	Strong rejection. Zandronum is not Skulltag, and nothing that is vital to the functioning of Zandronum is in skulltag_actors.pk3. How about this suggestion? Skulltag Actors should be continued as a third party project and removed from Zandronum completely. That way, it becomes just another PWAD that is updated like other PWADs are.

(0012991) Hypnotoad (reporter) 2015-07-22 00:26 edited on: 2015-07-22 00:27	Quote Strong rejection. Zandronum is not Skulltag, and nothing that is vital to the functioning of Zandronum is in skulltag_actors.pk3. It shouldn't matter if Zandronum is Skulltag or not, we're long past this. Zandronum.pk3 already has a dedicated actors/skulltag/ folder for items that cannot be separated, so Zandronum.pk3 does not and cannot even adhere to this principle. Quote How about this suggestion? Skulltag Actors should be continued as a third party project and removed from Zandronum completely. That way, it becomes just another PWAD that is updated like other PWADs are. I'd support this alternatively if we can combine skulltag_actors and skulltag_data together into one pk3, Carn actually gave me permission to maintain st data when I spoke to him about it via Steam.

(0012992) Leonard (developer) 2015-07-22 00:50	Quote combine skulltag_actors and skulltag_data together into one pk3 I would prefer this, I think it's a better idea.

(0012993) Frits (reporter) 2015-07-22 09:06	why not? Zandronum is everything skulltag once was and more. plus it makes running st modes more user friendly.

(0012994) Blzut3 (administrator) 2015-07-22 18:19	Quote expect the problem of out of date versioned st_actor pk3s being hosted everywhere and other problems to persist in the future. Doomseeker solved this long ago, but server admins don't care. Doomseeker will never query Wadseeker for skulltag_actors.pk3 now since it will always find the one next to zandronum.exe. Zandronum also has the GAMEINFO lump now which you should be able to request that skulltag_actors.pk3 be loaded as a dependency if your mod uses them. This is what skulltag_data should do so that it autoloads the actors pk3.

(0012995) Hypnotoad (reporter) 2015-07-22 18:42 edited on: 2015-07-22 18:46	Quote Doomseeker solved this long ago I think there are many people who tend not to update their server browsers often, and a large number of people are still using old versions of IDE. Quote Zandronum also has the GAMEINFO lump now which you should be able to request that skulltag_actors.pk3 be loaded as a dependency if your mod uses them. Can server browsers read the gameinfo (e.g. if someone needs st_data for their mod)? What happens if you connect without having the wad required in gameinfo? Quote This is what skulltag_data should do so that it autoloads the actors pk3. So if I modify st data to auto load st actors in gameinfo, and then have a mod autoload st data via its own gameinfo, will that result in both st data and st actors being loaded when running the mod? In general I do not understand the opposition to this at all. Absolutely nobody likes the current situation with the awkward hassle of having to load two pk3s for so many projects. Something has to change, if you really want to distance yourself from Skulltag then there is no reason to maintain st actors at all - you should let it be maintained 3rd party as AlexMax said (so it can be merged into st data). The current position of "we want nothing to do with skulltag", while actively maintaining skulltag_actors and distributing it with Zandronum, is totally incoherent and causes hassle for no good reason. If however maintaining compatibility with skulltag projects, and therefore maintaining st actors, is vital for Zandronum, then that's an exceptionally good argument for merging the two pk3s.

(0012998) Blzut3 (administrator) 2015-07-23 01:02 edited on: 2015-07-23 01:05	Quote I think there are many people who tend not to update their server browsers often, and a large number of people are still using old versions of IDE. Doomseeker auto updates now. If they're using an old version then there's really no excuse. Besides I think the version of Doomseeker included with 1.2 has the feature in question, it has been awhile. Quote Can server browsers read the gameinfo (e.g. if someone needs st_data for their mod)? What happens if you connect without having the wad required in gameinfo? Files pulled in with GAMEINFO are loaded before the wad with the GAMEINFO lump. These files get advertised by the server as usual. The difference is that the person setting up the server doesn't need to think about skulltag_actors.pk3 which is exactly what you want. Quote So if I modify st data to auto load st actors in gameinfo, and then have a mod autoload st data via its own gameinfo, will that result in both st data and st actors being loaded when running the mod? Yes. There might be some growing pains with getting the mod to load skulltag_data automatically since Zandronum needs to be aware of where the files are in order for it to work, but Zandronum should always be able to find skulltag_actors.pk3. Quote In general I do not understand the opposition to this at all. Absolutely nobody likes the current situation with the awkward hassle of having to load two pk3s for so many projects. The reason it is this way is to effectively deprecate Skulltag. It's a compatibility layer. The reason it's not merged with data is because actors implements more or less the native actors which may need to be changed with Zandronum updates (similar to how we did for 2.1 even though the last update prior was 1.1.1). Doing it this way allows us to be as close to upstream (G)ZDoom as possible which increases (G)ZDoom mod compatibility. In any case it's a total non-issue if you guys would just use the features we've added to make it a non-issue. If Doom Explorer doesn't handle skulltag_actors.pk3 as well as Doomseeker you should prod bond to also implement a priority file search so that it always locates the file next to the binary. Furthermore keep in mind that the people that had issues with updating their copy of skulltag_actors are the ones that are using the out of the box experience. Edit: I'm looking at the contents of skulltag_actors again. It might be worth discussing if more of the contents can be shifted over to skulltag_data. I don't know why we ship the statue actors for example.

(0012999) Hypnotoad (reporter) 2015-07-23 15:07 edited on: 2015-07-23 15:17	Quote Doomseeker auto updates now. If they're using an old version then there's really no excuse. Besides I think the version of Doomseeker included with 1.2 has the feature in question, it has been awhile. The point is, if I'm hosting a server I'll always use a versioned skulltag actors because of all the hassle caused in the past, and because there is no way of guaranteeing that the people connecting will be using an up to date doomseeker, rather than some old version of IDE say with old versions of st actors in their pwad directory (in fact I'm not sure if even the latest IDE/DE prioritizes Zandro directory and prevents getwad from getting st actors). I doubt any of the hosts of the major clusters will risk it in the future either. Regardless this is only one issue. The main thing is I cannot see any positives from separating skulltag actors into a separate pk3 out of Zandronum.pk3, only hassle. When I spoke to Edward-san, he seemed to suggest that there was no technical reason they can't just be merged, and that it's more about PR and the desire to distance Zandronum from Skulltag. As a PR move I think this has backfired quite badly, because it's probably just breaded more annoyance from the community. Quote The reason it's not merged with data is because actors implements more or less the native actors which may need to be changed with Zandronum updates (similar to how we did for 2.1 even though the last update prior was 1.1.1). Right, so we've established that skulltag actors are actually an important part of Zandronum development and you want to actively ensure Zandronum remains compatible and functional with Skulltag projects. So in that sense it appears to be similar to how Zandronum.pk3 is updated to ensure compatibility with Doom, Heretic, Stife, Hexen, Chex.. and Skulltag funnily enough. So why can't you just put the remaining actors actors, from Skulltag_Actors, into Zandronum.pk3's actors/skulltag/ directory for a start? Quote Doing it this way allows us to be as close to upstream (G)ZDoom as possible which increases (G)ZDoom mod compatibility. But would having the skulltag actor definitions in Zandronum.pk3 actually decrease compatibility with (G)ZDoom projects at all? This is one of the reasons why I raised the issue in the first place, because as far as I could tell there are no conflicts between any of the actor definitions in Zandro and skulltag actors. If however having the ST actor stuff decreases compatibility then I suppose that's a legitimate argument to keep it out. Incidentally, even though the developers have no interest in maintaining anything to do with skulltag_data themselves, would it be legal for a third party to distribute a new pk3 that merges skulltag actors and skulltag data together (assuming permission from Carn to modify st_data)? Cheers, and sorry for all my whinging and pestering!

(0013000) Blzut3 (administrator) 2015-07-23 17:35	Quote The point is... So let me get this straight, server admins are being stubborn and thus you find it weird that we're also being stubborn? Why should we clutter our project when we already implemented solutions? Just because there might be some users on old versions that don't know any better? Shouldn't we try to get them up to date? Quote As a PR move "PR" is a bit incorrect. It's a deprecation move. We're trying to get closer to upstream to allow faster code base upgrades thus we want to separate the Skulltag-isms into a mod. The recent change was reverting one of those Skulltag-isms which required a change in skulltag_actors.pk3 to keep the old behavior in Skulltag mods. Quote But would having the skulltag actor definitions in Zandronum.pk3 actually decrease compatibility with (G)ZDoom projects at all? Some edge cases involving actor conflicts (mostly worked around though). I'm open to having a discussion on working towards moving skulltag_actors.pk3 into skulltag_data.pk3 either in part or entirely. I should probably invite you to a dev meeting so we can properly evaluate this issue in real time.

(0013001) Hypnotoad (reporter) 2015-07-23 18:42 edited on: 2015-07-23 18:44	Quote So let me get this straight, server admins are being stubborn and thus you find it weird that we're also being stubborn? It's not necessarily stubborn, if there are multiple versions of a file with the same name floating around, and you have no means of knowing how all the users will be connecting to your server, it becomes prudent on their end to use a versioned file just to make sure. Quote Why should we clutter our project when we already implemented solutions? Honestly I personally feel that having to distribute Zandronum with a separate PK3 is actually more clutter, at least on our end, compared to neatly packaging the skulltag actor definitions into Zandronum.pk3. Quote Just because there might be some users on old versions that don't know any better? Shouldn't we try to get them up to date? Yes we should. I think part of the problem was that Zandronum didn't give a clear error message, so many had no idea exactly why they couldn't connect, even if they were sure their skulltag_actors was up to date. Should probably be looked into. Quote I'm open to having a discussion on working towards moving skulltag_actors.pk3 into skulltag_data.pk3 either in part or entirely. I should probably invite you to a dev meeting so we can properly evaluate this issue in real time. Sure, although I'm sure merging the two pk3s is fairly straightforward.

(0013009) Blzut3 (administrator) 2015-07-26 22:51	Recap from dev meeting: We're entertaining the idea of moving the resources out. The primary concern being the ability to update the actors should we have to revert any behavior to be in line with ZDoom. To that end, looking towards 3.0 we should identify any skulltag-isms left and trim any fat out of zandronum.pk3 if possible. As long as Carnevil allows Hypnotoad to update the Skulltag content then we should be able to reach that goal.

(0023216) Ru5tK1ng (updater) 2024-03-02 04:35	No change on Zan's end since skulltag_content is being maintained on its own.

This issue is already marked as resolved. If you feel that is not the case, please reopen it and explain why.
Supporters:	DrinkyBird Frits ibm5155 Leonard
Opponents:	AlexMax Dusk Blzut3 Monsterovich

Issue History
Date Modified	Username	Field	Change
2015-07-21 18:08	Hypnotoad	New Issue
2015-07-22 00:14	AlexMax	Note Added: 0012990
2015-07-22 00:26	Hypnotoad	Note Added: 0012991
2015-07-22 00:27	Hypnotoad	Note Edited: 0012991	View Revisions
2015-07-22 00:50	Leonard	Note Added: 0012992
2015-07-22 09:06	Frits	Note Added: 0012993
2015-07-22 18:19	Blzut3	Note Added: 0012994
2015-07-22 18:42	Hypnotoad	Note Added: 0012995
2015-07-22 18:44	Hypnotoad	Note Edited: 0012995	View Revisions
2015-07-22 18:46	Hypnotoad	Note Edited: 0012995	View Revisions
2015-07-23 01:02	Blzut3	Note Added: 0012998
2015-07-23 01:05	Blzut3	Note Edited: 0012998	View Revisions
2015-07-23 15:07	Hypnotoad	Note Added: 0012999
2015-07-23 15:08	Hypnotoad	Note Edited: 0012999	View Revisions
2015-07-23 15:09	Hypnotoad	Note Edited: 0012999	View Revisions
2015-07-23 15:17	Hypnotoad	Note Edited: 0012999	View Revisions
2015-07-23 15:17	Hypnotoad	Note Edited: 0012999	View Revisions
2015-07-23 17:35	Blzut3	Note Added: 0013000
2015-07-23 18:42	Hypnotoad	Note Added: 0013001
2015-07-23 18:43	Hypnotoad	Note Edited: 0013001	View Revisions
2015-07-23 18:44	Hypnotoad	Note Edited: 0013001	View Revisions
2015-07-26 22:46	Blzut3	Target Version	=> 3.0
2015-07-26 22:51	Blzut3	Note Added: 0013009
2015-07-27 16:05	Dusk	Priority	high => normal
2015-07-27 16:05	Dusk	Status	new => acknowledged
2015-07-27 16:05	Dusk	Summary	Merge Zandronum.pk3 and skulltag_actors.pk3 => Merge skulltag_actors.pk3 with skulltag_actors.pk3
2015-07-27 16:06	Dusk	Summary	Merge skulltag_actors.pk3 with skulltag_actors.pk3 => Merge skulltag_actors.pk3 with skulltag_data.pk3
2024-03-02 04:35	Ru5tK1ng	Note Added: 0023216
2024-03-02 04:35	Ru5tK1ng	Status	acknowledged => closed
2024-03-02 04:35	Ru5tK1ng	Resolution	open => no change required

Relationships