DavidJCobb

Some feedback, before I switch back to classic: I like the new header typeface a lot more than what's in classic. 250px-tall banner ads are massive -- literally an entire quarter of my screen height on a 1920x1080px desktop. Both the classic and beta layouts have a 250px banner ad on the profile page above the meaningful content; however, the classic profile page has a more compact layout. In both layouts, the profile content ends up nearly a third of the way down the screen at initial load. In the classic layout, the meaningful profile content (i.e. the tabbed view) is halfway down the screen, which isn't great. The beta layout is significantly worse due to its bulk, however, with the meaningful content being two-thirds down the screen and the "About Me" text being almost entirely below the fold. This is really bad. Bold text in the About Me section has its font color forced to white. If you use bolded hyperlinks with the bolding inside the hyperlink markup (rather than vice versa), then it becomes impossible to tell that the hyperlinks are hyperlinks. The offending selector is .prose-lexical :where(strong):not(:where([class~="not-prose"] *)) and I don't know why it exists. This isn't a hypothetical problem, either; it affected my migrated About Me text when I switched to the beta. Repro (markdown): [**Cobb Positioner**](http://www.nexusmods.com/skyrim/mods/74768) The mod list in the beta layout handles long mod names very poorly compared to the classic layout. The classic layout is willing to let the title consume more space and leave less space to the description; the new layout is rigid. Compare the images below (classic on the left); test-case is this mod which has a joke name. In both layouts, the mod list consists of one "card" per mod. In the classic layout, only the mod name, mod image, and specific (colored) pieces of text were hyperlinks. In the new layout, the entire card acts as a hyperlink to the mod, making it impossible to (via the card) jump to the mod's containing category, select and copy text from the title or blurb, or click on the author's name within the card to go to their profile. In particular, breaking text selection is annoying. The media list on our profiles has a similar issue to the mod list with respect to media titles; however, it's even worse, with even relatively short media titles being truncated. Compare the classic layout to the new one: I know that "just use the old design" is a bit of a cliche, but I can think of no better solution in this case. At the very least, the title should have a row to itself as it does in the old design, without having to compete with the stats or the profile picture for space. Were I in charge of revising this design, I might also show the profile picture in miniature to the left of the author name, getting rid of the word "by." Infinite scrolling is a pox on our society and it should be sent back to Hell where it belongs. In my experience, pagination is generally far better for usability (you can more easily know where you are within a list, and how large that list is) and appreciably better for performance (especially in memory-constrained environments like mobile browsers, where a theoretically unbounded amount of content being shoved into the DOM seldom ever ends well). Please rethink switching to infinite scrolling. I greatly, greatly dislike that the default sort order for profile content is the same as whatever our prefs are set to for searches. When I'm searching for other people's content, I generally want to find the most popular stuff first. However, if I'm looking at a specific content creator's works, I generally want to see it in reverse-chronological order -- see their latest and greatest stuff first, rather than legacy content. Additionally, I as an author would want someone to see my newest stuff first, rather than the same handful of popular mods, if they're specifically going to my profile to look for my content. I think it's user-friendly for profile URLs to contain usernames rather than user IDs. However, usernames feel more brittle, given that people are allowed to change theirs. I like that ID-based URLs still work, and at minimum I would appreciate having a reliable way to get an ID-based URL through the site UI, perhaps with a "Permalink" button or something similar. If you don't disclose your location on your profile, it displays as "Not Set." I think it'd be cleaner to avoid displaying it at all. Every page load seems to request a 930KB JSON payload (compressed to 145KB during transfer) containing the information for every single game that NexusMods supports -- about six thousand of them. This seems wasteful right off rip, but it doesn't get better when you actually look at the data. Each game in this payload contains: Name. Name but in lowercase. Why? There is literally a JavaScript function that does this for you client-side, and it takes, like, two picoseconds to execute. Forum section URL. Games that have no dedicated forum section still have this field and use the forum homepage as its value, so I'd ballpark it at around five or six thousand copies of the forum home page URL in this JSON payload. The URL for the game's section on NexusMods. As far as I know, game URLs follow the same format (nexusmods.com/gamename), so that's around six thousand redundant copies of the Nexus's domain name in this JSON data just for this one field. The subdomain name for the game's section on NexusMods: every game is accessible as gamename.nexusmods.com which I believe is done for backwards-compatibility. I haven't checked all six thousand games but glancing at a few, it seems like the subdomain name and the pathname are the same, so this is yet more redundant data. Basic stats: number of files; number of collections; date the game was added to the site; that kind of thing. At least this mammoth JSON payload gets cached so it only wastes tons of bandwidth for your first-ever pageload, but this is still ridiculous.

So Russia's answer to a (civil) war in Ukraine, was to invade and start a larger scale war??? Please explain the logic of that to me, because I sure ain't seein' it. neo-nazis can't kill people who are already dead (they can certainly recruit the traumatized, angry, disoriented, and more easily manipulated survivors, tho, but i guess that doesn't really matter so much to neanka)

"I wasn't wrong! You're just nitpicking, and also I was thinking of a completely different thing that I wasn't replying to and didn't mention." wow lol yeah, i think that's enough for me. i'm out

So if they can pay out 101k, why do they need money? to pay out 101k https://techcrunch.com/2018/07/01/wtf-is-dark-pattern-design/ https://medium.com/beautiful-code-smart-design-by-10clouds/5-common-ux-dark-patterns-interfaces-designed-to-trick-you-61fdede9718c You blatantly don't understand what a "dark pattern" is, and either plucked those articles off of Google without reading them, or read them and failed spectacularly at understanding them if you even tried at all. None of the examples in the articles you've linked to line up with what the Nexus is doing. You linked to those articles as a (lazy) way of rejecting someone else's statement that the Nexus doesn't trick people into thinking that Premium is needed. A picture's worth a thousand words, so here's a picture showing how the Nexus doesn't trick people into thinking Premium is needed: Now, if the Nexus form looked something like this (which I've actually seen on random websites before), then you'd be on to something: Fortunately, it does not.

anything you want in your comment (site rules still apply here!)

Di0nysys is correct. It's worth noting that nodes can share BSShaderTextureSet blocks, but not BSLightingShaderProperty blocks; trying to share the latter will cause crashes.

Scripts need to be compiled in the CK (or using the Papyrus Compiler that the CK uses). They are not compiled at run-time.

The script as written wouldn't even need to limit itself to 100 objects. It stores found objects in an array (limited to 100 items), but the array is never actually used. If all you want is to print object data to the Papyrus log, then ditch the array entirely and don't cap cellRefs.

If you don't mind -- I'm actually curious as to how you got an EffectShader to only apply to a human's head, because I don't see anything in the EffectShader data that would allow you to specify that. As for the difference between humans and Dwemer robots, the former use morphable/customizable FaceGen heads, specifically. I think the "Head" option in the Actor window is meant to preview those, not just any head.

Enable/disable parents are by far the best option for this situation. The difficulty in editing everything is very easily solved. If you select an enable-state parent and press Ctrl + 1, you can toggle the visibility of its enable-state children. Shift + 1 toggles the visibility of opposite-state children. This is exactly the kind of assumption that leads to bugs, though. A player could drop items in there if they're running low on inventory space but don't really want to get rid of something (e.g. dropping alchemy supplies on the floor for later). A player could drop items in there if they want to decorate the space. If they're role-playing, then maybe they think a dilapidated living space is fitting for their character, and they'll get it cleaned up later (and expect not to lose their things). Another mod could cause the player to drop items in the room, or could spawn markers at the player's feet while they're in the room. Depending on what that mod does, this could go very badly; picture a "Farore's Wind"-style teleport system, which could port the player into the "wrong" room if they set a warp point and then upgrade the house in the meantime. If you ship the mod and run into any of these problems, you're going to have a very hard time fixing it in a backward-compatible way. I cannot overstate how much better enable-state parents are for this sort of thing.

I've got a copy of the SKSE source code on hand (and therefore, most of the engine-level stuff that the community has decoded). I can tell you that the only MiscObjects that are fundamentally different are apparatuses (an Oblivion leftover), keys, and soul gems. Technical explanation: All other misc objects are just TESObjectMISC under the hood. They are distinguished only by the usual item data -- name, model, value, weight, and keywords. If "apparati, keys, soul gems, and other" isn't specific enough for you, then you'll want to check keywords in the Creation Kit and see if there are any useful ones that your script can check for (here's a function that might be better for looping).

It's not clear from your post whether you know this, but those events are only notified about the death of the actor they're attached to. If you want to do something when Bob, specifically, dies, then you need to put the script on Bob somehow. If you did put the script on the right character, then how did you do it? If your script is attached directly to the actor whose death you want to monitor, then don't do that unless that actor is added by your mod. Direct edits to actors can cause conflicts: only the last-loaded set of edits will actually take effect. Use a magic effect or a quest alias instead. Quest aliases allow you to attach data to an actor (the one that "fills the alias") for the duration of a quest. You'll want to have your script extend ReferenceAlias and attach the script to the alias. If you use an alias and still can't get it to work, make sure that it's being filled properly (i.e. it can "find" the actor) and that the quest is starting properly. If you need to monitor a specific actor's death, this is the easiest way. Magic effects in spells can have scripts attached to them, which can be notified about things that happen to the actor who has the effect. Those scripts should extend ActiveMagicEffect and be attached to a magic effect; that effect should belong to a spell, which you apply to the actor somehow (e.g. a cloak, an alias). If you use a magic effect and still can't get it to work, make sure that the effect is actually being applied (one way is to just give the effect a magic glow and see if that shows up in-game). This approach works best when you need to monitor varying actors, e.g. anyone near the player.

In response to post #56096151. #56096866, #56097731, #56102286 are all replies on the same post. Ah, the "How can mod author permissions be real if our eyes aren't real?" argument.

Given an Int[] Property UpgradeSpell, do: If KillCount == 5 UpgradeSpell[SpellToTrack] += 1 EndIf See, you're allowed to use arrayVariableName[intVariableName] to grab the (intVariableName - 1)-th entry in the array.

So if I'm understanding you right, you only have five Spell forms in the Creation Kit, and you apply the upgrades to these using scripts on their magic effects. If that's the case, then you just need an array of five Spells on your script. Maybe. Maybe not. The trick with arrays of forms is that you have to set their values in the Creation Kit. When a player installs your mod and starts playing, the values that are in the mod at that time are written into their save file. If you decide to update your mod with more spells, and you put more spells in the array, then that update will work for new users, but old users will still use the old spell list even after they install the updated mod (because the old list is in their save file). For your use case, I would recommend using a FormList of spells instead of a Papyrus array. A FormList is a form that only exists to provide a list of other forms. Like arrays, FormLists are edited in the Creation Kit and can be used with scripts; however, save files handle them differently, so you can actually update them when you update your mod.