loftar wrote:I've posted about this issue previously, but I guess it bears repeating in one post.
The reason I put code into resources is because it has a number of advantages. Most importantly, it's incredibly convenient for me to be able to push small changes (some minor tooltip, some custom graphics) without having to do a full client update and boot people who haven't updated. In that way, it helps custom clients as well, since the client author doesn't have to merge changes for every other patch just for the client to remain usable.
I do deeply understand why it's a pain for client modders, however. Precisely because the kind of code I tend to put into resources is "on the edge", so to speak (it tends to be the visible part of many mechanics), it's exactly the kind of code that client modders would tend to be the most interested in, and also important to interact with for the kind of client modifications that I can even agree are the most legitimate of modifications. As such, I'd honestly want to provide a better way to interact with it, and I've spent some amount of time trying to think of one (to no success thus far). It is of course true, nonetheless, that it's not a problem that I'm personally afflicted by, so it's not the kind of thing that I spend every day thinking about. As such, if you have any good ideas for how to achieve a better system for handling these things, I'm interested. That being said, it would have to be something that preserves the advantages that I derive from the current system.
shubla wrote:What exactly prevents you from adding these resource files with code in them to the git repository? It would be enough to expose the source code so custom client developers can then modify and copy the code as needed into their clients.
shubla wrote:It would be helpful if you told what your current process with the resource files that contain code is, so we could figure out if there would be some good solution to it, if you are too busy to come up with an one.
loftar wrote:shubla wrote:What exactly prevents you from adding these resource files with code in them to the git repository? It would be enough to expose the source code so custom client developers can then modify and copy the code as needed into their clients.
Since the source code is already available in the resources. I don't quite understand what the advantage of maintaining a separate Git tree with their source code would be.
loftar wrote:shubla wrote:What exactly prevents you from adding these resource files with code in them to the git repository? It would be enough to expose the source code so custom client developers can then modify and copy the code as needed into their clients.
Since the source code is already available in the resources. I don't quite understand what the advantage of maintaining a separate Git tree with their source code would be.
@LayerName("src")
public class Source extends Layer
{
public String name;
public byte[] code;
public Source(Message buf)
{
//src
//73 72 63 00
//length
//3F 02 00 00
//What is this byte? Presents as 01 in this case
buf.skip(1);
//Armpen.java
//41 72 6D 70 65 6E 2E 6A 61 76 61 00
name = buf.string();
//The rest of the bytes is the java code
code = buf.bytes();
}
@Override
public void init() { }
}
Aoyama wrote:Mr Loftar,
What is the single byte before the name in the "src" layer?
It's driving me nuts.
- Code: Select all
@LayerName("src")
public class Source extends Layer
{
public String name;
public byte[] code;
public Source(Message buf)
{
//src
//73 72 63 00
//length
//3F 02 00 00
//What is this byte? Presents as 01 in this case
buf.skip(1);
//Armpen.java
//41 72 6D 70 65 6E 2E 6A 61 76 61 00
name = buf.string();
//The rest of the bytes is the java code
code = buf.bytes();
}
@Override
public void init() { }
}
shubla wrote:Is this some standard format ? What does "/* $use: ui/tt/q/buff */" for example mean, or "> tt: Quality"
shubla wrote:Cannot understand why you just can't put them in github!
loftar wrote:Right, my recollection was that I just stuffed the source code right in there, but yes, you're right. The first byte is a version number in case of future changes, followed by a string indicating the filename, then followed by the actual source code. With the addition of the version number, your decoder seems completely correct.shubla wrote:Is this some standard format ? What does "/* $use: ui/tt/q/buff */" for example mean, or "> tt: Quality"
That's just the format I use to make the resource compiler construct the metadata, like the codeentry layer.shubla wrote:Cannot understand why you just can't put them in github!
I don't think my reasons or opinions have changed since we discussed it in this thread.
Exception in thread "Haven UI thread" java.lang.RuntimeException: Cannot fetch resource of non-resloaded class class res.ui.tt.q.quality.Quality
loftar wrote:Arguably the real problem with that solution is just getting javac in the development environment to be able to get code from resources onto its classpath, and I really don't know how to solve that issue.