I’d like to clarify guys that I did reach out to the seller (technically) by commenting my concerns on the products Marketplace page. To their credit, the seller has since changed the title of the plug-in and also told me they didn’t have the ability to issue a refund, so told me to reach out via the refund page. The seller did also have a video of how to use the plug-in on their page, but it didn’t show any indication of how it was working under the hood.
@Unreal_Josh - Thanks, I reached out to you guys via the Marketplace refund form and explained my concerns there. As for the Plug-in itself, it seems some users are happy (or oblivious to) the implementation and it obviously works well for them - but IMO it’s just going about it the wrong way and wasn’t what I was looking for.
@SE_JonF I’m under no impression that sellers are out there to screw folks over and as I said, I take no issue with the seller. It’s either they aren’t experienced enough or didn’t know about the existing engine code they could have hooked into. The plug-in in question would need to be completely started again if they chose to re-do it the way I suggest. I bought the plug-in purely because I wanted it to save me time implementing things myself.
There are some excellent Marketplace plug-ins and content which are very well put together - however I’d like the Marketplace to have a suitable refund system in place where I can take the risk to buy a product, and if it doesn’t work out for me I can refund it without issue. Blueprint systems in particular have a tendency to be created by those with little real programming knowledge, and do some pretty horrific things.
I can’t really see a way to implement a refund system like that which doesn’t result in massive amounts of piracy, so I guess for the meantime I’ll just have to stick to buying products from sellers I know.
I don’t think we should be too worried on that account, as long as the current system stays in place.
If the user requests a refund and it’s baseless (e.g. all the info was available on the store page, asset works as expected) Epic contacts the seller and asks them if they’d like to allow it anyway. I’ve had one request that differed there and it was where the user was an absolute beginner and didn’t know what they were doing and so Epic insisted on refunding them as it was never going to be of use to them. Either way I always authorise it and I think I’ve done a total of three refunds ever.
I assume an automatic system would be abused. Then again I’ve been tracking the natural byproduct of dissatisfied purchasers, which is piracy. The only version of my assets on pirated sites are two very old copies from launch. So in general I think we’re OK. There’s certainly a lot less piracy from the UE marketplace than there is from the Unity marketplace, which is a good indication that our users are all pretty happy with the arrangement.
Edit: I’ve just realised that you posted as a buyer, not a seller. I think a simple “can you let us know why you’re refunding this product” exit survey is probably enough, and make it require sign-off by the seller and Epic with an explanation by the seller if refusing. So, more legitimate refunds in the case of poor assets, no worries about habitual refunders.
I have felt the same, thou in my case the word “know” for me, is to look at sellers with participation in the community. There are sellers that even don’t drop a line here at the forums helping people, which makes me think they are just after the sales here and nothing else. I want to contribute buying from with people I feel are giving more to the community in return than just selling assets inside MP. Up to now, 80% of everything I sold I have used the money to purchase assets and from my experience the worst assets (20%, and worst I mean with issues, from these 20%, 4% are unusable) came from unknown people=non participant people in the community, well that cash will have a better use next time.
That’s my point too (although i do realize that there are better places to give more “concrete” examples though, but i wasn’t aware of their existance tbh), the current system is helping us in that regard but there’s always room for abuse, the idea is to minimize those … or at least be aware of their existence. As i said… the buyer-seller communication doubles as a protection layer against pirates or some ill intentioned people out there…
As you said though… i much prefer to have the communication layer so at least i can see why the people are opting out of our plugins, that way we can check if those claims are good feedback. Ithink that people are in their right to request a refund too, but we lose a lot of “magic” by removing that last layer.
I understand this sentiment as a buyer, but, as a future seller, I would hate that to happen. I am right in the process of submitting a code plugin and I admit I have violated a few of the Unreal guidelines. I did not do that light-heartedly. My coding style is the result of 20+ years of C++ programming and I do understand the value of having shared guidelines, especially when a potentially unlimited number of people are involved. However some of the Unreal guidelines not only promote baroque programming and/or are based on outdated misconceptions, but plainly contradict the guidelines promoted by language mainteners themselves. Things like “you should not use auto” should really be reconsidered in 2018. But I am digressing. I read that a plugin is being flagged as “bad” because it used int instead of int32. Well, that’s insane. I do hope this mindset is strongly opposed by code plugin developers. Don’t get me wrong. I’m not saying that everyone should code as they please, but my point is: 1) strictly abiding to guidelines does not (automatically) mean your code is good; 2) not abiding to guidelines does not (automatically) mean your code is bad. I’m ok with a stricter approval process that takes code quality into account, but having the marketplace maintainers take the role of “code police”, as the OP seems to suggest, is not a good thing for everyone involved: sellers, buyers and Epic itself. Just my opinion.
To be fair, that coding standards page hasn’t been updated in literally years - the auto keyword is now used in various default plugins that come with the engine. The reasoning wasn’t unsound though; in ~2015 when that document was last properly updated it was more difficult to assume that every environment would support C++11 features - as it happens, even Visual Studio 2017 still doesn’t fully support C++11, there are one or two minor holes in that regard.
Of course, it wasn’t my intention to say that the guidelines are “wrong” and I agree that they were even sensible at some specific point in time. Some of the guidelines have a direct connection to the future evolution of the code base (for example the naming of classes), so it’s good to have them in place and be respected. Other guidelines have no such impact. While it might still be good to have them too, especially for newbies, I believe that having guidelines cast in stone and be strictly enforced is going to limit the progress of the programming styles and the adoption of new programming idioms.
To be honest I’m quite OCD when it comes to programming style/syntax so that’s partly on me - but honestly I hate the use of auto in all cases, and I really don’t like curly braces on the same line, which this plug-in also had.
My complaints were regarding the stylistic choice than syntactical ones, which I agree you can’t really fault people for.
Playing devil’s advocate here but…
It’s because of the pointer. Granted… we know that the Cast returns a pointer of the Template given to the function, but that’s not obvious in the second example, hence auto could lead to potential misunderstanding.
I personally don’t use auto more than on a few iterators.
Thats a nightmare… auto feature is one of the oldest things planned to be added to C++ (the idea was there at 1993, with even the identifier “auto” reserved for future use) and really it is good for fast plain code or for test code, it might lead to unforeseen behavior of code and even assertion errors with more frequency, hence something you will only catch on testing while it could be avoided during the development at compilation time.
I’m totally with Bruno here. I use auto regularly and I did not see any incread occurrences of unforseen behaviour or assertion errors. By the way, your statement about auto being one of the “oldest things” doesn’t sound right to me. Do you have any evidence? As far as I know, C++ had the keyword auto since its beginning in 1983, although it had a different meaning: it was used to declare non-static local variables (the so-called “automatic variables” Automatic variable - Wikipedia). Since its use was optional and largely redundant, no-one used the keyword, so it was deprecated (I believe in C++98), while keeping it reserved. It was not kept reserved because another meaning was planned at that time and the same fate occurred to export. Eventually, in C++11 the keyword was recycled for the current meaning to avoid adding a new keyword.
I had a book at home from the C++ 2.0 reference back from 1993… it is not here anymore since I donated to a library museum 5 years ago, but you might be right about it being even older, I my have sounded a bit imprecise here, there were discussions on white papers at that time about the auto feature as it is today, but didn’t advanced. Also, I do know people with large experience will not produce code using auto with errors, but newbies might get into the trap. Readability for me is one of the most precious things in C++ code and as I stated, a single piece of test code might be clear enough when using auto, but I don’t think it will go well with large code… maybe I should get used to it… but after 28 years programming with same practices it is kinda annoying trying new stuff that my not add much to my peers.
And I should have awaked a bit earlier today, was lazy and sleepy, and my english was still dreaming, sorry for the lack of better words to express myself.
[USER=“1219630”]Iron G[/USER] we will get back into topic.
Even when a product on the market that I bought had many videos, as it still wasn’t enough. Because I recently bought some fast movement system as the developer never explained how it works. I had to figure it out and when I did. This movement system is over price of 10 dollars and it should be 5 at most or free at the lack of development of a long period of time. This product has been abandoned and I bought it. WOW! EPIC! WOW!
What about products that have been abandoned on the Marketplace?
These items/products need to be temporarily be taken down until the developer updates their product as it will tell Epic’s Marketplace System this item/product is still active until it’s 100% completed with a check-off list for Epic Employee to be approved. If they’re taking a Percentage of all Developers who use Epic Marketplace or Unreal Engine 4. Then they should at least look at what’s going on in **their Marketplace. **
This is something I figured out as well. Even if it states its compatible with 4.25, it still can be old as hell and within the overall quality or functionality may be of that year of release. Is there any option to see when something was first delivered to the marketplace and some update/changelog per marketplace item if things changed, got fixed? It’s one big plus from the Unity Marketplace that adds a lot more information for the buyer.
One thing I do for a couple of months now is to search by using the “newest” filter first and second, checking if there are any reviews, content discord and frequently answered questions about the product. In the best case, it has a discord or at least a forum-thread for more complex systems. Of course, this does not really apply to game assets. There, I would love to see some policy that content creators not only have to provide a showcase of items but at least some wireframe and one UV layout example. I had multiple items bought where I literally had to recreate these from scratch and just used the original asset as a grey box.