I'm porting a game from UT3 to UDK. One of the classes is a subclass of AnimatedCamera. However, AnimatedCamera seems to be missing from the UDK, as the compiler kindly tells me:
Error, Superclass AnimatedCamera of class ZCam not found
Where did AnimatedCamera go?
It looks like it has been removed from the engine. I just looked at a recent code drop. I'm not sure why they've removed it; but, if it's important to your project I would suggest re-implementing it.
It derives from camera, which appears to be intact in the newer versions of the engine. I wish I could help more specifically, but our version of the engine is older and heavily modified and I don't directly deal with camera animations :)
But, you're not crazy, it was removed.
From what I've seen, it's just a method of playing CameraAnims. As such, moving over the functionality shouldn't be too difficult.
Good luck!
Related
Did anyone has the comparison between these two libraries (Combres2 and SquishIt)? If one library is better than another one, I also want to know the reason for that.
I found the article said that Combres2 has a better compression than SquishIt. But it is almost a year ago.
http://blog.buzzuti.com/post/Combres-vs-SquishIt-e28093-A-battle-of-Minification-Combiner-and-Squishing-in-generale280a6.aspx
One thing to make note of is that SquishIt works in a different manner than Combres2, so it isn't a simple who produces better minified code.
SquishIt works very nicely with T4MVC, which you won't get with Combres2. On this basis alone I'd tell anyone to use SquishIt. Additionally, SquishIt is not xml config file based, which allows for a lot of flexibility. In fact, you could theoretically make an xml config file and mimic Combres2 if you really desired it.
In terms of minification SquishIt is actively developed, which means that if new methods to minify scripts are created you'll be more likely able to leverage that as well. Currently it supports JSMin, YUI, MS Ajax Minifier, Closure Minifier, or even no minifier.
Update 1/18/2012: There are now many other alternatives out there aside from SquishIt and Combres2. For starters, Microsoft is creating there own system for the next release of ASP.NET 4.5. Cassette, similar to SquishIt, and RequestReduce, which is quite different than anything else by automagically doing everything for you.
I'm a fan of SquishIt.. even though Combres and SquishIt both (optionally) use the YuiCompressor.NET library (which I am biased, for ;-) )
Being a fan of Justin Etheredge, I recommend/use SquishIt.
The reasons to one library is better than the other (for me) is if the final result is NOT a break code and still working.
I have test and working with the Microsoft Ajax Minifier, and I assure you that is working absolute correct - can even minifie the jQuery library with out any issue.
http://ajaxmin.codeplex.com/
http://aspnet.codeplex.com/releases/view/40584
documentaion:
http://www.asp.net/ajaxlibrary/AjaxMinDocumentation.ashx
Now if a library is one year old this have nothing to do, because they just working on javascript code that have some standards some years now.
To point again out : the better is the one that product minimum code that is still working under very complex javascript functions like the one jQuery have.
One note:a minified library can minified a full set of files at ones, do not try to minified one by one and them add them to a single file, this is not working.
This is meant as an answer to the 'Microsoft Ajax Minifier' recommendation, and a general warning for those that do so. As my reputation is a mere 41, I cannot add the comment there, where it should go. :(
For our team, the native C# VS2017 Microsoft compression (which may or may not be the same as the one labeled as 'Microsoft Ajax Minifier') failed on the css function 'calc', and badly.
That was a bit tricky to track down, since the error (obviously) only occurs during minification. And since we were minifying based on environment (interwoven with Release, Debug), that meant the calc bug (by default) never appeared on local. It just magically appeared when we pushed to production... and only on pages that used the calc function.
(Definitely agree that minimum code add-on is fantastic. But the native minifier can be faulty. So proceed with caution.)
If you are not using 'calc' (and you are noticing no other issues), then likely your team is fine with the default minification tool.
And of course, Microsoft could have fixed the bug since we discovered it. But bug reporting through msdn doesn't always lead to resolution of the issue. :(
There may be other issues. But in our case (since we use 'calc'), that was sufficient to have us investigate other minifiers, and SquishIt has been our team's choice. We had not looked at Compres2 at that time. Up until now, we've been very happy with SquishIt.
Side note: I'm in the middle of investigating minifiers again because of some sort of 'collision' between jQuery 3.6.0 and SquishIt for VS2017. (with no 'collision' between jQuery 3.4.1 and SquishIt, VS2017). Early stages of problem-solving process.
Best wishes and happy coding,
Michael M.
I started looking at Silverlight.FX by Nikhil Kothari to replace Prism/Unity with our Silverlight 3 project.
So far I like the code layout and structure. It looks well thought out.
But I can't get a lot of the samples working due to a System.Reflection.AmbiguousMatchException. Anyone else seeing this? Should I not be using this framework with Silverlight 3?
I'm using the framework with Silverlight 3 without issue. Referencing the pre-built dlls works for my project but I haven't tried compiling the source myself. Have you tried using the dlls?
After some heavy debugging this error is coming because some of the class names that Nikhil used I believe are now in Silverlight 3 beta 1. In the TaskList example the ListView's DataTemplate has a HoverEffect
<fxeffects:ColorFill FillColor="#406795D1" Duration="0:0:0.25"/>
This is the one causing all the problems I saw. Removing this took away the AmbiguousMatchException.
Well, that is avoiding the problem, not solving it. It looks like the problem is much deeper, and anything that uses classes that derive from the Effect base class is broken. That makes the use of Silverlight FX pretty boring.
I have tried to use the lib in the past, and had issues with it. While Nikhil Kothari is amazing in the things he has worked on, and his technical abilities, I find that he is not so responsive to solving issues (BTW, someone already posted this problem on his blog, without his response). I do not want this to sound like a knock on Nikhil, it is just something you need to consider when using open source for real-world projects.
I sure hope someone can figure out what the deal is with those classes, I have spent many hours debugging, without solving the issue.
I tried the Amazon Store sample and the TaskList sample using the latest version of the library (3.1 built against SL3), and samples seem to work fine, including the ColorFill effect.
I did rename the Effect class to AnimationEffect which you'd need to avoid the ambiguous API compile error you'd see if you tried to recompile the sources... but precompiled binaries would have been fine. Not sure I see why you'd get a runtime reflection issue however.
Sorry, I know it can be frustrating to not see a response/fix immediately, but theres just too many things going on esp. before a release. My hope is having the source around at least enables you to debug into/break into so at least one is not completely blocked. Yes, I realize its suboptimal, but at the same time it is the reality, as Noam pointed out... :-(
I'm having trouble finding any resource for adding ctrl-z undo capability to a Flex RichTextEditor control (a lack it apparently shares with other Flex text controls). I'm baffled that it's not in the native forms because it's such a fundamental capability, available in even standard browser text controls I believe.
Any mention of this issue on the Flex sites (there are several) conflict; one says the issue is "Closed" and the resolution is "External" (whatever that means).
Does anyone have any insight to offer? I've got an app the heavily requires extensive text editing. Flex in general works nicely, but this trivial lack is just about fatal, as anyone would imagine.
An example using the Flight Framework to easily implement undo/redo can be found here: http://www.xtyler.com/code/163
I've read elsewhere -- in fact, in the answers to one of my questions on SO -- that the issue is not going to be resolved in Flex 3. Which seems to be correct since we are in 3.2 or maybe even beyond that, and there's no undo in sight.
I was brave/stupid enough to implement an undo-redo in this component myself. At that time I was working on Windows. Now I'm on OSX and I realize just how non-cross-platform my solution is. The very statement of the problem (adding ctrl-z undo capability) is a large part of the problem (OSX has control AND this Apple key thing). Now I have to check how much work it would be to make the thing cross-platform... could be trivial.
By amazing coincidence, just today I've been thinking about NOT using the RichTextEditor but rather something external (FckEditor comes to mind) because the RTE leaves so much to be desired (hence I arrived at your question). I've worked with the RTE a ton and gotten it to do a lot of what I want, but I still wonder why they didn't "finish" this component...
Flex 3 controls do not natively support undo/redo. Here are a couple of libraries that may be of interest to you:
flexundoredo
as3undohistory
We have an internal Flex application which has been designed more through feature creep than by any kind of clear vision. It's basically a kind of CRM and reporting system which utilises quite a lot of Flex components (trees, graphs, custom components, datagrids - all sorts) and talks to a .NET webservice backend.
It was initially my first Flex project and has been written with the bodge, hope and repair kind of style you might expect from a prototype. However, it's now grown to the point where we'll be adding other (neophyte) developers, but it might not be impossible for one person (sigh, probably me) to rewrite the current snapshot in about a month. So, at this stage I'm thinking it might be a good idea to consider a new version implemented in the Mate framework.
I don't need advice on which framework to choose, what I would like is advice on how to go about refactoring the project. It seems like this will involve tearing everything down and pretty much starting again (which I'm not totally averse to), but does the framework have to be built in from the ground up? Are there any known and recommended methods of attacking this kind of problem?
I did a similar thing a couple of months back. What I did was that I created a new package structure and moved all "ported" code there as I went along. I started with the overall view structure and moved my way towards the "branches". The new code referenced the old where needed, but no old code referenced the new. Having a new package structure helped in making it clear what had been ported and what had not, and it was also easy to see when I made progress.
I've been working on a project called Axial that converts MSIL (compiled C# or VB.NET) to JavaScript. There are a few samples of working code, but some common situations don't work properly. (The current release doesn't work in production mode and the SVN code doesn't work in debug mode but is much cleaner.) I've heard from quite a few people that they hate writing JavaScript, so I know the project has some merit, but I'd guess that attitude is less prevalent among the SO community.
Assume the product works perfectly and smoothly, so your JavaScript works 100% of the time and a Visual Studio plug-in makes sure you're using the product correctly. Is this something you or your organization would use? What features other than straight code translation would interest you?
That sounds very much like a .NET-centric version of GWT. I guess the questions are:
Have I understood the purpose correctly?
Do you believe you can overcome any roadblocks that GWT users might stumble over?
Is there enough benefit in having a .NET version as well as GWT to make the duplication of effort worthwhile? (I'd personally just write the Java code and use GWT, but I know not all .NET developers know Java, and you may already have common library stuff you want to port.)
Do you have any useful ideas you could contribute to GWT? :)
(Disclaimer: I work for Google, but haven't used GWT myself.)
Been done (pretty much).