2
Quote from FrozenArrow6
I have been talking to girls on this one dating site, but to no avail.
I can never get anything perfect, but I'm sure I will. I'm still lurking dating sites; I hope I can find someone eventually.
2
PortableJim answered this far better than I can articulate (and since you already read and replied to his post, there isn't much more for me to add on here).My thought on it, isn't that Modloader needs to follow suit, just to "not violate distribution rules" of Mojang's code... but to allow Modloader to still work, once the option to directly Jar mod is removed.Quote from King KorihorSo your criticism of ModLoader has nothing to do with being compatible with Forge or anything like that, but rather that ModLoader isn't doing the class injection system that Forge is currently using instead of modifying the "minecraft.jar" file. I've never really understood this mechanism anyway. Color me stupid and ignorant in the process, but how do you modify existing classes in Minecraft without modifying the jar files? I know that the Forge guys have been messing with some low level Java stuff and injecting things into the bytecode images, but it isn't as easy as you are suggesting or something that you need to "get with the program" as if it is something that should be head smacking obvious to all mod developers. If this is something that Mojang is insisting that all mod developers should be using for any mods that formerly would be injected into jar files like modding has been doing, I would agree that it is something that Risugami ought to be doing. Then again, other than some strange philosophical basis I really don't see, a run-time modification of classes is still pretty much the same thing as happens when you modify the jar files. I appreciate Mojang's concern about copyright violations and a sort of loose tolerance of that violation by people like Risugami as something that ideally shouldn't be happening. Yes, Risugami is distributing is stuff written by Mojang along with his own custom modifications to that code. I really don't see how the way the Forge is making those modifications is necessarily any better though.
Quote from notfoodYou do know that ForgeModLoader, isn't being killed, it's just the compatibility with the RisugamiModLoader. ModLoader style mods can still be written just as you have always do and they will work under Forge. The thing is, that style of modding ties you to a certain version of Minecraft, while using the Forge API allows you to do more with less code, without reinventing the wheel and making it compatible with other mods. -edit- I derped hard. ForgeModLoader is being killed. Rip in pieces. Even though it's being deprecated... It shouldn't be that hard to write a core mod that does implement the ModLoader interface. Hm... who wants to be the next Risugami?
Quote from HobbyboyForgeModLoader (or FML) isn't being killed off, it will always still exist as it powers Minecraft Forge. Without it, Forge would still need to use Modloader and ModloaderMP on the client, and ModloaderMP on the server. After the modding api comes out, it will still be around, but would probably be loaded by the built in modding api.
See... it's conflicting information like this, that has some people thinking: "Nah, Forge isn't going to change that much... Modloader mods will still work with FML the way they have before...", and others screaming: "It's the end of Modloader support in Forge forever!".We need a concise, and accurate statement from Lex, so there is no misunderstanding what is going to happen, post-1.7.x.Quote from portablejimForgeModLoader has had support for writing mods 2 ways: The Modloader way (i.e. to be compatible with RisugamiModLoader (RML)) or the Forge way. In 1.7, with the way it stands at the moment, ForgeModLoader will only support the Forge way.
I couldn't have said it better myself.Quote from portablejimModification works (at the basic level) because once you have 'loaded' classes up, you can have a look at the internals and modify them. The difficulty arises because the code has already been compiled and so you have to work at that low level. It does require more advanced knowledge of java, even when using additional libraries to help. It not only allows less of the original file to be distributed (i.e. basically none of it) but also allow multiple modifications of a single function to not interfere with each other. The changes in attitude are also due to the new launcher that makes it easier to mod without modifying the jar. The old launcher had some limitations:These limitations had the effect that in order for modding to work, you needed to modify the minecraft jar, distributing new classes. Alternative launchers had a custom list of files to load and would customize how it launched minecraft. This allowed jar files loaded later to override to replace classes with other ones, allowing class modifications to work without actually needing to modify the jar. The new launcher solves both problems of the old launcher..
- Fixed list of jar files to load. If your code to load other classes was not in minecraft.jar it would not load.
- Fixed entry point. If your code did not change the main minecraft function to load itself first, it would not load.
This allows you to either do the class replacement using the libraries, or use alternative code to patch minecraft. All without touching the jar.
- The libraries to load can be specified in the config file. This can include your code.
- The first class executed is specified in the config file. You can set this to your code to do what you need to do before actually starting minecraft.
1
Quote from King Korihor
So your criticism of ModLoader has nothing to do with being compatible with Forge or anything like that, but rather that ModLoader isn't doing the class injection system that Forge is currently using instead of modifying the "minecraft.jar" file.
I've never really understood this mechanism anyway. Color me stupid and ignorant in the process, but how do you modify existing classes in Minecraft without modifying the jar files? I know that the Forge guys have been messing with some low level Java stuff and injecting things into the bytecode images, but it isn't as easy as you are suggesting or something that you need to "get with the program" as if it is something that should be head smacking obvious to all mod developers.
If this is something that Mojang is insisting that all mod developers should be using for any mods that formerly would be injected into jar files like modding has been doing, I would agree that it is something that Risugami ought to be doing. Then again, other than some strange philosophical basis I really don't see, a run-time modification of classes is still pretty much the same thing as happens when you modify the jar files.
I appreciate Mojang's concern about copyright violations and a sort of loose tolerance of that violation by people like Risugami as something that ideally shouldn't be happening. Yes, Risugami is distributing is stuff written by Mojang along with his own custom modifications to that code. I really don't see how the way the Forge is making those modifications is necessarily any better though.
3
Quote from cloudeh
Alright, so offering mod devs an opportunity to get their mods updated faster without having to rely on forge is wrong? No one is saying "USE FML EXCLUSIVELY" (although its compatibility with Modloader is almost 100% with non jar mods). They are saying, if you want to update your mods before the 1.4.2 release, you can use FML since it includes a Modloader compatible API. It really isn't a difficult concept. Providing you stick with the Modloader API in your mod, it should just work - providing risu doesn't completely change the interfaces (and due to the lack of changes in 1.4.2, that is unlikely).
2
2
Quote from StarshadesJack
If you keep having ideas, keep throwin' 'em my way. I can't promise I can or would want to implement them, but it's always good to keep me interested!
It's not a matter of which is better. Forge has superior capacities in comparison to Risugami's ModLoader on its own. My issue is simply "was it truly necessary to phase out RML for FML?"
To date, nobody has satisfied me with their answer. How will an answer satisfy me? If I no longer feel the urge to ask "why?" or "And this was a problem that truly troubled you until this move?"
Yes, this response is different from prior ones. I'm trying to find a way to explain myself that makes absolute sense.
And, really, it does boil down to the fact that I'm not a "srs bzns" kind of guy in regards to Minecraft modding. I do not and will not approach the topic from a business standpoint. Only a functional entertainment one.
12
package net.minecraft.src;
public class mod_throwMod extends BaseMod
{
public mod_throwMod( )
{
}
@Override
public String getVersion( )
{
return "1.3.2";
}
@Override
public void load( )
{
}
}public static Item throwItem;
throwItem = new ItemThrowing(332).setItemName( "Throw Item" );
throwItem.iconIndex = ModLoader.addOverride( "/gui/items.png", "/ThrowMod/ThrowItem.png" );
package net.minecraft.src;
public class ItemThrowing extends Item
{
public ItemThrowing( int par1 )
{
super( par1 );
}
}/**
* Called whenever this item is equipped and the right mouse button is pressed. Args: itemStack, world, entityPlayer
*/
public ItemStack onItemRightClick(ItemStack par1ItemStack, World par2World, EntityPlayer par3EntityPlayer)
{
if (!par3EntityPlayer.capabilities.isCreativeMode)
{
--par1ItemStack.stackSize;
}
par2World.playSoundAtEntity(par3EntityPlayer, "random.bow", 0.5F, 0.4F / (itemRand.nextFloat() * 0.4F + 0.8F));
if (!par2World.isRemote)
{
par2World.spawnEntityInWorld(new EntitySnowball(par2World, par3EntityPlayer));
}
return par1ItemStack;
}package net.minecraft.src;
public class ItemThrowing extends Item
{
public ItemThrowing( int par1 )
{
super( par1 );
}
/**
* Called whenever this item is equipped and the right mouse button is pressed. Args: itemStack, world, entityPlayer
*/
public ItemStack onItemRightClick(ItemStack par1ItemStack, World par2World, EntityPlayer par3EntityPlayer)
{
if (!par3EntityPlayer.capabilities.isCreativeMode)
{
--par1ItemStack.stackSize;
}
par2World.playSoundAtEntity(par3EntityPlayer, "random.bow", 0.5F, 0.4F / (itemRand.nextFloat() * 0.4F + 0.8F));
if (!par2World.isRemote)
{
par2World.spawnEntityInWorld(new EntitySnowball(par2World, par3EntityPlayer));
}
return par1ItemStack;
}
}if (!par2World.isRemote)
{
par2World.spawnEntityInWorld(new EntityThrowing(par2World, par3EntityPlayer));
}package net.minecraft.src;
public class EntityThrowing extends EntityThrowable
{
public EntityThrowing( World par1World )
{
super( par1World );
// TODO Auto-generated constructor stub
}
public EntityThrowing( World par1World, EntityLiving par2EntityLiving )
{
super( par1World, par2EntityLiving );
// TODO Auto-generated constructor stub
}
public EntityThrowing( World par1World, double par2, double par4,
double par6 )
{
super( par1World, par2, par4, par6 );
// TODO Auto-generated constructor stub
}
@Override
protected void onImpact( MovingObjectPosition var1 )
{
// TODO Auto-generated method stub
}
}@Override
protected void onImpact( MovingObjectPosition var1 )
{
setDead( );
}public void addRenderer(Map var1)
{
var1.put( EntityThrowing.class, new RenderSnowball( throwItem.iconIndex ) );
}@Override
public void load( )
{
//Stuff then put this
ModLoader.registerEntityID( EntityThrowing.class, "Throwing", 138);
}@Override
protected float getGravityVelocity()
{
return weight;
}public Entity spawnEntity(int var1, World var2, double var3, double var5, double var7)
{
if(var1 == 497)
{
return new EntityThrowing( var2, var3, var5, var7 );
}
else
{
return null;
}
}public Packet23VehicleSpawn getSpawnPacket(Entity var1, int var2)
{
if(var1 instanceof EntityThrowing)
{
return new Packet23VehicleSpawn( var1, 138 );
}
else
{
return null;
}
}ModLoader.addEntityTracker( this, EntityThrowing.class, 138, 64, 1, true );
1
1
1
Now that 1.9 is finally released and Forge community is slowly working towards a 1.9 version, I guess I gotta dust this dang thing off and prep to maybe do some coding again in the next few months. Or something. IDK.
I'm really gonna have to see how the 1.9 combat mechanics are implemented in code before I make any real decisions on where I'm going with this mod --if even anywhere.
Current thoughts:
- That combat strength meter is gonna be a butt
- The sweeping mechanic is gonna be a butt
- You bet your butts I'm gonna make sure Skeletons stop having infinite ammo
1
Wandering Testificates will probably sell things that you'd normally have to explore to find or are generally difficult to craft/create.
For example, you might find one selling seraph wings or anchor charms (which you'd otherwise have to synthesize via alkahestry which typically requires ingredients gathered on incursions into the mirrored plain). You also might find one selling rare artifacts you'd normally only find in chests.
There may be different variants of Wandering Testificates that, similar to villagers, have different outfits and specialize in selling different items.
It's also likely these wanderers will use a different trading GUI with some slightly different mechanics.
I'm also debating giving the player a way of 'summoning' a wanderer. E.g., create a kind of signal post and then if the player isn't nearby for an amount of time, the signal post summons the wanderer to meander in from afar.
Makes them slightly more reliable than just hoping one spawns randomly nearby.
1
Wandering traveling Testificate? Because why not ¯\_(ツ)_/¯
I would like for him to wear a hat but I can't get the hat to render and I'm tired of poking at it for now.
Ideally, these guys pop up once in a while and sell you rare things. IDK.
4
Download Latest Version Here: Nephenee ver. 1.2_s2
Old Versions:
Nephenee ver 1.2_s1
Nephenee ver. n.1.0
Download Latest Source Here: Will post soon, once 1.2 gets out of _s phase!
----------
Since most of Nephenee's code is publicly available source provided by Mojang, this project is open source. Additionally, no profits will be made from its existence.
However, if you'd like to tip me for my work, you could always head over to my Patreon and pledge a buck?
(Sure, it's not a Patreon for Minecraft stuff, but on the plus side you get cool art-y stuff?)
---------
This utility was made possible thanks to Mojang's publicly released Anvil Converter Source
What Is Nephenee?
Nephenee is a Java-based command-line application that allows you to search through a Minecraft world's .mca files for instances of a particular block ID and replace them with another value.
Why?
Well, it's a complicated answer.
This utility served a noticeable purpose back in pre-1.7. Minecraft still relied heavily on those precious limited integer block IDs and ID conflicts were a very real thing. Take me, for example. Pre-1.4.2, I picked ID 145 for a mod ore block. And then 1.4.2 came out and 145 was now vanilla anvils. Yay! Nephenee came into existence as a means of fixing the problem of now having wild anvils all around my world save.
Today, ID conflicts really aren't a thing because string IDs and automatic mapping handling. HOWEVER! Just in case, Nephenee is back in action for whoever might need it and why ever it might be needed!
Instructions
1) Download the latest jar file
2) Place the downloaded .jar in a convenient location
3) Open a command prompt / terminal and navigate to the jar's location
4) Type in the follow:
Where [version] is the rest of the jar name (the version), and [script file] is a path to the .nee script file you wish to run.
5) Read and follow Nephenee's prompt(s). It's mostly an automated utility.
Note: While it's technically an executable jar, please refrain from trying to run it from your file manager via double click. It no work-y that way.
.nee Scripts
Nephenee uses nephenee files (.nee) to figure out what it's supposed to do. Here's an example:
The above file tells Nephenee to:
- Go into the minecraftModded1710 directory in your AppData/AppLib/Home folder
- Find the world named test1
- Search in only the overworld dimension
- Replace all instances of Thermal Expansion's "Rock Wool" of metadata 2 with GrowthCraft's "Fruit Press" of meta 0
Note:
- You can have as many worlds as you want in a single file. Just put another DIRECTORY WORLD [...] ENDWORLD
- You can have as many REPLACE lines as you want
- String block IDs are currently case sensitive. Type them carefully!
- You can use -1 as a metadata wild card (i.e., ignore metadata for that block)
- You can specify any permutation of the three main dimensions (overworld, nether, end)
- You must specify at least one dimension or Nephenee won't do anything
- If you don't specify the directory, it defaults to the regular .minecraft folder to find the given world
- You can't specify directories outside of AppData/Application Support/Home right now
- You can put comment lines in .nee files by prefixing them with #
Legacy Mode
Nephenee offers a "Legacy" mode that allows you to use numeric block IDs instead of strings. This is mainly for pre-1.7 worlds, people who don't know how to string IDs in 1.7, or operating on vanilla worlds. To enable Legacy Mode, use the legacy flag:
OR
Note: In Legacy mode, string IDs are turned off. You can only use numeric IDs.
An example of a legacy script:
Picture
FAQ/NAQ
For the curious-minded!
Q) Is Nephenee safe to use?
A) Yes, it should be. I've done testing and I've yet to see any detrimental side effects. But, just to be safe, you should back up your world save elsewhere just in case!
Q) Does Nephenee work with FTB/Technic/etc?
A) Unfortunately, Nephenee does not work with launchers or dedicated servers that store world saves elsewhere than the Windows AppData, Mac Application Support, or Linux home directory. You'll have to move those world saves to a valid location. However, it does work nicely with Mojang's profile launcher.
Q) Does Nephenee let you replace instances of blocks found in inventories or chests?
A) No, it's strictly world blocks. ItemStacks of blocks are unaffected.
Q) Does Nephenee work with worlds that have save data for mod-added dimensions (e.g. Aether, Twilight Forest)?
A) Unfortunately, Nephenee does not yet have support to detect extra dimension data folders. This hopefully might get fixed in a forthcoming update!
Q) Why script files?
A) Would you rather be typing into an endless command line user prompt?
Q) Why no GUI?
A) Because it's a command line tool. Also, GUIs suck and I hate them.
Q) What's a "nephenee"?
A) My favorite character from Fire Emblem.
Version History
1.2_s2
- Fixed a bug with extracting metadata nibbles incorrectly (thanks for the help, Shadekiller666! ... Mojang...)
- Fixed a bug with putting back metadata nibbles incorrectly (missing bit mask)
- Added some more console output so users know it's working and not frozen
1.2_s1
- Actually probably works with block IDs higher than 255
- Metadata sensitivity
- 1.7 String ID support
- Multi-world support?
- Directory specification
n.1.0
- Basic ID find/replace
- .nee file support
Upcoming Features
- More robustness for handling users trying to input all the wrong things.
- More personality?
- Support for extradimensional region folders
- Better code?
- TE mode for replacing ItemStacks of blocks?
1
Postin' art again because lolwhynot ¯\_(ツ)_/¯
(Full res: http://starshadesjack.tumblr.com/post/117670742399/hephaestus-from-danmachi-requested-by-neonie)
1
I took my driving exam back in April 2014 (yes, I've had a license for less than a year so far and hi, I am 23) and it was ridiculously easy. It was pretty much just a drive around the block in a minimal traffic area. Not really sure why but I'm somewhat grateful for that since I passed first try. The only thing the examiner/officer had to say was for me to watch my speed (I have difficulty keeping speed consistent and it'll vary +-5MPH, typically).
It's kind of odd that I managed to pass it so easily. Unlike most people, I didn't really get a permit until I was an adult and I didn't really do the requisite 50 hours of driving + 10 hours of night driving (or w/e) so I pretty much just winged it ^^;;
Fortunately, I got to use my own car for driving and a 2014 Subaru Legacy is an amazing vehicle to drive test in.
1
<3
Heheh, yeah, I use Paint Tool SAI, which has a "stabilizer" setting that lags the input a bit but smooths the lines. It goes from 0 to 15 and then S-1 to S-7. I use S-5 for final line-art. Suuuuper smooth laggy drawing xD;;
But, it's useful because then you get super cute smooth line art like this and people absolutely adore it! but still not enough love to get commissions... OTL;;;
4
(x-post from and full res on my tumblr)
2
[edit: since my avatar does change and no longer is my own art, the avatar in question:
2
Oh, that's not a bad idea at all. It might conflict with some other mods but I like it and I'm going to add that.
I'm thinking the player won't be able to drop items in the M.P. They also won't be able to transfer them into chests (which will be a unique kind of chest that only accepts items only found in the M.P.). This is also to prevent the player from circumventing the caveat of amulets taking up space.