I have been looking from everywhere how would it be possible to make a save game file in java applet but of course it is not possible to just make an xml file... (or would it? please tell me!)
I don't want to make the "player" to log in to game with username, password and stuff like that, that goes to some server and things like that...
Just what would be the easiest and the most simple way to save a couple of variables so the player don't need to start the game from the beginning every time? (Becouse in an rpg game it would be so lame...)
Generally you can't save files, because of the security restrictions. Unless it's running as a trusted applet, which is problematic. The short answer is no, you can't write files, because Java applets runs in sandbox. From sandbox you don't see the local file system.
Maybe you can store your save game in a cookie? Here you have an official tutorial how to handle cookies from Java.
This link can be also helpful, somebody had a similar question.
Related
I have this chess engine i wrote in java. Thing is, I need to make a exe application that can take commands following a certain protocol (UCI). Ive had many problems trying to get this to work, but ill keep this brief and share the most important ones.
Other engines pop up cmd when you click on them, mine is just a basic java CLI (Dont know if this is a problem).
My anti virus keeps stopping me from opening the exe. Launch4j gives me a warning telling me I should sign it to prevent this sort of thing, but I dont know what that means.
So heres the deal, I know this post is word vomit, but Im truly at a loss right now. Id like general order advice on how I should approach the problem and maybe some advice on wether i should be using launch4j in the first place.
UPDATE: The reason i wanted to make an exe in the first place is because thats the format that was suggested in the lichess documentation (I wanted to upload my bot to lichess). I wrote a bat file that executes the jar file and it worked fine. Thanks to everyone for the suggestions.
Without thinking, I created an entire program in Java and began designing a website to use this applet. All it does is create image in a certain way but there is a bit more code (classifications and default values/images) that I just felt was easiest to do with Java. Now I have a Java app and HTML CSS and JavaScript that I can't seem to do much with.
I have thought of 2 ideas (below) but I don't know what the general alternative is to applets nowadays.
I have a spare PC I may use and just alter my applet to run the back-end of a server-based site instead, but I am hesitant to use my own IP and bandwidth for something like this. Also, this app doesn't even need access to the internet so this just seems like way overkill.
I could just release the .jar, but I plan on expanding the available options. I also told people that this website was coming. I'd like to be able to just update the website.
I don't really plan on writing my program in another language. This took me time to make. If there is no way to work Java into my site, I may just abandon the project altogether.
I am mainly concerned with Chrome for this problem.
Edit: I would like to use GitHub as my host, just in case this helps at all.
You can run anything you want on the server, including java programs. So
you could run the image creation program in the server and present the
resulting image using a standard img tag.
How would I be able to share my jframe or jpanel on a website without having to extend from a applet?
I want to be share my java gui program with other people without having them have java or download a zip file for them to run it.
I read online that using an applet is insecure and outdated. Other responses insisted in learning javascript. However, I want to stick with java. I also read about using Java Web Start but it is quite confusing for me. May someone give me a general gist or even a starting point for me to research on this topic.
I have a javacard and it has 2 applets installed. Now I would like to select one among the two. Currently how I do is that, I provide the cap file of the applet from which I get its AID. But I don't find this method satisfactory. So
Is there a way or steps to get the AID of the applets installed in a java card without having the cap file?
Is there a way to select the applet without its AID? By this I mean that is there a way to make an applet auto selectable after reset?
Are there any other ideas or insights over this?
For the questions you have asked,
Yes. PyApduTool can make you reach you goal. This tool can help you get all the packages' or applets'AID in java card even though you don NOT have the cap file.
Just press the "Refresh" button. the things you need appears in the right text field.
You can set you applet as "Default Selected" when installing it.
In this way, you can make you applet selected by default without having to know its AID.
For convenience, it should be better to know the applet-AID.
Only one applet can be the default selected.
The answer from Andy is good but i feel that its missing an important part of the question:
Javacard get applet AID of installed applets through Java code
If the question refers to finding installedf Applets from the code of one java card applet itself than this answer might apply:
First, it is possible to get the AID of the applet itself by JCSystem.getAID().
Second, it is not possible to "detect" other applets from within an installed applet.
Although if you know the other applet's AID you can get a hack of useful information about it using JCSystem and GPSystem.
So apart from inside JavaCard code, the Card Manager is able to list of installed applets with all their privileges and so on. You can use a tool of your choice. If you are working with JCOP, I recommend JCOP Shell. If you work with freeware I recommend Global Platform Pro from Martin Paljak.
Beside selecting AIDs and default selection there is no direct way to select an applet. There is an indirect way by using the SharedObjectInterface mechanism from JavaCard which lets you change control flow to a different applet.
No, Im not asking for a full made program :) Im kind of new to Java as language so Im not familiar with java libraries at all and my experience is mostly about php, but I understand OOP well.
My scenario:
I want to build a Java applet to my website, by which different users can share a same screen window in which they can drag and drop things(images) to specific positions and when one does, it would update the screen to the others. Before connecting, user would choose to build a new screen or join other. If he wants to join other he would just enter some existing (random) screen id to connect to. If he wants to create a new one he would access this screen in which he would see the screen id to share with someone else. I dont care if two persons wants to drag and drop different item to same spot, it would then just use the one that came last.
Now that you understand what I want to build...
What I really just need is the skeleton structure of something like this. What parts I will need to build something like this? Libraries and such, where should I look for tutorials, Best practices, hierarchy, should I use tcp or udp? I just need something where to start from.
An applet is run in the system memory of each individual client. There are strict rules about what applets can and cannot do, and I am not sure whether or not applets would be allowed to make remote connections to other users. I would advice doing some google leg work on java applet security and seeing what you dig up.
Assuming this is possible:
In terms of architecture, I think you would want one person designated as the host create the game and run all the game logic, while the clients just receive information pertinent to graphics being displayed (location, size, texture, what have you) and sends back information about what the client is doing.
I did something like this as a school project in high school, but I was forced to sign the applet to make it do remote http connections. I would assume this is still the same case.
Hope that helps a little bit.