Tungsten makes light bulb fillaments. Silver has no use yet unless maybe for chandeliers.
Posts by zfoxfire
-
-
Also, I just found an awesome video that explains what objects are. I had so much trouble wrapping myself around objects when i was younger. this video explains it so well. i did't even know that when I thought I was creating an object, i was making a reference to that object. Kinda gives a good insight into how the JVM works so I learned something new today
-
Red posted some sample code to import a 3d model. Hope that helps:
(Future) custom objects and built-in textures
Also, if you have any experience doing procedural programming then you'll have to wrap your head around what objects are since Java is an object oriented language
-
-
The trailer from december makes the game look better than what I've seen watching lets play videos of No Mans Sky.
-
oh... i just thought of something.. plugin bundling would be a cakewalk with maven. Arcane Desmond mentioned to me how he used to test minecraft mod bundles (something like Tekkit would be a great example). The process he described to me seemed very manual and tedious. When I set up new maven projects at work, I have to write a pom file to describe all the various jars i want to include. Im sure Netbeans offers a way to generate this file. Essentially you would be building a list of all plugins to include. Netbeans can compile either the sources or the built jars and make a massive jar.
A jar is essentially a collection of classes and additional asset files. Even with the additional libraries that might be needed, your Netbeans should be consolidating all those classes (your and the additional libraries) into a single jar. So combining multiple jars into a new massive jar (the bundle of mods) can be made, tested, and distributed easily as well.
-
I understand the neuron situation my synapses have been firing like mad since that API came out. Its distracting me from my day job.
Yes. A snapshot is essentially a pre-release version. I do agree with you that it is wise to limit who can see them otherwise you have end users compaining about your plugin busting their game. Multiple repositories in maven could be set up, one per developer. The repos are accessible via virtual repos that join all repos together. Virtual repos are made available to the outside world and require authentication if linked to the rw user database) so developers decide in their own repos who can access their snapshots and releases or we can just agree to make a single repo of snapshots and limit access to trusted developers and testers in this community. The release repos can be made available to the public and eventually be linked to the Steam Workshop ( i still know nothing about SW but it sounds like something to manage plugins in versions so I assume it has maven support).
But yes, disclaimers galore must be placed with developer contact info published. This can be written directly into a jar which contains lots of meta data in addition to the code. A jar is essentially a smart zip file. Infact they are compressed exactly the same way! Every possible precaution must be made to ensure that plugins are installed as is and Red51 is not responsible if we break the game! ;-p
Regarding the elevator scenario, i still think single jar is best approach. If you provide an elevator model, it is inside the jar. The plugin works out of the box. Your instructions can say you can optionally make the subfolder and have the folder contain the config file and user provided model. Your code in the jar just has to be writen to ovverride the model a config file and defined model name are in that optional subfolder.
But regardless of how you implement it, the subdirectory matching the jar name is essentially a place to modify the mod or maybe where the jar can create a temp file or something. It would be up to the developer on how to use the folder.
Placing the jar outside a subfolder makes it a bit easier to update jars (all jar files immediately under the plugins directory) or a way to quickly restore a plugin behavior (wipe the subfolder).
The way red described keeping all assets in one jar is very common practice for making a jar. If you build a simple jar, all the included classes (libs) should get put into the jar. Same with images or 3d models. If you study how the asset jars in rising world are designed then you should see what I am talking about.
Minecraft has a very messy approach of creating a disguisting and deeply nested directory structure. I do not understand the reason for this. Rising World on the other hand composes of about a dozen or so jars with some config files. Very very well organized.
And here is my grande future vision of things:
The only reason i suggested integrating into the rising-world.net domain is to make it easy for us to control access by rw usernames. Same thing with some other ideas that I've ran by Red a while ago... granting developers git repositories to centrally manage and share plugin source code. I also had an idea of sharing blueprints through git as well... I envision that someone might someday write a plugin to share blueprints. They can be versioned as well and sent directly to a user or shared publically hence the need for a repository. Public blueprints might also come into play if someone was to write a plugin to generate custom villages or dungeons with different themes. Red51 is writing the dungeon generator, we would just need a way to override dungeon rooms with custom blueprints for each room (this is still very speculative as we still do not have dungeons yet nor API calls to customize dungeon generation but I just picture lots of stuff working togethrt if we make repositories to share our plugins and blueprints.
The above would be made easy if we had an option to centrally store and distribute. I do not like the way the minecraft community distributes plugins. Its a very manual process. But I suppose that in itself discourages players from misusing mods. But isn't that essentially what my idea or the Steam Workshop opening the door to?
-
-
@zfoxfire posted this here, but I am replying here as an attempt to keep all contributions about this topic together.
Placement: I agree that it, in the specific case of single-file plug-ins, placing the file in the main "plugins" directory would be easier. I am not sure it would be globally easier, though. Having a rule with sub-cases or exceptions is more complex and error-prone that a single-sentence rule:
"Each plug-in shall placed into its own sub-directory under the "plugins" directory, unless it is a single file, in which case it can be directly placed in the "plugins" itself".
is not easier to read, to remember and to put into practice than:
"Each plug-in shall placed into its own sub-directory under the "plugins" directory".
Unless, the rule will be to have only single-file plug-ins, in the form of a ZIP-ped file, which will be placed in the main "plugins" directory.
File type: whether to natively support ZIP files or not -- in addition to OR instead of .jar files -- is a decision which the dev team can make, having in the mind the general structure and economy of the app.
Personally, I would NOT push this option, though. The ZIP file has to be expanded, sooner or later. This can happen in memory each time the application starts up, resulting in greater memory occupation and slower start-up time.
Or it can be done once, the first time the application finds a "new" plug-in ZIP in the standard "plugins" directory, extracting into a specialized destination directory. This raises some issues as well, though.
*) It might be hard to decide when a plug-in is "new": how to detect a new version of a plug-in with exactly the same the ZIP file name, in order to update the destination directory containing the expansion? Has to application to keep track of file time stamps too?
*) What if "myPlugin_1_1.zip" is added to the "plug-ins" directory? How the application can decide that this a new version of "myPlugig.zip" and delete the expansion of the previous version?
*) Having both the ZIP file and its expansion may lead to confusion and/or to sync problems due to manual updating the latter without updating the former too (we ALL did this this kinds of things, didn't we?)
So, unless there are other compelling reasons, I would not suggest supporting ZIP at all.
Of course, this does not affect distribution: plug-ins could still be distributed as ZIP files; it would be the care of the user to expand them into the appropriate (sub-)directory.
Under this respect it would be useful to encourage authors to distribute plug-ins in ZIP files already providing their own sub-directory directly in the ZIP file (so that these ZIP files could be expanded directly in the main "plugins" directory, without directly dealing with sub-directories).
Miwarre,
I made a new thread here: Zip vs Jars, Plugin nameing conventions, upgrades, and Maven repositories
We can use that to hammer this out there. This one also talks about repositories so goes a bit beyond the scope of package names but still very relevant. If you want to consolidate some of your thoughts from the following thread then please do so: Package name requirements? -
Consolidating a few thoughts from other threads that I posted so I will be deleting them shortly..
I am concerned about how we will be installing/managing zips can be dificult to maintain and distribute. So I'm going to give some specific suggestions. This is all stuff I do for a living so I'm going to speak with some authority on the issue. I'll also go back and delete my posts in other threads since I'd like to keep this discussion in one place.
1. If we use zip files then everyone has to come up with their own way to manage and distribute their plugins.
2. We need a way to track versions and be able to see incremental builds or development (snapshot) builds and distribute them easily.I suggest we consider using Maven to build and distribute our plugins. I just purchased a standalone copy of RW to confirm this but it looks like the standalone uses a helper application as Minecraft does so awesome bbq sauce! Now we need something simlar for plugins and possibly eventually distribution of the server jar with maybe a helper application (or script as well)
I personally manage a a few different maven repos at my job. Sonatype Nexus OSS is a free version that could possibly be integrated into rising-world.net. Not sure how it would link up with the current user database but it might be possible to make it a repository for our community only. I'm currently experimenting with Sonatype on my personal web server so I'll folow up on this when I can.
Now, Netbeans supports Maven-based projects. Here's a quick-start with screenshots. Essentially this allows you to build a jar following the versioning standard that Maven uses and I'll sumarize below:
https://platform.netbeans.org/…-maven-quickstart.html#01So a few terms:
Artifact: anything that is built. A JAR would be an exmaple of an artifact
Release build: this is where you build an official release of a jar. This can represent one plugin. This is only one release artifact per version : e.g ... areaProtection-1.0.0.jar
Snapshot build: this is the development version that uses the same version as the intended release build. for example, areaProtection-1.0.0-SNAPSHOT.jareach snapshot is built, deployed to maven, and available for testing. anyone who wants to examine the jar deployed will always get the latest 1.0.0-SNAPSHOT as snapshots contain many builds, each with an internal timestamp
About snapshots: The thing nice about snapshots is that they are incremental but keep the same version. The API jar that Red51 shared with us is a perfect candidate for maven. It has already been updated a few times but each time it is, we need to download and update our local copy.. If this was built with maven, we would essentially point our Netbeans to the maven repository and request something like:
maven.rising-world.net/central
maven.rising-world.net/snapshotsonce inside the each directory, you browse it the way you brows files on any typical webserver. here is an example of a common maven repo:
https://repo1.maven.org/maven2/the namespaces inside can match whatever we want: e.g. for example, we might navigate to the API like this: net/jiwgames/risingworld/api/1.0 or if i wanted to add my own plugin I can use my own domain space and mine would be in us/zork-foxden/myFabulousPlugin/1.0.0-SNAPSHOT
Whenever Red51 updates a pre-release of his API and deploys it as a SNAPSHOT, we all now can pull the latest by referencing 1.0-SNAPSHOT rather than having to manually download and install. Then when us modders distribute our plugins, we deploy them into this maven repo and its available for anyone. Then someone has to write a plugin for RisingWorld (or Red can integrate it into the application) to help us manage versions. So lets say that in the game, we want to try out Zork's myFabulousPlugin-1.0. In RisingWorld, you look at the mods you are using, the system seens that you are on 1.0 but wait, there's a new version in the works... 1.1-SNAPSHOT. Now that means the snapshot 1.1 is still in the works and might be still a bit buggy but yuu can choose to filter out snapshots and just wait for the next release which would make the most recent 1.1-SNAPSHOT become 1.1. Maven allows you to filter releases and snapshots so its quite convenient.
------------------------
Regarding installations of zips.....
The plugins folder should allow either zip or jar. If a developer wants to not use maven, they can make their own zip and come up with their own versioning scheme, or a make their own jar and provide install instructions to maually download the zip or jar and drop it into the plugins folder.I've been thinking about this for a while and there should not be any extraction process on the zip or jar. Java always runs a jar without extracting it. The only reason we would need subfolders is if there might be user custom configuration so for example:
Scenario1: For simple plugins that do not have options for users to customize. file is not extracted as the contents will not be modified:
- plugins
- zorkPlugin-1.0.jar
--OR--
- plugins
- zorksPlugin-1.0.zip
Scenario2: for plugins that might have config files within a folder created contains any generated and modified files (config files, databases, etc):
- plugins
- zorkPlugin-1.0.jar
- zorkPlugin
- libs (any additional libraries downloaded that werent in the jar)
- registeredUsers.db (custom user data that the plugin uses)
- configFile.txt (some config file)
In scenario 2, the directory matches the plugin name and is in the same folder level under plugins. The content in the directory is up to the plugin to establish. Not sure if the API should include something to create userdata folder and limit any file changes to that directory -- to prevent the plugin from accessing the rest of the filesystem). Version is explicitly not included so that if you upgrade your plugin, the config file remains in the same location. Not sure if this standard should be implemented in the game itself or if its up to us to figure this out our own.
- plugins
-
No problem.
I am consolidating a lot of info anyways so its best if I just delete them myself. -
Hi Red,
I'm about to make a pretty long post about Maven. Is it possible for me to move some of my other posts under that thread? I'd like to consolidate. If not, I will just delete my own posts from other threads.
-
i agree. I will see if i can move some of my posts.
-
Hi Winddbourne,
You probably didn't mean ill intentions at all. I should apologize on behalf of myself some others here if you perceived any hostility from us.
The "when's the next update" get's asked alot. I know its a legitimate question but it has been a cause of drama in the past and myself and some others who are a bit outspoken on this forum get sick of it after a while. Typically Rising World updates come around the end of each month and now it's been over one month since the last rollout so we are on edge and expecting some disgruntled players throw hissy fits. I do not believe that this really was your intention but it did strike a chord at the time.
I guess the average gamer really has no clue what's going on behind the scenes which is probably why we get some drama in the first place. I know how hard Red51 works and the monumental efforts needed to make the changes needed. Rising World is a VERY ambitious project and probably too much for just one person to write so it will take a while. So I tend to get defensive whenever I perceive someone trivializing or be-rating the work being done. by the JIW team.
About the Java API, its stil a work in progress for its first release but it looks like a great API. In the long term, it will be the better choice because of its power. LUA certainly easier to use. I think LUA has object oriented capability but its not completely native like it is with JAVA. The decision to go this route was a tough one but necessary. It required lots of time writing new code but if we are to expect to get the kinds of mods we see in Minecraft then this is clearly the best choice. As you may recall Red did make this decision last year to switch from LUA to JAVA. Over the past few months, much time was spent to get the API ready which has caused delays with other features but its going to pay off in the long run
-
pretty sure an official map is planned but the api seems to have enough to support a 3rd party one
-
Miwarre,
It is just a perception. Considering that only one person writes the code, the update frequency is perfectly acceptable. I say "slow" because that's going to be the perception of newcomers to this game. It's best to set the expectation than to have people wondering why things are "taking so long". Am I perpetuating it? Probably. I realize the types of updates going on now are complex and probably can't be broken up into smaller updates. I remember after the Water update we got a few tiny updates containing new craftable items which came out real fast. To me, that's what would be preferred. I imagine Rising World development will be "slow" for the remaining of the alpha stage. In beta, focus should be more on tweaking and tuning rather than designing from scratch. Is "slow" a poor choice of words? Perhaps. But as I said, its important to set expectations with the community.
Back in the day, early access would not have been possible so no end users would have experienced the wait time for development. Back then the software was boxed and shipped to stores. Only then did they become available to play. Software updates afterwards would have been rare without Internet. I'm sure it still happened on a small scale over BBS' but that was probably with shareware, not big-box software.
-
Windbournne,
I am glad that you agree that sometimes "soon " is the only answer you can give. I also am happy that you agree that a small effort goes a long way. I feel that Red51 excells in efforts to communicate with and support the community. His efforts in that regard do compensate for slow development blues.I am confused however what you are really complaining about if you are a developer yourself and understand development setbacks and how personal life complicates things.
The new API specs were just published and Red has been actively helping the modders here to begin transitioning to it. New player models combined with lots of new object models and replacements for old ones have been in development since earlier this year. Water, models, dungeons, and the new API have been developed pretty much in parallel for a while. I'm sure you can understand how that can complicate things especially when only one person writes the code. So yeah, "soon" or "it gets there when it gets there" is about the best you can expect officially cause as I said before, he has gotten burned in the past for making deadlines that fell through.
ArcticKitsu is explaining similar frustration as he deals with people on other game forums that do nothing but complain and badmouth when updates are slow. We have a good community here. Most of here accept "soon". Dungeons will be ready soon. The new API is going to be integrated first however. Btw, i hope youve had a chance to look at the api yorself. If you are a modder then we would appreciate any feedback you have in that regards.
-
this reminds me of somebody who left a negative review on steam about Rising world. He claimed the game was s***** because the file size was so small.
I later suggested to Red that he convert all the texture files to BMP and the music and sounds to WAV and maybe add an uncompressed 1080p intro video for the sake of artificially inflating the game size
The point is that file size is irrelevant. If everything is procedurally generated then the file size will naturally be tiny. Just check out those 64k demos for PC computer
-
Red, thankyou for clarification on PivotPoint. The doc makes more sense now.
-
I am 33, I also have memory and learning problems myself. I am very slow learning new things and become extremely frustrated trying to learn new stuff and my job requires me to learn lots of new languages and tools on the fly. I make up for most of my short comings with adderall (just started a few months ago and i wish I started taking it before I went to college) and just working 50 + hours a week to compensate for my short comings. I spend time at home learning new things or sometimes spend 4 hours at home focusing on solving one problem that was annoying me for days at the office.
I understand college is not cheap. I paid for community colege out of pocket. I conveniently finished my associates at the same time I got laid off from my last tech job at the peak of the recession in early 2009. I went to a university after and even with unemployment benefits and grants racked up $50k in debt from student loans and credit cards. Im sloowly paying that off now. The job I have now and my sallary was totally worth the sacrifices I made. I also have security knowing I have a diverse portfolio of marketable skills now. I afelt old at university but knew guys going back at 40 who also landed good programing jobs afterwards. Its never too late.
But none of thats is relevant. You probably arent wanting to code for a living. You just want to write some awesome mods for a game you play far more than I do! You can learn on your own or at your own pace. The API for RW is a standard looking reference for any language. Silver already provided a link for the jdk8 api so thats a great starting point. Now try some basic applications. Designing a gui calculator will give you great exposure to using swing and how to manipulate buttons and how to group elements in a jpanel. This likely wont directly work with RW because the interface for gui in RW is not standard which is why we have an API for RW to follow. But learn the basics of java. Or do what Red suggested and wait for others to write mods for this game and peek at their code. I also find examples help a lot when I cant find a solution on my own. This is why websites like stack overflow is amazing but even there, everyone assumes you already understand the basics. please consider the public libraries if you are really on a budget.