Why are my loot_tables are not working but everything else is? Minecraft Fabric Modding - fabric

I am trying to create a fabric mod for minecraft that adds a new ores. I want to make it so that when an ore is mined it drops an item. Everything seems to be working great except for the loot_tables files. When any of the four blocks I have added a loot_table file for are mined they don't drop anything.
The only other issue I have had is that the ores I have added are extreamily slow to mine and I can not figure out how to make them mine faster.
Here is a link to the project files:
https://github.com/zebkane/uranium
Any help would be greatly appreciated.
I have tried everything I can think of but I'm pretty new to java and modding so I don't really know what I am doing. There are no errors and everything else in the mod works as exprected.

Related

Creating a Testing level

Im trying to build my first testing level in Cryengine.
Im really new to coding and c++ (basically a baby).
I have modelled the island in Cryengine.
I want to make a Server for my friend to log in to test If we would be able to run it-
I cannot find root/system.cfg to set parameters there I have looked everywhere for it. it is just hiding or I am doing something wrong?
I need to specify parameters: Set net_dedicatedServerArbitratorPort= in system.cfg to a sensible value.
Any help would be great :)
Thank you. Wish me luck.
I have tried looking in Visual Studio, Tried Cmake, Looked in every folder in the Directory of the testing island.
I really dont have and idea how to run it, im just trying to follow the Cryengine Manual.

Why is my VPython program running so slowly on this glowscript IDE?

so I'm currently struggling with figuring out why my VPython program runs so slowly. I worked on this with others a few months ago, and it was working perfectly fine then, but opening it now, the program became super buggy!
http://www.glowscript.org/#/user/cs5squad/folder/Public/program/Sep
I thought that maybe it was glowscript/VPython itself, but I looked at previous drafts of this project I did, and it was working perfectly.
http://www.glowscript.org/#/user/cs5squad/folder/Public/program/notlaggy
I worked on this project with someone else, and so I'm thinking that person may have added one line of code or something to make it work so slowly. I'm not a particular expert at VPython, so I'm a little lost as to what I can do to fix this.
Thank you so much in advance!
I think you have too many stars. Try changing
def star_maker():
"""Generates random stars."""
for x in range(10000):
to
def star_maker():
"""Generates random stars."""
for x in range(1000):
It seems to run smoother.

Using grunt + django, ways to speed up compiling some SASS? (3.3 and compass, with user themes)

THE PROBLEM
I'm looking for a way to decrease the 40-50 second wait every time our SASS needs to compile into main.css. I've already gotten it down from over a minute by switching from using Compass for compiling to using grunt-contrib-sass. I need to get it down to 5-10 seconds, or as close to that as possible.
CAN'T USE LIBSASS
I'm a little bit stuck using SASS 3.3 and Compass unless we absolutely have to switch for the performance. We do use bootstrap-sass so it would be hard to get rid of Compass entirely. This means we can't easily switch to libsass. But any code in Compass can also be copied from their repository directly into our _mixins partial so anything is possible with enough effort.
USER THEMES
The worst thing for our speed by far is that we have different usergroups, each with their own set of variables used to compile the SASS with a custom theme. So our SASS needs to compile once for the main theme, main.css, and then once more for each usergroup in the system to make their theme.css. As we add users the compile time that results when any of our main partials are changed increases linearly. Any suggestions to speed this up are also welcome.
REPLACE #IMPORT WITH REQUIRE?
I read on the TreeHouse blog that #import slows things down a lot when using the stock Ruby SASS compiler. We do have a lot of partials, and the user themes as well, and we have bootstrap-sass rigged to compile using our variables instead of bootstrap's default ones. So there are a lot of #import statements. TreeHouse used Sprockets in their Rails project, replacing #import with //=require, to speed up their ~1min SASS compilation to something like 3 seconds. Django has a port of Sprockets called django-gears, could implementing that have the same effect on our SASS? Can we use django-gears together with grunt? There doesn't seem to be much mention of using the technologies together in the Google-sphere.
(edit: found the article I was talking about, updated this section. http://blog.teamtreehouse.com/tale-front-end-sanity-beware-sass-import)
Edit 2: No, Grunt and django-gears don't really work together. I don't think we need to use Gears to achieve this effect though. I'm going to try using some sort of Grunt file concatenation plugin to replace the Sass #import statements, I'll report back here about what it does to our compilation time.
CONCLUSION
Anyway, that's all the research I've done so far, pretty much. We could rewrite our SASS to work with libsass, which would be tough and take a decent amount of time. We can implement django-gears to possibly-maybe speed things up using require. Or, not mentioned yet, we can replace Grunt with Gulp. Gulp seems to have a slightly faster version of grunt-contrib-sass but might cause trouble if we need a plugin later down the line that doesn't exist for Gulp (since Gulp is smaller/not as well-supported as Grunt).
Is there anything that I've missed so far in my research? Any further suggestions? I'm not terribly experienced so any sage advice Stackoverflow has to offer would be greatly appreciated. :)
Posting this as an answer instead of an update to the question because we did find an acceptable solution to our speed problems. There's always room for improvement though (and our compilation time is still hovering at a bit above average). I ended up refactoring everything to work with grunt-sass and our total compile time, including all main and customer themes, dropped to ~5 seconds.
By the way, using grunt-concat or any other way to circumvent the Sass #import statement didn't speed things up at all. I'm not sure what crazy bug the TreeHouse Blog developers experienced that implementing Sprockets fixed, but what worked for them didn't work for me.
The real breakthrough came when I found the article Is Libsass, the lightning fast Sass compiler, ready for prime time?, written by Ben Frain. He mentions a library called sass-list-maps, written by Lu Nelson, that emulates Sass 3.3 maps in lower versions of Sass. Using sass-list-maps and some of the other tips in that article, I refactored our Sass until it resembled a much earlier version. It didn't take a huge amount of time despite our large codebase, I just commented out all the partial imports in partials/_all.scss and added them back in one at a time, compiling with grunt-sass each time and fixing any errors (manually inspected the CSS too, there were some bugs there that didn't cause compilation errors).
The only thing left to work around was Compass, which wouldn't compile with libsass even after I copied it into our project from github. We ended up replacing Compass with Bourbon, a mixin library that will add itself to the file structure of your project so it is easily accessible to import. It also has the side-effect of being very lightweight and sharing most of the same syntax as Compass so almost no changes were in order there. It's fully compatible with libsass/node-sass.
In the end, our Sass compiles way faster, and everyone is happy. 5 seconds is still a little on the long side with grunt-watch running it's only a minor annoyance. If I manage to bring the compile time down more I'll post how I did it here as well.

How to solve cache? issue when using jasmine standalone

When I go to SpecRunner.html in my browser, the unit tests run fine. The issue I am having is if I change one of the tests, or the code that it tests and refresh the page, it doesn't load the new tests or change at all. I thought that this would be a cache issue, but I have the chrome dev tools disable cache selected.
What am I doing wrong?
Thanks
EDIT: tried restarting my computer, nothing. Clearing cache, nothing. I don't understand why this would be happening.
EDIT2: tried force reload, nothing... changed the file name and reference and still loaded the old code...
This might not answer your specific problem, as there are a million reasons this could happen.
For me, it was because I had deleted some files and then re-added them as a git submodule. After doing this, ls was showing me the OLD files, and I didn't realize that I had to go up a directory and then back in to interact with the new files I had just pulled down.
Old question but I ended up here when looking for an answer, so here's my solution in case it helps anyone - I was having a similar problem with jasmine-rails, removing jasmine-specs.js from public/assets did it for me. I'm using the jasmine-rails gem from https://github.com/searls/jasmine-rails.

Problem with editing Template Monster .fla file

I am having the worst luck with this. We bought a template to update our own website (don't have enough time to start our own from scratch!) but when I make simple changes in the Flash CS4 native file and re-export the swf, it doesn't work correctly!
I am wondering if anyone has run across the same problems with a Template Monster Flash website template.
Thanks.
Please give us more details by what you mean with "it doesn't work correctly!". Text is the wrong size? Buttons don't work? Entire screen is blank? etc etc
One thing to try is check what version of flash and what version of actionscript you are exporting to, make sure they are the same versions it was designed with. You could also try downloading an older version of Flash and see if that fixes the problem (they all have 30-day trials). And finally, you did pay money for a product, if it's defective, contact the people that sold it to you.
use flash mx ppl..it's so easy..