When I press language button, it don’t work by some reason. In my previous game on UE4 it was all exactly the same and it worked but in UE5 it don’t.
I can’t change loading policy to Always in UE5.
Related
There are actually two camera problems.
The first is that sometimes the RMB to control the camera angle in Studio doesn't work. Sometimes using the LMB or movement keys helps, other times (like right now) it doesn't do anything. The hand cursor appears to shake in the direction I want to pan the camera but nothing happens. I did have an Advanced Camera plugin.
When I'm testing my game in Studio, I have NO camera control via RMB and zooming is nonfunctional. This is to say that I can turn using my mouse, but RMB doesn't change how mouseview works. Probably unrelated, but I cannot get scripts from the toolbox for run, crouch, zoom, etc. to work, either, even when I place them where instructed.
I get these errors in my game:
16:36:47.313 ▼ ActivateCameraController did not select a module. (x3) - Client - CameraModule:362
16:36:47.314 ActivateCameraController did not select a module.
16:36:47.314 ActivateCameraController did not select a module.
I've been having trouble with Studio eating up too much bandwidth when NOT in use during actual gameplay in Roblox (exe), so I removed all the Studio plugins, thinking one of them might be the culprit (deliberate or accidental), and also hoping it might fix the camera issues. No such luck.
Probably unrelated, but I found a couple of apparently simple viruses (Vaccine and Fire) using clone() and spread() to reproduce within the confines that their simple scripts dictated. I removed all instances, as well as a presumably fake Antivirus. The first two were very basic scripts designed to spread the script and didn't do any damage (although the latter would damage players).
#Kylaaa came up with the answers, but there's no way for me to mark them as answers.
The problems did not occur in a new game until I copied all the stuff I'd added into it (from the troubled game).
Regarding RMB not working in the Studio:
Sometimes, if the Workspace Camera gets set to Scriptable, all mouse inputs stop working. You could try checking if switching the CameraType to Fixed or anything else fixes your problem. It should be in the Properties window when you select the Camera in the Workspace.
What I did: I changed the mode and the problem stopped. I suspect that the Advanced Camera plug-in that I had removed had something to do with the problem.
Regarding the camera not zooming and RMB not working during testing:
you have a malicious script somewhere in your Workspace. You can search/filter the workspace for Script and it will show all of the objects with scripts in them. I would recommend removing or Disabling the each of the scripts until you find which one is causing the errors
When you click on a Script in the Explorer, look in the Properties widget. There should be a checkbox titled Disabled. When you select that, it will prevent the script from running when the game starts
What I did: I deleted a bunch of stuff my son had added, and then disabled ALL scripts, then started enabling them one unique instance at a time (i.e. duplicates were enabled simultaneously). The camera problem didn't come back except when I edited a script during testing. I never located the problem script, despite going through and triggering all scripts.
Reading the book "The Spec UI framework". Trying to implement the part described in chapter "Taking over the entire screen".
After executing the code suggested in the book:
WindowExample new openWorldWithSpec
it seems to be impossible to return to previous state. Tried to delete the new WorldMorph in the inspector. Also tried with halos, as the book suggests but those buttons that are available in the halo menu don't allow it to be closed.
Is it an intended behaviour for this (to be executed to prepare an end-user environment and disable programming UI) or am I missing something?
Working in Pharo 5.0, Mac OS X version.
That is indeed intended behaviour, as part of making applications that do not allow access to the development environment anymore. But you can take a look at the code for PharoLauncher to see how you can enable a developer mode
You can actually get back to normal by:
Alt-Ctrl-Clicking on the Morph (macOS combo may be different, this is for Windows).
Clicking on the little wrench and ask for inspect.
In the evaluation pane, do:
self delete
World menu is available again.
Open a browser.
Done.
If one disables halos in settings, this is a tad harder.
I'm working on wrapping some Cocoa functionality in an Objective-C library that will be called from a cross-platform C library. One of my goals is to provide someone who does development in C on Linux with the ability to deploy to OSX without having to get into XCode, nib files, etc. I want them to be able to compile and link their code on OSX using the command line tools, and end up with a regular resizeable main window with the usual buttons and so on, an application menu and a dock icon that looks and behaves as expected, etc.
I'm working on OSX 10.8.5. I have XCode 5.0 installed. Here's my gcc --version output:
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 5.0 (clang-500.2.76) (based on LLVM 3.3svn)
Target: x86_64-apple-darwin12.5.0
Thread model: posix
I've figured out how to present a main window, how to set up the application menu, and various other things, programmatically, without using XCode or any nib or plist, but I've run into a problem with the dock icon.
I set a custom dock icon image by calling:
[NSApp setApplicationIconImage:dockImage];
When the user quits the app, the dock icon image reverts to something else (some kind of default application icon or view), briefly, before going away. How can I prevent that from happening without using XCode to create a nib or a plist?
I've tried setting the activation policy of NSApp to prohibitted in the app delegate's applicationShouldTerminate method, to try to hide the dock icon before this switch back occurs. That didn't help, it does hide the window and the dock icon, but the dock icon still switches back to the default icon, briefly, as part of the process of hiding. I confirmed this by returning NSTerminateLator, and confirming that setting the activation policy to prohibited does cause the dock and the icon to hide even though the app is not terminating, and not setting it leaves it unhidden.
I've tried subclassing NSApplication and overriding the setApplicationIconImage call. I have confirmed that it is being called a second time, by something other than my code (well, or not directly by my code, anyway), just before the program exits. I've tried preventing the second call to it from working by calling the super function the first time, but not the second time, and I've confirmed that code in that function can prevent my code from changing the application icon, but that didn't fix the problem. It still happens anyway, somehow.
I've also tried removing the application badge, like this:
[[window dockTile] setShowsApplicationBadge: NO];
just in case it was something to do with that, but that didn't work. The docs say that app badges are no longer relevant as of 10.6, but I was grasping at straws.
Being stumped on the programmatic front, I'm now trying to find out how to package an .app from scratch,without using XCode, and see if maybe I can create a plist from scratch that has a reference to application image in it. But a programmatic solution would be preferable, as I'd really like to minimize what goes into the OSX-specific packaging of a deployment.
Another possibility might be to use XCode once, to produce a very generic, bare-bones .app that my deployment scripts copy and alter.
Please don't shoot my question down as being "too broad" or "not constructive" or something like that. I realize I'm reinventing wheels that already exist in various forms, but there's no law against trying to build a better mouse trap, or just a different or even a worse one, for that matter. I realize I'm trying to fix a problem that a lot of people would consider inconsequential, but XCode-produced apps don't have this problem, and I really don't want the tools I'm creating to produce any user-visible artifacts like that. I'm not intending to diss Apple's tool chain or invite debate about whether or not what I'm pursuing should be pursued. I have a specific, technical problem that I'm looking for solution to that is within the constraints of my goals.
Just today I started noticing an "X" symbol in the bottom right of my live tiles, see picture.
I'm a little concerned, as I'm currently in the certification queue, that this means I've missed something from the package - a default badge image, for example. Do you know what this means?
The answer appears to be that your developer licence has expired!
when I tried to build something I got a popup alerting me to the problem and asking me to log in to my account again. At which point I was given a new developer licence, was able to build again, and all the crosses magically disappeared! :o)
I imagine the only reason your apps were still working was because they were still in a suspended state so weren't going through a proper launch cycle. The X means it won't run anymore as you don't have a valid licence.
Here's a though question:
I need to find out when the user double-clicked the OS X desktop, but not icons on it.
Now, I have thought of the following solutions, though I am not sure if they are doable:
Using desktop icons position (not sure how to get them), and the size of the desktop icons, we could theoretically check once the user double-clicks on the desktop, if it is inside one of the icon areas. Contra: Might not be flawless as some icons might be transparent or not taking up the entire icon size.
Maybe there is a variable that tells us if a icon from the desktop has been clicked? Then we could just check if that variable has been activated when the user double-clicked the last time the desk.
I am certainly still open to other (better) solutions, but they need to be sandboxable for the Mac App Store.
This is probably not going to be appropriate for the Mac App Store, for a number of reasons.
First, how are you going to intercept clicks outside your window? There are a few different mechanisms for this (e.g., event taps), but none of them are allowed in sandboxed apps. And that's intentional, and for a good reason—you're not supposed to be interfering with other apps or with the OS.
On top of that, it's hard to imagine that whatever you're trying to do wouldn't count as non-standard UI/HIG stuff, which is another reason for rejection.
But, assuming none of that were a problem, and you could intercept clicks on the desktop, there's no documented way to get all the icons on the desktop, so you have to read the .DS_store file directly, which means relying on private implementation information, which is another thing you're not allowed to do.
Finally, you have to get access to that .DS_store file. Unless you're expecting the user to drag the (invisible) file or its parent directory to your app or select it in an NSOpenPanel or something, the only way to get such access from inside the sandbox is via a temporary exception entitlement. Which you can't use unless you can justify to the reviewer why you need it as a workaround for a bug or limitation in the OS. So, what's your justification going to be?