View Issue Details

IDProjectCategoryView StatusLast Update
0004037unrealircdpublic2019-09-11 22:21
ReporterkatsklawAssigned ToGottem 
PrioritynormalSeverityfeatureReproducibilityN/A
Status closedResolutionduplicate 
Product Version 
Target VersionFixed in Version 
Summary0004037: [feature] require|deny module block
DescriptionThis block will require a linking server to have a specific list of modules loaded to successfully connect to the network. This is helpful to enforce modules that must be loaded on all servers on the network. This block should have the ability to require certain modules as well as deny modules.

To support this block a list of modules will need to be sent during burst.

module
{
   type require|deny;
   name "m_stinkyfeet";
   reason "no stinky feet allowed!";
};
TagsNo tags attached.
3rd party modules

Relationships

duplicate of 0005369 has patchGottem Detect missing (global) mods network-wide 
child of 0005282 assignedGottem Gottem's todo list yo 

Activities

Stealth

2011-08-06 18:58

reporter   ~0016737

I'm not sure how this could be added and still maintain backward-compatible linking capabilities. This is mainly because s2s communication is not sanity checked (reasons are explained in other notes), so introducing an unknown command to earlier versions may cause crashing.

katsklaw

2011-08-06 19:14

reporter   ~0016738

well if I'm not mistaken, unreal ignores unknown s2s data as-is. if a server sends a list of modules in a raw 005 or CAPAB manner I'm fairly certain that it'll be ignored. There really isn't any way to desync a server with it.

Obviously, a change like this to the protocol will warrant a bump in UnrealProtocol, thus allowing the use of a deny version block to prevent a hybrid network.

Additionally, if I am incorrect about unknown s2s data being ignored. A question in the Config script can ask if older versions are going to be used(default to 'yes' for sanity) and if so, disable this feature.

Stealth

2011-08-06 19:18

reporter   ~0016739

Or simply have the feature disabled if there are no blocks present, as well as a big fat warning about compatibility.

syzop

2015-07-19 18:40

administrator   ~0018524

Idea looks fine, though.. hmmm.. maybe it could be made more generic like not only requiring modules but channel/user modes? Then again, you can use the require module for that I suppose... we could stick with that.

I'm presuming this would work for directly-connected servers only, then it's fine.

Something more along the lines of other blocks though, like deny/allow channel, deny/allow dcc, so... deny/allow module? hmm.. ok.. deny/require module then :D
Also support multiple module names in one block? Or not?

I don't have plans to work on this (at this point anyway), but the idea is fine, I think.

There's a 'features' sub-struct in the server struct for things like this. Put a linked list in there.. free it at the right place... parser code... etc...

syzop

2019-08-27 14:19

administrator   ~0020858

See related new feature request 0005369 to do it in modules. Still this one is nice too.
And still probably use "require module" and "deny module" rather than module::type.

Gottem

2019-09-11 22:21

developer   ~0020882

Both this feature and the one Syzop linked above can (and prolly should) be done from the same module, so I'll close this one and continue in the other. Just seems silly to have 2 issues for the same module. :D

Issue History

Date Modified Username Field Change
2011-08-06 01:51 katsklaw New Issue
2011-08-06 18:58 Stealth Note Added: 0016737
2011-08-06 19:14 katsklaw Note Added: 0016738
2011-08-06 19:18 Stealth Note Added: 0016739
2015-07-19 18:40 syzop Note Added: 0018524
2015-07-19 18:43 syzop Status new => confirmed
2015-07-19 18:44 syzop Status confirmed => acknowledged
2019-08-27 13:39 syzop Relationship added related to 0005369
2019-08-27 14:19 syzop Note Added: 0020858
2019-09-10 22:29 Gottem Assigned To => Gottem
2019-09-10 22:29 Gottem Status acknowledged => assigned
2019-09-10 22:30 Gottem Relationship added child of 0005282
2019-09-11 22:21 Gottem Status assigned => closed
2019-09-11 22:21 Gottem Resolution open => duplicate
2019-09-11 22:21 Gottem Note Added: 0020882
2019-09-11 22:21 Gottem Relationship replaced duplicate of 0005369