I'm currently working on a new project using HoloToolKit 2017.4.3.0, and I'm trying to re-use some code that was written between May-August 2017, the version used was likely v1.5.7.0, HoloToolkit-Unity for Unity 5.6.1f1+
In the MixedRealityToolkit-Unity for Unity 2017.1.2f1 update, the Test and Example folders were merged, and in my old code I now have a deprecated object called TestButton.
Can someone direct me on what happened to TestButton and what I need to do to get my old code working in the newer version of the toolkit that I'm using?
private TestButton button = null;
I get a compilation error telling me "The type or namespace name 'TestButton' could not be found (are you missing a using directive or an assembly reference?)"
I'm looking for the equivalent object type for 'TestButton' in 2017.4.3.0 but there's very poor documentation for the changes made. I posted this to the GitHub repository for the Mixed Reality Toolkit and no one responded. Just wondering if anyone here has any personal experience with updating old HoloToolKit apps from before they merged the Example and Test folders into newer versions. If anyone could just even point me to some documentation that lists and describes all the types in the SDK version I'm using that would be great.
If you mean that you were using TestButton defined in TestButton.cs, you can try use the button_test_pfb.prefab prefab provided in the version 2017.4.3.0.
Related
I want to add #draft-js-plugins/mention but at the moment it's not possible since one of the dependencies of this package is immutable js that use a very old version thus cause an issue in my project since I'm using the newest version. It's not possible to downgrade at the moment and so I'm wondering what are my other options? Is it possible to integrate DraftJS with other libraries for this feature only? Is it possible to build a custom 'Mentioned' feature? How can I integrate it with Draft?
Any recommendations and examples will be very much appreciated
#draft-js-plugins uses the same version of immutable as draft-js. So your problem would be draft-js which is using immutable#3.7.4.
See also: https://github.com/draft-js-plugins/draft-js-plugins/pull/1710
I solve the issue by using the 'react-draft-wysiwyg' package that was written on top of DraftJS and contains all the necessary plugins. A simple implementation that solves everything
I'm trying to import an SPM package in Xcode11. I can fetch the library and see it in the project as Swift Package Dependencies but when trying to import, Xcode doesn't find it.
I read that the problem could be custom configurations and not the standard e.g. Debug.
Does anyone know how to solve this without renaming the configuration names?
The best advice at the moment is this post on the Swift forums where Ankit says:
This is a known issue that Apple folks are tracking internally. Currently, Swift packages default to the "Release" configuration when anything other than Debug and Release is used. In theory, adding $(BUILD_DIR)/Release to SWIFT_INCLUDE_PATHS build setting for the custom configurations should work around this issue but it can lead to some weird errors in case something unexpected gets picked from that directory.
I have installed the time extension but my code will setup but not run. Same for the example models I've tried. The error message I receive is below. Thanks for your help!
P.S:I am running NetLogo version 6.0.4.
NetLogo is unable to supply you with more details about this error.
Please report the problem at https://github.com/NetLogo/NetLogo/issues,
or to bugs#ccl.northwestern.edu, and paste the
contents of this window into your report
java.lang.IllegalAccessError: tried to access field
org.nlogo.agent.World.tickCounter from class time.datatypes.LogoSchedule
at time.datatypes.LogoSchedule.getTickCounter(LogoSchedule.java:135)
at time.datatypes.LogoSchedule.performScheduledTasks(LogoSchedule.java:156)
at time.primitives.DiscreteEventSchedulerPrimitives$GoUntil.perform(DiscreteEventSchedulerPrimitives.java:95)
at org.nlogo.prim._extern.perform(_extern.java:36)
at org.nlogo.nvm.Context.stepConcurrent(Context.java:107)
at org.nlogo.nvm.ConcurrentJob.step(ConcurrentJob.scala:65)
at org.nlogo.job.JobThread.runPrimaryJobs(JobThread.scala:133)
at org.nlogo.job.JobThread.$anonfun$run$1(JobThread.scala:68)
at
scala.runtime.java8.JFunction0$mcV$sp.apply(JFunction0$mcV$sp.java:12)
at scala.util.control.Exception$Catch.apply(Exception.scala:224)
at org.nlogo.api.Exceptions$.handling(Exceptions.scala:41)
at org.nlogo.job.JobThread.run(JobThread.scala:66)
I'm not confident in my answer; however,
If you look at the code (updated Jan 14, 2017) (https://github.com/colinsheppard/time/blob/master/src/main/java/time/datatypes/LogoSchedule.java):
TickCounter getTickCounter(ExtensionContext context){
if(tickCounter==null){
tickCounter = context.workspace().world().tickCounter;
}
return tickCounter;
}
We see that the timer is getting the workspace's world's tickCounter.
If we look at the netlogo website for updates (https://ccl.northwestern.edu/netlogo/docs/transition.html), we see that:
One of our goals in NetLogo 6.0 has been to make it easier to develop
extensions and easy to develop more powerful extensions. To that end,
we’ve bumped the extension API from 5.0 to 6.0. Existing extensions
will need to recompile changing the “NetLogo-Extension-API-Version” in
their jar’s MANIFEST.MF from 5.0 to 6.0.
Some of the changes we’ve made to the extensions API include :
org.nlogo.api.Context now allows access to the current world and
workspace objects without requiring a cast to an
org.nlogo.nvm.ExtensionContext. org.nlogo.api.Workspace has been
introduced as a stable API for extensions to depend on. A NetLogo jar
is now available from BinTray. For a full list of changes between 5.0
and 6.0, please visit our Extension Transition Guide on GitHub.
That being said, I think the source code for the timer extension hasn't done the migration to conform to the new updates. You can see that it explicitly mentions the ExtensionContext.
Unfortunately, I believe the solution is to update the timer source code and commit.
I'm afraid I can't tell what the problem is from the error statement posted. The time extension is in flux right now because the NetLogo development team is updating it for inclusion in future releases of NetLogo. But they are not done and not all the bugs are out.
I am using Colin Sheppard's version at https://github.com/colinsheppard/time
It has been reliable except for the discrete event simulation primitives. The date/time utilities and the time series tool work, but we know that the discrete event scheduling does not work under NetLogo 6.x. If you want to use the discrete event scheduling, I'm afraid you'll need to be patient until the NetLogo project gets their version fully debugged.
I temporarily put a fairly comprehensive example code here:
http://langrailsback.com/file-transfers/
It includes Colin's version of the extension.
So I am converting a project from Unity 4.x to 5.x and there are a number of functions that the Unity compiler is warning me that are no longer supported or are obsolete.
My question is do these functions still work? (even though they are marked as obsolete)
I know at some point they need to be updated to the newer API but for the moment I just need to fix the bugs so that the game works. Are these functions still usable? or are they potentially the source of runtime bugs?
Thanks
All obsolete functions has been replaced with new functions. So should take a backup and update your project. Go to Assets->Run API Updater, if your project in not getting updated automatically. Dont worry unity will take care of most of the things.
Yes, it's still work ! They just only warning it.
But i suggest you should change for better result, Unity 5 will update you code from old project, then you should change it following warning, just replace
using "xxxx" instead.
to the current context.
I upgrade facebook unity plugin from version 4.2.4 to 4.3.3 yesterday.
For the old version, I just add the jar file in project/plugin/Android and add some specific code to use it.
As for the new version, it just give me a whole facebook android project, what am I supposed to do with it?
Compile it to an jar and use it like before?
Export my project and also with FB project then package it in Eclipse?(which is super waste of time everytime)
In fact I tried both:
1 . this is not works anymore, result in some resource id errors.
2 . I did make out a package, but it can not login like it works before in 4.2.4.
Does anyone meet same problem like I did?
I really think A sdk should not give whole prject out, because as a running project, there is too much sdk to add in, we dont have to much time to deal with each plugin everytime. A big company like facebook should make things easier.
BTW: the instructions on Facebook page is old, I could not get useful information from them.
You should be able to just "Build and Run" with the new 4.3.3 version (if you imported the package and left the structure as is. Be sure to clear out the old Facebook SDK before you import this one.) Unity would automatically compile it in with your project.
To answer your questions on why we did this:
The reason why it got switch away from a jar is that in the older version when it was compiled to the jar, it meant the R class had hard-coded resource ids at compile time (of the jar). Unfortunately, when other plugins were introduced into a project, it reorders the resource ids but doesn't adjust the R class within the jar. This would break integration and make integrating Facebook with the other android plugins useless.
The source of the android files were packaged along with it because several developers requested more ways to edit the code to their needs. There's several android plugins for Unity out there and while we do our best to make sure our Unity SDK plays nice with them, there can be cases were a developer would like extra control on how they merge together.
With that said, since you upgraded your project from 4.2.4 to 4.3.3, did you follow the changelog here: https://developers.facebook.com/unity/change-log-4.x/#131013?
Basically what happened was that since importing a package doesn't let us delete old files, there was no way to clean up projects that used the jar method. Keeping them both in the project breaks the android build. This is only a one time migration that should happen again.